I'm trying to create a deliverable executable on MS Windows but am having problems with Allegro version 5.0.
My program loads large data files, then manipulates the data to create values that are assigned to several global variables. Using the old excl:dumplisp, the new image inherited everything from the parent image, so the values were available on restart.
The documentation for the new excl:generate-application says that global values AREN'T inherited. So, it seems that the my only option is to manually dump the values of the key global variables into a file, which is then loaded (slowly) on starting the executable.
This is clumsy and will make the user wait a minute or two for something to happen.
What am I missing?
Thanks, Raul Valdes-Perez
+--------------------------------------------------------+ | Computer Science Department email: val...@cs.cmu.edu | | Carnegie Mellon University tel: (412) 268-7127 | | Pittsburgh, PA 15213 - USA www.cs.cmu.edu/~sci-disc | +--------------------------------------------------------+
* Raul Valdes-Perez wrote: > The documentation for the new excl:generate-application says that > global values AREN'T inherited. So, it seems that the my only option is > to manually dump the values of the key global variables into a file, > which is then loaded (slowly) on starting the executable.
generate-application lets you have various code run before the application is dumped, you could use that to load the values.
If you do a little experiment, like (setq a 1) followed by dumping with generate-application, then on re-starting "a" doesn't have the value. How then can I get expensively-computed values to be remembered in a generate-application dump?
- Raul
In article <ey34s7qb2ny....@cley.com>, Tim Bradshaw <t...@cley.com> writes:
|> * Raul Valdes-Perez wrote: |> |> > The documentation for the new excl:generate-application says that |> > global values AREN'T inherited. So, it seems that the my only option is |> > to manually dump the values of the key global variables into a file, |> > which is then loaded (slowly) on starting the executable. |> |> generate-application lets you have various code run before the |> application is dumped, you could use that to load the values. |> |> --tim
* Raul Valdes-Perez | If you do a little experiment, like (setq a 1) followed by dumping | with generate-application, then on re-starting "a" doesn't have the | value. How then can I get expensively-computed values to be | remembered in a generate-application dump?
You start by reading the manual. Have you done that? My guess is you haven't even tried, as that "experiment" of yours is pointless.
If you think I'm _really_ saying "you shouldn't be doing that if you don't know what you're doing", and that this is arrogant, let me counter by _actually_ saying that people who don't _want_ to know what they are doing really tick me off, because it's a type of arrogance that has become very popular with easy-to-use computers: Ignorance with an attitude.
#:Erik -- If this is not what you expected, please alter your expectations.
In article <3168087055232...@naggum.no>, Erik Naggum <e...@naggum.no> writes:
|> * Raul Valdes-Perez |> | If you do a little experiment, like (setq a 1) followed by dumping |> | with generate-application, then on re-starting "a" doesn't have the |> | value. How then can I get expensively-computed values to be |> | remembered in a generate-application dump? |> |> You start by reading the manual. Have you done that? My guess is |> you haven't even tried, as that "experiment" of yours is pointless. |> |> If you think I'm _really_ saying "you shouldn't be doing that if you |> don't know what you're doing", and that this is arrogant, let me |> counter by _actually_ saying that people who don't _want_ to know |> what they are doing really tick me off, because it's a type of |> arrogance that has become very popular with easy-to-use computers: |> Ignorance with an attitude. |> |> #:Erik |> -- |> If this is not what you expected, please alter your expectations.
I already cited the manual in the original post. Please re-direct your hostilities elsewhere.
* Raul Valdes-Perez wrote: > If you do a little experiment, like (setq a 1) followed by dumping > with generate-application, then on re-starting "a" doesn't have the > value. How then can I get expensively-computed values to be remembered > in a generate-application dump?
Yes that won't be inherited because generate-application spawns a new lisp to do the dump. But you can use the PRE-LOAD-FORM & POST-LOAD-FORM arguments to specify actions to be taken. Or just put the forms you want to evaluate in a file and specify this as one of the files to load.
In article <8gef6q$2j...@cantaloupe.srv.cs.cmu.edu>,
Raul Valdes-Perez <vald...@cs.cmu.edu> wrote: >I already cited the manual in the original post. Please re-direct >your hostilities elsewhere.
But apparently you didn't look in the part of the manual that explains how to arrange for some code to be run when the application starts up. Simply setting them before dumping doesn't do it, as you knew from the start. You have to define a function that will be invoked at startup time. The manual should explain how to do this (I don't have ACL, so I don't have the documentation, but I'm sure that it's in there).
-- Barry Margolin, bar...@genuity.net Genuity, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
I know that I can load a form or call a function upon start up. But as part of creating the application, I have lengthy computations that create values (lists) that have millions of elements. Using the old dumplisp, I could make an image that starts up instantly with all of the data ready to go.
With the generate-application alternatives I've heard (pre-load-form, calling some init function), a user will face significant delay at start-up due to loading, parsing, etc. of several megabytes. I want to avoid these delays, as I could easily with dumplisp.
Is there no way to do this with generate-application?
- Raul
In article <fnzW4.34$u47.1027@burlma1-snr2>, Barry Margolin <bar...@genuity.net> writes:
|> But apparently you didn't look in the part of the manual that explains how |> to arrange for some code to be run when the application starts up. Simply |> setting them before dumping doesn't do it, as you knew from the start. You |> have to define a function that will be invoked at startup time. The manual |> should explain how to do this (I don't have ACL, so I don't have the |> documentation, but I'm sure that it's in there). |> |> -- |> Barry Margolin, bar...@genuity.net |> Genuity, Burlington, MA |> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. |> Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
* Raul Valdes-Perez wrote: > With the generate-application alternatives I've heard (pre-load-form, calling > some init function), a user will face significant delay at start-up due to > loading, parsing, etc. of several megabytes. I want to avoid these delays, > as I could easily with dumplisp. > Is there no way to do this with generate-application?
Tim Bradshaw <t...@cley.com> writes: > > ... easily with dumplisp. > > Is there no way to do this with generate-application? > PRE-LOAD-FORM and POST-LOAD-FORM are called *before the image is > dumped*. This is reasonably clear from the documentation ... > Alternatively, you could have *tried* this to see what happened.
I guess I'll annoy some people now by saying that I find the hoops Allegro wants me to jump through annoying. Even dumplisp gets tricky when I want to change the value of a variable in the common-lisp package or have to figure out which magic variable that names a magic function I need to setq. Yes, I can read documantation, try some experiments, and eventually get something working. But it's significantly harder to work it out than it is for the other Common Lisps I use, and even when I get something working it's hard to be sure I've done it the intended way - or even a good way.
So ... I think it's completely reasonable for someone to ask c.l.l for help. If c.l.l's Allegro experts don't want to help, fine: they don't have to help. But they shouldn't attack the guy.
* Jeff Dalton <j...@todday.aiai.ed.ac.uk> | I guess I'll annoy some people now by saying that I find the hoops | Allegro wants me to jump through annoying.
It is evident that you have tried something fairly reasonable. When people don't try something fairly reasonable before they complain, it's a different issue entirely and completely random whether the problem was in fact hard to solve.
#:Erik -- If this is not what you expected, please alter your expectations.
I spoke with somebody at Franz, Inc. who kindly explained the best procedure. Basically, with dumplisp you created a state following some procedure, then dumped the entire state. With generate-application, you take all the steps of this procedure and put them into a file surrounded by (eval-when (load) ...) and include this file in the third argument to generate-application. The file will then be loaded before the dump.
Others on this newsgroup hinted at this, but very tersely so I didn't quite grasp the hint. Also, I didn't see this clearly from reading the Franz documentation.
- Raul
In article <x2n1lgaw3w....@todday.aiai.ed.ac.uk>, Jeff Dalton <j...@todday.aiai.ed.ac.uk> writes:
|> Tim Bradshaw <t...@cley.com> writes: |> |> > > ... easily with dumplisp. |> |> > > Is there no way to do this with generate-application? |> |> > PRE-LOAD-FORM and POST-LOAD-FORM are called *before the image is |> > dumped*. This is reasonably clear from the documentation ... |> |> > Alternatively, you could have *tried* this to see what happened. |> |> I guess I'll annoy some people now by saying that I find the hoops |> Allegro wants me to jump through annoying. Even dumplisp gets tricky |> when I want to change the value of a variable in the common-lisp |> package or have to figure out which magic variable that names a |> magic function I need to setq. Yes, I can read documantation, |> try some experiments, and eventually get something working. |> But it's significantly harder to work it out than it is for the |> other Common Lisps I use, and even when I get something working |> it's hard to be sure I've done it the intended way - or even a |> good way. |> |> So ... I think it's completely reasonable for someone to ask c.l.l for |> help. If c.l.l's Allegro experts don't want to help, fine: they don't |> have to help. But they shouldn't attack the guy. |> |> -- j
