Call a external program from a program
NEDM64
bunch of User RPL programs here...
1. How do I call a external program (in this case, written by me in
User RPL) to execute?
2. Is it possible to run programs, and access variables stored in a SD
card without copying them to { HOME }?
John H Meyers
> How do I call a external program (in this case,
> written by me in User RPL) to execute?
If it is stored in a variable (VAR menu),
its name (within a program) will "call" it, e.g.
\<< DATE TIME 4 RND \>> 'PROG1' STO
\<< PROG1 2 \->LIST "Now" \->TAG \>> 'PROG2' STO
> Is it possible to run programs, and access variables
> stored in a SD card without copying them to { HOME }?
:3:VAR1 RCL
:3:PROG1 EVAL
Note: You can not store (STO) into an existing item in a "port";
to replace an item in a port, you must first delete the original.
[r->] [OFF]
NEDM64
> On Sun, 31 May 2009 17:27:16 -0500, NEDM64 wrote:
> > How do I call a external program (in this case,
> > written by me in User RPL) to execute?
>
> If it is stored in a variable (VAR menu),
> its name (within a program) will "call" it, e.g.
>
> \<< DATE TIME 4 RND \>> 'PROG1' STO
>
> \<< PROG1 2 \->LIST "Now" \->TAG \>> 'PROG2' STO
>
I feel so dumb! But when I use with a program I made to calculate the
parallel between two resitors called "PAR", ex: \<< 5 10 PAR \>> it
works as expected, but when I pair with a UserRPL program I got on the
Internet called KRAFT (a sequence of WAIT and BEEP, a Kraftwerk
excerpt) eg: \<< KRAFT \>>, it doesn't executes KRAFT, but gives me
'KRAFT'...
> > Is it possible to run programs, and access variables
> > stored in a SD card without copying them to { HOME }?
>
> :3:VAR1 RCL
> :3:PROG1 EVAL
>
> Note: You can not store (STO) into an existing item in a "port";
> to replace an item in a port, you must first delete the original.
>
> [r->] [OFF]
Thanks.
\<<OFF\>> EVAL
:P
Erdos New
"NEDM64" <87ne...@gmail.com> wrote in message
news:44d68b85-b0bd-4628...@r34g2000vba.googlegroups.com...
Bill Markwick
>
> I feel so dumb! But when I use with a program I made to calculate the
> parallel between two resitors called "PAR", ex: \<< 5 10 PAR \>> it
> works as expected, but when I pair with a UserRPL program I got on the
> Internet called KRAFT (a sequence of WAIT and BEEP, a Kraftwerk
> excerpt) eg: \<< KRAFT \>>, it doesn't executes KRAFT, but gives me
> 'KRAFT'...
If the KRAFT program is external to yours, then all you need is the
name:
<< yourprogram KRAFT >>
Don't put KRAFT in quotes or program delimiters and it'll run.
If you want to insert the entire KRAFT program so that your program is
portable (no need for the external pgm), the syntax is:
<< yourprogram << entire KRAFT program >> EVAL >>
Bill
Bill
John H Meyers
> \<< KRAFT \>> doesn't executes KRAFT, but gives me 'KRAFT'
Then there is no variable named 'KRAFT' in the current or any higher
calculator directory, in which case the evaluation of the name
leaves the name on the stack.
The 48G series owners manuals have very good explanations
of how everything is evaluated;
I know less about the 49/50 series manuals,
because they were not as inspiring to read :)
If by any chance KRAFT is a command in a library,
that you may have installed after entering your own program,
then just edit your program again (make no changes,
just press ENTER after you start editing).
Each time you complete a UserRPL editing session,
the text that you were editing is automatically
recompiled into a binary program.
During compilation, an unknown word such as KRAFT is searched for
in the current and higher directories, and if not found,
it is searched for in attached libraries (including built-ins).
If the word is found first in a directory, the word is compiled
as a variable name; if the word is found first in a library,
it is compiled as either a library command or internal command;
if the word is not found at all, it is compiled as a variable name.
When the program is decompiled (displayed or being edited),
the word KRAFT looks the same in all cases, but if it got compiled
as a variable name, its evaluation can only evaluate a variable,
whereas if it got compiled as a command (or library command),
it can only execute that command.
One may therefore sometimes need to recompile UserRPL,
to cause the compiler to recognize a newly installed
(or newly attached) library.
No such confusion occurs in SysRPL, where there is a specific unique syntax
for each different type of object, e.g. "ID X" for a "global" variable name.
"LAM X" for a "local" variable name, "ROMPTR mmm nnn" for a library reference,
"PTR nnnnn" for a direct ROM address, etc.
[r->] [OFF]
Horszowski
however a solution which always works independent of the order of
compilation is "KRAFT" OBJ->
Luis
John H Meyers
> I have run into this problem before. I never understood the reason,
> however a solution which always works independent of the order of
> compilation is "KRAFT" OBJ\->
The OBJ\-> or STR\-> command, with a string as its argument,
in fact "compiles" the string at that late time,
while you are running whatever program contains those commands.
So if by that time 'KRAFT' is a variable in the current or higher directory,
then that variable will be evaluated; otherwise if KRAFT is a command
in an attached library, that library command will be performed.
If neither, then 'KRAFT' will still be left on the stack.
Performing object-time compilation every time is slower than just editing
the calling program once, however, so unless you are specially providing for
calling something which metamorphoses back and forth between
being stored in a variable vs. in a library,
it may pay to just edit the calling program once,
after the called program or command has been installed,
which is sufficiently late enough.
[r->] [OFF]