hello,

- If you are OK with having 1 extra variable in your directory, you could
create a sub-directory for your variables, or a list in which you place all
your variables.
- you could 'hide' your variables. any variable located AFTER a 'no-name'
variable (create it using "" S~N) will not be visible. so, what you need to
do is: <<
1 "" S~N IFERR STO THEN DROP END followed by an ORDER command with the
variables that you want to hide located AFTER the empty object.
- I realy do not advise you to use the self modifying program. this is first
realy slow, and second, would not work for a program in library or something
like that...

cyrille

"Mark Edmonds" wrote in message
news:haqdnXqLlJr0kBrVnZ2dnUVZ8gidnZ2d@posted.plusn et...
>I want to save variables for some programs but I don't want to clutter the
> dirs up with vars. I want these variables to save values the program will
> read next time it starts up.
>
> The method I am thinking of now involves embedding the values in the
> program
> object and the program modifying itself and saving the modified version.
> For
> example, I could put a string at the top of a program with delimiters.
> When
> the progam loads, it looks for the delimiters and extracts the values.
> When
> the program exits, it recalls itself, extracts the code either side of the
> delimiters, rebuilds the string around the new values and saves it out.
>
> I'm pretty certain this will work but I am hoping there might be a more
> elegant method. Perhaps a way of making variables hidden? Perhaps a way of
> writing to an object as a file using an offset like random access?
>
> Any recommendations or tips here please?
>
> Many thanks,
>
> Mark
>
>

Cyrille,

Thanks for your help. Before I get into the detail, one question.

Could you explain the S~N bit please?

Is this creating a blank variable containing 1 or a variable called S~N
containing ""?

I haven't come across this S~N syntax before. Is the ~ significant in some
way?

Thanks!

Mark

"cyrille de brebisson" wrote in message
news:g67bnc$5vg$1@usenet01.boi.hp.com...
> hello,
>
> - If you are OK with having 1 extra variable in your directory, you could
> create a sub-directory for your variables, or a list in which you place
all
> your variables.
> - you could 'hide' your variables. any variable located AFTER a 'no-name'
> variable (create it using "" S~N) will not be visible. so, what you need
to
> do is: <<
> 1 "" S~N IFERR STO THEN DROP END followed by an ORDER command with the
> variables that you want to hide located AFTER the empty object.
> - I realy do not advise you to use the self modifying program. this is
first
> realy slow, and second, would not work for a program in library or
something
> like that...
>
> cyrille
>
> "Mark Edmonds" wrote in message
> news:haqdnXqLlJr0kBrVnZ2dnUVZ8gidnZ2d@posted.plusn et...
> >I want to save variables for some programs but I don't want to clutter
the
> > dirs up with vars. I want these variables to save values the program
will
> > read next time it starts up.
> >
> > The method I am thinking of now involves embedding the values in the
> > program
> > object and the program modifying itself and saving the modified version.
> > For
> > example, I could put a string at the top of a program with delimiters.
> > When
> > the progam loads, it looks for the delimiters and extracts the values.
> > When
> > the program exits, it recalls itself, extracts the code either side of
the
> > delimiters, rebuilds the string around the new values and saves it out.
> >
> > I'm pretty certain this will work but I am hoping there might be a more
> > elegant method. Perhaps a way of making variables hidden? Perhaps a way
of
> > writing to an object as a file using an offset like random access?
> >
> > Any recommendations or tips here please?
> >
> > Many thanks,
> >
> > Mark
> >
> >
>
>

On Wed, 23 Jul 2008 10:23:19 -0500, for Mark Edmonds:

There is a SysRPL entry point called "WithHidden"
by means of which any STO/RCL can be diverted
into a "Hidden directory" -- the calculator OS itself
uses that directory for storing things
which it doesn't want you to see,
and some libraries also use this idea
to save non-volatile data and settings.

Since there is only one system-wide "hidden" directory,
only one variable in it can have any given name,
regardless of your "current directory" path.

See the following thread (third article)
for potentially useful UserRPL programs 'Here" and 'Hidden'
of which the latter can be used for "Hidden directory" access
(the version posted works in _all_ HP48/49/50):
http://groups.google.com/group/comp....a151927e0119f/

Older post (with other usage notes):
http://groups.google.com/group/comp....3467dc8825c947

One could also, as previously suggested, use some other directory
to save things, which could be a subdirectory, but equally could be
some higher or "other path" directory, such as the 'CASDIR'
in which the HP49/50 series keeps some permanent information
which you normally don't directly see,
or you could "hide" some variables even in the current directory
(using tricks or third-party "variable hider" programs).

[r->] [OFF]

Mark Edmonds wrote:
> I want to save variables for some programs but I don't want to clutter the
> dirs up with vars. I want these variables to save values the program will
> read next time it starts up.

Put all your variable values into a list and then just save the list in
one variable. That way you only have one variable to worry about rather
than many.

Regards,
--
Bruce Horrocks
Surrey
England
(bruce at scorecrow dot com)

On Jul 23, 4:55 pm, Bruce Horrocks <07....@scorecrow.com> wrote:
> Mark Edmonds wrote:
> > I want to save variables for some programs but I don't want to clutter the
> > dirs up with vars. I want these variables to save values the program will
> > read next time it starts up.
>
> Put all your variable values into a list and then just save the list in
> one variable. That way you only have one variable to worry about rather
> than many.
>
> Regards,
> --
> Bruce Horrocks
> Surrey
> England
> (bruce at scorecrow dot com)

A reminder: when a program is called from within a given directory, it
can only store variables in that directory. But your program might be
some utility of general use which you might call from elsewhere than
its own directory.
Suppose you are in directory {HOME DIR1} and the program is ProgName
in {HOME DIR2}. You can run the program (via
{HOME DIR2 ProgName} RCL EVAL
for instance). But any variables will be stored in DIR1. You can get
around that by changing directories within the program and then
returning to where you were, e.g. by
<< ...
program code which leaves a value val1 on the stack which you want to
store as VAR1 in the program's own directory
PATH SWAP {HOME DIR2} EVAL 'VAR1' STO EVAL
.... >>
Irl

hello

> Could you explain the S~N bit please?

Transform a string less than 255 character into a name object. this allows
to create variable names that would otherwise be illegal.

> I haven't come across this S~N syntax before. Is the ~ significant in some
> way?
yes, it means that the command is bi-directional. ie, it's a S->N AND N->S
in one (ie, it transform a name into a string and a string into a name).
it's a trick that we started using a long time ago to save space and reduce
command number and that is still alive in the so called 'hacker library'.

cyrille

S~N converts "anystring" <-> 'anystring' (now a variable name)
and is a command in the built-in "Development Library"
of HP49/50 series only,
recognized for proper compiling and progam editing
only when that library has been "attached";
keeping flag -86 set will automatically attach it
on "warmstarts" (ON+C), or one can do HOME 256 ATTACH
at any time, before compiling or editing programs.

The set of commands in that library
may be viewed via 256 MENU or 256 TMENU,
and are likely to be explained in any
HP49/50 series "AUR" document.

One can also invoke S~N as #100016h LIBEVAL
on HP49/50 series, which can be compiled or edited
even if library 256 is not attached.

The HP49/50 series S~N command,
like other "user" commands in the "Development Library,"
does argument checking and is thus "safe" to use,
but the following, which work on all HP48/49/50
(including HP48S[X]/G[X]),
directly invoke the same internal functions,
bypassing argument checking,
and thus may cause a crash or memory loss
if lacking the proper object (and type) to work on:

#5B15h SYSEVAL @ "string" -> 'id' a/k/a $>ID

#5BE9h SYSEVAL @ 'id' -> "string" a/k/a ID>$

Safer versions in UserRPL for all HP48/49/50:

"'" SWAP + STR\-> @ can create only "legal" variable names

"" + @ converts any variable name to a string

One can use the internal $>ID to convert even an empty string ""
to a null (illegal) variable name: ''

When the VAR (variables) menu is being displayed,
a null name causes the menu to abruptly terminate,
somewhat like a "newline" inserted into a line of text;
the original reason for this designed behavior
was to conceal one single "hidden directory"
(used by the internal calculator OS)
at the end of the HOME directory.

However, once "hackers" discovered this fact,
they began designing "variable hiders,"
which store a null-named object into any directory,
thus concealing all of the subsequent variables
(only from appearing in the VAR menu, since
'xyz' RCL/STO/PURGE/EVAL continue to work normally anyway).

Besides being a bit awkward to maintain,
directories containing null variables
also introduce one danger, which is that
it becomes possible to purge an "apparently empty" directory
which really isn't empty, and if it then so happens
that any of its variables were "in use" at that time,
the next "garbage collection" may wipe out all user memory.

That's "all the news which fits" (in the time available to write it),
so have a good day!

[r->] [OFF]

On Thu, 24 Jul 2008 06:50:46 -0500, Irl thoughtfully wrote:

> A reminder: when a program is called from within a given directory,
> it can only store variables in that directory.

To store into any path, you can use:

"object" 'name' { path of another directory }
{ EVAL STO } PATH + EVAL

If you will be doing this frequently,
you might make the second line into a callable program:

@ Perform STO into a path provided on level 1:
\<< { EVAL STO } PATH + EVAL \>> HOME 'PSTO' STO

It's even easier to recall a variable from any path:

'name' { path of another directory } SWAP + RCL

The 'PSTO' program will work even if the { path } argument
does not start like this: { HOME dir1 ... }

However, SWAP + RCL works only for paths starting with HOME;
you could eliminate that restriction (accepting UPDIR
or even just any sequence of one or more directory names)
by doing the same thing as in the STO case, e.g.:

@ Perform RCL from a path provided on level 1:
\<< { EVAL RCL } PATH + EVAL \>> HOME 'PRCL' STO

I suppose we could also add something for PURGE:

@ Perform PURGE from a path provided on level 1:
\<< { EVAL PURGE } PATH + EVAL \>> HOME 'PPURG' STO

Gee, this is starting to become somewhat repetitive,
so perhaps we could generalize even further:

@ args { any commands } { path }
\<< { EVAL EVAL } PATH + EVAL \>> HOME 'PRUN' STO

@ Now we can simplify the original functions:
\<< { STO } SWAP PRUN \>> HOME 'PSTO' STO
\<< { RCL } SWAP PRUN \>> HOME 'PRCL' STO
\<< { PURGE } SWAP PRUN \>> HOME 'PPURG' STO

If any of these commands results in an error,
then we remain in the other directory;
it's left as an exercise to adjust PRUN, if desired,
to return to the original path, even after an error.

For running commands in the system "Hidden directory,"
we can instead just use a 'Hidden' function,
which acts on the next object following:

\<< RCLF SIZE 3 < #64037h #370C3h IFTE
#6FD1h SYSEVAL SYSEVAL \>> HOME 'Hidden' STO

Then use:

Hidden STO
Hidden RCL
Hidden PURGE
(Etc.)
Hidden HALT @ now you can inspect the hidden directory

Error trapping (and return to original directory) for 'Hidden'
is already built in, courtesy of the calculator OS.

All of the above work on any HP48/49/50 (even HP48S[X]/G[X])

Make a back up before using 'Hidden'
(just as for any use of SYSEVAL,
where any wrong address or input might lead to big trouble).

Also, do not store into, purge, or re-ORDER
any of these "system" variables in the hidden directory:

{ Alarms UserKeys UserKeys.CRC }

[r->] [OFF]

John H Meyers wrote:
> On Thu, 24 Jul 2008 06:50:46 -0500, Irl thoughtfully wrote:
>
>> A reminder: when a program is called from within a given directory,
>> it can only store variables in that directory.
>
> To store into any path, you can use:
>
> "object" 'name' { path of another directory }
> { EVAL STO } PATH + EVAL

or

"object" 'name' { path of another directory } PUSH EVAL STO POP

Regards,
--
Bruce Horrocks
Surrey
England
(bruce at scorecrow dot com)

On Thu, 24 Jul 2008 17:31:45 -0500, Bruce Horrocks thoughtfully wrote:

> "object" 'name' { path of another directory } PUSH EVAL STO POP

PUSH and POP (save and restore directory path and flags)
are available on all HP49/50 series,
but not on HP48S[X]/G[X]
(previous suggestions work on all HP48/49/50).

They also add a bit of extra execution time
(the things which are saved and restored
are actually saved in a permanent list named 'ENVSTACK'
within 'CASDIR' rather than just in "scratch memory"),
although this may not be significant to everyone.

One helpful thing is that if an error occurs,
you can then just manually POP to go back.

The use of 'Hidden' (store/recall in Hidden directory)
may be the fastest and easiest of all the alternatives,
due in part to that directory's memory location,
which may be why the internal operating system uses its own
Hidden directory for all its own variable storage needs,
as well as to the efficient automatic environment restoration
upon any errors.

Thanks again for noting PUSH and POP.

[r->] [OFF]

"John H Meyers" wrote in message
newsp.ues6fesqnn735j@miu.edu...
X
> but the following, which work on all HP48/49/50
> (including HP48S[X]/G[X]),
> directly invoke the same internal functions,
> bypassing argument checking,
> and thus may cause a crash or memory loss
> if lacking the proper object (and type) to work on:
>
> #5B15h SYSEVAL @ "string" -> 'id' a/k/a $>ID

using this wrap it's a little safer
IF DUP TYPE 2. == THEN ... END @ 2. = "string"

> #5BE9h SYSEVAL @ 'id' -> "string" a/k/a ID>$

using this wrap it's a little safer
IF DUP TYPE 6. == THEN ... END @ 6. = 'GlobalName'

> Safer versions in UserRPL for all HP48/49/50:
>
> "'" SWAP + STR\-> @ can create only "legal" variable names
>
> "" + @ converts any variable name to a string
X
[<-|] [CONT]

Hi all,

Thank you all very much for such useful information - sorry to have been
slow in saying this but I've been side-tracked elsewhere with limited time
and development was on hold.

There is a lot to take in here so bear with me whilst I digest it all and
I'll follow up with my decisions. Meantime, thanks again for such great help
from everyone

Regards,

Mark

"John H Meyers" wrote in message
newsp.uetk2fotnn735j@miu.edu...
> On Thu, 24 Jul 2008 17:31:45 -0500, Bruce Horrocks thoughtfully wrote:
>
> > "object" 'name' { path of another directory } PUSH EVAL STO POP
>
> PUSH and POP (save and restore directory path and flags)
> are available on all HP49/50 series,
> but not on HP48S[X]/G[X]
> (previous suggestions work on all HP48/49/50).
>
> They also add a bit of extra execution time
> (the things which are saved and restored
> are actually saved in a permanent list named 'ENVSTACK'
> within 'CASDIR' rather than just in "scratch memory"),
> although this may not be significant to everyone.
>
> One helpful thing is that if an error occurs,
> you can then just manually POP to go back.
>
> The use of 'Hidden' (store/recall in Hidden directory)
> may be the fastest and easiest of all the alternatives,
> due in part to that directory's memory location,
> which may be why the internal operating system uses its own
> Hidden directory for all its own variable storage needs,
> as well as to the efficient automatic environment restoration
> upon any errors.
>
> Thanks again for noting PUSH and POP.
>
> [r->] [OFF]

The use of a directory for storing the values is currently the front-runner
(for various reasons).

I had been thinking about this and the way I was going to deal with it is:

The storage dir will always be in home - that is fixed so the path is {HOME
MYDIR}

Now, the way I want the program to work is for it to return to the stack and
then be called again from a TMENU option. Each main function within the
program will generate a TMENU with a set of further sub-functions with code
in the TMENU that sets up and calls the routines required. In a way, it is a
bit like adding new menus to the built in menus. As the user is returned to
the stack whilst the program is still active, the user can change dirs at
any point so I can't rely on any path except the storage dir.

Therefore, each time a variable needs to be saved, there is a wrapper which
is:

PATH @ Preserve the current path
{HOME MYDIR} EVAL @ Move to the storage dir
@ -- code for storing variables goes here and when done, the next item on
the stack is the list from the earlier PATH --
EVAL @ Eval the path list to return to original dir.

Selected variables are only stored when a particular subfunction exits and I
use locals for everything else so the overhead of the wrapper code is small.

That's OK isn't it? I just have a nagging feeling I might have simplified it
too far!

Mark

Thanks all for explaining the S~N business. It was completely new to me as
I'm developing on a 48G and although I got a 49G a couple of days ago, I
haven't had time to delve into its more specific features. About the only
thing I've worked out on the 49G so far is that I hate the keyboard and it
seems considerably slower than a 48G. Otherwise, it looks like a very
promising machine in a nasty shell. I'll have to get a 50 soon...

Mark



"Veli-Pekka Nousiainen" wrote in
message news:J8gik.38621$_03.17748@reader1.news.saunalahti .fi...
> "John H Meyers" wrote in message
> newsp.ues6fesqnn735j@miu.edu...
> X
> > but the following, which work on all HP48/49/50
> > (including HP48S[X]/G[X]),
> > directly invoke the same internal functions,
> > bypassing argument checking,
> > and thus may cause a crash or memory loss
> > if lacking the proper object (and type) to work on:
> >
> > #5B15h SYSEVAL @ "string" -> 'id' a/k/a $>ID
>
> using this wrap it's a little safer
> IF DUP TYPE 2. == THEN ... END @ 2. = "string"
>
> > #5BE9h SYSEVAL @ 'id' -> "string" a/k/a ID>$
>
> using this wrap it's a little safer
> IF DUP TYPE 6. == THEN ... END @ 6. = 'GlobalName'
>
> > Safer versions in UserRPL for all HP48/49/50:
> >
> > "'" SWAP + STR\-> @ can create only "legal" variable names
> >
> > "" + @ converts any variable name to a string
> X
> [<-|] [CONT]
>
>

Mark Edmonds wrote:

> That's OK isn't it? I just have a nagging feeling I might have simplified it
> too far!

That's fine. TMENU is a great way to construct programs and very
in-keeping with the style of the calculator.

Regards,
--
Bruce Horrocks
Surrey
England
(bruce at scorecrow dot com)

Yes, agreed but there is one limitation I've just found - local variables.
Difficult to describe but if you have a program that uses locals and creates
a TMENU with code objects in the menu, the menu code cannot reference locals
in the main program. So how do you pass a value to a TMENU program object
without using a saved variable... hmmm... haven't sussed that one yet.

Mark

"Bruce Horrocks" <07.013@scorecrow.com> wrote in message
news:6f3e6eF99plcU1@mid.individual.net...
> Mark Edmonds wrote:
>
> > That's OK isn't it? I just have a nagging feeling I might have
simplified it
> > too far!
>
> That's fine. TMENU is a great way to construct programs and very
> in-keeping with the style of the calculator.
>
> Regards,
> --
> Bruce Horrocks
> Surrey
> England
> (bruce at scorecrow dot com)

On Sat, 26 Jul 2008 15:28:34 -0500, Mark Edmonds wrote:

> each time a variable needs to be saved,
> there is a wrapper which is:
> PATH @ Preserve the current path
> {HOME MYDIR} EVAL @ Move to the storage dir
> @ -- code for storing variables goes here and when done,
> the next item on the stack is the list from the earlier PATH --
> EVAL @ Eval the path list to return to original dir.

Where are the variable values that are to be stored
(and their names)?

Are they on the stack, above the "return to" path?

The various other previous suggestions
avoid ever leaving the "return to" path on the stack:
PUSH (HP49/50 series) saves it in the 'ENVSTACK' list in 'CASDIR',
while my earlier suggestions (for all HP48/49/50)
transfer it to the unseen "return stack" (program execution stack)
in temporary memory, which I think is a faster alternative.

If there are multiple items to store,
it might be more efficient to change paths only once,
storing all of the variables at once.

HP48 and HP49/50 "G" series calculators
can store multiple variables at once using lists,
e.g. { 1 2 3 } { a b c } STO

As to temporary ("local") variables, a TMENU
can reference any temporary variables that already exist
in programs which invoked TMENU.

You can use a HALT in a program,
after it first creates local variables
and then performs TMENU to set up a menu, e.g.:

\<< 123456 \-> xyz
\<< { xyz {"EXIT" \<< 0 MENU CONT \>> } } TMENU HALT \>> \>>

Now 'xyz' is a local variable in the menu;
when you press EXIT, the menu (and variable) both disappear.

There is also a 48/49/50 G-series trick
which allows separately compiled programs
to reference the same local variables;
the trick is simply that all variable names
which begin with one particular special character
are automatically compiled as "local" names (object type 7),
regardless of their context.

The special character is a left-arrow '\<-'
typed via calculator keyboard as Alpha Right-shift Left-arrow
(left cursor key), also produced by 142 CHR.

It is still necessary for some program to create the variable
before another program can use it, e.g.:

\<< 123456 \-> \<-xyz \<< ... PROG2 ... \>> \>> 'PROG1' STO

\<< \<-xyz SQ \>> 'PROG2' STO

Now PROG1 can call PROG2, and PROG2 can use PROG1's local variable.

Of course, a completely different approach might be for a program
to first go to a "private" directory where its variables reside,
then do everything with ordinary, "global" variables,
then return to the original directory after it finishes.

---

Our minds can think of many ways of accomplishing a thing;
if we have time, as well as experience, we can evaluate well,
and judge correctly what will best serve, in the long run,
before rushing to act;
otherwise we bomb or invade first, on ignorant pretexts,
then realize only much later what we could or should have done,
had we grown up and learned first
how to live in greater fullness of life,
and how to deliver that same pre-emptive blessing to others,
so that they would have done the same.

-[ ]-

Mark Edmonds wrote:
> Yes, agreed but there is one limitation I've just found - local variables.
> Difficult to describe but if you have a program that uses locals and creates
> a TMENU with code objects in the menu, the menu code cannot reference locals
> in the main program. So how do you pass a value to a TMENU program object
> without using a saved variable... hmmm... haven't sussed that one yet.

See John H. Meyers' next post about the use of \<- (back arrow) to
create local variables that are shared amongst more than one program.

Regards,
--
Bruce Horrocks
Surrey
England
(bruce at scorecrow dot com)

In article <6f6ofcFa1a4nU1@mid.individual.net>,
Bruce Horrocks <07.013@scorecrow.com> wrote:

> Mark Edmonds wrote:
> > Yes, agreed but there is one limitation I've just found - local variables.
> > Difficult to describe but if you have a program that uses locals and creates
> > a TMENU with code objects in the menu, the menu code cannot reference locals
> > in the main program. So how do you pass a value to a TMENU program object
> > without using a saved variable... hmmm... haven't sussed that one yet.
>
> See John H. Meyers' next post about the use of \<- (back arrow) to
> create local variables that are shared amongst more than one program.
>
> Regards,

Note however that as I understand it those shareable local variable only
exist while the program that creates them is running, so that crating
program must be halted with those variables still in existence and only
ended after those variables are done with.