newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[JDW]

(04-10-2017 10:23 AM)pier4r Wrote:  is the firmware stable? May I risk bricking my hp 50g or it is very unlikely?

Let me just say that Stable & Usable are two separate matters. I had it on my 50g and it worked fine within the limited confines of what it can do. But if you are heart-set on installing newRPL thinking that it will be a faster version of your stock firmware features, you will be sadly disappointed. There were too many missing features for me, which is why I reverted. But every 50g user needs to test it for himself to determine what is acceptable.

All said, it won't brick your 50g.

[Vtile]

(04-10-2017 11:36 AM)JDW Wrote:  

(04-10-2017 10:23 AM)pier4r Wrote:  is the firmware stable? May I risk bricking my hp 50g or it is very unlikely?

Let me just say that Stable & Usable are two separate matters. I had it on my 50g and it worked fine within the limited confines of what it can do. But if you are heart-set on installing newRPL thinking that it will be a faster version of your stock firmware features, you will be sadly disappointed. There were too many missing features for me, which is why I reverted. But every 50g user needs to test it (time to time) for himself to determine what is acceptable.

All said, it won't brick your 50g.

I think it needs that addition as it is WIP and sometimes we need to say the obvious out.

[JDW]

(04-10-2017 04:20 PM)Vtile Wrote:  I think it needs that addition as it is WIP and sometimes we need to say the obvious out.

Much more than that needs to be said. It is a "WIP that has no foreseeable conclusion."

I applaud the effort. I really do. I am astounded that anyone even started this terrific effort. And truly, the 50g is the last great piece of calculation hardware that HP ever kicked out. The 50g has so much untapped potential. newRPL too has great potential to unlock the real power of the CPU in the 50g. But alas, there is so much functionality missing. Yes, newRPL is a WIP. But if one were to ask, "about when in the future could we expect to get back all the functionality we have now in oldRPL," no one could even come close to giving a realistic answer.

I don't mean to be negative or pessimistic. I am a realist who has watched this project develop. I have a feel for the development pace. And yes, I know it is a labor of love, not a mega corporation's big-money effort. And my heartfelt thanks goes out to the good people working on it. But thanks and gratefulness is a separate matter for discussion. We are discussing "features" and "when," if ever, those features could be expected to appear in newRPL in stable form.

I don't say this to discourage the effort on newRPL. But someone needs to be open and honest about the facts. At the current pace of development on newRPL, I doubt we'd have the current functionality of the 50g in newRPL even 10 years hence. The page of development really is that slow. That's not a knock at anyone. It's just reality. If I can be proven wrong on that point, PLEASE! Prove me wrong. (I really want to be proven wrong. Really.)

So the question at this stage is, when you install newRPL in its current form, is it useable for you? If it is, outstanding. But if it isn't, please adjust expectations. You won't get all the functionality you want tomorrow, next week, next month or even next year. We need to be realistic about that.

[pier4r]

JDW thanks for sharing, so I rephrase my question.

If I do install the newRPL, I do see that there are no cas commands, ok, but can I use the CAS module through menus? (I suppose no, so I suppose I will lose the cas module)

The same is for plotting, can I still use the plotting menus? (again I suppose no)
Also producing Grobs is helpful (once ahain, I see that so far are not handled), can I use the menus to call a grob? (again a suppose no)

In other words, for the missing newRPL equivalents of userRPL commands, is the system falling back to userRPL ?

In strict terms of programming I do need loops, conditionals, variables, a bit of basic math operations (numerical) and the dir structure. If this is provided, at least for programming, I'm gold.

The problem arise when I want to do some operations with the 50g that I currently do, so plotting, exporting grobs (of long formulas), equation writer, a bit of CAS. If those are nevertheless available, just not in the newRPL version, then that's ok.

[JDW]

(04-11-2017 06:23 AM)pier4r Wrote:  ...for the missing newRPL equivalents of userRPL commands, is the system falling back to userRPL ?

In strict terms of programming I do need loops, conditionals, variables, a bit of basic math operations (numerical) and the dir structure. If this is provided, at least for programming, I'm gold.

Claudio will need to answer that seeing he is the primary designer of newRPL. But as to CAS and the other features you mentioned, as I said in my previous post, we are out of luck on those. You can get an explanation at the following URL regarding CAS, but an explanation isn't the same as actually having CAS:

http://hpgcc3.org/8-newrpl-news/36-algeb...xpressions

Sorry, I wish I was the bearer of better news!

[pier4r]

@JDW, thanks for the further reply. I did not see that post (I checked other links in the hpgcc3 site).

Well then I need to consider, I do believe the newRPL would be enough for most of my programming needs, but I do use also the 50g for plotting, cas and exporting pictures/GROBs (as far as I understood from the status, all this is not yet implemented, and that's ok).
Since I have only one 50g I am not sure I want to give up this.

So for the moment I'm settled to buy a second hp 50g (instead of a nspire/nspireCX/prime) to use it only for the newRPL, that's a great project and I would like to push the 50g a bit more. The other way, hpgcc requires more prerequisites so I deferred it once more. The point is that I have to save a bit before, so I'll have to wait.

[Helix]

NewRPL is still in alpha stage, so it is incomplete. It can't replace a common 50g, except for very limited usages. For example, when a program is edited, it is displayed on a single line, so this is almost unusable for me.
I have several HP 50g, so one of them is dedicated to newRPL. I find interesting to follow and test the evolution of this impressive project, but my current calculator is still the standard HP 50g.

[Claudio L.]

(04-11-2017 06:23 AM)pier4r Wrote:  JDW thanks for sharing, so I rephrase my question.

If I do install the newRPL, I do see that there are no cas commands, ok, but can I use the CAS module through menus? (I suppose no, so I suppose I will lose the cas module)

The same is for plotting, can I still use the plotting menus? (again I suppose no)
Also producing Grobs is helpful (once ahain, I see that so far are not handled), can I use the menus to call a grob? (again a suppose no)

In other words, for the missing newRPL equivalents of userRPL commands, is the system falling back to userRPL ?

In strict terms of programming I do need loops, conditionals, variables, a bit of basic math operations (numerical) and the dir structure. If this is provided, at least for programming, I'm gold.

The problem arise when I want to do some operations with the 50g that I currently do, so plotting, exporting grobs (of long formulas), equation writer, a bit of CAS. If those are nevertheless available, just not in the newRPL version, then that's ok.

This thread has over 500 posts, so it's hard to tell what's done and what's not. The best source for that information is the detailed status page, which gives you a pretty good idea of where we stand in terms of development.
Math capabilities-wise we are at 35% by the number of commands implemented and I believe this percentage to be a good representative number. Most notable missing pieces are:

• Solvers
• Many vector/matrix commands
• Plotting
• GUI
• CAS
  

This last item (CAS) may never happen, as it can take years, so newRPL might have to compromise and stop at the hp48 level, or eventually adopt a foreign CAS (much like the Prime did with XCAS), but that's "To Be Determined" right now.
The first and second items are relatively easy and could be implemented in a couple of months just to misleadingly increase that percentage number (same as statistics commands for example, very easy to implement but there's no need to implement them now just to show off with a simple summation). Instead, the priority now was set on creating a GUI and plotting engine. Right now the ability to plot is being designed and coded/debugged. This is a very dense area with a lot to code and not much to show for it, so it gives the appearance of slow development (it's all happening under the hood right now), but once plotting and the GUI is finished and unleashed, you'll start to see the solvers come live with an actual UI, function plotting, exporting your solutions in HTML with your plots in SVG to import in word processors or to view in browsers, proper customization and mode setting, etc. for a much more "finished product" appearance.
Basically, the current work will add to your hp48 classic stack experience a more modern worksheet model where people will be able to work on problems with less coding and more efficiency. But the engine to power all that will take a while to be released.

As JDW said, this won't brick your calc at all and what's implemented is quite stable, you are free to play with newRPL and go back to stock firmware as many times as you want. I have had newRPL on my calculator for over a year now and it just works (I use it for basic number crunching all the time at work). I don't like releasing code that's buggy because it creates a very negative impression on the product, so the releases are carefully tested beforehand so bugs are minimal (this also gives the appearance of slow development).
The 50g is very hard to brick (I haven't heard of anybody bricking a 50g), and newRPL doesn't touch the boot code at all, so even if you flash garbage disguised as firmware, you can still use certain key combinations (with a paper clip or power on cycle) to recover your calc.

Finally, I'd like to end by saying what's actually implemented:

• Programming
• Stack (including interactive stack with copy/paste)
• Basic arithmetic (reals, integers, variable precision up to 2000 digits, numbers in other bases)
• Basic complex numbers
• Basic symbolic expressions
• Basic matrix/vectors (including symbolic matrices/vectors)
• Lists and most list commands are complete
• Strings with UTF8 encoding (and therefore Unicode support)
• Units: 100% of units supported by the hp50g, plus some additional units, plus new user customizable base units.
• Angles (new concept: angles as objects), including polar vectors and polar complex numbers.
• Menus and custom keyboard definitions (much improved/changed from 50g)
• Command autocomplete
• On-calc help for every command on the menus (long press)
• SD card: Full support for directories, read/write files, etc. (unlike the crippled access on the 50g). This includes support for SDHC cards, up to 4 partitions, etc.
  

So despite the 35% completion, there's a lot to explore and test (277 commands that need beta testers!), and in some areas it leaves the 50g behind (like the ability to fully customize units, replace system unit definitions, or native support for angles and their automatic conversions).
At this level is not ready to replace your old 50g yet (I carry a second 50g with stock firmware with me at all times, use newRPL 90% of the time at work, and when I need something that's not implemented yet I pull the other one).

Your experience might vary, depending on your particular needs, and it will take some adjustment on your part to work with the double menus, the new Alpha mode, the interactive stack, etc. My personal experience is once you get used to it there's no turning back, a feature I can't live without now is the 8-level stack "Undo" on the left cursor, allows me to do a calculation, then go back a couple of steps to review a partial result, maybe change a number and redo. When I use the stock 50g I find myself pressing left cursor only to get disappointed I have to start over.

Give it a shot, play with it and report back, good or bad feedback is welcome.

[pier4r]

(04-11-2017 02:22 PM)Claudio L. Wrote:  Give it a shot, play with it and report back, good or bad feedback is welcome.

Thanks for your very exhaustive post! And yes, what you suggest is a good idea. I will install it and, then, according to myvneeds, I will report what I missed.

About the slow development: development does not appear slow as long as the dev team publish/post something as updates, as you post here. At least this is my perception.

About the plotting engine. Already doing that seems a super huge big task. I do admire your skills, even just in discipline, to go through it! Moreover your (paraphrased) "I do release software without severe bugs" , I know very well that it means a lot of work.

I find the statement where you said that you have two 50g quite reasonable though. If one can have two 50g, it would be great. That would be my long term objective.

[pier4r]

So I'm not sure if I messed around or it is just the 50g. (I used the firmware linked in the first post)

The firmware flashed neatly, like reported here. I was a bit lost due to missing documentation about menus (yes, I read that Claudio either writes documentation or code, hopefully someone can help sooner or later with the docs. Without docs the end user is lost).

So to display the main menu I need to press SYMB, is that wanted?

For storing instead, I need to press "HIST". Is that wanted? I checked this thread back to page 27, but I did not find precise information how the keyboard is mapped. I thought that STO would have been fine, so I wonder why the decision on HIST.

As far as my understanding goes the system should be mostly oriented for RPL programming, but one big limitation , at least for me, would be the missing possibility to connect to the computer via USB. Or at least I did not find out how I can connect to the computer via usb. Using the SD card to load/unload programs and doing tests is possible, but it takes a while.

my home variables were not overwritten by the flash procedure, nor seen by the newRPL.

[Claudio L.]

(04-12-2017 09:29 PM)pier4r Wrote:  So I'm not sure if I messed around or it is just the 50g. (I used the firmware linked in the first post)

The firmware flashed neatly, like reported here. I was a bit lost due to missing documentation about menus (yes, I read that Claudio either writes documentation or code, hopefully someone can help sooner or later with the docs. Without docs the end user is lost).

The UI is still work in progress and things can/may change based on feedback, perhaps I should take a couple of months off coding and write some basic articles on the site to help newcomers.

(04-12-2017 09:29 PM)pier4r Wrote:  So to display the main menu I need to press SYMB, is that wanted?

Yes, newRPL's main menu is at the SYMB key. Since there's no CAS for now, it makes sense to use that key. Remember that APPS is taken by the 2nd menu.

(04-12-2017 09:29 PM)pier4r Wrote:  For storing instead, I need to press "HIST". Is that wanted? I checked this thread back to page 27, but I did not find precise information how the keyboard is mapped. I thought that STO would have been fine, so I wonder why the decision on HIST.

Same reason: Keys A to F are for the top menu, G thru L are for the second menu, hence STO/RCL had to be relocated. HIST was the best candidate.

(04-12-2017 09:29 PM)pier4r Wrote:  As far as my understanding goes the system should be mostly oriented for RPL programming, but one big limitation , at least for me, would be the missing possibility to connect to the computer via USB. Or at least I did not find out how I can connect to the computer via usb. Using the SD card to load/unload programs and doing tests is possible, but it takes a while.

There's no USB driver yet. What exactly is your preferred workflow in this case? I code all my tests directly on-calc, I'm interested to see what you are trying to achieve in terms of development environment for RPL, perhaps we can define some guidelines and I can work towards that goal.

(04-12-2017 09:29 PM)pier4r Wrote:  my home variables were not overwritten by the flash procedure, nor seen by the newRPL.

You mean after you went back to stock firmware your HOME variables were still there? That means you didn't even give newRPL a chance to fill up the memory then! :-)
In any case, do not trust those variables, as they could've been corrupted. The RAM is persistent in the 50g (unlike most hardware nowadays), and newRPL has no reason to clear up unused RAM, but uses whatever it can take, and only does garbage collection when it fills up all the memory. In your case, it seems you didn't create enough objects to fill up the memory all the way to HOME.

[pier4r]

Claudio thanks for the post and yes having a minimal direction helps (what is what on the keyboard) , as always with non trivial products.

My work flow, since I use the 50g and rpl, is always to code with the computer (a very old one with notepad that is doing its job) and then pass the file to the calculator for tests. Once the program is stable, then it may end in the flash or on the SD card to be recalled always, together with a string as help.

Last time I wrote a 3 kb dir (it is in another thread in the forum), and I frequently use the calculator to debug the program.

And yes I did not play long with the newrpl because without the possibility to program with the pc, and without directions (I clicked almost all the keys, along with trying to find a mini guide), I realized that the firmware may fit programs that are already complete but programs that needs to be tested may be required additional effort.

[Vtile]

The documentation (or lack of) have mentioned time to time. I wonder which license type, media format and what distribution platform would be the best for a such loosely defined project. I suspect that the documentation will not be one person project, but for a several persons in community along the way.

Atleast somesort of plan of document palette should be done and each invidual document (manuals) would need to have a standard inbuild (one chapter) about the layout, structure and fields that must be included in every section (ie. documentation of each command needs to have a date of modification on the manual). Also in command description it would be good to have a short "what have changed" section.

I think that wiki based documentation is one possibility, but will it have the correct structure.. I doubt a bit of it.


A) Quick Start quide
B) Advanced User Reference Manual
C) Library manual ??
D) User Reference (propably will be always WIP)

[pier4r]

A wiki would be great, for the structure, it comes slowly. If one tries to be perfect at first, it is doomed to fail. Assume "perfection" leads to little results.

Instead on a wiki (wiki4hp.com for example, or hpgcc3 itself) contributors contribute and there will be a contributor, for example Vtile himself, that would fix the layout.

[Vtile]

(04-13-2017 07:19 PM)pier4r Wrote:  A wiki would be great, for the structure, it comes slowly. If one tries to be perfect at first, it is doomed to fail. Assume "perfection" leads to little results.

Instead on a wiki (wiki4hp.com for example, or hpgcc3 itself) contributors contribute and there will be a contributor, for example Vtile himself, that would fix the layout.

No it needs to have somesort of pre-plan and structure if there is no such, no one can keep track what is deprecated information and what is current and functional etc. Such information is easy to add when someone adds a sentence or two, just add the date you did create the chapter or updated/modified it. You need to take to consideration that ie. NewRPL AURm will be 800+ pages monster when someday it is considered "ready", no one wants to write it twice because the pre-planning were sub-standard.

Wiki itself can serve as a good editing platform, but it is rather heavy in maintenance side (I would assume. I have no experience what you need to take account to run a such server and system) and isn't as straight forward for editors (you need to know the wiki-markup). Wiki also serves better at "dictionaries" not documentations as it is build for encyclopedia publishing. Also the license management might turn a nightmare on the long run, with only a handfull of core contributors to keep it clean. Also what happens to wiki if someone someday ports NewRPL ie. to different hardware .. will it work .. I doupt there would be a mix of two system and everything turns a mess without any informatic value.

One possibility might be a github and openoffice document style lightweight system, but again I don't have any experience on such.

[pier4r]

editing a wiki is way faster than a collaborative rich text document because there are a lot of controls already built in.

Sure you can start to have templates, and you need a minimum organization, but if the process proceeds slowly, you can do it. If the starting barrier is too high, it never starts.


Anyway this is a matter of approach. I saw too many collaborative projects "let's start good, let's define a foolproof standard!" not even finishing page 3.

Instead then you have random contributions, refactored from time to time, that creates stuff like the Mass effect wiki (I never played the game, but the community wiki is very well done. Just read the story line how long is and how well connected is).

You could be amazed what you can achieve with little moderation but otherwise free contributions where the interest is high.

edit: github is even more complicated than a wiki. If the wiki markup is a problem, I imagine a "git pull origin master" /check changes " git add -A , git commit -m 'changed this and that' , git push origin master . Then someone pushes without a pull, and, well, have fun.

[Vtile]

(04-13-2017 08:17 PM)pier4r Wrote:  editing a wiki is way faster than a collaborative rich text document because there are a lot of controls already built in.

Sure you can start to have templates, and you need a minimum organization, but if the process proceeds slowly, you can do it. If the starting barrier is too high, it never starts.


Anyway this is a matter of approach. I saw too many collaborative projects "let's start good, let's define a foolproof standard!" not even finishing page 3.

Instead then you have random contributions, refactored from time to time, that creates stuff like the Mass effect wiki (I never played the game, but the community wiki is very well done. Just read the story line how long is and how well connected is).

You could be amazed what you can achieve with little moderation but otherwise free contributions where the interest is high.

edit: github is even more complicated than a wiki. If the wiki markup is a problem, I imagine a "git pull origin master" /check changes " git add -A , git commit -m 'changed this and that' , git push origin master . Then someone pushes without a pull, and, well, have fun.

Like I said I have no first hand experience, so I do not see the pitfals.

Wiki is great, but I personally afraid that it turns to "spider webbing" of sort, clusters of information behind links and nothing that can be time to time composed to standalone manual.

TXT-file atleast have low requirements.

[attachment=4668]

[Helix]

My 2 cents about documentation:
I'm not inclined to read an 800 page manual in which 80% of the content would repeat the HP 50g behavior.
I think that in a first phase, a synthetic document, listing only the differences between the 50g and newRPL, would be extremely useful. This would be a sort of quick reference guide for HP 50g users. Most of this information is already in this thread. One has to read it from the beginning, collect the concise and clear descriptions written by Claudio in the update posts, and arrange them in a structured form. I can already think about different paragraphs:
- dual menu interface
- interactive stack
- alpha mode
- keyboard shortcuts (would repeat information present in other paragraphs)
- custom keyboard
- units
- SD card commands
…

I don't think that several months are required to produce such a document. I planned to make something like that just for me, but for publishing it I'd have several problems:
- I don't write easily in English, so it would take some time to me, and my writings should be read and corrected by someone else
- I don't know how I would share such a document, as I even don't know HTML
- currently I'm not ready to do that. This is more a winter activity for me.

[Claudio L.]

I like that there's 3 people talking about docs! So far it's been just me and I hate docs.
I'm ready to support *any* community effort to create docs. If you want a wiki, I'll set up a wiki server, if you prefer a different CMS just let me know (as long as it's free and open source, I can install it on my hosting account and get it running for the community).
The website uses Joomla, which is a great CMS but not very good for structured templates, and the articles are stored in a database, so it's not exactly easy to extract them to put in a book if anyone would want one.
Nowadays there's web editors that don't require you to know HTML (Joomla has one included).

There's many options out there, some were mentioned, some were not. An important one is Doxygen, which allows the person that's coding a new command to write structured documentation directly into the source code. It's great because you can keep the docs close to the code, therefore it's easy to keep it updated. However, the output is not very nice and it bloats the source code with entire chapters of text. But it's a valid option.
A wiki is a good option if it can be made secure enough, if it's too open it becomes the target of spam.
There's other CMS systems besides Joomla, but they are all very similar.
Then there's authoring tools: LaTEX is great for book-quality and to keep the format very rigid, but the learning curve will scare contributors away easily. Also, it's not as easy to put the content online as it is with content already in HTML.
The plain text is acceptable as long as the structure is rigid and well defined (rigid as in "I can code a program that scans it and converts to HTML for a website").

Then there's also the on-calc help for each command that is in plain RPL files (plain text). This can be used as a starting point for the command reference, adding more detailed explanations, examples, etc. to the terse 2-line explanation given in the help.
In the meanwhile, I added the ability to take screenshots to the simulator, just choosing an option in the menu will dump the screen as a PNG or any other supported file type. That should help in capturing images for the docs.

[Vtile]

For a wiki the dokuwiki seems to somewhat positive. It is more simplistic that MediaWiki and doesn't use database, but a plain text files for easy access (without wiki system).
This from 10 minute reading and googling.
https://en.wikipedia.org/wiki/DokuWiki
https://www.dokuwiki.org/dokuwiki#

Here is 2nd version of TXT file, with mainly balling the ideas for table of content.