This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Problems with tguile's unexec


Bernard URBAN <Bernard.Urban@meteo.fr> writes:

> >>>>> "Greg" == Greg Badros <gjb@cs.washington.edu> writes:
> 
>     Greg> When I do: tguile --dump guile-all test-all.scm # (see below
>     Greg> for test-all.scm)
> 
>     Greg> and then run ./guile-all, I get a prompt that looks like:
> 
>     guile> <s
>     Greg>        ^ actually the <= single glyph character
> 
>     Greg> and before every printed response I get
> 
>     Greg> <f ^ same <= single glyph character
> 
>     Greg> For example, below, I entered "4" into the prompt:
> 
>     guile> <s 4
>     Greg> <f4
> 
> This is caused by using module (ice-9 emacs). 

Doh!  I should've known.  Thanks!

What are people's thoughts on making just the using of a module
have behaviour beyond just exposing new symbols?  (As is the case with
the (ice-9 emacs) module that confused me).  It seems like if actions
are permitted, modules should be allowed to be "use-d" with arguments.

This has come up in Scwm where I had some modules that had top-level
expressions that added key or mouse bindings.  I've since tried to not
do any of this, sometimes wrapping the code in a procedure and then
asking the user to (enable-foo-bindings) or whatever.  Seems like there
are some interesting issues here..

>     Greg> Also, I'm confused about why I have to run
>     Greg> `load-all-modules' again after starting ./guile-all before
>     Greg> the procedures are visible.  Can anyone explain this to me?
> 
> I did no encounter this behaviour (even with (ice-9 emacs) loaded).
> Could you be more specific ? I made the test on Solaris.

On x86 GNU/Linux Redhat-6.0 (glibc) using guile-1.3.5 out of CVS as of
yesterday, I do:

/usr/bin/tguile --dump guile-all test-all.scm

./guile-all
guile> open-pipe
ERROR: In expression open-pipe:
ERROR: Unbound variable: open-pipe
ABORT: (misc-error)

Type "(backtrace)" to get more information.
guile> (load-all-modules)
guile> open-pipe
#<procedure open-pipe (command mode)>

Where test-all.scm is as posted before (also reproducible with test-popen.scm:

;; begin test-popen.scm
(define-public (load-all-modules)
  (use-modules
   (ice-9 popen)))

(load-all-modules)
;; end

)

Could this be due to changes in the module system in recent Guile?  Or
are you using the same version and the behaviour is just different on
Solaris?  I'm glad to hear that the expected behaviour is for the
symbols to be immediately visible in the dumped executable, as otherwise 
it would seem wrong.

>     Greg> Incidentally, is there a good way to write a module that
>     Greg> exports symbols from a bunch of modules that it imports?
>     Greg> E.g., a single module guile-all.scm that does the
>     Greg> use-modules, and then another module can just use that one
>     Greg> module and get at all the symbols?
> 
> Here is an example taken from guile-stklos-1.3.3 
> (file stklos-3.0b2/stklos-sup):

<snip>

> It says that the exported symbols from (clos-1.7 clos) and (tk4.1 win)
> are added to the exported symbols from (stklos-3.0b2 stklos-sup).

It'd be nice to wrap this functionality in a nice "exporter.scm" module
for guile-proper.  No reason for others to be cutting and pasting code
for something that is of general, reasonably mainstream use (especially
to provide an abstraction barrier given the complexity and flux of the
module system).

>     Greg> Finally, how robust is unexec?  What's the probability that
>     Greg> I'd be able to use the code from tguile-core.c embedded in
>     Greg> Scwm and get Scwm to be able to dump itself after loading a
>     Greg> bunch of its modules?
> 
> Unexec is borrowed from emacs. So it is possible to make it work on
> your toaster, but only as long as you stay within the paradigm of
> emacs. This means that you may have problems with dyn-loading code
> in a dumped executable. 
> 
> On ELF machines (Linux, Solaris, Irix) it should be ok, but on HP-PA
> you are hosed. I have some documentation about HP-PA dyn-loading
> process, but no time to work on the subject.

Yes, I read your notes about the issues with HP dyn-loading and can live 
with that.  I'm viewing this all as a startup-time optimization on some
platforms that are philosophically important to me that happen to all be 
ELF-based.

Thanks for your excellent and timely response-- I really appreciate it!

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]