Gentle Reminder: hpprgm

[Tim Wessman]

A gentle reminder to people about the hpprgm extension and others in use in the calculator - these are not plain text files!

I've seen several people now post files labeled with an hpprgm extension when in fact they are plain text. Please remember that hpprgm files are in fact BINARY files and not meant for editing with a text editor. While you can open an exe with a text editor, making changes will cause problems and most likely crashes. The same WILL happen if you are manually tweaking hpprgm files.

When the format changes as new features are added, your programs will confuse people as they try to load them and they fail. The fact that you can currently open them and they seem to show plain text primarily does not mean you should go ahead and edit things.

You have been cautioned and please remember this! For the sake of people in the future getting totally perplexed as to why things aren't working, I'd ask you to keep your plain text source files as source, and only have the hpprgm extension on files that were generated by HP software (or some other specialty program).

[jebem]

Thanks for this information, Tim!
I've inserted a entry link to your post in the Prime's documentation sticky thread.

[Eddie W. Shore]

I prefer keeping the text files too. If all else fails I can just copy and paste the text file into the program editor on the Connectivity Kit.

[Kevin Ouellet]

(03-28-2014 10:17 PM)Tim Wessman Wrote:  A gentle reminder to people about the hpprgm extension and others in use in the calculator - these are not plain text files!

I've seen several people now post files labeled with an hpprgm extension when in fact they are plain text. Please remember that hpprgm files are in fact BINARY files and not meant for editing with a text editor. While you can open an exe with a text editor, making changes will cause problems and most likely crashes. The same WILL happen if you are manually tweaking hpprgm files.

When the format changes as new features are added, your programs will confuse people as they try to load them and they fail. The fact that you can currently open them and they seem to show plain text primarily does not mean you should go ahead and edit things.

You have been cautioned and please remember this! For the sake of people in the future getting totally perplexed as to why things aren't working, I'd ask you to keep your plain text source files as source, and only have the hpprgm extension on files that were generated by HP software (or some other specialty program).

When (or if?) Omnimaga re-opens its downloads section to new file uploads, you can be sure that any hpprgm file that is just a plain text file or manually tweaked one will be rejected. I'll be sure to inform the admins about that possible issue. Hopefully Cemetech, TI-Planet and Hpcalc.org do the same.

Also, another issue is when people upload their code on the forums instead of posting a real hpprgm, in many cases the code will not work if copy/pasted into the connectivity kit (or was it when doing so in the emulator?), thanks to the whitespace glitch.

[eried]

As a community I think we have to make our own format. I like docx/apk/xap styled ones, archive with xml descriptor + files. It can contain metadata like description, snapshots, etc.

Right now even the sharing the plain code is messy because the symbols, unicode, etc.

[patrice]

Since the very beginning, I took the habit to always work with text files in unicode.
I use .prime as my programs extension (non CAS programs).
The problem with binary files is that there is always a chance that the format change, and new emulator versions can become unable to reread the files.

If someone is interested, I have build a language file for UltraEdit.

[debrouxl]

Quote:As a community I think we have to make our own format. I like docx/apk/xap styled ones, archive with xml descriptor + files. It can contain metadata like description, snapshots, etc.

If we ever made our own custom format, we should indeed add metadata (starting with version number), and it should indeed be in a type of container aimed at supporting multiple embedded files (ZIP files, tarballs, ar archives, etc.). However, JSON (or YAML, but that isn't supported in browsers) is a better choice than XML: it's expressive enough, more lightweight, and less of an annoyance in some browsers.

Having cross-platform, lightweight tools for reading and writing such files is a must.

[eried]

(04-05-2014 08:14 AM)debrouxl Wrote:  

Quote:As a community I think we have to make our own format. I like docx/apk/xap styled ones, archive with xml descriptor + files. It can contain metadata like description, snapshots, etc.

If we ever made our own custom format, we should indeed add metadata (starting with version number), and it should indeed be in a type of container aimed at supporting multiple embedded files (ZIP files, tarballs, ar archives, etc.). However, JSON (or YAML, but that isn't supported in browsers) is a better choice than XML: it's expressive enough, more lightweight, and less of an annoyance in some browsers.

Having cross-platform, lightweight tools for reading and writing such files is a must.

Exactly, web converter, win/linux/mac from/to this format to txt, hpprgm, app, etc

I was thinking on something similar to the apks, 1 plain file with the version, 1 metadata in .xml and another xml that describes the contents

[debrouxl]

Quote:Exactly, web converter, win/linux/mac from/to this format to txt, hpprgm, app, etc

Yup. Per the same reasoning as libhpcalcs (portability and interoperability with other languages), there needs to be a C/C++ implementation offering a C API. Non-native frameworks (for a start: Java, C#) would be a worse choice; Java is widespread, but many non-Windows users refuse to install Mono.

Quote:I was thinking on something similar to the apks, 1 plain file with the version, 1 metadata in .xml and another xml that describes the contents

Hmm... why multiple files for the metadata, when a single one containing version, metadata (author, etc.) and contents description (calculator files, screenshots, etc.) does the job ?

[eried]

Well I was just thinking on a simplistic approach for restricted environment (i.e. a microprocessor with ethernet to read the version of the file to know if it is supported or no rather than parsing the xml)

About mono, there are tools to avoid installing mono, yet run it: http://linux.die.net/man/1/mkbundle - https://xamarin.com/

I have tested mkbundle and it works wonderfully https://www.youtube.com/watch?feature=pl...-k1hg&t=91 <- this is the same app running everywhere, tablet and model-b raspberry pi. But of course a plain ansi C version would be much better than a bloated thing in particular when you are looking for lightweightness (and incite other developers to code their own ports).

[debrouxl]

Quote:Well I was just thinking on a simplistic approach for restricted environment (i.e. a microprocessor with ethernet to read the version of the file to know if it is supported or no rather than parsing the xml)

But then, with more files into the container, you're complicating container parsing

Ultra-constrained environments wouldn't treat the files we're envisioning in the first place, as screenshots and .hpprgm files can be hundreds of KBs (currently, as shown by the documents generated by TI-Planet's mViewer GX Creator, beyond 1 MB, not only the slow transfer rate is tiresome, but instability ensues when trying to launch the programs). However, but both JSON and XML can be parsed on the fly, and in an absolute worst case (without a JSON or StAX parser), one could parse:
* for JSON: {, then optional whitespace, then e.g. ", version, ", optional whitespace, :, optional whitespace, text to integer, comma;
* for XML: <?xml version="1.0" encoding="UTF-8"?>, optional whitespace, <!DOCTYPE ...>, optional whitespace, <some root tag>, optional whitespace, <version>, text, </version>, and decode the text.

I'm aware of both the existence of mkbundle, and the bloat of the generated solution
It's not just .Net / Mono: embedding a subset of the Java VM + class library, even in Java 8 times, or Python, Perl and friends, would yield similar results to embedding a subset of the .Net / Mono VM + class library.

[Tugdual]

(03-28-2014 10:17 PM)Tim Wessman Wrote:  A gentle reminder to people about the hpprgm extension and others in use in the calculator - these are not plain text files!

I've seen several people now post files labeled with an hpprgm extension when in fact they are plain text. Please remember that hpprgm files are in fact BINARY files and not meant for editing with a text editor. While you can open an exe with a text editor, making changes will cause problems and most likely crashes. The same WILL happen if you are manually tweaking hpprgm files.

When the format changes as new features are added, your programs will confuse people as they try to load them and they fail. The fact that you can currently open them and they seem to show plain text primarily does not mean you should go ahead and edit things.

You have been cautioned and please remember this! For the sake of people in the future getting totally perplexed as to why things aren't working, I'd ask you to keep your plain text source files as source, and only have the hpprgm extension on files that were generated by HP software (or some other specialty program).

Tim, I have mixed feelings when I read your post. On one hand I think it is cool that you share this information. On the other hand I wonder if this is the right customer service. I mean did you wonder why some people would prefer to share hpprgm files rather than source code? You seem to assume that it is a mistake but are we missing a need? I don't have the answer myself but I would be tempted to wonder if there is a need for binaries rather than source code? Like developing a new market? Selling protected maths libs? Not saying that it is desirable, just wondering and wandering...

[Han]

(04-05-2014 08:00 PM)Tugdual Wrote:  Tim, I have mixed feelings when I read your post. On one hand I think it is cool that you share this information. On the other hand I wonder if this is the right customer service. I mean did you wonder why some people would prefer to share hpprgm files rather than source code? You seem to assume that it is a mistake but are we missing a need? I don't have the answer myself but I would be tempted to wonder if there is a need for binaries rather than source code? Like developing a new market? Selling protected maths libs? Not saying that it is desirable, just wondering and wandering...

I think you misread his post. Tim is suggesting not naming a text file with an .hpprgm suffix if it is not in fact such a file. An analogy would be to ask folks to not use a .pdf extension if their file is not an actual pdf file (and is just plain text). I don't think Tim is suggesting that no one publish .hpprgm files. But if we do, at least ensure that it is in fact such type of file.

[Tim Wessman]

(04-05-2014 11:47 PM)Han Wrote:  I think you misread his post. Tim is suggesting not naming a text file with an .hpprgm suffix if it is not in fact such a file. An analogy would be to ask folks to not use a .pdf extension if their file is not an actual pdf file (and is just plain text). I don't think Tim is suggesting that no one publish .hpprgm files. But if we do, at least ensure that it is in fact such type of file.

Exactly correct. Publishing and sharing the files is great - provided they are actually hpprgm files. If they are just text files then there is lots of potential for confusion, crashes, and just not a nice experience for anyone. You talk about a need to share binary only vs source only. Yet that wouldn't be possible if a whole bunch of people are putting "hpprgm" extension files around that in reality are just plain text. I am encouraging people to look at that as an executable (which it is) versus a text file.

[Marcio]

I think it would be nice to have the option to protect the code just like the 50g does. Some of these programs carry a lot of work and dedication, others might have private data bank.

Will this be addressed in the next firmware update?

Thanks.

Marcio

[bobkrohn]

Please Please Please Please Please Please

Let's keep the conversation and enthusiasm going on Source Code "containers".

AND

getting the Connectivity Kit working or creating a reliable alternate.

(Attention: eried & debrouxl who are apparently the ones who have the mental horsepower to do this? )

Simple Code Containers are best. Through this Thread I just learned about yet another programming problem.

White Space Error. Are you kidding? No traps to filter that out?
Gee, if the Code was just simple ASCII only...

I am trying to save Text versions in MS Word but all the leading spaces from formatting the code a lost.

I'd like to try the UltraEdit add on, so will email the person who brought it up


Get'er Done!

[Thomas_Sch]

(03-12-2015 12:20 AM)bobkrohn Wrote:  ... I am trying to save Text versions in MS Word but all the leading spaces from formatting the code a lost.

Much better choices for editing & saving source code from Prime are usual programmers editors like notepad++, jedit, SciTE/Scintilla, (programmer's editor of your choice) ....
- http://notepad-plus-plus.org
- http://www.techsupportalert.com/best-fre...editor.htm
They offer neat formating, intending/ unintending, folding, partly syntax highlighting (HP PPL is a little bit related to Python or Pascal .. try the different language settings, using 'Pascal' in Notepad++ works fine for me), block comment, and so on.

In my opinion Text processors like MS Word are a much worse solution.

[Didier Lachieze]

I concur, Notepad++ is great.

[DrD]

(03-12-2015 07:44 AM)Didier Lachieze Wrote:  I concur, Notepad++ is great.

Do you use (prefer) Notepad++ for PRIME programming? If so, do you have any tips you can share on how to integrate it into, or along with the conn kit? (Things like the initial code framework, program transfer to the Virtual Calc and Hdwe Calc, etc).

One major complaint I have with the conn kit is the small font size, which makes it hard for me to see things, and makes debugging more difficult.

[Marcio]

Notepad++ is indeed excellent. The Conkit won't always work here with the prime. After I lost a program I spent the whole day creating, simply because the conkit will lose communication with the prime If I click the save button - I can actually see that the progress bar gets stuck in the process on the prime and then comm is lost - after that I usually use notepad to create programs, transfer them to conkit so I can start debugging using the emulator. Once everything is in place, I try to transfer the code to the Prime.
Marcio