scott@edson.ee.UAlberta.ca (Scott Stephens) (09/21/89)
I've had some problems with PowerPacker 2.2a. I've packed several files with it, most of them worked fine, but the commands which are normally found in c: haven't worked. The programs I can name offhand are copy and mount, but I tried the others also, and any I executed didn't work. I know its not just because they're in the c: directory, because other files which I put there (like TxEd) packed and worked fine. Copy will work again if I unpack it but when packed it does absolutely nothing. The hunks in these files are nothing out of the ordinary, and PowerPacker doesn't complain about them. I'm using WorkBench 1.3, and I was wondering if anyone else has had this problem, and what they did about it? Thanks in advance. R. Scott Stephens
swarren@eugene.uucp (Steve Warren) (09/21/89)
In article <1989Sep20.221509.4401@edson.ee.UAlberta.ca> scott@edson.ee.UAlberta.ca (Scott Stephens) writes: >I've had some problems with PowerPacker 2.2a. I've packed several files with >it, most of them worked fine, but the commands which are normally found in >c: haven't worked. The programs I can name offhand are copy and mount, but >I tried the others also, and any I executed didn't work. I know its not just >because they're in the c: directory, because other files which I put there >(like TxEd) packed and worked fine. Copy will work again if I unpack it but >when packed it does absolutely nothing. The hunks in these files are nothing >out of the ordinary, and PowerPacker doesn't complain about them. I'm using >WorkBench 1.3, and I was wondering if anyone else has had this problem, and >what they did about it? Thanks in advance. > > I don't remember if copy worked or not. Dir worked, as did delete, but intermittently. I've decided that it's a good idea to leave the C: files unpacked. I've been experimenting with power-packer 2.2a & it seems to me that everything has gotten significantly more fragile when I boot from a disk that is thoroughly packed. By this I mean that I went through a workbench disk and packed every file over 6K. Then I went back and unpacked (actually just copied the files back from the master :-) any files that seemed to be causing problems. The problem I found with copy, delete, dir, etc., was that when I am using these commands I am often typing ahead of AmigaDOS. Packed commands don't like this very much. But I found that if I wait for all activity to cease before issuing the next command it will usually work. If it doesn't work then the error is usually not enough memory to load the command - a pretty amazing error when there is supposed to be 500K still free and the command is dir. The other thing that I don't like is the way the screen flashes with that rippling red color for two or three seconds while the command is decrunched. This is OK for bigger applications that only get executed every once in a while, but it is irritating in the CLI to have the screen flashing at you like this all the time. Solution - don't crunch the C: commands. Especially if you like to run a lot of things resident or run them out of the RAM:. It just slows you down and irritates you, and causes your commands to fail intermittently. (Of course stuff that will be resident can't be packed). But I like the disk savings it gives you on other applications. I got nearly 50% crunched on Preferences and other large programs. So what if it isn't the solve-all for us floppy-bound Amigoids. It sure does help a lot when used with discretion. I am concerned that I seem to be visiting the GURU more than normal. However, as I said I am just experimenting right now. I suspect that I've probably still got something crunched that would better be left alone. --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
rickfor@ncrcae.Columbia.NCR.COM (Rick Forrest) (09/22/89)
Add this to the list: Don't Arun a powerpack'd program under 1.2. That is, if you're running 1.2 Arp, use Run or Runback instead. Arun makes memory go away permanently. Other than that, it's a great util, which i'd be using if I hadn't bought a hard drive. For what it's worth... Rick Forrest.
hrlaser@sactoh0.UUCP (Harv R. Laser) (09/22/89)
In article <1837@convex.UUCP> swarren@eugene.UUCP (Steve Warren) writes: [some stuff about PowerPacker 2.2a deleted] > >The other thing that I don't like is the way the screen flashes with that >rippling red color for two or three seconds while the command is decrunched. Well you can control that, you know. Look in PP2.2a's "Prefs" menu and you'll probably see a checkmark next to "Color 1." Check "pointer" instead and your mouse pointer will flash different colors instead of the whole screen when you run a packed program. What PP needs is a 'config' file to save parameter changes so one can customize the menu choices to his liking and have the program load with those settings each time it's run. PP is a terrific program. The script mode is brilliant. I've seen a lot of expensive commercial software that isn't written as well and doesn't perform as well as this. -- | Harv Laser | SAC-UNIX, Sacramento, Ca. | | Plink: CBM*HARV | UUCP=...pacbell!sactoh0 | | "The human brain is the only computer made of meat" |
new@udel.edu (Darren New) (10/06/89)
In article <1858@sactoh0.UUCP> hrlaser@sactoh0.UUCP (Harv R. Laser) writes: >What PP needs is a 'config' file to save parameter changes >so one can customize the menu choices to his liking and have >the program load with those settings each time it's run. Actually, you could write a program that you give it the name of the screen and window and a menu option. That program would wait for that screen, then that window, then the menu to appear, and then would hook into the input.device and pass on a MenuPick message (or whatever it's called) to the window. Then we would have a generic configuration program for anything with menus. Then we put it in ARexx scripts and viola (:-), we're running menu-only program that don't have ARexx ports from ARexx! Now, could this be done with keys, too? You betcha. Hmmm.... I wish I had as much time as ambitions... -- Darren
tj@shawnee.cis.ohio-state.edu (Todd R. Johnson) (10/06/89)
In article <898@nigel.udel.EDU> new@udel.edu (Darren New) writes:
< Actually, you could write a program that you give it the name of the
< screen and window and a menu option. That program would wait for that
< screen, then that window, then the menu to appear, and then would
< hook into the input.device and pass on a MenuPick message (or whatever
< it's called) to the window. Then we would have a generic configuration
< program for anything with menus. Then we put it in ARexx scripts and
< viola (:-), we're running menu-only program that don't have ARexx
< ports from ARexx!
< -- Darren
Hmmm.... Sounds like you need ScripIt. I believe that it will
do everything that you want and more. Scripit even has an ARexx port
and a program that will take a scripit script and turn it into a
directly executable program. To make scripts you can write them by
hadn or use a recorder to generate an initial script. The entire
package is very nice. I got the latest version off a local BBS.
---Todd
-=-
---Todd
tj@cis.ohio-state.educna@cory.Berkeley.EDU (Na Choon Piaw) (10/06/89)
In article <65039@tut.cis.ohio-state.edu> Todd R. Johnson <tj@cis.ohio-state.edu> writes: > Hmmm.... Sounds like you need ScripIt. I believe that it will >do everything that you want and more. Scripit even has an ARexx port >and a program that will take a scripit script and turn it into a >directly executable program. To make scripts you can write them by >hadn or use a recorder to generate an initial script. The entire >package is very nice. I got the latest version off a local BBS. I downloaded ScripIt, and it certainly looked very nice. The trouble is that it bombs with dmouse, and right now, I need dmouse more than scripit. Anyone knows how to get the two of them working together?? > ---Todd > tj@cis.ohio-state.edu ------------------------------------------------------------------------- Na Choon Piaw P.O Box, 4067, Berkeley, CA 94704-0067 cna@cory.berkeley.edu Disclaimer: I'm speaking only for myself! piaw@ocf.berkeley.edu "Still on honeymoon with his Amiga...." -------------------------------------------------------------------------
ranjit@grad2.cis.upenn.edu (Ranjit Bhatnagar) (10/06/89)
In article <898@nigel.udel.EDU> new@udel.edu (Darren New) writes: >In article <1858@sactoh0.UUCP> hrlaser@sactoh0.UUCP (Harv R. Laser) writes: >>What PP needs is a 'config' file to save parameter changes >>so one can customize the menu choices to his liking and have >>the program load with those settings each time it's run. > >Actually, you could write a program that you give it the name of the >screen and window and a menu option. That program would wait for that >screen, then that window, then the menu to appear, and then would >hook into the input.device and pass on a MenuPick message (or whatever >it's called) to the window. Then we would have a generic configuration >program for anything with menus. Then we put it in ARexx scripts and >viola (:-), we're running menu-only program that don't have ARexx >ports from ARexx! Now, could this be done with keys, too? You >betcha. Hmmm.... I wish I had as much time as ambitions... Amazingly enough, this is exactly what DigiPaint 3 from NewTek does. Every user function (and a few mysterious extras) has a command word associated with it, which you can send from an AREXX script. There's also a big file on the digipaint disk containing the correspondence between keys and command words, so you can change the command-key equivalents by changing this file. There's another file like that for gadgets, but it's in binary, so I don't know how the information is stored. Here, for your amusement, is an AREXX script that will regularize the pallettes of a set of IFF files. Use it for making ANIMs with those silly programs that STILL don't know how to change pallettes between frames. DigiPaint 3 must be running when you invoke this. I haven't actually TESTED this script; it gives you an idea of what's going on, though. /* pals.rexx */ /* before using, bring up DigiPaint and set it to the appropriate screen parameters: interlace or not, width, and height */ /* it's DESTRUCTIVE! Will replace each file with the remapped version. */ address 'DigiPaint' 'Aoff' /* turn everything off */ 'Clsc' /* close digipaint screen so things move faster */ 'Load' /* bring up load picture requester */ 'Fnam'||arg(1) /* specify arg(1) as filename */ 'Dnam' /* clear directory name */ /* I've tested: if you specify '' as directory and 'ram:pics/foo' as filename, it loads ok */ 'Okls' /* accept this filename */ 'Pfil' /* use pallette from first file */ 'Sron' /* shrink HIRES pictures to fit HAM mode */ 'Oklo' /* go ahead with load */ 'Save' /* save possibly shrunk version on top of old version */ 'Okls' do i = 2 to arg() /* for each subsequent file */ 'Load' 'Fnam'||arg(i) 'Dnam' 'Okls' 'Pcur' /* keep current pallette */ 'Oklo' 'Save' 'Okls' end /* there you have it. */ "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
new@udel.edu (Darren New) (10/06/89)
In article <18040@pasteur.Berkeley.EDU> cna@cory.Berkeley.EDU.UUCP (Na Choon Piaw) writes: >I downloaded ScripIt, and it certainly looked very nice. The trouble is So how about sending it to alt.sources.amiga or comp.sources.amiga or whatever? - Darren
ranjit@grad1.cis.upenn.edu (Ranjit Bhatnagar) (10/06/89)
In article <15175@netnews.upenn.edu> ranjit@grad2.cis.upenn.edu.UUCP (Ranjit Bhatnagar) writes: >Here, for your amusement, is an AREXX script that will regularize >the pallettes of a set of IFF files. Use it for making ANIMs with Argh! I can't believe I spelled 'palette' wrong four times in one posting. Sorry... - ranjit "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
hrlaser@sactoh0.UUCP (Harv R. Laser) (10/10/89)
In article <898@nigel.udel.EDU> new@udel.edu (Darren New) writes: >In article <1858@sactoh0.UUCP> hrlaser@sactoh0.UUCP (Harv R. Laser) writes: >>What PP needs is a 'config' file to save parameter changes >>so one can customize the menu choices to his liking and have >>the program load with those settings each time it's run. > >Actually, you could write a program that you give it the name of the >screen and window and a menu option. That program would wait for that >screen, then that window, then the menu to appear, and then would [rest of explanation deleted] Well, guess what.. PowerPacker 2.3a showed up recently (we have it up on People/Link and by now it's probably everywhere) and has a "Save Preferences" feature.. ya just set up PP the way you want it to run everytime, save the prefs from one of its menus, it writes S:PowerPacker.prefs and then looks for and uses that prefs file whenever you run it again. PP's author, Nico Francois also includes in the distribution archive, a little program called PPMORE which will read and display PowerPacked TEXT files directly. Slick. Now all we need is a PPSHOW to directly load and display PowerPacked IFF pictures. -- | Harv Laser | SAC-UNIX, Sacramento, Ca. | | Plink: CBM*HARV | UUCP=...pacbell!sactoh0 | | "The human brain is the only computer made of meat" |