Omnimaga
Omnimaga => Completed => Our Projects => BatLib => Topic started by: Xeda112358 on January 26, 2011, 09:51:49 pm
-
This topic is meant for the discussion of bugs in BatLib. Currently, I am aware of three bugs (off the top of my head):
-The fonts don't seem to work in OS menus
-GetStats is not liking archived variables (it crashes when used on them)
-It crashes randomly, even on BASIC code.
Here is a screen shot of that last one. The first crash happens after 19 iterations, the second at 2346, the third at 827, and the fourth at 799.
-
I was tempted to change the topic title to Zerglings.
On-topic, I hope you don't have too much troubles fixing the bugs. Should we use this thread for bug reports if we find any when testing?
-
Hmmm does the same program crash at the same spot every time you run it? If so, it might be an issue with the compiling? If it crashes randomly, maybe an issue with interrupts?
-
Well, the only code that was being executed in the first ones was BASIC code. The last one included the sum( command which is all that should be affected by the parser. Also, it runs through the loop and seems to crash randomly. I had it run over 10 000 times before it crashed.
@DJ Omnimaga: Yeah, I think this should be the bug report place.
-
Haha, so the bug is fixed! I edited my last post in the "SpriteLib" topic with the updated version.
The problem was simple and it isn't the first time I made the mistake! I forgot to disable interrupts before using SP!
I tested it and it got over 200 000 iterations without crashing, so I think it is safe ♥
I think it is almost out of Beta mode now \(^_^)/
-
lol, poor SP. * ZTrumpet wonders how it's doing after being abused like that.
-
Oh, SP will be fine... after a long recuperation and a few visits to psychiatrists...
Anywho, the new bug is with command 64 in the yet to be released version.
It is the program CopyProg, but when I run it, if the var to be created has a name >4 chars long, it throws a syntax error. It still creates the var as it should and if it is 4 chars or less, it has no problems.
-
I fixed another bug that was plaguing the dim(41 command (GetStats), yesterday. I couldn't find the problem until I was working on ReCode yesterday and it kept crashing whenever I tried storing to Ans. I opened the debugger in Wabbitemu et voila! The RAM area I was using to store the value of the stack pointer was getting corrupted whenever a new variable was created, apparently. Too bad nothing about that is mentioned in the system call documentation (that I read). I moved the location a few months ago into OP5 so that I could use OP6 is temporary RAM (it is very temporarily used) because I figured that since BatLib uses very few bcalls, OP5 wouldn't get affected... Oh well, now it is in a safe place in RAM that doesn't get affected by the OS.
-
Nice to hear more bugs are getting fixed, also I'M glad to see you back. :D
By the way any idea if you can fix that While End bug you mentionned in another topic?
-
Yep, I'm working on it at the moment. It actually isn't that difficult to fix, I just never thought about the possibility of the bug until after I made the code. I will just use a counter to find Then, Repeat, While, and other such statements that increments and have it decrement every time it hits an "End" so that when it reaches 0, that is the proper End to end at.
-
Ah ok, I hope it isn't too much hassle to fix X.x
-
Okay, that little problem was fixed, so now you can nest blocks that use End ^-^ So pretty much the following is now valid:
While xx
If yy
Then
<<stuff>>
End
End
-
I found a bug. If with dim(29) it draws out of bounds and you get an "undefined" error (This appears to only happen when y is too high). When you go to Y= you get e ton of garbage text and then a ram clear or a battery pull.
-
Okee dokey, that problem is fixed, now. Should I upload it now or wait until the next update and trust nobody uses rectangles too large?
-
Wait I would vote. I can just include bounds so the rect never goes offscreen.
-
What happened was I had an error handler that made sure the X and Y coordinate never went off screen, but I forgot to check the width+x and height+y :D
-
I realised a while ago, that BatLib always made real outputs in multiples of 2 digits (so sometimes there would be a leading 0), but I didn't realise that the calc would see 0100=100 as false. Since adding in the ReCode log(Text( function, I simply rewrote the code a little and now the outputs are not multiples of two digits. Also, I noticed in my latest demo release that a mysterious last digit was being read and output, so I fixed that (it was outputting that the number was one digit longer than it actually was). In the next release, those bugs won't be there :)
Also, BatLib will automatically run in 15MHz mode if it can. This means ReCode now starts in 15MHz mode if it can. Should I make ReCode start at 6MHz instead?
-
I managed to fix dim(54 so that it isn't buggy when reading the last database entry (or last line in a program). Pretty much, here is what dim(54 does...
Because it is easier to understand, I will use the example of reading a line in a program. Newlines are the token 3Fh or 63 in decimal. Setting the line byte as 63 will thus let you read lines in a program. If you try to read line 1, you will get the first line, 2 reads the second, et cetera. Before, since it wasn't exactly designed to read lines in programs, it needed a line token at the end of the file. Also, there was no protection against reading past the file.
Now, the command is fixed up so that if you try to read past the file, you get the last line and you do not need to waste a byte by putting a line token at the end.
In case anybody is curious:
41 is the space token (so you can read between spaces). This is useful if you need to separate words in a sentence ^-^
63 is the newline token. Useful for reading lines in a program
88 is the token for X which is useful for equations, maybe
For others, you can use dim(66, to get the value for a token
-
Um, I found a bug with RecallPic in ReCode. The problem? Instead of typing in 78 (ld a,b) I typed 18 which caused everything to mess up x.x Just goes to show how 1 byte can cause a crash XD So, anywho, here is the fixed version...