Re: How about UserRPL command to store "bare" text to SD?

I think that this is veering a bit away from
what I meant to say under this changed Subject line,
as will become clear when we come to the third point below:

On Mon, 12 Jun 2006 21:38:35 -0500, James M. Prange wrote:

Note that Xmodem transfers are also binary only. It seems to me
that it shouldn't be that difficult to implement "ASCII", that is,
decompiled and optionally translated object transfers, for Xmodem,
just as with Kermit transfers. After all, the decompiler, compiler
and KVISLF, KINVISLF, and KVIS "translators" are already
implemented as supported SysRPL commands, and the binary/ASCII
transfer and via IR/Wire system flags are available.

I believe that the connectivity kit (Conn4x) already does exactly this,
sending the conversion programs to the calc upon connection
(a version of the "Xmodem server" is even provided for older HP48S/G),
then simulating "ascii transfer" using Xmodem alone.

Much the same applies to "transfers" to and from the MMC/SD card
starting with the 49g+. Perhaps another system flag (or two) could
be used, making the transfer via IR/USB/RS-232/card, assuming that
the 50g will indeed have both RS-232 compatible and USB I/O
available.

For Kermit, I believe that the existing functionality
takes care of all such matters; for USB, the connectivity kit
should also still take care of it -- except for its being somewhat
cavalier in *evaluating* almost any transferred file whatsosever,
rather than just *storing*without*execution* (HP Kermit properly
guards against inappropriate execution, as do the more advanced
versions of my posted UserRPL text IN/OUT commands for independent
in-calc processing for Emu48 and other equivalent I/O purposes).

In any case, it seems to me that the user should have a choice
of Binary or "ASCII" transfers to the card.

Well, although I started out trying to suggest biting off that whole
thing at once, I am now trying to settle for something more basic
and more fundamentally vital, which is just to be able to store
a string (or hex string) directly to the SD card, verbatim,
without 13 bytes of prefixes ("HPHP49-x" + prolog + length),
and to be able to do this without an extra Filer library
and the entire ARM toolkit, if at all possible;
ideally via a built-in new *user* command, if that could be inspired,
whose function is simply "store this literal string to that file"
(support from the Kinpo ARM OS side might also be involved, though
I don't know exactly how the entire responsibility is divided up).

That alone takes care of the entire "hard part,"
on top of which we can use our own rather simple programming
(even UserRPL with syseval to invoke K[IN]VIS[LF])
to supply everything else that we'd also like to add
for storing our UserRPL programs in the popular Ascii (editable) form,
which is just one of the many uses to which we could put
a more basic and universal "store this literal string as a file" command.

No extra flags would be necessary in this case, because I am
not now proposing "overloading" any existing STO command;
the existing flags control K[IN]VIS[LF] as needed,
and we'll supply the very simple additional programming
to incorporate that part ourselves -- all we need
from anyone else is the basic "store this text as a file" commmand,
and with that alone, "all else can be added unto us" :)

Perhaps KVISLF could even be fixed so that a CRLF pair would be
correctly translated to CRCRLF instead of being left as is.

Have you filed a bug report at bugs.hpcalc.org?
(is there any possibility it might have been a deliberate decision,
for some purpose we haven't thought through yet?)

By the way, I've filed an enhancement request for just the basic
"store this bare string as a file without adding anything" command:
http://bugs.hpcalc.org/long_list.cgi?buglist=216
with the following "pitch":

"Bare" text files from SD can be RCL'ed to stack,
but can not be STO'd back without 13-byte prefix.

Since SD card is an external storage medium,
rather than a port (which is the very reason for the
extra 8 bytes "HPHP49-x" in the prefix), "bare text" literal
string storage (for editors, GPS, surveyors, and all similar
file exchange purposes) would be highly desirable,
and would increase the potential for marketable
external applications using the calculator for SD output.

For longer discussion please see
http://groups.google.com/group/comp.sys.hp48/msg/1d55d1a371887294
(or the entire thread), thanks.

Do you think you could get Joe to pray for it, too? :)
.

Relevant Pages

  • Re: Constructing an existing variable name
    ... The S~N command from the development library will convert a string to a name and vice versa. ... Now the only idea I have is to store all of the variable names for a ...
    (comp.sys.hp48)
  • Re: Using Substr and Regular expressions.
    ... I am attempting to take a string similar to the following as input: ... of the input file and store it as a variable to be used later. ... you can do it on the command line. ... echo response_93_johndoe_1171994965031.xml | ...
    (comp.lang.perl.misc)
  • Command line from php
    ... I am able to run a command line statement from php. ... Now i want to store ... echo $string; ...
    (alt.php)
  • Re: Command line from php
    ... I am able to run a command line statement from php. ... Now i want to store ... echo $string; ...
    (alt.php)
  • TIP #185: Null Handling
    ... nulls, and command modifications for manipulating them. ... Tcl deals with strings, the universal medium for representing data. ... is know and it is an empty string, but if a respondent forgets to give ...
    (comp.lang.tcl)