HP Forums

Full Version: [SOLVED] 50g Invalid Syntax error receiving ASCII file
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
This happened before so I switched to binary transfers but now I want to use ASCII and I can transfer a directory just fine using Kermit, to the computer. When trying to transfer the file back to the calculator I get Invalid Syntax.

I tested with 0 TRANSIO and 3 TRANSIO in both directions. I can always copy the directory to the computer but I can never copy it back. What am I missing here?

I am hoping I can fix the corruption http://www.hpmuseum.org/forum/thread-1672.html by restoring the ASCII source to all the code I've written.
Is the proper "%%HP: T(3)A(R)F(.);" header line present at the beginning of the ASCII file?
Yes, I believe so. I won't be able to verify for another few hours until I can start the box I use to communicate with the calculators, but I am sure the header is there and ok (one of the first things I checked yesterday).

This seems to only happen with directories. Single files transfer to and fro just fine.

Update: Yes, this is the first line cut-and-pasted:

Code:
%%HP: T(3)A(R)F(.);
Is it possible that you have any object descriptors in the ascii directories that are "placeholders" instead of the actual objects? Things like SysRPL, Saturn code, library data, system binary numbers, and a few other objects don't get converted into a translatable string by the built-in decompilers. You'll see a generic description for those objects instead; something like:

External
Library Data
Code

Those will cause errors if they are encountered when the 50g is attempting to compile the ascii version of the directories.
No, there should not be. This is all user RPL code and I typically code on the device and then occasionally save backups on a computer via Kermit. I just can't get the directories to download to the device.

In our thread on Roman Numerals I was able to download several people's user RPL programs to time them. So individual ASCII files work, just not the directories. I have never gotten a directory to download in ASCII at all, as far as I can remember.

Is there anybody using Kermit who can do this? I'm not sure where the problem is.
(06-22-2014 03:55 PM)HP67 Wrote: [ -> ]Is there anybody using Kermit who can do this? I'm not sure where the problem is.

Is there an option to use XMODEM (I think you're on Linux IIRC)? Binary transfers are more reliable via XMODEM. Kermit is inherently an ASCII interface and binary transfers have always been slightly twitchy when exchanging data btwn different systems. Also, no idea if you're transferring any Lists in those folders, but there are definitley problems downloading complex lists, though that may have been a Conn4x issue.
The problem is ASCII transfers, not binary. I'm using Kermit on UNIX, not Linux.

I believe I have solved the problem but I don't understand exactly why. My observation before about it not working with directories but working with files was misleading.

After thinking about what DavidM wrote I had a hunch.

Apparently when downloading files that contain the source code for libraries that are installed on the calculator, compilation causes some kind of problem. I suppose this happens with ASCII because it gets compiled whereas the binary is already compiled. Purging the libraries allowed me to download the directories in ASCII.

Does this make any sense? Perhaps the system objected to compiling a command that already exists in an attached library.

Thanks guys.
(06-23-2014 06:40 AM)HP67 Wrote: [ -> ]Perhaps the system objected to compiling a command that already exists in an attached library.

You've hit the nail on the head. Here's another way of looking at what's happening.

The syntax for a valid directory object is as follows:
Code:
DIR
<id> <object definition>
<id> <object definition>
...
END

Put the following string on the stack:
Code:
"DIR MOD 12345 END"

That string is an attempt to build a directory object with a single item -- a number (12345) with the name of "MOD".

Now execute OBJ\->. You should see an error message indicating a Syntax Error, because when "MOD" is encountered by the system compiler, it is recognized as a command instead of a valid ID.

If you change MOD to some other string that isn't already defined, the OBJ/-> command will correctly convert that string to an ID and leave this on the stack:
Code:
1: DIR
   <whatever> 12345
   END

...where <whatever> is the name you chose.

I believe it's the internal compilation step of restoring your directories that is generating the error in your situation. When the compiler encounters the strings in the ID position of your directory objects, they are translated into library command references instead of IDs. This happens as a natural consequence of their existence in a previously-installed library. A library command reference is not a valid ID, hence the syntax error.
Thanks. That's a good explanation. It seems like this problem could come up in other ways then also, whenever a piece of ASCII code was downloaded with a directory name that collides with any global name.
Reference URL's