[WP34S] New GUI features

[Marcus von Cube]

(01-04-2016 03:57 PM)fhub Wrote:  

(01-04-2016 03:38 PM)Marcus von Cube Wrote:  Due to a program error on my side the temporary files used to be created in the root directory of the current drive.

Well, I see the temporary files of your emulator in the current directory (of wp34sgui.exe), not in the root. But I have write permission to all my folders, so no problem for me.

"used to be" is past tense. The error is fixed in the current release.

Write permission doesn't help in Windows 7. The root folder is protected. Explorer can ask the user for the required privileges but a user program normally does not do this. It just fails.

[fhub]

(01-04-2016 04:13 PM)Marcus von Cube Wrote:  Write permission doesn't help in Windows 7. The root folder is protected.

Maybe 'write permission' was not the correct choice, I wanted to say that I'm always working as Admin, so I have no problems to also write anything to the root folder (at least in Vista).

Franz

[Marcus von Cube]

(01-04-2016 04:20 PM)fhub Wrote:  Maybe 'write permission' was not the correct choice, I wanted to say that I'm always working as Admin, so I have no problems to also write anything to the root folder (at least in Vista).

My account is an admin account, too, but Windows 7 runs a user program with reduced rights (to improve security agains malware). You have to explicitly run a program as admin to allow changes to system folders.

[pascal_meheut]

I've uploaded new versions with Import/Export in the correct order. And Import seems to work fine on Windows.
I'll add the preference to choose another "tools" directory later.

[fhub]

(01-04-2016 10:55 PM)pascal_meheut Wrote:  I've uploaded new versions with Import/Export in the correct order. And Import seems to work fine on Windows.

Yes, working now without problems!
(I see you've now also changed the temp directory)

Quote:I'll add the preference to choose another "tools" directory later.

There's no hurry - I've already changed it to my own directory.

Many thanks,
Franz

[pascal_meheut]

I've added an option to select the tools directory (in preferences, works like the 1st tab to select the library directory).
And merged the recent changes to the complex_mode branch.

[Marcus von Cube]

The classic emulator in complex_mode has been updated, too. The executable has been renamed to wp34cgui.exe.

[BarryMead]

(01-07-2016 08:10 AM)pascal_meheut Wrote:  I've added an option to select the tools directory (in preferences, works like the 1st tab to select the library directory).
And merged the recent changes to the complex_mode branch.

Thanks Pascal:

The Qt emulator now has full source level import/export in native Linux! Just point the tools directory in the right place and it works! With the ability to more easily share sourcecode for WP-34s programs I am hopeful that the community will be encouraged to create and share more wp34s programs.

[pascal_meheut]

(01-07-2016 11:04 PM)BarryMead Wrote:  Just point the tools directory in the right place and it works!

And even this should not be necessary as a copy of tools is inside the distribution and should work out of the box.

[BarryMead]

(01-08-2016 02:21 AM)pascal_meheut Wrote:  And even this should not be necessary as a copy of tools is inside the distribution and should work out of the box.

I am sure this is the case if you choose one of the pre-built distributions. I always use a custom compile changing a few file names in QtEmulator.h so that the Help/Manual menu item shows my Personalized 3.3 pdf manual that I bought from Walter, and so that the three versions of the Qt emulator that I compile don't step on each other's config/data files. I compile 3 separate Qt Emulators, one with "Bit's" Optimizations, one for the Standard WP-34S, and one for the Complex branch. I also point the separate config files to separate Tools directories so that the assembler uses the right op code file to generate matching binary data for each Emulator. I tested everything and it all works flawlessly. I also re-flashed my calculators with the latest firmware (with Bit's Optimizations) and confirmed that all of the import/export features work and generate the proper op-codes. This new Qt Emulator has nearly every feature I ever wanted. Thanks to Marcus, and Pascal for this giant leap forward!

Marcus: After some additional testing, I did discover an issue with the "Calculator/Export Program" menu item. As a test I pointed the program counter at the 'TVM' program in flash, and copied that
program down to RAM with the P.FCN PRCL command, then I exported that RAM program to a file called TVM.wp34s. When I tried to import that saved source program I found that it caused the assembler to error out. It seems that the "Export" process isn't generating [space] or [narrow-space] macros within [alpha] strings in the exported source files, and the assembler does not recognize a space character ' ' in an [alpha] string, but requires the [space] or [narrow-space] macro instead. I thought you would like to know as soon as I found the issue, so you could perfect the operation of the Export feature.

I found a similar quirk when I tried to export/import the digamma.wp34s program. On line 75 the export failed to prefix the "CONJ" op code with "[cmplx]CONJ" so the re-assembly failed.

Do you know of any source code level test files that they used to validate the Assembler/Disassembler? Perhaps we could re-use these test files to validate the Export/Import features. It would be good to have a test file which includes an exhaustive list of Op-Codes from every sub menu, and also includes every parameter/argument type allowed to be sure they are disassembling and assembling correctly.

[Marcus von Cube]

(01-08-2016 12:01 PM)BarryMead Wrote:  Marcus: After some additional testing, I did discover an issue with the "Calculator/Export Program" menu item. ... It seems that the "Export" process isn't generating [space] or [narrow-space] macros within [alpha] strings in the exported source files, and the assembler does not recognize a space character ' ' in an [alpha] string, but requires the [space] or [narrow-space] macro instead. I thought you would like to know as soon as I found the issue, so you could perfect the operation of the Export feature.

I found a similar quirk when I tried to export/import the digamma.wp34s program. On line 75 the export failed to prefix the "CONJ" op code with "[cmplx]CONJ" so the re-assembly failed.

Thanks for detecting this. Can you try again? (I didn't update the Qt build but if I understand you correctly that isn't a problem for you.)

[fhub]

(01-08-2016 06:00 PM)BarryMead Wrote:  If you tell me which files you changed, I can copy them over into my Qt build and run the test. Otherwise I will have to switch to a windows machine and install a bunch of programs to get it to the state where I can run the tests in Windows.

These 2 files have changed:
/trunk/commands.c
/trunk/storage.c

You can always see the changed files when you click on the SVN number [rXXXX] after 'Tree' here:
http://sourceforge.net/p/wp34s/code/HEAD/tree/

Franz

[BarryMead]

(01-08-2016 05:10 PM)Marcus von Cube Wrote:  Thanks for detecting this. Can you try again? (I didn't update the Qt build but if I understand you correctly that isn't a problem for you.)

Marcus: That seems to solve the issues I found with Export Thanks Again!

I noticed that the changes to storage.c and commands.c were applied only to the trunk branch not the complex_mode branch. The commands.c file is quite a bit different for the complex branch so I couldn't just copy it over. I carefully merged in the differences. But all seems to work now. Thanks!

I just wanted to let you know that the tests I made on the Export/Import features were by no-means exhaustive! Over the next couple of days I plan to Export/Import each of the
standard library functions to see if I can help find any additional anomalies. If anyone knows the developer of the Assembler perl scripts, and can ask him if he has an exhaustive Op-Code/Argument Test Suite, it could be useful to validate the Export/Import features. Take Care, Barry

[Marcus von Cube]

I can assure you that we don't have exhaustive test scripts. Delegating the bulk of the testing to our intended audience has worked out pretty well so far.

[BarryMead]

(01-08-2016 08:49 PM)Marcus von Cube Wrote:  I can assure you that we don't have exhaustive test scripts. Delegating the bulk of the testing to our intended audience has worked out pretty well so far.

It certainly has! The WP-34s has to be one of the most feature-rich, bug-free calculators on the planet! There are some very brilliant people in this forum. I often feel honored to observe the quality and quantity innovative ideas that emerge from this "Intended Audience"! When I need to take a vacation from the daily grind, which often seems to lack intellectual stimulation, I visit this forum and my faith in human intellect is restored. It seems to re-ignite that spark of inventive/creative energy that can fade without the interaction of respected colleagues.

Thanks to all, Barry

[fhub]

(01-08-2016 06:33 PM)BarryMead Wrote:  ...the changes to storage.c and commands.c were applied only to the trunk branch not the complex_mode branch.

Have you seen this, Marcus?

Franz

[Marcus von Cube]

(01-09-2016 12:59 PM)fhub Wrote:  Have you seen this, Marcus?

Yes!

[Nigel (UK)]

Complex mode hasn't been updated for a while - entirely my fault. As a first step towards rectifying this I've downloaded the latest code base and have begun by trying to compile the new emulator using Visual C++ Express 10 (which I've always used before).

This doesn't work. To start with I got an error from the #include afxres.h directive in the file wp34s.rc: the file afxres.h wasn't found on my computer.

I commented out the #include directive and added the lines

Code:

#include "WinResrc.h"
#include "WinNT.rh"
#include "windows.h"
#define IDC_STATIC              (-1)     // all static controls

copying from previous versions of the file and following online solutions to the same problem. This time I got the following error:

Code:

4>..\emulator\wp34s.rc(181): error RC2104: undefined keyword or key name: ID_FILE_OPEN

.
Eventually I discovered that commenting out all of the new menu items in wp34s.rc allowed the code to compile, but this is not an ideal solution!

Am I doing something silly? (Quite likely.) Or is it no longer possible to compile the code with Visual C++ Express?

Nigel (UK)

[Marcus von Cube]

(01-10-2016 09:25 PM)Nigel (UK) Wrote:  ...I've downloaded the latest code base and have begun by trying to compile the new emulator using Visual C++ Express 10 (which I've always used before).

This doesn't work.

The Express version of Visual Studio does not support MFC programming. You cannot compile the emulator.dll. (This is why I put all the GUI stuff into the DLL to make it possible to compile the rest of the emulator with Visual C++ Express.) You will have to load the wp34c_express.sln file into VC Express. The emulator DLL is part of SVN, in particular the debug version and symbols.

[fhub]

Hi Marcus!

There's a serious problem for users of the complex WP34s version when using the new 'Import program...' feature:
I'm rather sure that anyone using both (the normal and complex) emulators will probably have the assembler tools and the opcode files in one and the same directory (usually 'tools').
Now the opcode-files wp34s.op and wp34c.op are not compatible, but the GUI does not tell the assembler explicitely which *.op file he should use, and so he always uses the normal file wp34s.op - and this will of course lead to a wrong state file (with wrong or even illegal opcodes), when you import any sourcefile with the complex emulator!

I see 2 possible solutions for this problem:
1) The best way would be to change the opcode table of the complex emulator, so that 'new' opcodes (only existing in the complex version) would not overwrite opcodes of the normal version, but just use 'free' opcode numbers (there are lots of free places in wp34s.op). With this method we won't even have the need for an extra wp34c.op - all opcodes (the 'normal' and the 'complex' ones) would be in the same file wp34s.op.

2) The other method is to explicitely add the option '-op wp34c.op' in the complex emulator when calling the assembler, but in this case you would also have to add the location of the opcode file, i.e. a working option could be '-op ..\tools\wp34c.op' assuming the assembler and the opcode file both are in ..\tools.

IMO the first method with only one wp34s.op for both emulator versions is certainly the better choice (especially because the same problem exists for the QtGUI version, too!), but who can rewrite the opcode addresses in the complex emulator, so that they are at free places?

Franz