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 |
+--------------------------------------------------------+
> 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
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
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
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.
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
> 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
> > ... 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
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.
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 <x2n1lga...@todday.aiai.ed.ac.uk>, Jeff Dalton <je...@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