48-49 Transfer
SsNash
didnt have much luck. Bombed out halfway through transfering the directory
with an invalid something. Then I tried transfering directory to PC then 48
still didn't work.
I have been using a ? as first character in my variable names so I can sort
the usefull functions to the top of the list. Suspect it may be
incompatible with the 48. Are they compatible and any other traps to watch
out for, I thought UserRPL was compatible between the 48 & 49.
Dennis Straley
Make sure the 49 is in APPROX mode as well.
Dennis
David Haguenauer
>didnt have much luck.
Make sure you use ASCII transfer mode. Objects that aren't purely data
shouldn't transferred in binary mode between a 48 and a 49.
>I have been using a ? as first character in my variable names so I can
sort
>the usefull functions to the top of the list. Suspect it may be
>incompatible with the 48.
I don't think this what caused the transfer to fail.
>I thought UserRPL was compatible between the 48 & 49.
It is, under a few conditions. Which is enough to make transfer pretty
hard for most people.
David Haguenauer
http://zap.to/hsimpson
John H Meyers
> Was trying to transfer some equations to a workmate's 48GX
> from my 49G and didn't have much luck.
> Bombed out halfway through transfering the directory
> with an invalid something.
From this we can deduce that you did use "ascii mode" to send,
as is appropriate for UserRPL transfer, because a "binary mode"
transfer would not "bomb out in the middle" (unless for
"Insufficient Memory") -- any "binary" transfer 49 <-> 48
results in an error-free transfer, except that what you
receive is a useless string, e.g. "HPHP49-x....." (the calc
protects itself from the incompatibility of a different-model
binary file by leaving it in the form of the received
byte string, rightfully refusing to "execute" it).
With "ascii" transfer, however, the sending calculator
converts the object to text (as would be displayed if editing),
only the text is sent to the other calc, and finally the
receiving calc re-interprets the text, as if it had been
typed into the command line.
To pinpoint the "Invalid Syntax" error, transfer your program
to the other calc in the form of a text string (more below
about how to do this), then recall the received text string
to the stack and run this syntax-checking program
(which I keep in my HOME directory, stored as 'CHK'):
\<< "" { V } ROT + INPUT \>>
This program displays the string in the editor;
when you press ENTER, its syntax is then checked,
and any error is highlighted.
If you fix all errors, then pressing ENTER leaves
a corrected-syntax string on the stack, and you can convert it
to an object (assuming it is a program, directory, list, etc.)
by using the OBJ\-> or STR\-> function on the text string
(you could include OBJ\-> after INPUT in the above syntax checker,
if you want to automate this).
> Then I tried transfering the directory to PC, then to 48,
> but it still didn't work.
I tried transfering my burned toast to a cold plate first,
but when I finally stuck it in my mouth, it was still inedible :)
However, if you look at your file on your PC, it begins with
a line which resembles this:
%%HP: T(3)A(D)F(.);
The above line tells Kermit what modes to automatically set,
on the receiving calculator, to properly interpret the text
(which is treated as if you had typed it into the editor).
Use Notepad (or equivalent) to insert this new line
below that first line:
C$ $
The above line is an undocumented syntax feature,
which tells the UserRPL interpreter to take the entire
remainder of the text, and make one string object out of it
(be sure to leave one space between the two dollar signs).
Now, when you send this slightly adjusted computer file
to your other calculator, it will arrive as a string,
and you can use the "syntax checker" program on it.
It is also possible to send the original variable as a string
directly from one calculator to the other; you just need to
convert it to a string first (and store it into some other
new variable name, so you can then send it).
To make sure that the conversion to a string does not lose
any significant number digits, first put the calc in STD display
mode, then do 64 STWS to display all bits of any binary values,
then convert the object to a string using either "" + or \->STR
(the former inserts "new line" characters exactly where the editor
would do so; the latter may not break long lines into shorter lines;
\->STR must also be used if the original object is a list).
> I have been using a ? as first character in my variable names
> so I can sort the useful functions to the top of the list.
Variable names like '?XXX' are acceptable on an HP48/49,
although I can't say the same about file names on your PC.
When you try to transfer the whole HP directory as one file,
however, only the name of the directory variable gets used
as a file name on the PC.
> I thought UserRPL was compatible between the 48 & 49.
Mostly, but when you transfer a whole directory at once,
if even one single variable in that directory contains
anything incompatible (e.g. SysRPL/ML), then the whole directory
suffers from the problem of even one incompatible variable.
It is also possible to transfer on a file-by-file basis:
Set the receiving calc to Kermit Server mode
(right-shift, cursor-right); submit a list of file names
(instead of just one file name) to the sending calc.
If an error occurs on just one variable, drop that name
from the list, and continue with the rest.
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
Sent via Deja.com http://www.deja.com/
Before you buy.
James M. Prange
"SsNash" <##ssnash#@bigpond.net.au> wrote:
> Was trying to transfer some equations to a workmates 48GX from my 49G
and
> didnt have much luck. Bombed out halfway through transfering the
directory
> with an invalid something.
By any chance was a global variable renamed to something that the
user's guide says can't be used as a global variable name?
Follow JHM's advice, that should pin it down. If you still have a
problem, please try to be more specific in your next post.
Then I tried transfering directory to PC then 48
> still didn't work.
>
> I have been using a ? as first character in my variable names so I
can sort
> the usefull functions to the top of the list. Suspect it may be
> incompatible with the 48. Are they compatible and any other traps to
watch
> out for, I thought UserRPL was compatible between the 48 & 49.
>
>
Generally, the 49G UserRPL is a superset of the 48G series UserRPL.
That is, the 49G has commands that the 48 series doesn't, so if any of
these new commands are sent to the 48, then the 48 should treat them as
global names. I don't think that this would cause an error in the
transfer, but any program using them won't work correctly after the
transfer.
For transfers from a 48 to a 49G, it is possible that a new 49G command
name could be the same as a 48 global name, which would cause a
problem.
Of course, for transfers in either direction, be sure that your
programs don't contain any SYSEVAL commands.
These considerations also apply to transfers between the 48S and 48G
series.
--
JMP
China Township, Michigan, U.S.A.
ssn
UserRPL program in there amongst all the equations. Forgot it was there and
it probably cause the problem. Your right it was in ASCII mode and it was
exchanching packets until it bombed.
Cant test your theory right now as the 48 has left town. It will be back
again for christmas and I'll try talking to it again then. I'll save your
post for reference.
If I had a 48 rom I could try it in the Emu emulator.
Thanks.
"John H Meyers" <jhme...@miu.edu> wrote in message
news:8v546u$tea$1...@nnrp1.deja.com...
Keith
I am running 1.19-4 , I have transferred a directory as a string as John H
Meyers directed and I get an "Invalid Syntax" error at this line when
running his chk:
A '0_m^2'
the cursor is blinking on the " ' ". Why is this a syntax error?
In fact there are many Invalid Syntax errors. I am using the transfer mode
on both calcs and both have identical transfer options set.
Transferring should be much simpler.
"John H Meyers" <jhme...@miu.edu> wrote in message
news:8v546u$tea$1...@nnrp1.deja.com...
SsNash
wrong:
- Syntax of object has to be correct for both HP48 and HP49 for ascii
transfer. This appears to be what stops a transfer midway through, you get
packet transmission then it stops at the offending code.
- You cant transfer into port memory.
- If using file manager you can transmit multiple object selections but on
the receive end you have to press 'receive' again for each object otherwise
transmission times out.
- Transmitting from I/O menu is time consuming as you choose and transmit
individual files.
- Haven't tried it yet but for a lot of objects using the PC Connectivity
with drag'n'drop as an intermedery looks to be easier.
- Make sure your not short of memory.
- Not sure if you can use the server mode on one of the calculators to let
the other calculator drive the process.
SSNash
"Keith " <cordier...@mediaone.net> wrote in message
news:Os_W5.49750$%P2.58...@typhoon.we.rr.com...
James M. Prange
"SsNash" <##ssnash#@bigpond.net.au> wrote:
> Seems to be a few gotcha's in the transfer process. Correct me if I'm
> wrong:
> - Syntax of object has to be correct for both HP48 and HP49 for ascii
> transfer. This appears to be what stops a transfer midway through,
you get
> packet transmission then it stops at the offending code.
> - You cant transfer into port memory.
> - If using file manager you can transmit multiple object selections
but on
> the receive end you have to press 'receive' again for each object
otherwise
> transmission times out.
> - Transmitting from I/O menu is time consuming as you choose and
transmit
> individual files.
> - Haven't tried it yet but for a lot of objects using the PC
Connectivity
> with drag'n'drop as an intermedery looks to be easier.
> - Make sure your not short of memory.
> - Not sure if you can use the server mode on one of the calculators
to let
> the other calculator drive the process.
>
> SSNash
>
otherwise you'll get an error.
My practice is to transfer to the PC first, so I have a chance to
review it on the big screen before sending it on to the receiving
calculator.
--
JMP
China Township, Michigan, U.S.A.
Veli-Pekka Nousiainen
VPN
> I am running 1.19-4 , I have transferred a directory as a string as John H
> Meyers directed and I get an "Invalid Syntax" error at this line when
> running his chk:
>
> A '0_m^2'
>
> the cursor is blinking on the " ' ". Why is this a syntax error?
> In fact there are many Invalid Syntax errors. I am using the transfer mode
> on both calcs and both have identical transfer options set.
>
> Transferring should be much simpler.
David Haguenauer
>transfer.
I suppose it only has to be correct for the receiving calculator. If it's
on the sending calculator, then the syntax is probably ok for this one.
>- You cant transfer into port memory.
No, not directly.
>- If using file manager you can transmit multiple object selections but
on
>the receive end you have to press 'receive' again for each object
otherwise
>transmission times out.
It should work with the receiving calculator in Kermit server mode.
>- Transmitting from I/O menu is time consuming as you choose and transmit
>individual files.
You can use a list of files (instead of a single name) as the argument to
SEND. The Filer's SEND should be doing exactly this; SEND the list od
selected files.
>- Not sure if you can use the server mode on one of the calculators to
let
>the other calculator drive the process.
The client calculator may do whatever it likes (sen, receive, execute
commands on the server), but the most common use is to use the server as a
multiple, timeoutless RECV.
David Haguenauer
http://zap.to/hsimpson
Keith
special characters that the PC chokes on.
I wish HP spent a little more time on this area rather than the HP49 case.
"SsNash" <##ssnash#@bigpond.net.au> wrote in message
news:90huea$1c8$1...@merki.connect.com.au...
Keith
There does not seem to be any pattern to it.
"Veli-Pekka Nousiainen" <v...@surfeu.fi> wrote in message
news:3a2ca90f$1...@news.vip.fi...
> Exact mode on??? SHould be Approx.
> VPN
> "Keith " <cordier...@mediaone.net> wrote in message
> news:Os_W5.49750$%P2.58...@typhoon.we.rr.com...
> > Hi,
> > I am running 1.19-4 , I have transferred a directory as a string as John
H
> > Meyers directed and I get an "Invalid Syntax" error at this line when
> > running his chk:
> >
> > A '0_m^2'
> >
> > the cursor is blinking on the " ' ". Why is this a syntax error?
> > In fact there are many Invalid Syntax errors. I am using the transfer
mode
> > on both calcs and both have identical transfer options set.
> >
> > Transferring should be much simpler.
> Yep
>
>
John H Meyers
> I have transferred a directory as a string
> and I get an "Invalid Syntax" error at this line:
> A '0_m^2' [ the cursor is blinking on the ' ]
> Why is this a syntax error?
It isn't (neither in Exact nor Approximate mode),
so the real cause is likely to lie elsewhere,
within the entire transferred file,
but since the whole file was not copied here,
we do not know what else it says.
It's not uncommon in various programming languages
for a mistake at one point to eventually produce
a compiler complaint about something else, and
this sort of thing can also happen here.
Similarly in living systems; a headache's cause
may be a liver dysfunction, so a brain scan
may fail to reveal anything at all.
Going even further (as I'm wont to do),
society tends to address its problems of poverty,
crime, drug abuse, ethnic clashes, etc. by focusing
on the most nearby point, and trying to cure it there,
whereas the root cause of all of these things
lies out of sight, deep within human consciousness,
where all root causes of all human relationships
have one common source, and conversely, there is
one basic nourishing element which can be introduced,
which starts at once to eradicate all the symptoms at once.
For 40 years we have been trying to turn society's attention
to realize this one simple thing, but like maneuvering
a massive ship to glide safely into its harbor berth,
when it has originally been veering in the wrong direction,
it's very slow going to turn it 'til it comes 'round right.
> In fact there are many Invalid Syntax errors.
As the Queen of Hearts said to Alice, in Wonderland:
"Begin at the beginning,
and when you come to the end, then stop."
> I am using the transfer mode on both calcs
> and both have identical transfer options set.
With one exception, the sending calc sends everything
necessary to set the receiving calc into the correct mode(s)
anyway, so the receiving calc (assuming use of Kermit)
requires much less attention as to its own mode settings.
That is, the "Translation mode," [for non-ascii characters],
the Angle mode [Degrees, Radians, Grads], and the
Fraction Mark mode (dot vs. comma) are automatically set
by the automatically transmitted header line, e.g.:
%%HP: T(3)A(D)F(.);
In addition, the presence of the above ascii header line
automatically forces ascii receive mode, while the presence
of the alternative binary "HPHP49-x" header automatically forces
binary receive mode (if the receiving calc is of the same,
binary-compatible model, e.g. 48<->48 or 49<->49).
The one thing that is left out on the HP49 side, when the
HP49 is receiving a file, is that it doesn't know whether
it should be in Exact or Approximate mode, to best interpret
a file sent in ascii mode (i.e. as editable text).
If one HP49 is receiving an ascii file from another HP49,
it is best to pre-set the receiving HP49 to Exact mode
(so that it can distinguish exact integers from floating-point);
if an HP49 is receiving a file from an HP48,
it is best to pre-set the HP49 to Approximate mode (so that
integers sent as text by an HP48 without trailing decimal points
will be interpreted as real numbers, as they were in the HP48).
If an HP49 is receiving the ascii file from a computer,
then it depends on how the file was originally generated;
if integers without decimal points should be interpreted
by the HP49 as Exact integer type, the use Exact mode, but
if you want these to be interpreted as real numbers instead,
then use Approximate mode; that's what these modes mean.
The reason for these differences is simply that the HP48
displayed all real numbers, in STD display mode, without
trailing decimal points, which was perfectly reasonable
for all the years before any HP49 appeared.
Then one day, a new object type (Exact integers) manifested
itself in the HP49, and to distinguish this new species
from real numbers, the STD display mode of the HP49
includes a visible trailing decimal point after every
Real integer, while omitting it from every Exact integer;
the HP49 compiler interprets each of these types
separately when in compiling in Exact mode, according
to whether the decimal point is present or not, but
interprets all whole numbers from text input as the
older "real" type when compiling in Approximate mode.
Thus, we use Exact mode when we want an HP49 to act
like a full-blown HP49, and we use Approximate mode
when we want an HP49 to act more like an HP48.
> Transferring should be much simpler.
But now that we understand what's going on,
doesn't that fact alone make it much simpler for us?
More comprehension -> Deeper perspective -> Life is simpler
Wholeness -> Simplicity
http://members.aol.com/MusBuff/page40.htm
(see "Simple Gifts")
"So advanced, it's simple" (slogan of Canon Corp.)
-----
Since Christmas is coming, why don't we let
visions of sugar-plums dance in our heads;
try this, in fact, on any HP49 or HP48 ascii file in your PC:
Change the "ascii header line" to look more like one of these:
HP49 %%HP: T(3)A(D)F(.);
[or]
HP48 %%HP: T(3)A(D)F(.);
Now see whether you can still transmit the file to either
your HP49 or your HP48 (depending on where it came from).
It still works, doesn't it?
Well, then, if the HP49 automatically generated the former
header (with HP49 inserted before %%), this would have no
detrimental effect on any HP49 or HP48 still being able
to receive the file, right?
Well, then, going one step further, suppose that the HP49
decided to do one more new thing: if it saw "HP49" in front
of an ascii header, then it could *automatically* set itself
to Exact mode while compiling the file, just as it does for
the other modes represented by the ascii header, and of course,
if "HP48" appeared instead, then it could set itself to
Approximate mode instead, before compiling the received text.
Then, when sending HP49 -> HP49, it would no longer be necessary
to even remember to set Exact mode; when sending HP48 -> HP49,
various possibilities could be considered:
Recognize "HP48" if edited into PC files, or make
Approximate mode the default, or distinguish "Get from HP49"
from an additional I/O menu choice "Get from HP48"
(forcing Exact vs. Approximate mode in the respective cases).
Instead of "HP48" and "HP49" one could also use something
else, e.g. how about M(E) vs. M(A) for Exact/Approximate modes,
or I(I) vs. I(R) for "interpret integers as Integer vs. Real" ?
Well, that's how it could have been done, but that was as of
the Ghost of Christmas Past, before Santa was shipped the
first so many thousand HP49s to distribute last year;
this year he is probably too interested in new toys
to fiddle with the innards of any old ones.
_____scotty______
48GX "M" model . HP connectivity won't work on my PC . My 48 shows
it is getting the server cmds and it says " connecting" but PC says
not connected .
Did a hardware check , got U_LB OK .
48 rcvs OK but HYPERTERMINAL gets garbadge .
48 sends "a" , HT gets a U.C. "O" !
--------------------------------------------------------------
Keith <cordier...@mediaone.net> wrote in message
news:7oEX5.835$jt2.1...@typhoon.we.rr.com...