[WP34s] Bugs in V3.0



#69

It's better to start a new thread, because the buglist in V3.0 seems to be endless ... :-(

Next bug: the register browser (with [f][EXIT]) doesn't work correctly anymore - first it shows RgX, but with arrow-up/down it immeadiately switches to R00 or R99 and you can't get back to the stack registers anymore.

Edit: and now I found another thing, but this is the same in ALL previous versions I have (back to SVN 1294): when I'm in the register browser and switch to the flag browser (with [->]), then I just see "not numeric" for every flag number I chose!?

Maybe I misunderstand something here, but what's the purpose of this flag browser when I don't see which flag is set or cleared?

(but as I already said, it seems this feature has never worked)

Edited: 7 Nov 2011, 7:25 p.m. after one or more responses were posted


#70

Might be good to have this kind of detailed testing discussion on the sourceforge forum:

https://sourceforge.net/projects/wp34s/forums/forum/1342471

You can create a new "V3.0 bugs" topic under "Open Discussion".

P.S. I'm enjoying these discussions between Franz, Marcus, Walter and Pauli and will follow them wherever they happen I'm just concerned that: a) not everyone feels the same b) it'll be easier to search the discussion if it's stored in sourceforge's forum.

Edited: 7 Nov 2011, 7:13 p.m.


#71

Quote:
Might be good to have this kind of detailed testing discussion on the sourceforge forum:

https://sourceforge.net/projects/wp34s/forums/forum/1342471


Yes, in principle you are right, but there's only one big problem: with my old internet notebook (Win98 + IE6) I can't create an account on sourceforge - I've already tried it many times. :-(

Franz

#72

Do you remember the old Beatles tune "Fixing a Hole?". Seems to be the right soundtrack here.

I already found some of your bugs. Maybe I was too tired yesterday to check them in or recompile the binaries. I'll report back when they are fixed.

Yes, WP 34S is a huge construction site at the moment. Taking the elevator may make you drop down its shaft instead of taking you to the desired floor. Your bug reports are very welcome at the moment. You know my email. If it's getting too detailed, contact me directly.

#73

Quote:
Next bug: the register browser (with [f][EXIT]) doesn't work correctly anymore - first it shows RgX, but with arrow-up/down it immeadiately switches to R00 or R99 and you can't get back to the stack registers anymore.

This one was fixed last night but not committed. Typing a '.' toggles between X and the local registers if there are any defined at the moment.

Quote:
Edit: and now I found another thing, but this is the same in ALL previous versions I have (back to SVN 1294): when I'm in the register browser and switch to the flag browser (with [->]), then I just see "not numeric" for every flag number I chose!?

Maybe I misunderstand something here, but what's the purpose of this flag browser when I don't see which flag is set or cleared?

(but as I already said, it seems this feature has never worked)

This is a misconception. The register browser does not show any
Flags but accesses the Flash backup instead. On the hardware the backup area is always valid but on the emulator you need(ed) to have a valid wp43s-R.dat file for this. I've automated the process: If no backup exists, the backup area and the RAM contain the same data when the program starts.

I changed the display in the browser to "Bkup" to make this clearer. Revision 1847 contains the changes.


#74

Quote:
This is a misconception. The register browser does not show any
Flags but accesses the Flash backup instead.

Ahhh, so my "Maybe I misunderstand something here" was the right guess. :-)

#75

Since yesterdays release SVN1879 there's a serious new bug.

Suddenly my polynomial solver stopped to work correctly, and I could track it down to the SLVQ command, which now seems to clear the return stack and immediately stops the program with the program counter at 000.

The only difference for SLVQ in xrom.wp34s that I can see is this new XLOCAL command (instead of the previous LocR 04), so I guess the problem is anywhere in these new "private XROM local registers" introduced in SVN1879.

And I find this XLOCAL also in a few other routines in xrom.wp34s, so I guess these commands will also make problems!?

Franz


#76

Thanks for the pointer. I need to check this out.

Edit: Should be fixed now (was a bad one!)

Edited: 18 Nov 2011, 11:06 a.m.

#77

Has there anything changed wrt. the shortcut-keys [A]-[D]?

Suddenly (with todays SVN) [A] doesn't execute LBL A anymore, but just executes Sigma+. :-(

Franz


#78

Franz, I'm working on this and may have broken it. I'll check it tonight.

Edit: should be fixed.


Edited: 23 Nov 2011, 3:14 p.m.


#79

Quote:
Edit: should be fixed.

Yep, working again, thanks! :-)
#80

Next bug:

CPX RCL * doesn't work anymore (the * is just not accepted after CPX RCL)

CPX RCL + doesn't work, it gives C RCL K

I guess I should better just ignore all new SVNs ... :-(

Franz


#81

You are one of our most valuable testers. Keep going!

I have to check this out.

EDIT: This was a stupid attempt at an optimization which didn't save a single byte but broke things. :-(

Edited: 26 Nov 2011, 5:43 p.m.


#82

Quote:
This was a stupid attempt at an optimization which didn't save a single byte but broke things. :-(

Well, too much 'optimization' isn't always a good idea. ;-)
#83

And the next one:

The stack is: X:1 Y:2 Z:3 T:4

After executing CPX RCL X the stack is: X:1 Y:1 Z:1 T:2

After executing CPX RCL Z the stack is: X:1 Y:2 Z:1 T:2

Slowly I'm wondering what is still working at all, the current SVN version is in fact absolutely unreliable and thus unusable. :-(

Franz


#84

I don't think these are any new bugs. I assume this has ever been the way you found out.

The problem with cRCL Z seems to be that the stack lift is performed before the command is carried out which leads to the result you see. In the case of cRCL X, there seems to be an additional issue with the direction of the memory copy. This seems all to be a little bogus to me and I'll check with Pauli what can be done about it. It's certainly not a new problem.


#85

Quote:
I don't think these are any new bugs. I assume this has ever been the way you found out.

Well, it's at least new since 2.3 (or 3.0).

I've tried it with the last stable 2.2 version (SVN 1797), and both commands work correctly as they should, and not like in the new 3.0 SVNs. But even my last 3.0 SVN 1865 (which I thought would be a correct release) shows this new buggy behaviour, so it would be needed to go back even before 1865 to find where this bug (and it definitely is one!) has been introduced.
Quote:
The problem with cRCL Z seems to be that the stack lift is performed before the command is carried out which leads to the result you see. In the case of cRCL X, there seems to be an additional issue with the direction of the memory copy. This seems all to be a little bogus to me and I'll check with Pauli what can be done about it. It's certainly not a new problem.

Well, I don't really care about stack lifting or not - a cRCL Z should put Z and T in X and Y, and a cRCL X should do the same (and so move X and Y to Z and T). I think there's no discussion about this.

Edited: 27 Nov 2011, 9:01 a.m.


#86

I agree that the behaviour is wrong. We have to investigate the reasons. It's most certainly not a change in the keyboard engine but some other code change. Thanks again for finding this out.

Edit: On my V2.2 (1782) 30b, cRCL Z returns the same (bogus) values you are reporting.

Edit 2: The code wasn't using intermediate variables which caused the stack lift and the recall to interfere if the source register pair lived on the stack. Should be fixed now.

Edited: 27 Nov 2011, 10:19 a.m. after one or more responses were posted


#87

That's a real old one: even on my v2.0 build 1108 complex RCL Z returns these wrong values. It does a proper stack lift, however, so there are 1 2 1 2 3 4 in levels X through B (guess what stack size I use ;-)

#88

Quote:
Edit: On my V2.2 (1782) 30b, cRCL Z returns the same (bogus) values you are reporting.

Yes, you're right, now I've tried it again with all my older versions and the bug indeed is in all versions.

Don't know what I've done wrong in my first trial!? :(

#89

I've just checked in my bugfix.


#90

Are now both bugs fixed, also cRCL X ?


#91

It was all the same bug. The code was using pointers to the source registers and then doing a stack lift which moved the data away before it was accessed. "Shift happens." :-)


#92

Ok, then until the next one ... ;-)

#93

If there is going to be a bug fixed V2 (old keyboard layout), I would be pleased to be pointed to it.


#94

Alexander, I don't have a problem if you take care of this. Here is the code I changed:

xeq.c:


static void do_crcl(const decimal64 *t1, const decimal64 *t2, enum rarg op) {
decNumber r1, r2;

if (op == RARG_CRCL) {
decimal64 x = *t1;
decimal64 y = *t2;
lift2_if_enabled();
regX = x;
regY = y;
} else {
... // no changes in this part
}
set_was_complex();
}


#95

Quote:
Alexander, I don't have a problem if you take care of this. Here is the code I changed:

Well, I doubt that many here (including me) have the environment to change and compile the WP34s project themselves.

So it would indeed be a good idea to release an updated/bigfixed V2.2 version (maybe the last stable SVN 1797 would be a good candidate).
#96

Thanks for the honor but I have absolutely NO idea how to do this. And frankly, even in my wildest dreams I don't picture myself learning to read and write code or install IDEs and compilers on my netbook or iPhone... ;-)


#97

I just wanted to add that I'm perfectly happy with my V2 version as it is. I will most probably never ever encounter this bug while using it - or any other, for that matter. So only if one fine day you definitely have no better things to do, only then you may consider working on V2. It is in no way urgent to me and I will live happily ever after praising the WP34s in the state it is in right now! :-)

Thanks to you and the whole team for making it and for putting so much time and effort in it!

Edited: 28 Nov 2011, 10:56 a.m.

#98

sound like time to create a V2.2 branch (I know, I sound like a broken record :-)

What Revision should be used: 1797?


#99

Build 1797 is a good start. Then read SVN, especially the short release notes accompanying each build.

We will proceed with what's going to be v3.0, however, as Pauli posted here earlier already. Sorry, but we simply don't have the resources to follow two development lines at the same time - may lead to losing both tracks shortly.


Quote:
Build 1797 is a good start. Then read SVN, especially the short release notes accompanying each build.

1800 was labelled "safety checking" and appears to be the beginning of the local register code so I would start with 1798.

Quote:
Sorry, but we simply don't have the resources to follow two development lines at the same time - may lead to losing both tracks shortly.

Agreed, there should be another (group of) volunteer(s) that takes care of back-props to V2.2. I'll see if I can get around to creating the V2.2 branch this week. Then I have to re-install the ARM cross compile environment.


Quote:
1800 was labelled "safety checking" and appears to be the beginning of the local register code so I would start with 1798.

1798 was no build, it was just a source change with a macro removed.

The last 2.2 build version was indeed 1797.

My rationale is that 1798 was a zero-risk change (removed code that was #ifdef'd out) that will make merging fixes easier.


I have created wp34s/branches/V2.2 and submitted the fixed xeq.c along with an updated wp34sgui.exe.

When I'm back at work Monday (where my serial cable is) and I can test the calc.bin I'll commit that too, along with another wp34sgui.exe with the correct VERS.

We have to figure out what will be in the V2.2.zip file now. The equivalent would be everything under wp34s except trunk. Perhaps we should do something more paired down? Just the V2.2. manual, the library, DLLs and binaries?


You may need to branch the library, too.


Technically that means library needs to move under trunk. I could just make a copy under branches/V2.2 I guess it really depends on whether we think we'll have a V4.0 one day with new command mnemonics.


V4 is very unlikely :-)
At least on this hardware platform.


- Pauli


Quote:
V4 is very unlikely :-)
At least on this hardware platform.

I concur :-) The display, you know ...

Walter


If you take it seriously, the platform is inappropriate for all versions we have created so far. ;-)


Quote:
the platform is inappropriate for all versions we have created so far. ;-)

Don't exaggerate! Sitting in the corner moaning about the reality isn't the way we chose. We started with a platform featuring a mushy keyboard - now we've got a far better one. Maybe we'll even see a better display once - hope dies last ;-)

Read my comment the other way round: We've achieved results we ourselves had never envisioned before we actually implemented them.

I've patched, built and tested the V2.2 version of calc.bin. You can download it and install it with MySamba.

The revision number is 1990, which is a sub-version-ism, but it still says V2.2

I have also uploaded a new version of the V2.2 zip file, called wp34s-V22-1990.zip.

Going forward I'm open to suggestions as to what fixes should be ported over. I'd be open to doing a monthly update to the V2.2 load.

dominic

Edited: 7 Dec 2011, 12:50 p.m. after one or more responses were posted


Quote:
I haven't updated the V2.2 zip file, coz I haven't quite figured out how, other than taking, replacing the relevant files and re-uploading it as is.

That's how it goes.

I find reference to cRCL X and cRCL Z in this thread. Are those the bugs in 1797 that have been fixed with 1990? Any others?

Edited: 5 Dec 2011, 3:08 p.m.


yes, that was the only bug fixed in 1990.

are there other?


Seems like there must be some. The only thing I have noticed recently (which may or may not be considered a bug), is that when single-stepping through a program, if an alpha prompt is encountered which would normally be displayable in large font, it will instead be displayed in small font.


Quote:
Seems like there must be some.

Jeff, be nice :D :D

I dumped the commit comments into a
wiki4hp page - if you see anything there that looks like a fix to a bug in V2.2, please let me know. It think there maybe some fixes to some of the probability functions.

Quote:
The only thing I have noticed recently (which may or may not be considered a bug), is that when single-stepping through a program, if an alpha prompt is encountered which would normally be displayable in large font, it will instead be displayed in small font.

I won't be propagating cosmetic fixes.


Quote:
Quote:
Seems like there must be some.

Jeff, be nice :D :D


I intended no disparagement. If there are no other bugs, that means perfection has been reached, which seems a tall claim to make, that's all :-)

Quote:
I won't be propagating cosmetic fixes.

Understood. If I discover a defect in operation, I shall inform you.

Edited: 10 Dec 2011, 12:58 p.m.

And again something broken in the latest build SVN 1967: the quadratic solver SLVQ doesn't work anymore!

If I run it without any program loaded (i.e. after a fresh install with "Erased") it just does nothing.

And if I've loaded a program and I'm within this program (i.e. have previously switched to program mode and moved down a few steps), then SLVQ (back in manual mode) seems to execute any step of this program and thus ends up in any error message.

The same if SLVQ is used in a program: in this case SLVQ just seems to jump to any program step.

And a different problem: when I load a flash region with PRCL n, then a simple R/S doesn't start the loaded program - it works only if I first switch to program mode, make at least a SST, go back to manual mode and R/S again.

Edit1: also scrolling with [h][CAT] doesn't work with [up] when at the beginning of the list ([down] at the end works)

Edit2: all mentioned problems did not happen with SVN 1950/51 from 29.Nov.

Franz

Edited: 1 Dec 2011, 10:18 a.m.


Thanks for the report. There is certainly more broken than you have found because we did a major rewrite of label search and such to support END. This affects all programs, not only those actually containing an END statement.

Until we have ironed out this all, you should better revert to an earlier release for actual work.


Quote:
This affects all programs, not only those actually containing an END statement.

I've not yet included and END to my Laguerre solver which I'm still working on.
Quote:
Until we have ironed out this all, you should better revert to an earlier release for actual work.

Well, if I'd stay with an older stable release I couldn't find and report any errors in your new code ... ;-)

Quote:
Well, if I'd stay with an older stable release I couldn't find and report any errors in your new code ... ;-)

This is very much appreciated. I found a bug in the XROM calling code (the label in XROM wasn't found and no error thrown). I don't know if that has an effect on the other bugs found but SLVQ should work again. PRCL needed an update, too.

I won't have time to do much work on the project in the next few days but I'll try to fix the bad bugs at least.


Quote:
I won't have time to do much work on the project in the next few days but I'll try to fix the bad bugs at least.

Well, your last 'bugfix' makes the emulator now completely unusable. :-(

Starting the emulator, clicking on R/S ---> Crash!

New start, trying to do PRCL n ---> Crash!

New start, trying to solve a quadr. equ. with SLVQ ---> Crash!

Good night ---> Crash! ;-)


Quote:
Good night ---> Crash! ;-)

No crash here. I assume SVN must have messed it up somehow. :-(

I did a recompile and checked it in again. The version is 1970.

Edited: 1 Dec 2011, 7:06 p.m.


Quote:
I did a recompile and checked it in again. The version is 1970.

Well Marcus, also this new compile 1970 crashes exactly the same way as 1969, so there was definitely something "kaputt" in it. ;-)

Fortunately in the current SVN 1974 these problems have disappeared again - they are working (almost) fine.

But there's one small bug in SVN 1974 I've just found, and it's about scrolling through the catalog ([h][CAT]):

If there is no program loaded in memory, then everything works fine - scrolling [down] and [up] is working correctly and is wrapping around at the bottom and top of the list.

But if you have (loaded) any program in RAM, then going [up] in the list makes problems as soon as you reach the top of the list, i.e. your program in RAM. If you continue to press [up], then suddenly strange commands (instead of labels) appear in the list (and even 'exotic' characters), and finally the program crashes again.

These commands or strange characters look as if the catalog code would jump anywhere into the XROM code when pressing [up] beyond the top RAM program!?

So I guess I've finally found a way of 'Synthetic Programming' on the WP34s ... ;-)

Franz


Quote:
But if you have (loaded) any program in RAM, then going [up] in the list makes problems as soon as you reach the top of the list, i.e. your program in RAM. If you continue to press [up], then suddenly strange commands (instead of labels) appear in the list (and even 'exotic' characters), and finally the program crashes again.
These commands or strange characters look as if the catalog code would jump anywhere into the XROM code when pressing [up] beyond the top RAM program!?

Here everything is working as expected. I may have to test it with the exact set of .dat files you are using. You know my e-mail address. Please zip it up for me! (I need everything ending on .dat in your working directory).


Quote:
Here everything is working as expected. I may have to test it with the exact set of .dat files you are using. You know my e-mail address. Please zip it up for me! (I need everything ending on .dat in your working directory).

Ok, sent!

But I've tried it and it works (or better: crashes) with any dat-files.


Quote:
But I've tried it and it works (or better: crashes) with any dat-files.

Should be "crashed" now.

Quote:
Should be "crashed" now.

Yes, it's working now!

But the bad thing is, that now there's no chance anymore for synthetic programming. :-(

(and I was already looking forward to a 'flying goose' on the display ... ;-))

BTW, is it normal (intended) that immediately after loading a program/flash with 'PRCL n', a simple [R/S] doesn't work, ie. doesn't start the program?

Only after switching to program mode and going one step down (to the program label) R/S starts the program.

I guess the program counter isn't set automatically INTO the first program when you load a flash dat-file!?

Franz


Quote:
BTW, is it normal (intended) that immediately after loading a program/flash with 'PRCL n', a simple [R/S] doesn't work, ie. doesn't start the program?
Only after switching to program mode and going one step down (to the program label) R/S starts the program.
I guess the program counter isn't set automatically INTO the first program when you load a flash dat-file!?

Definitely not! I've no time to work on this now (my table tennis team is waiting). It's a bug and must be related to the new handling of program bounds.

No end in buglist ... ;-)

Today I wanted to enter a "cpx x~~0?" (in SVN1977) just to see that this command is not accepted.

After clicking [CPX][h][TEST] the command "Cx~~_?" appears, but when I now enter 0 or 1 then I get "undefined op-code" (or ??? in programming mode), and when I enter 2 (or any higher number) I get a "SKIP 2_" instead of the complex-compare.

Happy bugfixing, :-)

Franz

Edited: 4 Dec 2011, 6:51 a.m.


The complex approximate compares never worked correctly and were removed sometime ago. Leftovers of the code were still present in the keyboard handler which made it possible to enter unimplemented commands. Thanks again for you detective work!


Quote:
The complex approximate compares never worked correctly and were removed sometime ago.

Well, that's also a method for bugfixing: simply removing the buggy code. ;-)

But I don't really understand the/your problem with complex approx compares? Shouldn't e.g. a "cpx x~~0?" be just equivalent to real compares "x~~0?" AND "y~~0?" ?

And the same for register Rn: "cpx x~~? nn" is equivalent to "x~~? nn" AND "y~~? nn+1".

Or does it mean that also real approx compares aren't working realiably or correctly?

Franz


We had an internal discussion about it and an approximate compare of a complex number to zero only makes sense if you define a small circle around the origin of the complex plane and check if the number falls within the bounds of this circle. (The comparison between arbitrary numbers can be reduced to comparing the difference against zero). But what is the correct size of the circle? If you have a workable idea, we can rethink it.

From a math standpoint, the whole business of approximate compares is a bit flaky. The present implementation uses the display setting to round the number(s) and compare the rounded results. It would be better to define some system value epsilon and check if the difference of the compared values is smaller then epsilon. This doesn't scale very well. A relative measure would be more appropriate.


I understand your considerations about these approximate compares in general, but I don't see any difference between real and complex numbers.

If you use the current display setting for real compares, then why not do the same for complex? And whether you test separately the real and imaginary part for being ~0, or you do it with the cABS value (which would mean your 'circle') is just a matter of taste.

Your idea with a system value 'eps' is indeed not that bad - and if one wants relative compares, well, then he has to do code it himself. ;-)


I did some research in my mail archive and found out that we didn't remove the code for approximate complex compares. It had never bin in!


Quote:
It had never bin in!

A textbook example of binary overreacting ;-D

Possibly Related Threads...
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 351 12-10-2013, 11:37 PM
Last Post: Les Bell
  Digging for bugs Stefan Dröge (Germany) 2 175 11-13-2013, 04:39 PM
Last Post: Stefan Dröge (Germany)
  [HP-Prime] Simple Game (Bugs) CompSystems 1 182 11-01-2013, 10:18 AM
Last Post: Han
  HP-35s Cos[x] and Tan[x] bugs resolved? Thomas Windisch 2 199 10-31-2013, 01:12 PM
Last Post: Dieter
  RPN bugs both present in Prime Calc and emulator Eelco Rouw 9 432 10-16-2013, 12:22 PM
Last Post: Eelco Rouw
  [HP-Prime] AND, OR BUGs? CompSystems 0 101 10-04-2013, 04:03 PM
Last Post: CompSystems
  HP 50g: question about bugs Miguel Toro 2 206 09-26-2013, 01:27 PM
Last Post: Miguel Toro
  [HP-Prime xcas] operations with complex numbers + BUGs + Request CompSystems 9 469 09-08-2013, 10:40 PM
Last Post: CompSystems
  [HP_Prime] definition of functions, APPLY command and BUGs CompSystems 1 173 09-05-2013, 03:59 PM
Last Post: CompSystems
  [HP-Prime xCAS] Review Polynomial Tools + BUGs + Request CompSystems 0 137 09-05-2013, 12:53 PM
Last Post: CompSystems

Forum Jump: