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

[pier4r]

For the wiki I could start (slowly but steady) on wiki4hp. Finally we can use that site, that I already heavily used in 2013. Bruce made me admin too but I don't know if Claudio is OK with it (I mean having the content decoupled from his site) . Otherwise just integrate a dokuwiki and I think we are good (the most portable and full of features that I know. It is used at least by wiki4hp and openwrt).

Then, as MediaWiki and dokuwiki user I have to say that both are not so trivial at the end. Even markdown (another concept whatsoever) needs a bit of time to be mastered. Nevertheless I do assume that if someone is willing to go with through new rpl, then he is also willing to learn a couple of markup commands (and when not, does not matter, one writes another one makes the layout. That's the wiki power).

For the spam. Wiki spam happens only because the wiki is well known (and even wiki4hp struggles with that) or because the editing is open to not registered users. To avoid spam one can allow edits only from registered users and that's it. The community is not so large so it is manageable.

I would really like to have efforts going on one site for the entire community, but when that is not possible I adapt myself. In any case, I do believe that collaborative efforts wins when it is about non commercial endeavors.

[Claudio L.]

(04-14-2017 12:59 PM)pier4r Wrote:  For the wiki I could start (slowly but steady) on wiki4hp. Finally we can use that site, that I already heavily used in 2013. Bruce made me admin too but I don't know if Claudio is OK with it (I mean having the content decoupled from his site) . Otherwise just integrate a dokuwiki and I think we are good (the most portable and full of features that I know. It is used at least by wiki4hp and openwrt).

I do want to keep the project in a single website. It's already too scattered with Sourceforge holding the sources, hpgcc3.org some docs and links, and this forum with most of the info. The idea would be to complement and integrate the docs (or wiki) into the project website. I'm perfectly capable of setting up a wiki on hpgcc3.org if that's the way to go. It's paid hosting so I'm free to install pretty much anything I want.

(04-14-2017 12:59 PM)pier4r Wrote:  Then, as MediaWiki and dokuwiki user I have to say that both are not so trivial at the end. Even markdown (another concept whatsoever) needs a bit of time to be mastered. Nevertheless I do assume that if someone is willing to go with through new rpl, then he is also willing to learn a couple of markup commands (and when not, does not matter, one writes another one makes the layout. That's the wiki power).

As for the backend software to run a wiki, I want a few features that are important for this type of document:
* The markdown language needs to be relatively common, so the docs can be extracted and printed on a book with reasonable ease (not sure any Wiki qualifies for this)
* I want math formulas rendered properly on the wiki (Mathjax support or similar LaTEX compatible rendering).
* I want support to insert images (this is common) but also support to include SVG graphics. This is important so we can create scalable graphics (mostly diagrams and function plots, etc.) that will print on a book with decent quality.

(04-14-2017 12:59 PM)pier4r Wrote:  I would really like to have efforts going on one site for the entire community, but when that is not possible I adapt myself. In any case, I do believe that collaborative efforts wins when it is about non commercial endeavors.

The newRPL project needs to be on its own site because it might (will?) be ported to other hardware platforms once it reaches a certain degree of maturity, or if the 50g hardware starts to disappear. In particular, the Prime port is not so far fetched (if I only had more time...). If it ever gets ported to a TI calculator, being at wiki4hp wouldn't make a lot of sense.

[pier4r]

@claudio: thanks for the clarifications.

Then I would say making a wiki on your site would help everyone that is willing to contribute.

Nice that the newRPL can be ported, I always though it was not so easy to port C code for a certain ISA, at least to other embedded devices from completely different manufacturers, like TI. For android/windows/linux I do believe there are not much problems, since those platforms offers a lot of resources (ram and libraries) normally.

To produce a book from a wiki, I know this feature mostly from mediawiki (you can see it on wikipedia). For dokuwiki I am not sure, there are plugins but I did not test them. The book produced on mediawiki is not bad but it is neither something with ultra great typographic quality. It is always a trade off . I repeat myself saying that better to have content than to have pretty empty or barely useful pages.

Moreover I also think that a wiki with proper taxonomy would be more useful than a book, but it depends on the objectives.

About the pretty latex format, Mathjax is easy to include, and dokuwiki supports it (as well as mediawiki).

About SVGs, I am again not so sure because they can be exploited as code client side (they can be executed) so maybe they are blocked. I wouldn't mind simple images for starting and then maybe an additional upload place (if you can install stuff as you wish, there are forms) to upload svgs and then link them.

[Claudio L.]

(04-14-2017 02:56 PM)pier4r Wrote:  About the pretty latex format, Mathjax is easy to include, and dokuwiki supports it (as well as mediawiki).

About SVGs, I am again not so sure because they can be exploited as code client side (they can be executed) so maybe they are blocked. I wouldn't mind simple images for starting and then maybe an additional upload place (if you can install stuff as you wish, there are forms) to upload svgs and then link them.

I just checked the dokuwiki site and there's an extension to support Mathjax, and also an extension to have an SVG editor to create diagrams directly on the wiki. I'm not sure how good it is, perhaps doing it offline on Inkscape would be better but the good news it's very well supported.
I also read that dokuwiki stores the articles as plain text files rather than a database. I like that for archiving/backup purposes and also for templates (we could create a template for a dummy command, then use it for all commands to get consistent formatting).
This weekend I'll be busy with work but the following one I'll see if I can setup dokuwiki with all these extensions and I can give a few of you access to start creating the basic outline structure, we can fill in the details over time.

[pier4r]

yes dokuwiki can interface with whatever type of database, as well as the simplest one, flat files.

The point is that by default there are not so many version stored. If I#m not mistaken the last 100 version are stored, otherwise one has to change it from the settings.

I used dokuwiki as portable wiki in a portable LAMP environment around 2013 (then I discovered wiki4hp).

For starters I may help extracting info from this site and the already existing documentation (as well as creating entries for the commands listen in the project status), then active users of newRPL may contribute until it gets a windows/linux version or the usb connectivity.

Surely one of the first thing to coordinate is to make a sort of discussion category. One nice example for meta discussion (and once again it shows the power of collaboration) is the original wiki: http://wiki.c2.com/ , well they are changing the wiki engine though.

[Claudio L.]

(04-14-2017 11:01 AM)Vtile Wrote:  Here is 2nd version of TXT file, with mainly balling the ideas for table of content.

I agree docuwiki with plain text files should do the job fine, as long as the templates are followed strictly.
It seems to have namespaces (directories) and then one file per page (article). This works great for the command reference, as each command can have the file named exactly like the command, and for example the files could be put on an SD card and used as an extended help with a simple program that searches for a file and displays the text, expanding the current menu hints.

Enough talking, now I have to setup a wiki server, I'll report back when it's ready (couple of weeks).

[pier4r]

Thumbs up claudio.

On a side note, to show an example about "how do I use the userRPL", I coded this program in 2-3 hours (with interruptions): http://www.hpmuseum.org/forum/thread-816...l#pid71819

Most of the time was taken debugging syntax errors, design errors and missing knowledge about some facts about RPL objects (like FACTORS wants exact numbers).

Now already the comments would be hard to write on the 50g itself, for those I may pass the program with the SD to the 50g after having written it on the PC.

The other problem is debugging. I passed the program to the 50g like 30+ times to fix every time the next error (especially the syntax errors). Doing that with the SD would be a no go for me. If I need the speed on the 50g I would just drop everything and go the hpgcc way (that is a great way) if newRPL would be limited on the SD card.

Consider that I do not use emulators, so I debug on the device (indeed I will assume the shifts will give up soon).

[smartin]

Hello,

Several months ago I discovered the newRPL project, which I’ve been playing with over the past few months. First I’d like to say how impressive a feat newRPL is turning out to be, especially given that it is still “alpha” software and yet it has much more of a late “beta” or production feel (even though there are many commands yet to be implemented).

Initially the main challenge that I faced was that lack of systematic documentation, so I started working through the hundreds of threads (and Claudio’s website) to learn about using newRPL. At that time I started writing a user’s guide to collect all the scattered information together. I have spent some time thinking about a good way to host documentation that anyone in the community could contribute to, and decided on using GitHub along with the lightweight Markdown language. Up until now I didn’t see much in the forum about documentation so these recent posts were quite encouraging. From these recent posts it seems that Claudio would like to keep documentation on his site, using a wiki. But, since I’ve already written up some docs I’d like to point to it here if anyone is interested. It is far from complete, and certainly I'd appreciate any comments/feedback/error corrections:

https://github.com/smartin-calc/newRPL-hp50g-usersguide

I’d like to contribute to the project, so if Claudio sets up a wiki I’d work with that.

Cheers,
Steve

[pier4r]

smart, very nice work!

Kudos!

The problem of github markdown is that is not so immediate for a newcomer to break up in different articles, while a wiki normally is a tad easier.

Nevertheless nice effort!

As soon as Claudio sets up the dokuwiki I do think we can settle the basic taxonomy and template for commands.

Side note: I wonder why people do those useful work and then they do share late thinking it is not useful.

[Claudio L.]

(04-20-2017 12:29 AM)smartin Wrote:  Hello,

Several months ago I discovered the newRPL project, which I’ve been playing with over the past few months. First I’d like to say how impressive a feat newRPL is turning out to be, especially given that it is still “alpha” software and yet it has much more of a late “beta” or production feel (even though there are many commands yet to be implemented).

Initially the main challenge that I faced was that lack of systematic documentation, so I started working through the hundreds of threads (and Claudio’s website) to learn about using newRPL. At that time I started writing a user’s guide to collect all the scattered information together. I have spent some time thinking about a good way to host documentation that anyone in the community could contribute to, and decided on using GitHub along with the lightweight Markdown language. Up until now I didn’t see much in the forum about documentation so these recent posts were quite encouraging. From these recent posts it seems that Claudio would like to keep documentation on his site, using a wiki. But, since I’ve already written up some docs I’d like to point to it here if anyone is interested. It is far from complete, and certainly I'd appreciate any comments/feedback/error corrections:

https://github.com/smartin-calc/newRPL-hp50g-usersguide

I’d like to contribute to the project, so if Claudio sets up a wiki I’d work with that.

Cheers,
Steve

Kudos for the effort! Yes, we have come to a point on the project where we need docs for people to start using it. I like your picture of the calc with the red diagrams over showing how the menus work (would like to see more of that). I still haven't been able to work on the wiki setup, but when it's ready I invite you to participate (and everyone else willing) in creating a unified manual in a collaborative way.

[smartin]

(04-20-2017 07:49 PM)Claudio L. Wrote:  Kudos for the effort! Yes, we have come to a point on the project where we need docs for people to start using it. I like your picture of the calc with the red diagrams over showing how the menus work (would like to see more of that). I still haven't been able to work on the wiki setup, but when it's ready I invite you to participate (and everyone else willing) in creating a unified manual in a collaborative way.

Diagrams are always good. For this one I took a picture of my calc and then overlaid the call outs. It would be helpful to have some functionality to capture the screen as a graphic image that could be used in the documentation. I tried LCD-> but it doesn't appear to be implemented.

Another thought is whether there should be some kind of formal bug reporting system, instead of reporting back to this forum. I did notice that the sourceforge site of newRPL has ticket functionality, which could be used to report bugs. Should we use that?

Thanks,
Steve

[Claudio L.]

(04-21-2017 01:52 AM)smartin Wrote:  Diagrams are always good. For this one I took a picture of my calc and then overlaid the call outs. It would be helpful to have some functionality to capture the screen as a graphic image that could be used in the documentation. I tried LCD-> but it doesn't appear to be implemented.

Another thought is whether there should be some kind of formal bug reporting system, instead of reporting back to this forum. I did notice that the sourceforge site of newRPL has ticket functionality, which could be used to report bugs. Should we use that?

Thanks,
Steve

I did add screenshot functionality to the PC simulator, so you'll be able to put whatever you want on the screen and save it as a PNG for web use. We also have a couple of keyboard images with the labels changed (thanks to another forum member) that can be used.
I created the wiki site last night, not too happy with the theme, font selection, SVG plugin is not working fine, etc. I need some more time to get this working perfectly, but feel free to take a peek:
Take a look at the bottom line, I hope everyone agrees on the license (after what happened to the WP34 manual, which was open sourced, then closed, then was forked and caused the rage of the original author).

We do have a closed bug tracker that we use for development. Since bug reports need to be screened anyway, people report here and I screen them, then create the ticket only when the bug has been verified.

Those interested in collaborating please send me a PM with a valid email address and I'll create a user for you.

[pier4r]

I do think the wiki looks already awesome. Typographic details can come later.

So can we take it as stable and start to work on it? (once we get in as users)

My idea was to start a talk discussion (creating the namespace "talks:" ) about ideas on the taxonomy of the wiki. The taxonomy can change of course, but having a guideline every time (say the taxonomy is stable for a year before being slightly modified) helps.

[Claudio L.]

(04-21-2017 04:06 PM)pier4r Wrote:  I do think the wiki looks already awesome. Typographic details can come later.

So can we take it as stable and start to work on it? (once we get in as users)

My idea was to start a talk discussion (creating the namespace "talks:" ) about ideas on the taxonomy of the wiki. The taxonomy can change of course, but having a guideline every time (say the taxonomy is stable for a year before being slightly modified) helps.

I think it will be more practical and quick to have a few people (the usual suspects in this thread) define the skeleton for the wiki, everybody else will be able to chime in and write about those individual topics, keeping the structure fixed.
It will be much more efficient this way, as endless discussions will have only one outcome: nothing will get done, as it's hard to please everybody, people gets discouraged after unnecessary criticism, etc.
There's a small group here, skilled and willing to write, and I want that group to feel free to write without being criticized for every word. There will be time later (later="when we have an actual manual") to revisit little things, perhaps change an example with another one, explain better an area where readers have trouble, etc.
Let's get the job done, and be criticized for it afterwards, rather than debate how to do it without ever actually doing it. That's the newRPL way.

[pier4r]

Yeah that's actually is how things get done (nice discussions about this on the c2.wiki, for example:

http://wiki.c2.com/?DoTheSimplestThingTh...ssiblyWork

Whatever the guideline 8I would suggest from Claudio), as I wrote in PM, if we have it fixed somewhere in the wiki, at least we can refer it to.

[Vtile]

The best is the worst enemy of the good and simplicity is elegance. Nice to see that this (doc) is getting somewhere.

[smartin]

(04-21-2017 02:54 PM)Claudio L. Wrote:  I created the wiki site last night, not too happy with the theme, font selection, SVG plugin is not working fine, etc. I need some more time to get this working perfectly, but feel free to take a peek:
Take a look at the bottom line, I hope everyone agrees on the license (after what happened to the WP34 manual, which was open sourced, then closed, then was forked and caused the rage of the original author).

We do have a closed bug tracker that we use for development. Since bug reports need to be screened anyway, people report here and I screen them, then create the ticket only when the bug has been verified.

Those interested in collaborating please send me a PM with a valid email address and I'll create a user for you.

Wiki looks great!

I'm fine with the license.

And, thanks for the info on your bug tracking system. I didn't realize that you did have a formal backend bug tracking system. That is what I was mostly concerned about. I'll just report here in the forums if I notice any problems, since that seems to work for you.

Looking forward to adding content to the wiki!

-Steve

[Claudio L.]

April update! (almost May actually)

The new revision of the firmware has the following changes:

* Menus 1 and 2 can be set black or white independently with flags -15 and -16. Flag cleared means black menus.
* The editor finally decompiles programs in multiple lines, does indentation, and opens in multiple lines when required.
* Commands from the menus that have some structure (IF..THEN.ELSE..END, etc) interact with the editor to format and indent the text appropriately.
* Flag -59 (IIRC) will disable auto indentation in the editor, in case you prefer it that way.
* Implemented MIN and MAX commands.
* Bug fixes here and there.

The next update will focus on adding some commands that are long overdue, so another push in the command count is coming.
Unfortunately, the graphics engine is not ready yet. You might see some commands in the autocomplete suggestions but you shouldn't use them yet, they are not stable or complete. It will be a little longer until that part is finished.

In the next few days I will update also the PC simulator, the new version comes with a visible keyboard (just for looks, it doesn't do anything but looks cool), and most important the option to save screenshots, much needed for the wiki team.

[smartin]

Is there edit functionality for objects already on the stack? I understand how to move up and down the stack using the arrow keys, but it isn't obvious how to edit an object (or program) already on the stack, am I missing something here?

Also, you may want to update the copyright in the latest ROM to 2017.

Thanks,
Steve

[Claudio L.]

(04-29-2017 02:15 AM)smartin Wrote:  Is there edit functionality for objects already on the stack? I understand how to move up and down the stack using the arrow keys, but it isn't obvious how to edit an object (or program) already on the stack, am I missing something here?

Also, you may want to update the copyright in the latest ROM to 2017.

Thanks,
Steve

EDIT command is not implemented yet (I know, kind of trivial now the editor is working...), so there's no functionality to edit an object at an arbitrary place in the stack.
I'll make a note to add it, not sure which key to use but I'll figure something out.
That's why I think I need to make a push to add many commands that seem trivial but are somehow missing. The next update will have some extra functionality.

PS: Thanks for the hint, I need to update the version string.