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: Help: modules and -s switch


   From: Ian Grant <Ian.Grant@cl.cam.ac.uk>
   Date: Mon, 29 May 2000 17:52:37 +0100

   I used to use (use-modules ...) to load my C module but now I use
   (dynamic-call # (dynamic-link #)) instead because of the problem of
   putting architecture dependent executables in $(datadir).

   This works, except I don't know how to get the new definitions into
   the right module because which module that is depends upon whether
   guile is being run interactively (when it should be the guile-user
   module) or in command-line mode with the '-s' option to run a script.

   Currently I have a scheme module (database postgres) that looks like this:

   (define-module (guile-user))
   (dynamic-call "init_postgres" (dynamic-link "libpostgres.so"))
   (define-module (database postgres))
   (define-public (other-parts-of-the-interface-written-in-scheme ....

   which only works for interactive sessions.  How can I conditionally
   execute the '(define-module (guile-user))' appropriately?  Or is
   there a specific top-level module for non-interactive guile?

there seems to be many module access/init conventions:

(1) call dynamic-call/dynamic-link directly
(2) guile-gtk style
(3) hobbit style
(4) libtool-module style (???)

i've used hobbit style for THUD, fwiw.  i think libtool-module style is
going to be the default in the future, but that's from perusing source a
few months ago; perhaps that has changed.

w/ that background, the answer to your question is: it depends.  (my
copy of) ice-9/boot-9.scm defines var `registered-modules', although i
notice its value does not change when loading scheme-defined modules;
it's for C-defined modules only.  you can either extend this or bypass
it entirely [untested code follows]:

;; machinery
(module-add! the-root-module 'my-modules '())
(module-add! the-root-module 'register-my-module
	     (lambda (name)
	       (module-set! the-root-module
			    'my-modules
			    (cons (name (current-module))
				  (module-ref the-root-module
					      'my-modules)))))
(module-add! the-root-module 'my-module-registered?
	     (lambda (name)
	       (assoc name (module-ref the-root-module 'my-modules))))
					    
;; usage
(define-module (my module-1))
(register-my-module '(my module-1))
(or (my-module-registered? '(my module-2))
    (define-module (my-module-2)))

;;;;;
however, this is all pre-caffeine advice and on reflection i would
actually recommend against implementing yet another module init/access
convention.  something like the above should be integrated w/ the
C-defined module registry; each convention does basically the same
thing so all that code should be factored, not re-re-(re!)-duped.

thi

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