Threaded Mode | Linear Mode

Claudio L. · 03-05-2018, 03:15 AM

(03-04-2018 10:09 PM)The Shadow Wrote: I can think of refinements for both of these, though I'm not sure how practical they are to code:

a) Have LIBRCL take three arguments instead of two. The third one is a default value - if the recall fails, the default gets both returned and LIBSTO'd.

b) Instead of, or in addition to, $HANDLER, there is $DEFAULTS. This is a simple list of names and content, which are to be stored into the directory when the library is attached. There might also be a command LIBDEF which would restore the directory to the default values in case things get borked up.

I personally think that either version of b) is more elegant, provided there's a way to re-run the $HANDLER or restore the $DEFAULTS. Otherwise, programmers will effectively have to implement a) anyway.

I like a) but not as an addition to LIBRCL (BTW, LIBRCL takes a single argument, just like RCL), I think LIBDEFRCL is a more appropriate name (actually, a DEFRCL command should probably exist too as a general purpose RCL that provides a default). This way, the developer still has the option with LIBRCL of detecting the missing data (with IFERR) and doing something other than provide a default, while LIBDEFRCL will simply provide a default, which is a simple solution for 99% of cases. I don't think it should store this default, after all it will always default to this value anyway, so why waste storage.
The advantage of a) vs. b) is that a) works well when there was partial data loss or corruption. What doesn't convince me about b) (or the $HANDLER idea altogether) is that if data gets lost arbitrarily, it doesn't automatically repair it. The user would need to reinstall the library or reset it completely, losing all those settings instead of just the few that got damaged.
Also, I like that LIBCLEAR works well with LIBDEFRCL, since it will reset to default values by simply cleaning up the directory.
Regarding $DEFAULTS, I think individual values using LIBDEFRCL would work better than having a lot of default values in one large list.
Besides, you'd have to have LIBCLEAR also store the $DEFAULTS, or a different command to store the defaults. But then using LIBCLEAR would leave libraries in a non-working state, until new defaults are stored.
I don't like that "gap", so I'll go for LIBDEFRCL as the best solution.
Thanks for the idea!

The Shadow · 03-05-2018, 07:08 PM

Claudio, glad you like it. I for one will prefer LIBDEFRCL to IFERR loops, and you're right, it'll handle the vast majority of cases.

As for the arguments, I guess I had LIBSTO on the brain.

Claudio L. · 03-05-2018, 07:30 PM

(03-05-2018 07:08 PM)The Shadow Wrote: Claudio, glad you like it. I for one will prefer LIBDEFRCL to IFERR loops, and you're right, it'll handle the vast majority of cases.

As for the arguments, I guess I had LIBSTO on the brain.

I fixed the issue you mentioned with names becoming garbled. I also added LIBDEFRCL and... the weekend was over before I could finish the autocomplete. As soon as I get that finished I'll update all ROMs.

The Shadow · 03-05-2018, 10:05 PM

Also, LIBCLEAR doesn't seem to work on a library that has been DETACH'd.

The Shadow · 03-05-2018, 10:20 PM

What's the syntax on LIBDEFRCL? Does the default come before or after the variable name? I'm trying to get ready. Smile

Claudio L. · (This post was last modified: 03-06-2018 05:07 PM by Claudio L..)

(03-05-2018 10:20 PM)The Shadow Wrote: What's the syntax on LIBDEFRCL? Does the default come before or after the variable name? I'm trying to get ready.

DefObject 'Name' LIBDEFRCL

EDIT: Libs were updated to build 1052 with all of the above.

The Shadow · 03-07-2018, 08:25 AM

I've made several libraries now, and there seem to be bugs in CRLIB. After extensive experimentation, I think the problem lies in visible commands that reference other visible commands in the same library. Such programs often seem to fail in freakish ways... Multiple things can be put on the stack, sometimes things from the library directory that were created by other programs entirely.

Claudio L. · 03-07-2018, 03:15 PM

(03-07-2018 08:25 AM)The Shadow Wrote: I've made several libraries now, and there seem to be bugs in CRLIB. After extensive experimentation, I think the problem lies in visible commands that reference other visible commands in the same library. Such programs often seem to fail in freakish ways... Multiple things can be put on the stack, sometimes things from the library directory that were created by other programs entirely.

Please email me a failing example and I'll investigate. Is it still failing after rebuilding the libraries with the latest ROM?
CRLIB does a very delicate, surgical job of re-coding your programs replacing the IDENTs you use in the directory with LIBPTR objects that call the code inside the library. I have made several simple tests to check specific cases and couldn't make it fail, so I need your help in providing code that fails.

The Shadow · 03-07-2018, 05:11 PM

Claudio,

Library sent. And yes, I compiled it multiple times with the latest ROM.

Claudio L. · 03-09-2018, 04:17 PM

(03-07-2018 05:11 PM)The Shadow Wrote: Claudio,

Library sent. And yes, I compiled it multiple times with the latest ROM.

Found the bug and fixed it (all roms were updated to 1055). Turns out the ignore list was counting wrong, and the library object total size was miscalculated, trimming off the last 2 commands of the last program in the library (XDOT), the last command being the end of the secondary, so it kept executing other random objects in memory after the program ended. All fixed now.

The Shadow · 03-09-2018, 04:43 PM

You're a marvel, Claudio! I'll try building again.

Back to solvers, forms, and the plotting engine, then? Not necessarily in that order?

The Shadow · 03-26-2018, 07:55 PM

Any new news? I've been really busy with work lately myself, so I haven't had much chance to do anything with libraries.

Claudio L. · 03-26-2018, 08:15 PM

(03-26-2018 07:55 PM)The Shadow Wrote: Any new news? I've been really busy with work lately myself, so I haven't had much chance to do anything with libraries.

Me too, but I manage to code an extractor that pulled all commands from the source and pass them to the wiki (I invite all of you to look at chapter 6 on the wiki).
The idea is that from time to time I'll just run the extractor again and the chapter 6 main command list will be automatically updated with new commands, and new libraries as well.
The organization is per-library in the newRPL source code, so it's perhaps not the best for a manual. However, I don't want people to start changing the commands from one drawer to the other, since all that work will be overwritten the next time I run the extractor.
Once development stabilizes, we'll never run the automatic extractor again, and we can manually sort the commands in a more "human" way.
What will never get overwritten are the individual descriptions for each command, so we can start documenting all of them right now. I only did 2 for testing (DROP and DEPTH, not exactly the most difficult ones!). The idea is every time somebody creates a page to document a new command, it will use the same template, so all commands will look similar to these two.

So now it begins: the collective effort to document all commands. So far: 2 are hardly complete (the examples should be better).

The Shadow · 03-26-2018, 09:47 PM

Nice! I didn't know that a number of those existed! CMP in particular looks useful. And I kind of like having it broken up by topic, though eventually an alphabetic list of links would be nice.

I notice that UNROT doesn't appear? I know it's on the calculator...

And I'm guessing that RULEMATCH and RULEAPPLY aren't ready for primetime yet?

Claudio L. · 03-27-2018, 03:35 AM

(03-26-2018 09:47 PM)The Shadow Wrote: Nice! I didn't know that a number of those existed! CMP in particular looks useful. And I kind of like having it broken up by topic, though eventually an alphabetic list of links would be nice.

I notice that UNROT doesn't appear? I know it's on the calculator...

Thanks, I didn't notice the missing UNROT, there was a misplaced @HIDE in the sources that was hiding it.
Also, CMP needs to be marked as NEW, didn't catch it.

Regarding the list... there's already one (I'm a step ahead on this one). It's in the Appendix, but since it will pick up commands as they are documented, so far it has a short list of 2 commands.

(03-26-2018 09:47 PM)The Shadow Wrote: And I'm guessing that RULEMATCH and RULEAPPLY aren't ready for primetime yet?

Not quite, you can define very simple replacement rules, but more complex rules cannot be defined yet, I need to rewrite the engine with a new backtracking algorithm.
Also, any commands that don't have a description yet are not implemented.
Commands that show CHANGED have differences in behavior with userRPL, this way it draws the user attention that it merits a good look at the docs before trying to use them.

pier4r · 03-27-2018, 12:55 PM

(03-26-2018 08:15 PM)Claudio L. Wrote: Me too, but I manage to code an extractor that pulled all commands from the source and pass them to the wiki (I invite all of you to look at chapter 6 on the wiki).

Nice! Surely some commands would benefit from further explanation but I am sure it will come slowly.

Where do I find the commands in the code? I tried to brows it, but aside some library files, like library arithmetic, I missed the others somehow. In other words I did not find (quickly) where the command are defined.

From there I can slowly work out the arguments, when the command is not that similar to userRPL.

Claudio L. · 03-27-2018, 03:00 PM

(03-27-2018 12:55 PM)pier4r Wrote: Nice! Surely some commands would benefit from further explanation but I am sure it will come slowly.

I only added a "short" explanation on the command list, so you can have an idea of what the command does before clicking, and also you can search in case you don't know exactly the name of the command. For example, on most browsers you can use Ctrl-F to find for instance "poly" and will take you right to the "Arithmetics and polynomials" category, and once you open it, you can keep searching to quickly jump through all the commands related to polynomials. This has always been a frustration for me when using the AUR (even the bookmarked one) because I can't recall the name of the command I'm looking for, and searching for terms in the entire book turns up too many results, takes a while to find what you are looking for.

(03-27-2018 12:55 PM)pier4r Wrote: Where do I find the commands in the code? I tried to brows it, but aside some library files, like library arithmetic, I missed the others somehow. In other words I did not find (quickly) where the command are defined.

From there I can slowly work out the arguments, when the command is not that similar to userRPL.

The commands are in the 'lib-*.c' files (libraries) and the in-calc help is in the 'lib*.nrpl' files (which can give you additional clues).
They are defined in 2 places within the same library file:
* At the beginning there's a list of macros CMD(...) and ECMD(...) on each library. CMD(...) is used when the command name has "normal" characters and can be used as-is in C, and ECMD(...) for the opposite case. With ECMD(...) you define first a C-friendly name for the command and then the actual calculator command as UTF-8 text. For example, STO is defined using CMD(STO,...) but STO+ is defined as ECMD(STOADD,"STO+",...) because + cannot be used in C.
* Then the actual implementation is inside a switch() statement later on the same file. Once you see for example that STO+ is defined as STOADD, search the file for 'case STOADD:', or in most cases simply 'STOADD:' will suffice to find the actual code of the command.

If you have any questions on particular commands, feel free to email me privately so we don't pollute the forums or the wiki discussion.

What's the next step? On one side I'd say it's wise to first define the bulk of commands that are the same as the 50g. Those are the vast majority and you don't need to look at the code so it's fast to document them (please don't copy the AUR since it's copyright protected, come up with your own original explanations and examples). On the other side, current users can look up those in the AUR in the meanwhile, and really need the new commands explained, or the ones that have changed. So it seems wise as well to start doing the exact opposite. I don't know what's best.
I'd say start with whatever picks your interest, but please stick to the given template so there's consistency.

pier4r · 03-27-2018, 03:33 PM

thanks for the tip, I think it will be useful also for others. If I find time (I have still a couple of obligations open at the moment) I will gladly help. If I go astray from the template, you can always say it (here, wiki, pm, mail, whathever).

The Shadow · 04-04-2018, 02:12 PM

A thought that came to me yesterday: When it comes time to do the plotter, a plot type for implicit functions would be nice. That's a fun (and useful) thing on the Prime.

Claudio L. · 04-04-2018, 03:38 PM

(04-04-2018 02:12 PM)The Shadow Wrote: A thought that came to me yesterday: When it comes time to do the plotter, a plot type for implicit functions would be nice. That's a fun (and useful) thing on the Prime.

Noted, I still haven't touched the subject.
Right now I started on the Forms and UI but then it occurred to me that I needed a few things first:
* Variable properties: A variable can have properties now. I have a couple in mind that will be used by the Forms framework, for example a preferred unit for display.
* An event framework to trigger something when a variable changes, which will help build applications more easily. The idea is that you create a variables, 'A', 'B', for example, and define a program that does for example C=A+B, triggered every time A or B change.

Then that idea mutated into automatic evaluation of a tree of those triggers.
Now you define 'A' with a value, 'B' with a value, and 'C' with the formula 'A+B', and the system will automatically recalculate C every time A or B change.
Then if you define 'D' = 'C^2', changing A will recalculate C that will trigger a recalculation of D.
This way you can work through problems and when you finish, changing the input data gives you a new solution automatically. The Forms would become more of a text template to display these variables, their formulas and the values intermixed with explanations, text and possibly graphics. It leans more towards MathCAD (or SMath studio, same thing) rather than the traditional INFORM.