Greetings,
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: ······@cs.cmu.edu |
| Carnegie Mellon University tel: (412) 268-7127 |
| Pittsburgh, PA 15213 - USA www.cs.cmu.edu/~sci-disc |
+--------------------------------------------------------+
From: Tim Bradshaw
Subject: Re: global variables when making executables in Allegro?
Date:
Message-ID: <ey34s7qb2ny.fsf@cley.com>
* 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
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 <···············@cley.com>, Tim Bradshaw <···@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
From: Erik Naggum
Subject: Re: global variables when making executables in Allegro?
Date:
Message-ID: <3168087055232681@naggum.no>
* 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 <················@naggum.no>, Erik Naggum <····@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
From: Barry Margolin
Subject: Re: global variables when making executables in Allegro?
Date:
Message-ID: <fnzW4.34$u47.1027@burlma1-snr2>
In article <············@cantaloupe.srv.cs.cmu.edu>,
Raul Valdes-Perez <·······@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, ······@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 <·················@burlma1-snr2>, Barry Margolin <······@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, ······@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.
From: Tim Bradshaw
Subject: Re: global variables when making executables in Allegro?
Date:
Message-ID: <ey3aehh9jt0.fsf@cley.com>
* 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?
PRE-LOAD-FORM and POST-LOAD-FORM are called *before the image is
dumped*. This is reasonably clear from the documentation at
http://www.franz.com/support/documentation/5.0.1/doc/cl/building_images.htm
Alternatively, you could have *tried* this to see what happened.
--tim
Tim Bradshaw <···@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
From: Erik Naggum
Subject: Re: global variables when making executables in Allegro?
Date:
Message-ID: <3168167338713202@naggum.no>
* Jeff Dalton <····@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 <··············@todday.aiai.ed.ac.uk>, Jeff Dalton <····@todday.aiai.ed.ac.uk> writes:
|> Tim Bradshaw <···@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
From: Tim Bradshaw
Subject: Re: global variables when making executables in Allegro?
Date:
Message-ID: <ey3k8gl9n4c.fsf@cley.com>
* 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.
This is reasonably well described in the manual.
--tim