So the solution to my problem is to strike the -fno-mco flag on bdepend, and add a -fmco flag when bigloo is compiling a module. Ta-da! No more inconsistent module initialization, and no more complete system recompiles. Wonderful!
P.S.--Maybe someone (me?) should write something up for inclusion into the Bigloo manual about bdepend and mco files. There's very little in there right now (hence my problems making this work).
*** ERROR:body:Inconsistent module initialization Module `body' is inconsistently initialized by module `__nbody'. At least of the two modules must be recompiled (see also -unsafev option).and I
This problem arises because bdepend doesn't think that import commands in the module header create dependencies. Normally this is true---bigloo modules can, in general, be separately compiled---but in the case of a heap file, it won't work. (It also won't work for the file which has the -dload-sym option on the command line if you're doing dynamic loading.) The heap file needs to be recompiled if any of the modules it imports have changed their exports. Probably it's easiest to just add a command to the Makefile so that the heap file depends on all the source files in the project; this will recompile it more than necessary, but it's easy and the heap file doesn't take very long to compile.
EDIT: Actually, this problem afflicts all files, not just the heap ones. If module A imports module B, then module A needs to be recompiled if module B's exported interface changes. I've submitted a bug report about bdepend not recognizing this to the bigloo list.
There are two steps involved: 1. Alter the bigloo compilation process so it builds the proper dynamic libraries and 2. Make sure that the executable bigloo is linked against the dynamic libraries, and not the static ones.
#1: The way I know to do #1 is to edit Makefile.config after running ./configure [whatever-options-you-want]. Scroll through Makefile.config and change the following options:
makeThe make process will halt with an error! That's OK. Re-edit the Makefile.config file by changing the LDLIBS variable to LDLIBS=-lbigloogc-2.7a -lc -lSystem.B -ldylib1.o -lm -lc -lgcc (you should alter the "-2.7a" to whatever version of bigloo you're compiling). The compile should now finish. You will have both libbigloo***-***.a and libbigloo***-***.dylib in the lib subdirectory.
#2: Though it seems like you should be able to ensure that the bigloo executable is linked against the dynamic libs by using the --sharedcompiler=yes flag to the configure script, this doesn't work. However, the fix is easy enough: edit the dboot target of the file comptime/Makefile. There will be a section looks something like
doboot: $(O_OBJECTS) if [ "$(SHRD_COMP)" = "yes" -a -f $(BOOTLIBDIR)/lib$(LIBRARYNAME)_s$(VERSION)$(SHAREDSUFFIX) ]; then gc=-lbigloogc-$(RELEASE); if [ "$(GCCUSTOM)" = "no" ]; then gc=-lgc; fi; $(CC) $(EXTRA_LD_OPT) $(CFLAGS) -o $(BIGLOO_DEST) $(O_OBJECTS) -L $(BOOTLIBDIR) -lbigloo_s-$(RELEASE) $$gc $(EXTRALIBS); else gc=$(BOOTLIBDIR)/libbigloogc-$(RELEASE).a; if [ "$(GCCUSTOM)" = "no" ]; then gc=-lgc; fi; $(CC) $(EXTRA_LD_OPT) $(CFLAGS) -o $(BIGLOO_DEST) $(O_OBJECTS) $(BOOTLIBDIR)/libbigloo_s-$(RELEASE).a $$gc $(EXTRALIBS); fi -$(STRIP) $(BIGLOO_DEST)$(EXE_SUFFIX) @ echo "$(BIGLOO_DEST)$(EXE_SUFFIX) done..."you want to make it look like:
doboot: $(O_OBJECTS) if [ "$(SHRD_COMP)" = "yes" -a -f $(BOOTLIBDIR)/lib$(LIBRARYNAME)_s$(VERSION)$(SHAREDSUFFIX) ]; then gc=-lbigloogc-$(RELEASE); if [ "$(GCCUSTOM)" = "no" ]; then gc=-lgc; fi; $(CC) $(EXTRA_LD_OPT) $(CFLAGS) -o $(BIGLOO_DEST) $(O_OBJECTS) /tmp/bigloo2.7a/lib/2.7a/libbigloo_s-2.7a.dylib /tmp/bigloo2.7a/lib/2.7a/libbigloogc-2.7a.dylib else gc=$(BOOTLIBDIR)/libbigloogc-$(RELEASE).a; if [ "$(GCCUSTOM)" = "no" ]; then gc=-lgc; fi; $(CC) $(EXTRA_LD_OPT) $(CFLAGS) -o $(BIGLOO_DEST) $(O_OBJECTS) $(BOOTLIBDIR)/libbigloo_s-$(RELEASE).a $$gc $(EXTRALIBS); fi -$(STRIP) $(BIGLOO_DEST)$(EXE_SUFFIX) @ echo "$(BIGLOO_DEST)$(EXE_SUFFIX) done..."(The difference is that we have explicitly included the libbigloo_s-2.7a.dylib and the libbigloogc-2.7a.dylib libraries on the $(CC) command line---including the
SYDNEYPACIFIC-THREE-FORTY-ONE:/tmp/bigloo2.7a farr$ otool -L bin/bigloo
bin/bigloo:
/tmp/bigloo2.7a/lib/2.7a/libbigloo_s-2.7a.dylib (compatibility version 0.0.0, current version 0.0.0)
/tmp/bigloo2.7a/lib/2.7a/libbigloogc-2.7a.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3)
Now, to make a loadable bundle, issue the following command (this example comes from the Bigloo manual, section 13.1 under the dynamic-load procedure documentation):
MACOSX_DEPLOYMENT_TARGET=10.3 gcc -bundle -undefined dynamic_lookup -o mod.bundle mod1.o mod2.oThis command replaces the ld -G -o lib.so mod1.o mod2.o command from the manual. You can now load the bundle with
(dynamic-load "mod.bundle")from the REPL. You need the MACOSX_DEPLOYMENT_TARGET=10.3 so that it doesn't complain about the -undefined dynamic_lookup option; if you don't have 10.3, you can probably get away with -undefined suppress, but I haven't tried it.
1: I think it would be really neat if someone found a way to make all of this ad-hoc makefile-modifying happen automatically as part of the Bigloo build process on Mac OS X. I think it'll take someone more knowledgeable about the internals of the build process, but I may have a look at it later.
2:What happened here is that libbigloo requires the garbage collection library, so we have to include it in the LDLIBS variable. We can't put it in there at the beginning because the GC library doesn't exist yet, so we have to wait for the build to fail and then put it in. This is necessary because Mac OS X makes a distinction between dynamic libraries (which are treated like ELF static libraries for link purposes, but like ELF shared (or dynamic) libraries for loading at runtime) and loadable bundles (which are treated like ELF shared libraries all the time). In English: you have to have all the symbols for a .dylib at link time, though the libraries which contain them won't be loaded until run time, while you don't need the symbols for a .bundle until you use them at runtime.
3:And I don't understand why---the command that make issues has -lbigloogc-2.7a -lbigloo_s-2.7a and my documentation tells me that linking against the dynamic library version is the default in OS X, so I really don't understand what's going on here.
4: But very kludgy.
In any case, by my measurements, Bigloo is much faster than either Chicken or Gambit on floating-point code, so it's still my choice. I would love to find a syntax-case implementation for it, but define-macro is probably just as good for my uses. I posted a message about my attempts (and failures) getting dynamic loading to work with Bigloo. If I could just make that work, it would make my development much easier (it's a real pain to have to recompile the REPL every time I want to define a new class or whatever).
As an aside, I really, really like the foreign interface to PLT Scheme---it's by far the best one I've ever dealt with. This paper explains the rationale. Definitely The Right Way to do it.
The solution is to write modules with macros like this:
(module with-gensyms
(eval (export-exports))
(export (with-gensyms-expander x e)))
(define (with-gensyms-expander x e)
(match-case x
((with-gensyms (?sym) . ?body)
(e `(let ((,sym (gensym)))
,@body) e))
((with-gensyms (?sym1 . ?rest) . ?body)
(e `(let ((,sym1 (gensym)))
(with-gensyms ,rest ,@body)) e))))
(eval '(define-expander with-gensyms with-gensyms-expander))
And use them in other modules like this:
(module f64vector
(eval (export-all))
(import (with-gensyms "with-gensyms.scm")
(do-macros "do-macros.scm"))
(load (with-gensyms "with-gensyms.scm")
(do-macros "do-macros.scm"))
(type (tvector f64vector (double)))
(export (f64vector::f64vector . inits)
(with-f64vectors-expander x e)))
(define (f64vector::f64vector . inits)
(let* ((n (length inits))
(v (make-f64vector n 0.0)))
(let loop ((i 0) (list inits))
(if (null? list)
v
(begin
(f64vector-set! v i (car list))
(loop (+fx i 1) (cdr list)))))))
(define (with-f64vectors-expander x e)
(match-case x
((with-f64vectors ?vecs (<- . ?body))
(with-gensyms (result n i)
(e `(let* ((,n (f64vector-length ,(car vecs)))
(,result (make-f64vector ,n 0.0)))
(do-times (,i ,n)
(let ,(map (lambda (sym)
`(,sym (f64vector-ref ,sym ,i)))
vecs)
(f64vector-set! ,result ,i
(begin ,@body))))
,result) e)))
((with-f64vectors ?vecs . ?body)
(with-gensyms (i n)
(let* ((vector-syms (map (lambda (sym) (cons sym (gensym))) vecs))
(process-body-term
(lambda (term)
(match-case term
((?result <- . ?body)
`(f64vector-set! ,(cdr (assoc result vector-syms))
,i
(begin ,@body)))
(?- term)))))
(e `(let ((,n (f64vector-length ,(car vecs))))
(let ,(map (lambda (sym)
`(,(cdr (assoc sym vector-syms)) ,sym))
vecs)
(do-times (,i ,n)
(let ,(map (lambda (sym)
`(,sym (f64vector-ref ,sym ,i)))
vecs)
,@(map process-body-term body))))) e))))))
(eval '(define-expander with-f64vectors with-f64vectors-expander))
(Note that this module uses two macro-modules---one of which is not listed above---to define a third. I'm sorry for the confusing example, but it's what I have handy.)
How does this work? Here's my understanding:
(module repl
(import (with-gensyms "with-gensyms.scm")
(do-macros "do-macros.scm")
(f64vector "f64vector.scm"))
(main main))
(define (main argv)
(repl))
It took me a long enough time to figure this out (and I wouldn't have figured it out without some suggestions from jg malecki (see this message and its antecedents---thanks jg) that I thought I should post the explanation here so that other people don't have to go through the same difficulties that I have.
(with-vectors (a b c) (a <- (+ b c))) (with-vectors (a b c) (<- (+ a b c))) (with-vectors (a b c) (a <- (+ b 2)) (print "I can insert statements, too.") (c <- (+ a b)))
The second form above returns a fresh vector whose elements are the sums of the corresponding elements in a b and c. The length of the new vector is the same as the length of a. In all cases, the number of iterations of the body is the length of a (this isn't quite the right thing to do---that would be to make the number of iterations be the minimum of the lengths of a b and c or to throw an exception if a b and c are not the same length). The macro follows:
(define-expander with-vectors
(lambda (x e)
(match-case x
((with-vectors ?vecs (<- . ?body))
(with-gensyms (result n i)
(e `(let* ((,n (vector-length ,(car vecs)))
(,result (make-vector ,n)))
(do-times (,i ,n)
(let ,(map (lambda (sym) `(,sym (vector-ref ,sym ,i)))
vecs)
(vector-set! ,result ,i
(begin ,@body))))
,result) e)))
((with-vectors ?vecs . ?body)
(with-gensyms (i n)
(let* ((vector-syms (map (lambda (sym) (cons sym (gensym))) vecs))
(process-body-term
(lambda (term)
(match-case term
((?result <- . ?body)
`(vector-set! ,(cdr (assoc result vector-syms))
,i
(begin ,@body)))
(?- term)))))
(e `(let ((,n (vector-length ,(car vecs))))
(let ,(map (lambda (sym)
`(,(cdr (assoc sym vector-syms)) ,sym))
vecs)
(do-times (,i ,n)
(let ,(map (lambda (sym)
`(,sym (vector-ref ,sym ,i)))
vecs)
,@(map process-body-term body))))) e)))))))
It requires a completely obvious (I hope) do-times macro, and also with-gensyms (a lisp favorite):
(define-expander do-times
(lambda (x e)
(match-case x
((do-times (?i ?n) . ?body)
(with-gensyms (nn nn-1)
(e `(let ((,nn ,n))
(let ((,nn-1 (-fx ,nn 1)))
(do ((,i 0 (+fx ,i 1)))
((=fx ,i ,nn-1) ,@body)
,@body))) e))))))
(define-expander with-gensyms
(lambda (x e)
(match-case x
((with-gensyms (?sym) . ?body)
(e `(let ((,sym (gensym)))
,@body) e))
((with-gensyms (?sym . ?rest-syms) . ?body)
(e `(let ((,sym (gensym)))
(with-gensyms ,rest-syms ,@body)) e)))))
Nifty, huh? I also have one for my f64vectors (as described in my last post one can make vectors of doubles---the natural behavior from bigloo approximates SRFI 4):
(define-expander with-f64vectors
(lambda (x e)
(match-case x
((with-f64vectors ?vecs (<- . ?body))
(with-gensyms (result n i)
(e `(let* ((,n (f64vector-length ,(car vecs)))
(,result (make-f64vector ,n 0.0)))
(do-times (,i ,n)
(let ,(map (lambda (sym)
`(,sym (f64vector-ref ,sym ,i)))
vecs)
(f64vector-set! ,result ,i
(begin ,@body))))
,result) e)))
((with-f64vectors ?vecs . ?body)
(with-gensyms (i n)
(let* ((vector-syms (map (lambda (sym) (cons sym (gensym))) vecs))
(process-body-term
(lambda (term)
(match-case term
((?result <- . ?body)
`(f64vector-set! ,(cdr (assoc result vector-syms))
,i
(begin ,@body)))
(?- term)))))
(e `(let ((,n (f64vector-length ,(car vecs))))
(let ,(map (lambda (sym)
`(,(cdr (assoc sym vector-syms)) ,sym))
vecs)
(do-times (,i ,n)
(let ,(map (lambda (sym)
`(,sym (f64vector-ref ,sym ,i)))
vecs)
,@(map process-body-term body))))) e)))))))
(module foo
(type (tvector array-of-int (int)))
(export (foo::array-of-int ::int ::int))
(main main))
(define (foo len init)
(make-array-of-int len init))
(define (main x)
(let ((v::array-of-int (foo 10 20)))
(print v)
(array-of-int-set! v 5 6)
(print (array-of-int-ref v 5))))
Apparently you can also find more examples of this in the recette/vector.scm module in the source for Bigloo.
While the proposal to close the case was ultimately rejected by senior officials, documents show that the inquiry was at a virtual standstill when an article in The New York Times on March 4, 2003, reported that at least one of the prisoner's deaths had been ruled a homicide, contradicting the military's earlier assertions that both had died of natural causes. Activity in the case quickly resumed.I'm getting tired of our side being the bad guy so often. Why is the army not more thorough about disciplining those responsible for this kind of crap? At best, I would say it's apathy, or a desire to protect your own---however flawed they may be---and at worst, I would say it's because those in charge actually think this sort of thing is OK. Either way, it's not making me very happy. This also shows the media at its best---the army wasn't doing anything, and the NY Times got them moving. Let's hear it for the fourth estate!
