[WP-34S] Emulator/debug - single/double copy/paste

[pito]

Is it possible to "copy" the entire double when in D? And to see double "value" in the debug window?
(3.3 3605)
P.

[Dieter]

(06-05-2014 07:11 AM)pito Wrote:  Is it possible to "copy" the entire double when in D? And to see double "value" in the debug window?

Im am afraid it's not. There are two different emulators, the classic (wp34sgui.exe) and the Qt-based one which you obviously use. Both do not allow copying a 34-digit result to the clipboard. They do not even copy the 16 digits in single precision mode. 12 rounded digits is all you get.

Maybe we can setup a feature request here. Just like you, I consider this a very useful function on either of the two emulators. It would have saved quite a lot of effort (and errors due to manual re-typing) in the past. Is there a way we can have this feature and have complete (16 or 34-digit) numbers copied, please?

Dieter

[walter b]

(06-05-2014 11:31 AM)Dieter Wrote:  There are two different emulators, the classic (wp34sgui.exe) and the Qt-based one which you obviously use. Both do not allow copying a 34-digit result to the clipboard. They do not even copy the 16 digits in single precision mode. 12 rounded digits is all you get.

Maybe we can setup a feature request here. ... Is there a way we can have this feature and have complete (16 or 34-digit) numbers copied, please?

I can confirm this observation. Since also the present copy & paste features have their merits, we'd need an additional "copy entire number" button within the drop-down menu which would put either the 16-digit or the 34-digit number in X to the clipboard, depending on DBLOFF / DBLON.

d:-)

[Dieter]

(06-05-2014 11:50 AM)walter b Wrote:  I can confirm this observation. Since also the present copy & paste features have their merits, we'd need an additional "copy entire number" button within the drop-down menu which would put either the 16-digit or the 34-digit number in X to the clipboard, depending on DBLOFF / DBLON.

So were are at least three now. ;-)

While we're at it: this would be nicely complemented by a "paste entire number" feature. Currently 12 digits are all you can enter, both on a physical 34s as well as on the emulator(s). Maybe.... "very maybe"... may I even dare to think this...? Maybe it could be possible one very far day that... the (34s and/or 31s) would accept more that 12 digits without a "too long error" ? I know I am asking for something completely unthinkable, but anyway...

Dieter

[Paul Dale]

(06-05-2014 12:01 PM)Dieter Wrote:  Maybe it could be possible one very far day that... the (34s and/or 31s) would accept more that 12 digits without a "too long error" ? I know I am asking for something completely unthinkable, but anyway...

I don't have any idea how this could be crammed into the 34S. We'd need more RAM for the input buffer and more flash for the extra code.

The 31S ought to be possible, it isn't too tightly pressed for memory.


- Pauli

[walter b]

(06-05-2014 12:11 PM)Paul Dale Wrote:  

(06-05-2014 12:01 PM)Dieter Wrote:  Maybe it could be possible one very far day that... the (34s and/or 31s) would accept more that 12 digits without a "too long error" ?

I don't have any idea how this could be crammed into the 34S. ... The 31S ought to be possible, it isn't too tightly pressed for memory.

The 31S doesn't feature DP, so it's only half the fun (pun intended). Personally, I don't see a pressing need to hack more than 12 digits into either one though.

d:-)

[pascal_meheut]

(06-05-2014 11:31 AM)Dieter Wrote:  Im am afraid it's not. There are two different emulators, the classic (wp34sgui.exe) and the Qt-based one which you obviously use. Both do not allow copying a 34-digit result to the clipboard. They do not even copy the 16 digits in single precision mode. 12 rounded digits is all you get.

The reason the behave the same is that the Qt-Emulator has been designed to replicate the classic one whilst being portable on OSX & Linux and then enhanced.
Displaying and copying in full precision would be possible but I do not have time to work on it right now.

But this is open-source software so if a brave soul want to give it a try, he (or less likely she) can.

[Martin Hepperle]

(06-05-2014 06:16 PM)pascal_meheut Wrote:  [...]
But this is open-source software so if a brave soul want to give it a try, he (or less likely she) can.

Well, I tried to tinker a bit with the sources, but found it quite cumbersome and finally threw up my hands in despair. I am planning to give it a second try, though.
The archive file structure seems to be a bit... well, can we say a mess?
Some files seem to have been developed for Visual Studio, but I also see other files which look like Eclipse project files.
Also it is not clear what is part of the emulator and what is part of the real thing.
I tried to rebuild the project files for my VS 2008. Quite time consuming as one has to find out the relations between the sub-projects etc.
I learn that some of the projects need other projects to be run as a postprocessing step in order to generate some of the source files. Also some tricks seem to be involved like translating a source file twice etc.
All this can be found out, but is no fun and may discourage other people from joining your project.

It would be much easier for an interested novice, if a short README file would explain the main logic of the build process and the tools used. What is the build order and what are the prerequisites?
Maybe for Windows and/or Linux platforms. One can always use a VirtualBox or similar, so maybe the Linux/Eclipse approach would be the better choice.

Just a small README file could save the world...

[walter b]

Let's face it: it's a hobbyist's project. SourceForge is all we have for file storage and revision handling. The main participants (writing SW) succeeded in working within that environment and with some additional emails back and forth. Anybody else who wants to go into that needs a brave heart at least. But there are no snakes and dragons waiting ...

d:-)

[pito]

(06-12-2014 02:38 PM)walter b Wrote:  .. Anybody else who wants to go into that needs a brave heart at least..
d:-)

I've been trying to compile and my Avira stops the build indicating WP34s\windows\catalogs\Release\catalogs.exe does contain TR/Dropper.Gen. Most probably a false positive - can you confirm?
(XP, VC++Expr2010 fresh, Yagarto, ActPerl fresh, trunk fresh)

[Marcus von Cube]

(06-13-2014 10:17 AM)pito Wrote:  

(06-12-2014 02:38 PM)walter b Wrote:  .. Anybody else who wants to go into that needs a brave heart at least..
d:-)

I've been trying to compile and my Avira stops the build indicating WP34s\windows\catalogs\Release\catalogs.exe does contain TR/Dropper.Gen. Most probably a false positive - can you confirm?
(XP, VC++Expr2010 fresh, Yagarto, ActPerl fresh, trunk fresh)

Some false positive virus alerts have occurred here, two. The only chance I had was to disable one engine of my GDATA real time virus checker during the build.

[Marcus von Cube]

(06-12-2014 07:58 AM)Martin Hepperle Wrote:  The archive file structure seems to be a bit... well, can we say a mess?
Some files seem to have been developed for Visual Studio, but I also see other files which look like Eclipse project files.

Just a small README file could save the world...

I must admit that building both the real thing and the classic Windows emulator is quite a mess. You'll need some stuff before you can start, such as a working Perl installation.

The classic Windows emulator is build with Visual Studio 2010. The free Express edition is sufficient if you do not want to modify the core emulator DLL which uses MFC libraries and headers. Open the proper SLN file and all will be build automatically.

The Eclipse files simply define the project and delegate the build to the Makefile. This is for the real thing and has nothing to do with the emulator. When I'm performing builds, I use some cmd files in the project root. The IDEs are just for editing and debugging.

I remember to have written this down somwhere but I don't recall where exactly. Maybe in the Wiki.

[pito]

(06-13-2014 01:25 PM)Marcus von Cube Wrote:  The classic Windows emulator is build with Visual Studio 2010. The free Express edition is sufficient if you do not want to modify the core emulator DLL which uses MFC libraries and headers. Open the proper SLN file and all will be build automatically.

The Eclipse files simply define the project and delegate the build to the Makefile. This is for the real thing and has nothing to do with the emulator. When I'm performing builds, I use some cmd files in the project root. The IDEs are just for editing and debugging.

I remember to have written this down somwhere but I don't recall where exactly. Maybe in the Wiki.

After reading available wikis I've tried the easy part - to build the emulator (VSC++2010, using TortoiseSVN). Getting following errors (see attached).
When looking at the Makefile for building the calc.bin I can see you use some .exe(s) generated during the emulator build - so it seems to me there is a dependency..

[Marcus von Cube]

Quote: 'svnversion' is not recognized as an internal or external command,

Install the SVN command line utilities (they come with TortoiseSVN) and change your path to point to them.

[pito]

(06-13-2014 04:19 PM)Marcus von Cube Wrote:  Install the SVN command line utilities (they come with TortoiseSVN) and change your path to point to them.

ok, now the last issue to tackle (see below).

[Marcus von Cube]

(06-13-2014 04:55 PM)pito Wrote:  

(06-13-2014 04:19 PM)Marcus von Cube Wrote:  Install the SVN command line utilities (they come with TortoiseSVN) and change your path to point to them.

ok, now the last issue to tackle (see below).

It looks like the build is trying to copy (an outdated version) of the manual to the location where the emulator expects it for its Help menu. Just ignore the error or patch the copy command in the wp34sgui post build event.

[pito]

(06-13-2014 05:10 PM)Marcus von Cube Wrote:  Just ignore the error or patch the copy command in the wp34sgui post build event.

Ok, I get the rev3668 emul, so it seems it is mine
PS: maybe the link in the sourceforge "How to build" to svn repo needs an update..

Quote:' Run the subversion command to get the latest software: svn co https://wp34s.svn.sourceforge.net/svnroot/wp34s wp34s

[pito]

(06-13-2014 01:25 PM)Marcus von Cube Wrote:  The Eclipse files simply define the project and delegate the build to the Makefile. This is for the real thing and has nothing to do with the emulator. When I'm performing builds, I use some cmd files in the project root.

In eclipse I see in GNU Includes

Quote:C:\Programme\Microsoft Visual Studio 10.0\VC\atlmfc\include

Where it shall point to? I do not see such dir in VC (the atlmfc).

[Marcus von Cube]

(06-13-2014 05:48 PM)pito Wrote:  In eclipse I see in GNU Includes

Quote:C:\Programme\Microsoft Visual Studio 10.0\VC\atlmfc\include

Where it shall point to? I do not see such dir in VC (the atlmfc).

This looks like an Eclipse artifact from an automatic scan of all C code, including the MFC based emulator code. You can safely ignore it.

[pito]

(06-13-2014 08:48 PM)Marcus von Cube Wrote:  [This looks like an Eclipse artifact from an automatic scan of all C code, including the MFC based emulator code. You can safely ignore it.

Now, with makeflash.cmd (with the path set to my yagarto) I get - see flash-build.log below.