I used to have deliver `scripts' which did something like: (load ...sysdcl...) (compile-system ... :load t) (deliver ...) (quit) Is it `better' to compile in one image & then load & deliver in another? I guess `better' means that less grut from the compiler will survive into the delivered image. Thanks --tim
Something I stopped worrying about some time back. Memory isn't as tight as it used to be and marginal gains (at best, I'd guess) aren't worth the hassle. What size does it deliver down to? -n Tim Bradshaw wrote: > I used to have deliver `scripts' which did something like: > > (load ...sysdcl...) > (compile-system ... :load t) > (deliver ...) > (quit) > > Is it `better' to compile in one image & then load & deliver in > another? I guess `better' means that less grut from the compiler will > survive into the delivered image. > > Thanks > > --tim
* Nick Levine wrote: > Something I stopped worrying about some time back. Memory isn't as tight > as it used to be and marginal gains (at best, I'd guess) aren't worth the > hassle. We're not really worried about size, what I meant rather was for instance structures the compiler builds or symbols it interns which might cause clutter of various kinds in the image - as an example (which I know how to stop, I think) I don't really want source location information in the image which someone could find. --tim
* I wrote: > We're not really worried about size, what I meant rather was for > instance structures the compiler builds or symbols it interns which > might cause clutter of various kinds in the image - as an example > (which I know how to stop, I think) I don't really want source location > information in the image which someone could find. The reason I (slightly) worry about this kind of thing is not worrying about someone going through the code with a hex editor, but because we provide a Lisp listener in our image (and the compiler, in fact). --tim