amoss@SHUM.HUJI.AC.IL (Amos Shapira) (03/06/91)
Hello, What about perl compiling a script and dumping only the script in binary form to disk? I suppose I'm suggesting here the obvious, but I haven't seen any refference to this option on this list. The advantages of this over a simple dump is that you don't generate a copy of the interpreter for every script while you still save the startup overhead. Any other Pro's or Con's? --Amos Shapira C.S. System Group Hebrew University Jerusalem, Israel amoss@shuldig.huji.ac.il
rbj@uunet.UU.NET (Root Boy Jim) (03/07/91)
In article <9103060939.AA07794@shum.huji.ac.il> amoss@SHUM.HUJI.AC.IL (Amos Shapira) writes: >Hello, > What about perl compiling a script and dumping only the script in > binary form to disk? YES! Please don't fall into the trap tha TeX and emacs did. Undumping is a real pain in the ass. At least in emacs it makes sense, because there is only one copy undumped. But to clone the perl interpreter for every different script compiled is bad. > I suppose I'm suggesting here the obvious, but I haven't seen any > refference to this option on this list. Well, you beat me to it. You can use emacs rules: when I give a filename, first check 'filename.plc' then 'filename.pl' then 'filename' as given. After all, I don't want to have to call my scripts something.pl. > The advantages of this over a simple dump is that you don't generate > a copy of the interpreter for every script while you still save the > startup overhead. Exactly. -- [rbj@uunet 1] stty sane unknown mode: sane
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/07/91)
In article <124823@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > YES! Please don't fall into the trap tha TeX and emacs did. > Undumping is a real pain in the ass. At least in emacs it makes > sense, because there is only one copy undumped. Please distinguish between INITeX's \dump and the checkpointing provided by certain UNIX implementations. The former makes perfect sense and is always worthwhile. The latter is only occasionally useful. It is a shame that perl and emacs aren't nearly as flexible as TeX. As I suggested to Larry many months ago, perl should have a good enough idea of its internal state that it can pass that entire state to another perl process; saving the state in a file would do the trick. ---Dan
rbj@uunet.UU.NET (Root Boy Jim) (03/07/91)
In article <5359:Mar701:28:2991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <124823@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >Please distinguish between INITeX's \dump and the checkpointing provided >by certain UNIX implementations. The former makes perfect sense and is >always worthwhile. The latter is only occasionally useful. You might want to explain the difference. >It is a shame that perl and emacs aren't nearly as flexible as TeX. As I >suggested to Larry many months ago, perl should have a good enough idea >of its internal state that it can pass that entire state to another perl >process; saving the state in a file would do the trick. At least the state of the perl script prior to execution. What I am leery of is trying to rewrite an executable program while it is running. While this is what loaders do, every vendor seems to have its own variant. Reading undump and crt0.o is enuf to make almost anyone throw up. While Larry seems to have provided hooks for this, he provided no working examples for any systems or machines in the distribution. In fact, I wonder if he undumps any of his scripts. Oddly enuf, emacs uses both techniques; undumping, which I consider evil because of its thousand variations, and byte compilation, which is machine independent. -- [rbj@uunet 1] stty sane unknown mode: sane
les@chinet.chi.il.us (Leslie Mikesell) (03/08/91)
In article <124847@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >Oddly enuf, emacs uses both techniques; undumping, which I consider >evil because of its thousand variations, and byte compilation, >which is machine independent. I think the best perl approach would be to allow explicit keywords in the program to specify where to look for and/or store the compiled version. Then if you attempt to run the uncompiled version and this keyword is parsed, the specified location is checked for a compiled copy that is at least as new as the uncompiled version. The compiled copy could have some magic tokens at the beginning so they could be recognized and executed directly, and byte order, word size, and allignment requirements of the machine that compiled the code could be deduced as well so most machines could do a quick fix and continue. Les Mikesell les@chinet.chi.il.us
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/15/91)
In article <124847@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > In article <5359:Mar701:28:2991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >In article <124823@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > >Please distinguish between INITeX's \dump and the checkpointing provided > >by certain UNIX implementations. The former makes perfect sense and is > >always worthwhile. The latter is only occasionally useful. > You might want to explain the difference. Inside INITeX, \dump produces a format file (plain.fmt, for example) in an essentially portable way. The format file contains enough of TeX's internal state that it ``tex &plain.fmt'' will bring it back to that state. Of course, the existence of format files implies that Knuth was careful to keep TeX's internal state sufficiently well organized for \dump to work. Typical UNIX checkpointing (viz., a core dump) records lots of system-specific information, including the entire text of the process. In relatively unorganized programs this is all you can do. ---Dan