How to overwrite files with hp49?
Dennis Straley
APPS) I noticed that entering the file in the NAME field executes the file
rather than entering the name in the field. This is not a Good Thing,
especially with experimental hackers operating the equipment. Is there a
workaround for this? The overwriting problem, not the hacker...
Dennis
Veli-Pekka Nousiainen
I think that you're right, but try the following, instead of:
FILE => 'FILE'
--
Regards, VPN
_________________________________________________________
Veli-Pekka Nousiainen ; e-mail= v...@fcsolutions.com
Sokinsuontie 3 A 1, FIN-02760 Espoo, Finland
TEL, WORK= +358 (9) 859 2025 ; (WORK2= +358 (3) 4728 300)
Future Computing Solutions Oy ; URL= http://www.eiffel.fi
_________________________________________________________
HP25,HP28S,HP41CX,HP48SX,HP48GX,HP49G,HP71B,HP75C & TI89
Vote for the "82484A Curve Fit for HP71B" => HP49G !!!
Dennis Straley <dst1...@aol.com> wrote in message
news:20000106014121...@ng-fy1.aol.com...
John H Meyers
> While attempting to overwrite an existing file using the
> TRANSFER menu (under APPS) I noticed that entering the [unquoted]
> file [name]in the NAME field executes the file, rather than
> [just] entering the name in the field. This is not a Good Thing.
By contrast, in the HP48G applications (e.g. Memory Browser), you can
enter unquoted variable names, or even commands, and none of them
will get executed, but the HP49 has a tendency to naively
EVAL everything, instead of taking care to just *compile* it
(because it's easier to take that little shortcut after "palparse",
instead of doing the small extra step of checking for two
special outcomes and handling them slightly differently).
Even in the HP48, the Interactive Stack editor (and maybe the
Matrix Writer, but I haven't checked) did the same, but Kermit
is very careful to never EVAL anything after parsing, thank goodness.
I will shortly post a simple little SysRPL program which I have
on another machine, to show how easily this can be prevented
(but you can't fix the internal applications with it yourself).
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
Sent via Deja.com http://www.deja.com/
Before you buy.
Jean-Yves Avenard
The reason why the HP49G input form now *execute* the command line, as no
link at all with:
"it's easier to take that little shortcut".
On the opposite, it was much more complicated to evaluate the command line
in a safe way (stack can't be corrupted whatever you can do).
In fact, on the HP48, the solution used was extremely simple. Either the
command line return on object, or it will be a string.
So if in any Hp48 InputForm, you type something like:
23 45 +, you will get after ENTER: "23 45 +"
It's a string not a command.
We found that it was more useful to be able to evaluate the command line, so
you could type this kind of RPL expression in a field.
For example, in the solver, you could directly type commands like:
'SIN(X)' INTVX
You would get directly the answer instead of:
Bad Argument Type and "'SIN(X)' INTVX
Also, in Algebraic Mode, it was necessary to get 6 when typing: '1+2+3'.
This kind of operation was nearly impossible with the current HP48
architecture. When you run an InputForm, a lot of objects are put on the
stack. The HP48 design team could not do otherwise, than generating at most
one object and not run it, as this object could corrupt the stack and make
the calculator crash.
One way that could have been possible is:
Before running the command line, save the whole stack in a list, then save
it in a local.. However, it would have been very memory consuming, and
extremely slow.
To prevent this, we've created a "Virtual Stack" on the HP49.
It's a set of APIs that can manipulate a RPL Stack:
-Save it
-Restore it
This virtual stack has a similar structure as a Local Variable stack.
It is made with blocks, that is protected exactly like local variables.
If you trap an error, the Virtual Stack created inside the ERRSET and
ERRTRAP will be automatically deleted, exactly as a local variables bloc
would be.
As a matter of fact, *running* the command line, was a much more difficult
job as you suggest in your previous post.
The Virtual Stack is now used in nearly every HP49 applications.
It is extremely useful (and really fast) when you want to save immediately a
complete stack, without using any memory.
The virtual stack is located inside a string which is the first object in
TEMPOB.
the Algebraic HPBasic makes a big use of the Virtual Stack, and everytime
you run a command, the stack is saved then restored.
It is also a good way to make a secure environment.
As an example.
If in an InputForm you type DROP, you will get the error: "Too Few Argument"
even if the stack was not empty.
Before the HP49 runs the command, it saves first the stack into the Virtual
Stack, then run the command. Once the command has been run, it restores the
Virtual Stack above the new one...
I believe that the Virtual Stack is one of the most powerful tool in the
HP49... It's much faster than manipulating list, especially when using
meta-objects.
You can save almost instantly the Stack into a very secure area.
I believe that the choice used in the HP49 is not a bad one. If it's true
that Global Names get executed, which can be annoying in some cases.. The
ability to run a RPL command inside the InputForm, is a big PLUS over the
HP48.
As a conclusion: if an object is always executed when you validate the
command line, it was not to make things easier... as it was definitely not..
Here is a list of all the APIs to manipulate the Virtual Stack as well as
the description and the structure of the Virtual Stack.
All these entries are supported, you programmer you make use of them as much
as possible..
*
* Virtual Stack Manager
*
* Provides differents APIs to manage a virtual RPN stack
*
* API:
* PopVStack: Pop one stack from the Virtual Stack to the RPN stack
* RPN: obm ... ob1 -> ob'n ... ob'1
* Vir: [ob'n ... ob'1] ->
* GetVStack: Get one stack from the Virtual Stack to the RPN stack
* RPN: obm ... ob1 -> ob'n ... ob'1
* Vir: [ob'n ... ob'1] -> [ob'n ... ob'1]
* PushVStack: Push the RPN stack into the Virtual Stack
* RPN: obn ... ob1 -> obn ... ob1
* Vir: -> [obn ... ob1]
* PushVStack&Clear: Push the RPN stack into the Virtual Stack, and clear the
RPN stack
* RPN: obn ... ob1 ->
* Vir: -> [obn ... ob1]
* PushMetaVStack: Push the meta into the Virtual Stack
* RPN: [B] -> [B]
* Vir: -> [B]
* PushMetaVStack&Drop: Push the meta into the Virtual Stack and drop the
meta
* RPN: [B] ->
* Vir: -> [B]
* GetMetaVStack: Put the meta from the Virtual Stack to the stack
* RPN: obn ... ob1 -> obn ... ob1 [B]
* Vir: [B] -> [B]
* SetMetaVStack: modify the elements of the vstack according to a meta on
the stack
* RPN: [B]' ->
* Vir: [B] -> [B]'
* note: [B] and [B]' MUST be of the same size!
* GetMetaVStackDROP: Put the meta from the Virtual Stack to the stack and
drop the meta' size
* RPN: obn ... ob1 -> obn ... ob1 [ob'n ... ob'1]
* Vir: [ob'n ... ob'1] -> [ob'n ... ob'1]
* PopMetaVStack: Put the meta from the Virtual Stack to the stack
* RPN: obn ... ob1 -> obn ... ob1 [B]
* Vir: [B] ->
* PopMetaVStackDROP: Put the meta from the Virtual Stack to the stack and
drop the meta' size
* RPN: obn ... ob1 -> obn ... ob1 ob'n ... ob'1
* Vir: [ob'n ... ob'1] ->
* DropVStack: Drop the last level from the Virtual Stack
* RPN: ->
* Vir: [B] ->
* PushVStack&Keep: Push the RPN stack above the meta into the Virtual Stack,
and keep the meta
* RPN: obn ... ob1 [B] -> [B]
* Vir: -> [obn ... ob1]
* PushVStack&KeepDROP: Push the RPN stack above the meta into the Virtual
Stack, and keep the exploded meta
* RPN: obn ... ob1 [ob'm ... ob'1] -> ob'm ... ob'1
* Vir: -> [obn ... ob1]
* PopVStackAbove : Pop one virtual stack, push it above the current RPN
stack
* RPN: ob'm ... ob'1 -> obn ... ob1 ob'm ... ob'1
* Vir: [obn ... ob1] ->
* GetElemTopVStack: Get the nth element of the current virtual stack.
Warning: No verification
* RPN: #n1 -> Elem
* Vir: [obn ... ob1] -> obn-n1
* PutElemTopVStack: Put ob as the nth element of the virtual stack. Warning:
No verification
* RPN: ob #n1 ->
* Vir: [obn ... ob1] ->
* GetElemBotVStack: Get the nth element of the current virtual stack.
Warning: No verification
* RPN: #n1 -> obn
* Vir: [obn ... ob1] ->
* PutElemBotVStack: Put ob as the nth element of the virtual stack. Warning:
No verification
* RPN: ob #n1 ->
* Vir: [obn ... ob1] -> obn1
* GetVStackProtectWord: Hacking stuff: Get the protection word of the last
VStack level
* RPN: -> #n
* GetVStackProtectWord: Hacking stuff: Change the protection word of the
last VStack level
* RPN: #n ->
* Vir: change the protection word of the last level
* Structure of the Virtual Stack
* Object Prologue (CSTR): 5 nibbles
* Size Virtual Stack : 5 nibbles
* Size used by VS : 5 nibbles
* Number of blocs : 5 nibbles
* 00000 : 5 nibbles
* Bloc1
* ...
* Blocn
* 00000 : 5 nibbles
*Structure of a bloc:
* Length of a bloc : 5 nibbles
* Protection word : 5 nibbles
* Address Object1 : 5 nibbles
* ....
* Address Objectn : 5 nibbles
* 00000 : 5 nibbles
* Length of a bloc : 5 nibbles
** Author: Jean-Yves Avenard
** Date Written: 4/1/99
ASSEMBLE
ABASE 0
_VSPrologue ALLOC 5
_VSGlobalSize ALLOC 5 =_VSEnd-_VSGlobalSize
_VSRealSize ALLOC 5 =_VSEnd-_VSRealSize
_VSNbBloc ALLOC 5
_VSFirstZeros ALLOC 5
_VSSecondZeros ALLOC 5
_VSEnd ALLOC 0
ABASE 0
_BlocLength1 ALLOC 5 Offset to skip up to BlocEnd
_BlocPW ALLOC 5 Protection word
_BlocZeros ALLOC 5
_BlocLength2 ALLOC 5
_BlocEnd ALLOC 5 Offset to skip before BlocLength1
_BlocElem EQU 4
RPL
Regards
Jean-Yves
"John H Meyers" <jhme...@miu.edu> wrote in message
news:85dqa5$v8p$1...@nnrp1.deja.com...
John H Meyers
Very thorough, interesting and useful post, thank you!
> it was much more complicated to evaluate the command line
> in a safe way (stack can't be corrupted whatever you can do).
Let's see what comes up below.
> In fact, on the HP48, the solution used was extremely simple.
> Either the command line return on object, or it will be a string.
I thought that COS (or CLVAR, or any command) will also return
a string (maybe the original string sent to palparse, or else
the compiled object turned back into a string again?)
> So if in any Hp48 InputForm, you type something like:
> 23 45 +, you will get after ENTER: "23 45 +"
One would have to be very careful about evaluating programs;
a rule which might work is that it could be okay to do so
if every element was valid in an algebraic object, then
you could treat it the same as an algebraic, which might be
to just do sysrpl EVAL if algebraic is valid in the form field,
or else try CRUNCH.
> Also, in Algebraic Mode, it was necessary to get 6
> when typing: '1+2+3'.
This might be covered by the above suggestion.
> This kind of operation was nearly impossible with the current HP48
> architecture. When you run an InputForm, a lot of objects
> are put on the stack. The HP48 design team could not do otherwise,
> than generating at most one object and not run it, as this object
> could corrupt the stack and make the calculator crash.
Valid algebraics generally could only create one result,
except in the sneaky case of using a User-Defined Function
which is not well behaved (as someone recently posted).
> One way that could have been possible is...
> To prevent this, we've created a "Virtual Stack" on the HP49...
Thank you for the excellent and detailed presentation
(which I mailed to myself to save it, even though Eric
probably has it on his current CDROM already :)
> the Algebraic HPBasic ...
That answers someone else's question of the past, too ;)
> I believe that the choice used in the HP49 is not a bad one.
> If it's true that Global Names get executed, which can be
> annoying in some cases.. The ability to run a RPL command
> inside the InputForm, is a big PLUS over the HP48.
Could we say that it takes the place of the CALC form option?
But consider the possibility of using the "safe compile-only"
and then allowing algebraics to be evaluated, or non-user
programs (secondaries) which contain no commands
(and also evaluate them in your virtual stack environment)
> As a conclusion: if an object is always executed when you
> validate the command line, it was not to make things easier...
> as it was definitely not..
I must have meant that this is why user programs do it ;)
BTW, I still don't see how you protect against CLVAR etc.
in the current forms, as "virtual stack" doesn't include
"virtual VAR directory" as well, does it?
> Here is a list of all the APIs to manipulate the Virtual Stack
> as well as the description and the structure of the Virtual Stack...
I hereby nominate you to the Dave Arnett Hall of Fame :)
[for supplying so much very useful information]
Where did he go, anyway --
did someone plug him in backwards one day?