The Flu

Not that I have it (or usually get it, being young and in good shape). However, this article in the New York Times today points out that vaccines are "apparently ineffective" in preventing the flu for elderly people:

The fact that the vaccine study showed that inoculations have had only a modest effect in the elderly is particularly worrisome, because this is a group that tends to suffer high rates of complications and deaths from the disease and vaccination is the standard practice. In people over 65, the vaccines "are apparently ineffective" in the prevention of influenza, pneumonia and hospital admissions, although they did reduce deaths from pneumonia a bit, by "up to 30 percent," the study says.

"What you see is that marketing rules the response to influenza, and scientific evidence comes fourth or fifth," Dr. Jefferson said. "Vaccines may have a role, but they appear to have a modest effect. The best strategy to prevent the illness is to wash your hands."

Being young, I would like to see mention of the effectiveness of the vaccine in younger people (i.e. whether it's worth it for me to get one).

On a related note, how do people who don't believe in evolution at all (i.e. something made the world exactly as it is now) cope with the idea of viruses sharing genetic material and becoming resistant?

Bigloo Finalization Library

I've just posted a library which allows finalization of Bigloo objects before they're reclaimed by the GC. You can view the documentation and download the library here.

Manuel provided the hint to look at doc/README.finalizer, but I didn't like the way finalization was done in the example there, and it seemed a bit out of date. So, I wrapped up my own finalization library. I worry that I may have gone overboard (both in the documentation and in the care I've taken with license), but I have had a lot of trouble using poorly-documented libraries in the past, so hopefully this will be helpful to more people because I've spent some time writing out good documentation.

Bigloo 2.7a Beta Mac OS X Package

I've just posted a Mac OS X installer for the latest (Sept 20) beta of Bigloo. You can read more about it here. It's been quite a lot of work to compile Bigloo properly on OS X (which you can read about on the Bigloo mailing list), and Manuel has been a huge help. Many of these things are happening automatically now, but I figured that, since I've already put in the effort, I might as well make things as easy as possible for those following. Instead of putting a few #defines into some header files, typing ./configure --lots-of-options and then compiling, you can now just grab the disk image and Bigloo is only 4 clicks away. Enjoy!

Bigloo Internals, More Dynamic Linking and Shark...

without much Scheme-y stuff in sight.

Over the past few days Manuel Serrano has been helping me improve the speed of my n-body integrator by changing the behavior of Bigloo's threading when run in single-threaded mode on OS X. There is a function in runtime/Clib/cthread.c called denv_get which, I assume, gets some representation of the current dynamic environment. Since the cthread.c functions are really stubs for a more complete thread implementation denv_get is really short---it compiles to about 5 instructions (including prelude and post-lude) on my machine. Unfortunately, in the beta version of 2.7a from 18Aug denv_get was installed as the function to get the dynamic environment through a function pointer, preventing its inlining by the C compiler. My n-body code was spending upwards of 50% of its time in denv_get (remember: 5 instructions!). Manuel had me insert #define BGL_DYNAMIC_ENV_ALTERNATE 1 in runtime/Include/bigloo.h from the newest beta of 2.7a (12Sept)¹. This apparently allowed for inlining of denv_get in single-threaded mode---presto: faster by a factor of two.

I'm mentioning this for two reasons: 1. Manuel is really cool to take so much time to help me with my performance issue. 2. If you use OS X and Bigloo 2.7a beta, you should definitely get the 12Sept version and insert #define BGL_DYNAMIC_ENV_ALTERNATE 1 into runtime/Include/bigloo.h!

In other news, Maunel has used my patch fixing a problem with the build script which was preventing the building of the compiler with shared libraries even when the --sharedcompiler=yes option was provided to configure. This makes it much simpler to build a bigloo linked against dynamic libraries on OS X. All you have to do is make sure to provide --sharedcompiler=yes (and, if you like, --sharedbde=yes) to configure. Then edit the Makefile.config, changing the following variables:

• LD=gcc
• LDFLAGS=-dynamiclib -single_module
• LDLIBS=-lbigloogc-2.7a
• SHAREDSUFFIX=dylib

That's it---no restarting the make in the middle after changing options or anything. (I can't remember whether this works for building the Development Environment, but I do remember that if it fails it's pretty clear what to fix.)

Finally, I'd just like to put in a plug for SHARK, Apple's profiler that comes with OS X. You can profile a running process, obtaining a call graph with who-calls-who and elapsed time in each call path, see the memory usage pattern (and page faults), look at the disassembled object code with color-coded hot spots and pipeline stalls, and get helpful advice like using the reciprocal square root estimate assembly instruction rather than the math library sqrt when you don't need super accuracy. I can't imagine the amount of effort it would have been to do the profiling I've done today and yesterday with gprof! Bigloo works quite well with SHARK, since it outputs relatively idiomatic C code (though you might have to de-mangle function names with bigloo-demangle); other compilers like Gambit-C (C used as assembler) or Chicken (C used in CPS) wouldn't give you code that SHARK would help with much.

Eventually I'll get back to Scheme-y things (I haven't written a good macro in days!), but I thought it would be good to get down some of the things I've been doing lately.

1: You can get the 12Sept beta of 2.7a from INRIA's FTP Site or its mirror at U. Nice.

Hybrid Cars and Pork

In today's New York Times:

"I would like to get more hybrids out of our system because I do think it's something that is here to stay," William Clay Ford Jr., chairman and chief executive of Ford Motor, told reporters in Detroit on Aug. 23. Last fall, Ford introduced a hybrid version of its Escape sport utility vehicle, the first of several hybrids planned.

At the same time, the energy bill signed by President Bush on Aug. 8 effectively gave a break to American manufacturers by extending what could be a tax credit of as much as $3,400 per car to purchasers of the first 60,000 hybrids sold by a company. The credit phases out after that. Toyota sold more than 60,000 hybrids in the first six months of this year, so the tax law seems intended to help General Motors and Ford.

[...]

The new tax law "seems to benefit those who haven't done anything in the area of hybrids until now," Christopher Richter, a CLSA Asia-Pacific Markets auto analyst, said in Tokyo. "And it seems to penalize those who have been pioneers."

No kidding! And note that Ford has leased its hybrid technology from Toyota---no R&D costs for them. The only good news on the pork-ridden government front is that California is going to make a distinction between hybrids based on their environmental quality:

In early August, California regulators started to distinguish between fuel-efficient hybrids and "muscle" hybrids, the high-powered versions that save little gasoline. Of the seven hybrid models now on sale in the United States, owners of the Honda Civic, Honda Insight and Toyota Prius can qualify for decals allowing them to drive alone, rather than with two or more passengers, in highway commuter lanes. That reward is not extended to four hybrids not rated as exceptional energy savers: Honda Accord, Ford Escape, Toyota Highlander and Lexus RX 400h.

Bigloo Tracing

I just saw that I'm being syndicated at planet scheme. Looks like it hasn't quite made it to planet lisp-like number of contributors (or probably readers). But, in honor of the nevertheless auspicious occasion I plan to say something scheme-y after the past few days of political posts (which, by the way, have probably alienated my one reader---sorry dude, but I call it the way I see it :) ).

I just noticed a very useful thing for debugging Bigloo: tracing macros! The way this works is you put (with-tracing n 'foo ...) declarations around your code and if the debug level (set by -g[2..4]) when compiling is greater than n you get a trace which outputs the symbol 'foo indented according to how many previous traces are active. You can also issue (trace-item . items) commands which display the items given at the appropriate level (though this only seems to work when the debug level is greater than 2). Want the debugging info to go away? Just lower the debug level (or---even easier---increase n) when you compile that module. It doesn't sound like much, but the indentation and (trace-item ...) are leaps and bounds better than the (print ...) statements I was constantly un-commenting and commenting out. I now have (with-tracing ...) scattered through my code---it's great.

Two warts if you use Bee in Emacs and dynamically load your compiled modules:

1. If an error occurs within the dynamic extent of the (with-tracing ...) form, the indentation doesn't always reset, so sometimes after several errors your traces are walking off the edge of the screen. (I don't know why a simple dynamic-wind doesn't cut it here:

   (dynamic-wind
      (lambda () (increase-trace-indentation!))
      (lambda () 'do something)
      (lambda () (decrease-trace-indentation!)))
   

   but it sometimes doesn't work.)
2. Sometimes the prefix of the trace data contains shell formatting characters that kind of mess up the output:

     |  |  |  |  |  |  |--+make-advancer-lambda
     |  |  |  |  |  |  |  |--+ calculate-new-dt
   

   Sometimes calling (trace-margin-set! "") clears this stuff, but sometimes it doesn't.

Anyways, even with the warts it's a pretty useful feature. Enjoy.

Update: In fact, you can get rid of all the cruft at the beginning of these lines by setting the parameter bigloo-trace-color to #f: (bigloo-trace-color-set! #f). Then everything works great within emacs.

What are they doing?

Yet more incompetence from our lovely executive branch: FEMA ignores an offer of help from Chicago.

Even before the storm hit the Gulf Coast on Monday, he [Chicago Mayor Daly] said, the city's Office of Emergency Management and Communications had contacted emergency response agencies in Illinois and Washington.

In the event of a disaster, the city offered to send 44 Chicago Fire Department rescue and medical personnel and their gear, more than 100 Chicago police officers, 140 Streets and Sanitation, 146 Public Health and 8 Human Services workers, and a fleet of vehicles including 29 trucks, two boats and a mobile clinic.

"So far FEMA has requested only one piece of equipment {ndash} [sic] a tank truck to support the Illinois Emergency Response Team, which is already down there," Daley said. "The tank truck is on its way. We are awaiting further instructions from FEMA."

Even before the storm hit the Gulf, Chicago was offering to help. Too bad FEMA doesn't believe in planning; they just lock the door after the horse has left the barn. You can read more about their obstructionism in the name of coordination from a list here. (Not that I'm opposed to coordination by one agency, but I think that you should have to demonstrate that you aren't a total fuck-up before being allowed to tell other helpful people what not to do. In any case, I'd have a lot more confidence in a press-release asking First Responders not to help unless requested by state and local authorities if it actually came from the state and local authorities, not from an ex-horse-show overseer and political supporter of the President.)

Labor Day

From a NY Times Op-Ed:

...But because the French work 35 hours a week, Americans sneer, forgetting that in many years French workers have a higher productivity rate than their American counterparts - proof that you can work better by working less.

Americans also forget that going to work every day is often more a chore than a pleasure. You seem more and more disillusioned about work: only a third of you say that you love your jobs. In such conditions, it's not surprising that you spend on average two hours of your workday ... not working. Answering personal e-mail messages, shopping online, playing computer games or chatting with co-workers ... it's so much more pleasant than working, really.

Only two hours a day? Hell, I might play two hours of foosball on a good (bad?) day. Then there are the days when I work 18 hours straight. It's just the nature of an intellectual job---when you're hot, you're hot, and when you're not you play around. Fortunately, I have an employer who realizes the capricious nature of Physics research---I wish everyone was so lucky in their "boss".

P.S.---I love my job! Guess I'm part of the lucky 1/3.

Science and Politics in the NY Times Magazine

There's an interesting article in the New York Times Magazine today about politics and science. The article discusses possible reasons for why most (nearly all?) scientists think the Bush administration has done an abysmal job listening to and properly reacting to scientific developments and studies. It's probably a good factual review of several instances where science was suppressed/changed for political ends in the administration, and also a good description of John Marburger's role and why he thinks he's doing good for science.

Unfortunately, I think the writer missed the point. He focused nearly entirely on the way that scientific results are incorporated into reports and policy decisions. This is surely an important component of how the administration treats science, but it's not the whole story. What I think really upsets scientists---me included---about this administration is not the specific suppression of a study in an EPA report (though this is pretty bad); it's their seeming disregard for facts and reason and their willingness to take public positions in support of pseudo-scientific, ideologically driven theories. This complaint would be there even if they had never, ever, pressured an employee to change the mention of scientific results.

Several examples of what, generally, pisses scientists off:

1. The president's stance on Creationism (aka Intelligent Design). I know that most of the country believes this, but I would hope that the president would want to lead the country, not follow it in its ignorance. (By the way, the article doesn't mention Creationism at all.)
2. The president's position on climate change, and the response of the administration to the overwhelming scientific consensus that CO2 is causing global warming. (This is discussed in the article, but more from a point of view of suppressing the relevant information in EPA reports and whatnot.)
3. The rationale for tax cuts in the face of growing deficits and no significant spending cuts. You can't have your missile-defense cake and eat it, too, people. This isn't science, but it's such a glaring stupidity that scientifically minded people can't help but notice it.

The common theme here is: the article focused on the details of policy---reports, committee selections, etc---but I think scientists are more interested in the projected public attitude of the administration. I think that most scientists would be willing to forgive some pretty big omissions and commissions on the details front if you didn't get the feeling that the people in change had wooden heads. I mean, if a guy really believes in Creationism and tells the public that it's on an equal scientific footing with evolution, does it really matter if he gets all the facts right in an EPA report? Admittedly, the public pronouncements of the President don't have as much of an immediate policy effect as the committee work and rules published by the agencies, but it's the public persona that people follow; Bush and the upper levels of the administration are basically telling the country that there's two worlds: the scientific, rational one and the one that does whatever you want. And you don't have to listen to the scientists because you can just live in the other world. That attitude does more damage than the specific examples in the article, and that's what really pisses scientists (well, at least me) off.

Update: I totally forgot about issues like AIDS in Africa, but it's another one. Again the message: it doesn't matter what you scientists discover about the best way to prevent AIDS---we don't have to listen to it. It's not getting the facts wrong; it's ignoring the facts you know to be true.

Update II: I didn't realize that this article was still available, or I would have linked to it above. Favorite quote (the article is by Pulitzer Prize winner Ron Suskind):

In the summer of 2002, after I had written an article in Esquire that the White House didn't like about Bush's former communications director, Karen Hughes, I had a meeting with a senior adviser to Bush. He expressed the White House's displeasure, and then he told me something that at the time I didn't fully comprehend -- but which I now believe gets to the very heart of the Bush presidency. The aide said that guys like me were ''in what we call the reality-based community,'' which he defined as people who ''believe that solutions emerge from your judicious study of discernible reality.'' I nodded and murmured something about enlightenment principles and empiricism. He cut me off. ''That's not the way the world really works anymore,'' he continued. ''We're an empire now, and when we act, we create our own reality. And while you're studying that reality -- judiciously, as you will -- we'll act again, creating other new realities, which you can study too, and that's how things will sort out. We're history's actors . . . and you, all of you, will be left to just study what we do.''

Really! This kind of shit goes over like a lead balloon with physicists (and probably most other scientists, too). Again, the outrage isn't in the details---it's in the fundamental assumptions of the people in power.

Google Helper for Mac

Google Mail Helper is available for the Mac! I'm now using it, but I'm wracked with guilt over my desertion of the wonderful soul who created Gee. Poor Lloyd---and because it never rains but when it pours, Lloyd looks to have lost a bunch of photos in a Linux drive crash. Bummer.

I guess people may still use Gee for other Atom feeds, but mail helper has much better features for Gmail (not least that it registers Gmail as the default mail handler so that accidentally clicking on those mailto: tags doesn't open up Mail.app but instead takes you to Gmail).

Chlorine Tidbits

Some sites regarding chlorine exposure in swimmers are interesting, since I just got back into swimming. The information is somewhat sketchy on the web (and most sites are trying to sell you something---as in http://www.karinya.com/chlorine.htm), but there are some seemingly-authoritative pages. This review points out that there isn't a very good understanding of the effects of chlorine and related compounds in the air above a pool. (It does also point to the well-known beneficial effect of swimming on asthmatic children, which is reassuring.) Excessive chlorination may lower the pH of the water, leading to problems with dental enamel. A good summary of papers is here.

In any case, I think swimming is pretty fun, and it keeps me in great shape. I'm not worried overly about the chlorination, since it seems like the health benefits far outweigh the risks, but I'm not saying that I wouldn't be happy if my pool used something else.

Sean Carroll's Blog

I just discovered Sean Carroll's Blog (he blogs along with several other physicists at cosmicvariance). Great stuff! I particularly enjoyed the political cartoons #1 and #2. Of course, the physics is neat, too.

I haven't hung out much with Sean (just a bit when I was visiting Chicago as a prospective grad student), but now I can follow him vicariously and wonder what Chicago would have been like. (Not that I'm unhappy here at MIT; just that it's interesting how different Sean and Ed are.)

bdepend Problems Solved

I just figured out why I was having problems with module initialization. I also solved a long-standing mystery in my own mind: what the hell are those .mco files that Bigloo produces all the time? In fact, .mco files are module checksums---reproduced (I assume) every time the interface to a module changes. So, bdepend does, in fact, know about dependencies on (import ...) modules; it just uses the .mco files to compute these dependencies, not the .scm files themselves! Very smart, since the .scm file could change in a way that doesn't affect the interface and therefore wouldn't require recompilation of every module which (imports ...) said .scm file.

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).

Bigloo GC and SIGINT

I've noticed in my work with Bigloo that sometimes when a process running from the REPL is sent SIGINT (C-c), the GC hangs in the function GC_lock. I don't know if it's related to dynamic-load-ing on OS X, or whether this is a general problem, and the GC is not very resistant to SIGINT. I suppose it could also be my optimization options on the compiled C code (I'm optimizing pretty heavily for my numerical work). I'm just putting it down here so I don't forget to file a bug report if I ever figure out the cause.

Inconsistent Module Initialization

I've been getting a lot of errors like the following lately from Bigloo:

*** 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 think I finally realized what the problem is. I have a bunch of modules which are all separately compiled, and then put together by a "heap" file as described in the chapter from the Bigloo manual on libraries, but the Makefile I'm using doesn't think that the heap file depends on the separately compiled files. So, the code the heap file uses to initialize the modules it imports becomes stale whenever the exported interface of these modules changes.

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.

Perserverance: 1 Static Linking: 0

Finally! I've figured out how to make dynamic linking of module files work with bigloo on Mac OS X! Details follow (though I should warn you that this is a total hack right now).

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:

LD

LD=ld

LDFLAGS

LDFLAGS=-dylib -single_module

LDLIBS

-lc -lSystem.B -ldylib1.o -lm -lc -lgcc

SHAREDSUFFIX

SHAREDSUFFIX=dylib

Now issue the command

make

The 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 full paths!) Now delete the old executable at bin/bigloo (relative to the unpacked bigloo directory) and re-make. Check with otool -L bin/bigloo to make sure that the bigloo executable really links against the dynamic libraries. The output of my otool looks like

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.o

This 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.

Footnotes

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.

Latest in the Quest for Speed

I found an interesting post which claims that Chicken is a bit faster than Gambit on floating-point code. There's a paper by Brad Lucier which talks about using Gambit to make a PDE solver, which would seem to refute this (Chicken doesn't achieve C speeds on numerics), but I suspect that his sparse matrix-vector multiply was memory-bound, so the speed of the code didn't matter too much.

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).

Gambit Isn't Fast Without (declare (unsafe))

Gambit, nice as it is about loading compiled code into an REPL, isn't fast numerically unless you compile using (declare (unsafe)). (At least it wasn't in my recent quick tests of some floating-point code.) Bigloo is much better at eliminating type checks and producing fast numerical code, even in safe mode. So, I guess it's back to Bigloo, because I don't want to have to worry about blowing things up when I misuse parts of my system. Bummer---I was really enjoying the syntax-case macros and easy-to-load code from gambit.

Gambit-C

I've just discovered a new scheme implementation which may be even better than Bigloo for my needs: Gambit-C. Gambit runs on Mac OS X, and compiles to C, just like Bigloo. However the compilation strategy is a bit different. Bigloo aims for roughly idiomatic C code (and relies on the C compiler for many optimizations), while Gambit really uses C as a portable assembly language (and therefore rarely cares about the C compiler optimizations). It looks like (just from reading results of google searches, etc) they are about equally fast in terms of numerical computation. However, Gambit has (from my point of view) a real advantage: loading dynamic libraries works on OS X! Therefore, I can compile my code, and load it into a running REPL---in Bigloo I had to recompile the REPL, and restart it to take advantage of newly compiled code. If the code changes, Gambit will compile it to XXX.o2, and XXX.o3, etc. Each time it's recompiled, the new object file is loaded, and the new functions replace the old ones---no need to stop the REPL process and restart. It feels much more like Common Lisp, but it will satisfy my advisor's need to have something which he can link into a pre-existing C library---the best of both worlds.

More Bigloo Macros

Regarding my previous post about Bigloo Macros and the REPL, I have realized that it's vital to export the macro-expander function from the module in which the macro is defined. Not doing this prevents recognizing the expander when (eval '(define-expander ....)) is evaluated. (Maybe this was obvious to everyone else, but I didn't realize it for a while.)