ICON issue

[periappi]

Hi,

I'm using the ICON function (cf. end of topic) in order to display images - by the way I use mviewer GX Creator from TI-Planet to generate it (https://tiplanet.org/forum/editgx.php). The problem is, I can't find a way to display two different images in the same program.
A picture is worth a thousand words... !



As you can see in the right part of the screenshot, I'm trying to make the same declaration coexisting... but my little experiment failed as it only showed the first variables (which have the same name)... So, is there a way I can isolate thoses variables ?

Thanks,

[Didier Lachieze]

(04-20-2016 09:12 AM)periappi Wrote:  As you can see in the right part of the screenshot, I'm trying to make the same declaration coexisting... ,

I'm sorry but I can't see anything in the right part of the screenshot, the text is way too small.

[periappi]

(04-20-2016 10:54 AM)Didier Lachieze Wrote:  

(04-20-2016 09:12 AM)periappi Wrote:  As you can see in the right part of the screenshot, I'm trying to make the same declaration coexisting... ,

I'm sorry but I can't see anything in the right part of the screenshot, the text is way too small.

Oh, I'm sorry. I did not want you to try to read the text, but to see that I tried to put those two "blocks" of code in the same program. Though, here is a screenshot of what you tried to read :



PS : The right part of the text is continues with alphabetic and numerical characters until the ";".

[Didier Lachieze]

I still can't read anything on the right side, but let me try to understand your issue: you're trying to put in the same program two ICON statements with the same name but different content ?
Why don't you use two different names and select dynamically in your program the one to display ?

[periappi]

(04-20-2016 11:39 AM)Didier Lachieze Wrote:  I still can't read anything on the right side, but let me try to understand your issue: you're trying to put in the same program two ICON statements with the same name but different content ?
Why don't you use two different names and select dynamically in your program the one to display ?

Yes, that's it !


Why don't you use two different names and select dynamically in your program the one to display ?

I thought about it, but I wanted to know if there was another explanation and a solution to that Is there one ?

[Tim Wessman]

How would it know which you want if they are both identically named?

[periappi]

That's why I ask, I'm looking for a solution to isolate them. Maybe you should try the only tool and see by yourself, maybe it would be easier to understand my situation (I suggest to create a menu and give to the user the choice of opening a picture (there would be 2 choices).

[Tim Wessman]

Preferably, they should move to direct support with PNG/JPG files in an application. That ICON keyword was never meant to be abused like they've done...

[periappi]

(04-20-2016 05:00 PM)Tim Wessman Wrote:  Preferably, they should move to direct support with PNG/JPG files in an application. That ICON keyword was never meant to be abused like they've done...

Is there an easier way to use and read pictures without using that keyword?

[Han]

(04-20-2016 05:02 PM)periappi Wrote:  

(04-20-2016 05:00 PM)Tim Wessman Wrote:  Preferably, they should move to direct support with PNG/JPG files in an application. That ICON keyword was never meant to be abused like they've done...

Is there an easier way to use and read pictures without using that keyword?

Create individual "files" and store them within an APP. AFiles is the command to save and recall files. You can even use PNG/JPG directly as files. You still cannot use the same "file name" for multiple files. I would recommend using Filename00.png Filename01.png etc to keep your files organized by Filename, though.

[periappi]

(04-20-2016 05:59 PM)Han Wrote:  

(04-20-2016 05:02 PM)periappi Wrote:  Is there an easier way to use and read pictures without using that keyword?

Create individual "files" and store them within an APP. AFiles is the command to save and recall files. You can even use PNG/JPG directly as files. You still cannot use the same "file name" for multiple files. I would recommend using Filename00.png Filename01.png etc to keep your files organized by Filename, though.

Ok, thanks for the advice Han It's good to see that there is always someone on this forum to help (quickly ) !! Thank you very much !

[debrouxl]

Quote:Preferably, they should move to direct support with PNG/JPG files in an application. That ICON keyword was never meant to be abused like they've done...

IIRC, the move was not performed for at least two good reasons:
* backwards compatibility;
* the ease of generating ICONs, represented as plain text - applications containing AFiles constructs are another story. HP's proprietary, Windows-only, non-scriptable (AFAWCT) infrastructure for generating such apps is completely unsuitable for a non-interactive batch generation workflow like that of mViewer GX Creator, running on a Linux server with a grsec kernel.

BTW, critor's initial tests of mViewer GX Creator with the latest firmware version are very disappointing. The results are worse than in the previous versions: not only the calculator is still very easily running out of memory (despite the memory leak fixes), but also, the relevant documents are corrupted to death upon reboot. Earlier firmware revisions have never done that in his tests, and mViewer GX Creator users for the Prime (we have a noticeable number of those) haven't reported that.
He provided more information, in French, at https://ti-pla.net/p200112 .

If Cyrille or someone else from HP wants unrestricted access to mViewer GX Creator (no daily cap of 10 generations) to throw images at it and gather testcases, just ask us. Both your account (Tim) and Bernard Parisse's already have it.

[Tim Wessman]

(04-21-2016 06:36 PM)debrouxl Wrote:  BTW, critor's initial tests of mViewer GX Creator with the latest firmware version are very disappointing. The results are worse than in the previous versions: not only the calculator is still very easily running out of memory (despite the memory leak fixes),

1. ICON was meant for bitmap data that should remain in memory constantly. Thus every time you send it to the device, it is parsed and *will remain in memory* until a complete boot. Thus the complaints about "bugs that HP hasn't fixed for years" when you run out of memory after sending MB worth of bitmaps over that will remain in memory.... it is working as designed. You may not like the design, but it is behaving in an expected manner.

The process works like this:

1. Message arrives over the USB.
2. It is decompressed.
3. Data is copied to disk files.
4. If program or app, it is parsed and objects are created.
5. Since ICON is in use, you've now stored a bitmap in RAM that will remain there until a fresh boot.

Is it any wonder you run out of memory with this? It is not leaking memory at all! You are asking the system to save that RAM with each ICON keyword.

I've tried explaining this now at least 4-5 times and nobody seems to listen.

Additionally, it is highly likely we will get rid of ICON either in the next release or the one after because we'll probably be switching to 888 color vs the 565 in use now, and it is *not* a portable format.

2. You have full support for PNG and JPG files with direct save and load. Can't get much more standard then that. Or memory efficient.

3. Make an .hpappdir folder. Stick in all your jpg/png. Stick in an empty .hpapp file of any kind. Stick your app program in there. Should be pretty easy to script no matter what the system.


If critor believes there are problems, have him send me his test files and I will look at it. All the files we had from your tool and tested with as part of our test plans worked just fine and never exhibited any of this behavior.

[critor]

(04-21-2016 07:01 PM)Tim Wessman Wrote:  Is it any wonder you run out of memory with this? It is not leaking memory at all! You are asking the system to save that RAM with each ICON keyword.

You apparently missed the point, Tim...

The problem is not about running out of RAM, which happened more often with the previous 8151 firmware.
The problem is that, with the latest firmware, when the calculator is low on RAM it starts corrupting/overwriting your own data.

Despite many attempts, I've been unable to reproduce such data corruption with the older 8151 firmware up to now.

[Tim Wessman]

(04-21-2016 07:26 PM)critor Wrote:  Despite many attempts, I've been unable to reproduce such data corruption with the older 8151 firmware up to now.

Well then please send the files. All the ones I have, and those in our test cycles do not exhbit any issues.

[critor]

(04-20-2016 05:00 PM)Tim Wessman Wrote:  Preferably, they should move to direct support with PNG/JPG files in an application. That ICON keyword was never meant to be abused like they've done...

I would have moved if it was easy and user-friendly.
I haven't tested yet with the latest firmware, but with 8151 apps were limited to 2MB.

This is certainly enough for a single big scrollable image... but not for a PDF document.

So for example for a, let's say 40 pages document, it would have to be split into 10 different apps for example with 4 images/pages per app, thus spamming the apps screen.
(unless there is a scriptable way to hide an app from that screen?...)

Sending an app over 2MB is making the calculator go crazy.

I did take the time to record and post an unlisted video and to report this issue here almost one year ago and never got any reply or information. I had to guess there was a 2MB limit by myself.
http://www.hpmuseum.org/forum/archive/in...832-2.html

[critor]

(04-21-2016 07:30 PM)Tim Wessman Wrote:  

(04-21-2016 07:26 PM)critor Wrote:  Despite many attempts, I've been unable to reproduce such data corruption with the older 8151 firmware up to now.

Well then please send the files. All the ones I have, and those in our test cycles do not exhbit any issues.

You may try with this unlisted document :
https://tiplanet.org/forum/archives_voir.php?id=496932

Here is a way which does reproduce the problem in all cases on my HW-C calculator :
- reset
- load the 5 first files : test01.hpprgm to test05.hpprgm
- reset to clear the RAM
- press Shift+Mem
- press Shift+Program
=> with firmware 10077, several programs just got destroyed (truncated to 0.23KB)
No such problem with firmware 8151.


I am also able to get similar data corruptions without even opening the memory screen, just by launching the programs, except that it's random (have to do it several times in a row and things like this...).
Maybe I've been lucky, but this never happened to me with the previous firmwares.

[Tim Wessman]

(04-21-2016 08:37 PM)critor Wrote:  I am also able to get similar data corruptions without even opening the memory screen, just by launching the programs, except that it's random (have to do it several times in a row and things like this...).
Maybe I've been lucky, but this never happened to me with the previous firmwares.

Thank you for the files and the steps. We will investigate.

[critor]

Here is another way which just triggered the problem twice in a row with the same above document, without any access to the memory screen this time :
- reset
- load the 5 first files : test01.hpprgm to test05.hpprgm
- reset to clear the RAM
- load the 5 next files : test06.hpprgm to test10.hpprgm
- reset to clear the RAM
- disconnect the USB (seems to free some more RAM)
- press Shift+Program
- launch test01
- keep pressing + to go to the next page until you get an error
- I get an error either when trying to open the 5th page, either when trying to open the 6th page
=> if it's when opening the 5th page, no problem
=> if it's when opening the 6th page, one or several used programs just got corrupt (truncated to 0.23KB) - they're still going to work (as still in RAM I suppose) until the next reset - after that they'll be unusable.


No such problem with the 8151 firmware, but as it has fewer RAM it won't trigger the error on opening the 6th page, but the 5th one, so it's not exactly the same RAM state (and in fact, it's not an error but a freeze here).

[cyrille de brébisson]

Hello,

I think that your problem mostly comes from the "rest to clear the RAM" stage...
Sending the program means writing them to file...
BUT, "reset to clear the RAM" is a OS/Driver function (done this way on purpose to make sure that ON+Symb does indeed reboot even if the application part is crashed)...

One of the side effects is that the reset does NOT flush the file caches. So, you have partially written programs on the file system, with a file size which might, or might not have been written, but most likely with bad data in the flash...

Reboot the calculator, your cached data is lost, the file system has crap data, the calculator 'tries to fix' the issue by truncating/erasing/resting the program.

Try doing an OFF/ON sequence before the "reset to clear the RAM" (OFF does make sure that all is written to the file system and flushed), and suddenly, I can not reproduce the issue anymore.

Cyrille