SdFiler error Hp50G

[Stevetuc]

New to Hp50G
I moved the two lib files L935 and L936 from SD into Port 2 using the file manager move function. APPS key now lists "SDfiler" but I get the following error message: "EVAL ERROR: Undefined Local Name" when run.
Ive seen a similar issue mentioned in google groups but the given solution of lib reinstall didnt help
http://compgroups.net/comp.sys.hp48/how-...50g/256573
The sd card works fine using regular File Manager. I have a 2 Gb card fat with a 256 mb primary partition for use with the calc.

Anyone know whats causing the error?

[pier4r]

Have you tried to soft restart the 50g?

ON + F3

Install a library, then restart, then check LIB. (right shift , then search for LIB)

[DavidM]

(12-05-2018 08:28 AM)Stevetuc Wrote:  Anyone know whats causing the error?

By any chance do you have "Last Stack" disabled in your MODE settings? If so, try turning that on and give it another try. Some SysRPL programs allocate null-named locals in a way that triggers that error when Last Stack is disabled. It may be that the SDFiler library does that when it starts up.

[Stevetuc]

(12-07-2018 09:40 PM)DavidM Wrote:  

(12-05-2018 08:28 AM)Stevetuc Wrote:  Anyone know whats causing the error?

By any chance do you have "Last Stack" disabled in your MODE settings? If so, try turning that on and give it another try. Some SysRPL programs allocate null-named locals in a way that triggers that error when Last Stack is disabled. It may be that the SDFiler library does that when it starts up.

David. Thank you very much, that nailed it!

[pier4r]

(12-07-2018 09:40 PM)DavidM Wrote:  By any chance do you have "Last Stack" disabled in your MODE settings? If so, try turning that on and give it another try. Some SysRPL programs allocate null-named locals in a way that triggers that error when Last Stack is disabled. It may be that the SDFiler library does that when it starts up.

Impressive knowledge of the system! I wouldn't find such info even after years of intense trial and errors.

[DavidM]

(12-13-2018 07:57 PM)pier4r Wrote:  Impressive knowledge of the system! I wouldn't find such info even after years of intense trial and errors.

The reality is not so impressive, though. I learned this the hard way: one day I noticed that several of my programs were throwing that error right away when I was trying to run them. I knew they had been fine before, and it took me quite a while to narrow down the problem. I had determined that it occurred during NULLLAM allocation, and then did a search on the comp.sys.hp48 newsgroup for "NULLLAM Undefined Local Name". One of the posts found by that search provided the essential clue: I had turned off Last Stack the day before while doing some testing and had forgotten to turn it back on, and that was the cause of the problem. It took me enough time to figure out that I'm not likely to forget it any time soon.

I'm a little surprised that more SysRPL programmers hadn't reported this problem on the comp.sys.hp48 newsgroup, because the Kalinowski/Dominik "Programming in System RPL (Second Edition)" book specifically recommends a method of NULLLAM binding (on page 115) that will trigger this problem. That book is considered by many to be the "SysRPL bible" for the later RPL calculators, so I would have thought this to be a more common issue for SysRPL programmers than it appears to be.

[3298]

(12-13-2018 08:27 PM)DavidM Wrote:  the Kalinowski/Dominik "Programming in System RPL (Second Edition)" book specifically recommends a method of NULLLAM binding (on page 115) that will trigger this problem.

Now I'm intrigued. I consider myself a SysRPL programmer, but since I haven't run into that problem yet (despite using NULLLAMs every now and then) I'd like to know what technique I should avoid. Is it the part about "instead of NULLLAM, any fixed address ROM object can be used"? Because that looks kind of unsafe on first look. I've considered quite some naughty stuff, but I'd always check how the system would respond to it, which I haven't done for that trick yet, For instance. before feeding the output of FPTR2 ^Z>ZH directly into something expecting a HXS: unless the latter command does some type checking or type dispatching things, the prolog won't matter, and the object structure will otherwise be the same; but lengths >16 nibbles would need some checking, because HXS calculations are generally done on 16 nibbles. I'm thorough like that.

[DavidM]

(12-13-2018 11:18 PM)3298 Wrote:  Now I'm intrigued. I consider myself a SysRPL programmer, but since I haven't run into that problem yet (despite using NULLLAMs every now and then) I'd like to know what technique I should avoid. Is it the part about "instead of NULLLAM, any fixed address ROM object can be used"? Because that looks kind of unsafe on first look.

I believe the statement "instead of NULLLAM, any fixed address ROM object can be used" is correct. I've never had a problem with it, at least.

In the "other ways of binding" section on page 115 of the Kalinowski/Dominik book, they state:

Kalinowski/Dominik Wrote:use this, which takes only 12.5 bytes, a savings of 55 bytes:
... NULLLAM TWENTYFOUR NDUPN {}N BIND ...

...and later down the page, a table showing some shortcuts:

Kalinowski/Dominik Wrote:N Commands to create N null named variables
-------------------------------------------
...
N NULLLAM #N NDUPN DOBIND

The problem is that, in both cases, the NULLLAM should be quoted (prefaced with a tick mark [']).

NULLLAM by itself works just fine as long as there is already a bound NULLLAM. When "Last Stack" is turned on, the system maintains needed items in a null-named local, but there may not be any defined NULLLAMs if Last Stack is turned off. That's what causes the problem: the unticked NULLLAM SysRPL command attempts to obtain a reference to the first bound NULLLAM, and if it can't find any it triggers an "Undefined Local Name" error. As long as "Last Stack" is enabled, there will always be at least one defined NULLLAM at run time.

It's fairly easy to see this in operation. Just create a simple SysRPL program with the following contents:

Code:

::
  NULLLAM DROP
;

Run it with "Last Stack" activated. It should execute successfully, though it doesn't do anything very interesting.

Now run it with "Last Stack" turned off. On my calculators, this always causes an "Undefined Local Name" error. Placing a tick mark in front of the NULLLAM fixes the problem.

[DavidM]

I suppose I should follow-up my previous posts by pointing out that in SDFiler (v 1.3), the source code for browser.s has the following lines (line numbers in brackets). I believe this is the source of the problem that Stevetuc encountered:

Code:

[597]  BINT1      ( selected item )
[598]  TrueFalse   ( empty, up/down for selection )
[599]  TrueFalse  ( current sort, exit condition )
[600]  NULLLAM
[601]  BINT14
[602]  NDUPN
[603]  DOBIND

The problem is in line 600, which can easily be fixed in either of two ways:

1) Preface the NULLLAM with a tick mark (') command
2) Replace NULLLAM with a fixed-address, innocuous opcode like TRUE

Option 1 is more clear (readable/maintainable), while option 2 works without the additional 5 nibbles that results from inserting the '.

[3298]

(12-14-2018 12:01 AM)DavidM Wrote:  The problem is that, in both cases, the NULLLAM should be quoted

Oh. That's gotta be a typo, and as such I read right over it without even consciously noticing it. Imagine what happens when your code is called by a program that stored some helper :: whatever ; in the most recent NULLLAM... like something that eats stuff from the stack... All hell's going to break loose. I've never done that obviously, which explains why I never ran into those problems with last stack disabled.
But knowing that TRUE, FALSE, NOP (can push with 'NOP in one command) and friends can safely be used is useful info, thanks. I might use that in the future in place of NULLLAM - but NULLAM itself still has a use: if you use that name for your local variables, there's an equivalent of 2GETEVAL for the first local variable: an unquoted NULLLAM. It might not be quite as fast as 1GETLAM EVAL (not tested, though I'm expecting things to be like that because this is recalling by name instead of by index), but it's shorter, so I prefer placing local-variable-stored subroutines in the first two variables to be able to use that trick.