nelson@skid.ps.uci.edu (Matt Nelson) (04/02/91)
Is there a way to RENAME a variable (esp. a directory) on the 48sx? As far as I know, the only way to do this is to recall the variable to the stack, store it under the new name, and delete the original copy of the variable. This is fine for most objects, but renaming directories in this fashion is extremely memory-intensive (it creates a second copy of the entire directory on the stack) and very slow. Try to rename the root directory of a large directory tree this way; there is a good chance that you wont have enough memory, and if you do, it will take mucho time. I do not know how or where variable NAMES are stored and maintained (are they contained within the directory object corresponding to the directory they live in?), but it seems like it should be possible to dive into the bowels of a couple of objects, change a few bytes, and voila, a new name. Am I missing something that already accomplishes this? Is it possible to do? Does anybody else share my frustrations with this simple operation? Do any of you ML programmers out there want to accept the challenge? Just venting a frustration that has been brewing since I got my 28s... -Matt Nelson nelson@psroot.ps.uci.edu
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (04/02/91)
-- In article <nelson.670529956@skid.ps.uci.edu>, nelson@skid.ps.uci.edu (Matt Nelson) writes: >This is fine for most objects, but renaming directories in >this fashion is extremely memory-intensive (it creates a second copy of the >entire directory on the stack) and very slow. Actually, a copy of the directory is not created on the stack, unless you execute NEWOB. You can prove this by changing something in the directory after you have recalled it to the stack -- the stack display will change as well. A copy is created when you store the directory in a new object, or when you edit it. If you are doing the renaming by hand -- recalling the directory, typing the new name, storing it, et cetera -- then part of the speed problem is the time to format and display the directory. You can suppress this by using a program to rename objects: \<< \-> old new \<< old RCL new STO old PURGE \>> \>> This will still use memory because two copies of the directory are in memory at once, but it should be faster. -- edp (Eric Postpischil) "Always mount a scratch monkey." edp@jareth.enet.dec.com
cloos@acsu.buffalo.edu (James H. Cloos) (04/02/91)
In article <nelson.670529956@skid.ps.uci.edu> nelson@skid.ps.uci.edu (Matt Nelson) writes: |Is there a way to RENAME a variable (esp. a directory) on the 48sx? | |As far as I know, the only way to do this is to recall the variable to |the stack, store it under the new name, and delete the original copy of |the variable. This is fine for most objects, but renaming directories in |this fashion is extremely memory-intensive (it creates a second copy of the |entire directory on the stack) and very slow. Try to rename the root |directory of a large directory tree this way; there is a good chance that |you wont have enough memory, and if you do, it will take mucho time. | |I do not know how or where variable NAMES are stored and maintained (are |they contained within the directory object corresponding to the directory |they live in?), but it seems like it should be possible to dive into the |bowels of a couple of objects, change a few bytes, and voila, a new name. | |Am I missing something that already accomplishes this? Is it possible to |do? Does anybody else share my frustrations with this simple operation? |Do any of you ML programmers out there want to accept the challenge? | |Just venting a frustration that has been brewing since I got my 28s... I agree that this would be nice (another benefit is that you wouldn't need to reORDER the directory), but..... The format of teh directories is basically a pointer to the next entry, a name, and an object. The name is stored in size (1 byte long, counts the characters, not the nybbles), the acsii code of the name, and the size again. If the new name is the same length as the old name, fine. You can just go in and poke the new ascii code in. If this is not the case, it will require mem to be shifted around. Shouldn't be too difficult, but I'm tapped out at the moment, so someone else'll have to tackle it. (R&D perhaps [hint]?) I certainly would find such a program useful. As I would about 20 other things I'm working on at the moment [SIGH]. Check out #7059Ch for the address of the current directory. From there you can look thru mem for the entry you want to change. Change the (# of characters times 2) nybbles to the acsii values of the name you want, and voi la': the name has changed! Good luck! -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>
kamidon@zip.eecs.umich.edu (Keith Amidon) (04/02/91)
> Etic Postpischil writes..... >If you are doing the renaming by hand -- recalling the directory, typing >the new name, storing it, et cetera -- then part of the speed problem is >the time to format and display the directory. You can suppress this by >using a program to rename objects: > > \<< \-> old new \<< old RCL new STO old PURGE \>> \>> > >This will still use memory because two copies of the directory are in >memory at once, but it should be faster. > > Wouldn't it be possible to do the purge before the store and thereby get rid of the twice memory requirement also? Am I missing something stupid? I'm afraid I don't have my HP here to test it on. Later, Keith Amidon ---- kamidon@zip.eecs.umich.edu --
rrd@hpfcso.FC.HP.COM (Ray Depew) (04/02/91)
> Is there a way to RENAME a variable (esp. a directory) on the 48sx?
Try this: put the old variable name on Level 2, and the new variable name
on Level 1. Then execute RENAME, which is
<< OVER RCL ROT SWAP PURGE STO >> .
Taken without permission from Bill Wickes' book, "HP28-HP48 Transitions."
I recommend the book highly, for the dozens of other little goodies it has
hidden in it.
Regards
Ray Depew
HP ICBD -- IC's By Decree
rrd@hpfitst1.hp.comrrd@hpfcso.FC.HP.COM (Ray Depew) (04/02/91)
In comp.sys.handhelds, I said: > ... from Bill Wickes' book, "HP28-HP48 Transitions." ^^? > I recommend the book highly, for the dozens of other little goodies it has > hidden in it. Sorry, my fingers slipped on the numeric keys. The book is actually "HP41-HP48 Transitions." I imagine Bill would be surprised to hear that he'd written a 28-48 book! Regards Ray
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (04/02/91)
In article <1991Apr2.140223.7718@zip.eecs.umich.edu>, kamidon@zip.eecs.umich.edu (Keith Amidon) writes: >Wouldn't it be possible to do the purge before the store and thereby get >rid of the twice memory requirement also? Hey, it works. Whadda ya know. If you alter individual things in the directory, what you see on the stack changes, but if you purge the entire directory with PGDIR, the object on the stack remains a pointer to the original directory. -- edp (Eric Postpischil) "Always mount a scratch monkey." edp@jareth.enet.dec.com
rkb@po.CWRU.Edu (Robert K. Brunner) (04/03/91)
In a previous article, mheubi@.itr.uu.ch (Heubi Matthias) says: > >The clean solution is to RCL the object to the stack, PURGE it, and then >STO it under the new name. Tho only problem on this way will be, that >the renamed object is now ordered as the first variable. > Heres a quick program to retain the prior order. Its kind of slow. \<< \-> src dst \<< VARS src RCL src PURGE dst STO OBJ\-> { } SWAP 1 SWAP START SWAP DUP IF src SAME THEN DROP dst END SWAP + NEXT \>> ORDER \>> By the way, isn't the indentation nice. If you print the variable instead of kermiting it, you get fairly nice indentation. Robert brunner@uirvld.csl.uiuc.edu
mheubi@.itr.uu.ch (Heubi Matthias) (04/03/91)
nelson@skid.ps.uci.edu (Matt Nelson) writes: >Is there a way to RENAME a variable (esp. a directory) on the 48sx? >As far as I know, the only way to do this is to recall the variable to >the stack, store it under the new name, and delete the original copy of >the variable. That's true. >This is fine for most objects, but renaming directories in >this fashion is extremely memory-intensive (it creates a second copy of the >entire directory on the stack) and very slow. Try to rename the root >directory of a large directory tree this way; there is a good chance that >you wont have enough memory, and if you do, it will take mucho time. That's wrong! If you recall a directory, no copy is created! try to modify the version on the stack, and then DROP it. The original will also be modified! The clean solution is to RCL the object to the stack, PURGE it, and then STO it under the new name. Tho only problem on this way will be, that the renamed object is now ordered as the first variable. >-Matt Nelson > nelson@psroot.ps.uci.edu -- ----------------------------------------------------------------------- Matthias Heubi / NeXT / Atari ST / HP-48SX / mheubi@itrpe.uu.ch ----------------------------------------------------------------------- ----------------------------------------------------------------------- Matthias Heubi / NeXT / Atari ST / HP-48SX / mheubi@itrpe.uu.ch -----------------------------------------------------------------------
Darren Freimuth <90731919@WSUVM1.CSC.WSU.EDU> (04/03/91)
>Heres a quick program to retain the prior order. Its kind of slow. > >\<< \-> src dst > \<< VARS src RCL src PURGE dst STO OBJ\-> { } SWAP 1 SWAP > START SWAP DUP > IF src SAME > THEN DROP dst > END SWAP + > NEXT > \>> ORDER >\>> >Robert >brunner@uirvld.csl.uiuc.edu One way to speed this program up would be to use the POS and PUT commands built into the calculator (Instead of building another list). The following is a little shorter and most likely faster. \<< \-> src dst \<< VARS src RCL src PURGE dst STO DUP src POS dst PUT \>> ORDER \>> ---------- Darren Freimuth (Electro) <90731919@wsuvm1.csc.wsu.edu> Acknowledge-To: <90731919@WSUVM1>
Dan_Ciarniello@cc.sfu.ca (04/03/91)
Here is a faster version of the Robert Brunner's variable rename routine with order preserved: \<< \-> src dst \<< VARS DUP src RCL src PURGE dst STO src POS dst PUT ORDER \>> \>> Dan Ciarniello Capilano College North Vancouver, B. C.
srosemer@nike.calpoly.edu (Steven Warren Rosemergy) (04/03/91)
brunner posted a program that renames objects; but, he forgot about directories. Here's a program that deals with this: \<< \-> old new \<< VARS old POS VARS SWAP new PUT old RCL IF TYPE 15 == THEN old RCL old PGDIR new STO ELSE old RCL old PURGE new STO END ORDER \>> \>>
rob@ireta.cynic.wimsey.bc.ca (Rob Prior) (04/04/91)
kamidon@zip.eecs.umich.edu (Keith Amidon) writes: > > Etic Postpischil writes..... > >If you are doing the renaming by hand -- recalling the directory, typing > >the new name, storing it, et cetera -- then part of the speed problem is > >the time to format and display the directory. You can suppress this by > >using a program to rename objects: > > > > \<< \-> old new \<< old RCL new STO old PURGE \>> \>> ^^^ I think it will fall apart right here. When you call 'old', it will evaluate the contents of 'old' on the stack, putting you into the directory. My 48sx isn't handy, so I can't try this, but I think that's what will happen. +------------ | rob@ireta.cynic.wimsey.bc.ca | Rob Prior, President, Still Animation Logo Design +------------------------------------------------------------
cook@hplvec.LVLD.HP.COM (Steve Cook) (04/04/91)
> Try this: put the old variable name on Level 2, and the new variable name > on Level 1. Then execute RENAME, which is > << OVER RCL ROT SWAP PURGE STO >> . I think it should be << OVER RCL ROT PURGE SWAP STO >>
sburke@jarthur.Claremont.EDU (Scott Burke) (04/04/91)
Guys, guys, guys... to cheaply RENAME something, do: 'old' RCL 'old' PURGE 'new' STO The PURGE automatically does a NEWOB on the 'old' sitting on the stack, but doesn't require two copies, thus saving memory. Scott.
sburke@jarthur.Claremont.EDU (Scott Burke) (04/04/91)
Someone just complained that the RCL PURGE STO sequence is a bummer because it would re-order the new object to the beginning of the VAR menu. Well, this is going to happen anyways, unless you're STOing into an existing variable. Scott.
ahernsd@mentor.cc.purdue.edu (Dynastar) (04/05/91)
In <298uZ1w163w@ireta.cynic.wimsey.bc.ca> rob@ireta.cynic.wimsey.bc.ca (Rob Prior) writes: >kamidon@zip.eecs.umich.edu (Keith Amidon) writes: >> > \<< \-> old new \<< old RCL new STO old PURGE \>> \>> >I think it will fall apart right here. When you call 'old', it will >evaluate the contents of 'old' on the stack, putting you into the >directory. My 48sx isn't handy, so I can't try this, but I think that's >what will happen. Hmmm, this is interesting. What you say should happen, so I tried a couple examples out. Ok, as an example, I have a directory called MATH in my current directory. First I stored the value 'MATH' in a variable called A. I then pressed A on the menu keys, and, as expected, I went into the MATH directory. I then went back to MATH, and tried this program \<< A \>> Again, as expected, it went into the MATH dir. I went back up, and purged A. I then tried a little more complicated program \<< \-> OLD \<< OLD \>> \>> When this is run with 'MATH' on the stack, it does NOT enter the MATH dir. Instead, it returns the value 'MATH' back to the stack. So it seems that when the program calls the local variable OLD, it does not evaluate it as it does in the previous example where A was recalled. This makes programming a LOT easier and allows you to write a RENAME program like the ones that have been posted. -- Sean Ahern ----------- Purdue University --------- ahernsd@mentor.cc.purdue.edu Dan Quayle: "Japan is an important ally of ours. Japan and the United States of the Western industrialized capacity, 60 percent of the GNP, :-) two countries. That's a statement in and of itself."
edp@jareth.enet.dec.com (Always mount a scratch monkey.) (04/05/91)
In article <298uZ1w163w@ireta.cynic.wimsey.bc.ca>, rob@ireta.cynic.wimsey.bc.ca (Rob Prior) writes... >> > \<< \-> old new \<< old RCL new STO old PURGE \>> \>> > ^^^ > >I think it will fall apart right here. When you call 'old', it will >evaluate the contents of 'old' on the stack, putting you into the >directory. Check the manual, where it explains how different objects are evaluated. In particular, global names and local names are evaluated differently. Evaluation of a global name causes evaluation of its contents. Evaluation of a local name causes the contents to be recalled. -- edp (Eric Postpischil) "Always mount a scratch monkey." edp@jareth.enet.dec.com
kskalb@faui14.informatik.uni-erlangen.de (Klaus Kalb) (04/06/91)
ahernsd@mentor.cc.purdue.edu (Dynastar) writes: >In <298uZ1w163w@ireta.cynic.wimsey.bc.ca> rob@ireta.cynic.wimsey.bc.ca (Rob Prior) writes: >>kamidon@zip.eecs.umich.edu (Keith Amidon) writes: >>> > \<< \-> old new \<< old RCL new STO old PURGE \>> \>> >>I think it will fall apart right here. When you call 'old', it will >>evaluate the contents of 'old' on the stack, putting you into the >>directory. My 48sx isn't handy, so I can't try this, but I think that's >>what will happen. >Hmmm, this is interesting. What you say should happen, so I tried a >couple examples out. [ example deleted ] RTFM Vol.2 ch25 p476 ... When a local name is evaluated, the object stored in the corresponding variable is returned to the stack but is *not* evaluated. ... So what ? -KK