newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(03-04-2018 06:19 PM)The Shadow Wrote:  I sent you the directory, Claudio.

Do variables not in the $VISIBLE list count as being in the library's private directory? Using the MyHW example from the wiki, would 'WORLD' LIBRCL return "world!"? Likewise, LIBSTO would overwrite it?

No, data your library stores with LIBSTO is not included in the library, but in a separate directory, created automatically when the first variable is stored. 'WORLD' LIBRCL will error 'undefined variable'.
Invisible commands and data included with the library are unnamed, cannot be RCL'd in any way. If you want the user to be able to get some read-only data, you need to make it visible or provide a program that returns it to the stack.

(03-04-2018 06:19 PM)The Shadow Wrote:  If not, how does one initialize library settings?

I'm still debating between 2 methods:
a) Library commands must detect if the data exists (by using IFERR with LIBRCL) and either recreate with LIBSTO or at least provide a default value.
b) Use a $HANDLER program that will be called on installation, removal and have it recreate the variables.

The first solution is more robust, but will add some burden on the programmer. The second solution also adds some burden (to write that handler), and doesn't address the case where the data is not there (for any reason, could've gotten corrupted and removed by the memory checker).

(03-04-2018 06:19 PM)The Shadow Wrote:  Also, I'm assuming that library variables don't conflict in any way with variables on the calculator, correct? So if I had attached MyHW, I could have a variable called WORLD elsewhere and it wouldn't be a problem?

In newRPL variables NEVER conflict with commands. The only issue when you have a variable named the same as a command, is that you cannot use it in ways where the command would be valid. For example
3 'DROP' STO is fine, 'DROP' RCL works as expected, but obviously, if you write just DROP, it will be compiled as a command, not as an identifier. In a symbolic, 'DROP(a)' will fail since it will recognize the command DROP as not allowed in a symbolic. So you can always create these variables, as long as you refer to them by quoted name.
The WORLD case you present is completely different, though. WORLD becomes an internal library command, not exposed to the user, therefore the word WORLD will never be compiled to the library command WORLD (which doesn't exist by the way, only commands in the $VISIBLE list receive a name, all others are null-named.
On the other hand, if you do create a variable with LIBSTO, it will never conflict with other variables. Physically it's stored in a directory '.Settings/LIBDATA/MyHW', that should clarify the effect for your use.