I've slightly developed the simple Black Hole test in the previous email. Here are the files I'm using:
- module1.scm (define (hello) (print "Hello") (newline)) (hello)
- module2.scm (define (world) (print "World") (newline)) (world)
- test.scm (import module1) (import module2) (hello) (world) (print "All Done!") (newline)
Here's what happens when I build and then try to run the executable:
simple-test # ls -l total 24 -rw-r--r--@ 1 benjohn benjohn 51 7 Jun 16:27 module1.scm -rw-r--r--@ 1 benjohn benjohn 51 7 Jun 16:28 module2.scm -rw-r--r--@ 1 benjohn benjohn 80 7 Jun 16:29 test.scm simple-test # bsc -exe test.scm Loaded Black Hole. Hello World *** WARNING -- "module1#hello" is not defined, *** referenced in: ("/Users/benjohn/Code/gambit/simple-test/test.c") *** WARNING -- "module2#world" is not defined, *** referenced in: ("/Users/benjohn/Code/gambit/simple-test/test.c") simple-test # ./test *** ERROR IN | test| -- Operator is not a PROCEDURE (#!unbound) simple-test #
So, I suppose I have two questions – should I expect to get these "not defined" error on symbols that are in other projects, and why doesn't the executable work? (it's the same error that I get with the executable from the openGL test project in the earlier email after the second invocation of bsc) :-)
Thanks, Benjohn
Afficher les réponses par date
Hi Benjohn,
Black hole doesn't compile modules using the command line, like Gambit does. There is info about this (which is hopefully up to date) in the README at https://github.com/pereckerdal/blackhole.
Best,
Hi Per,
Thank you – I'm going to copy this to the list because I think it might be useful for people in future who might be reading the archive.
On 7 Jun 2011, at 16:44, Per Eckerdal wrote:
Hi Benjohn,
Black hole doesn't compile modules using the command line, like Gambit does. There is info about this (which is hopefully up to date) in the README at https://github.com/pereckerdal/blackhole.
Ah! I actually did read that :-) Erm, but when I used it on the command line like gsc, it seemed to work (no errors or warnings), so I assumed it had :-/ Thinking (a bit), I suppose there's not a lot of way it could work because the patch I put in my .gambcini was small and didn't mention anything to change the argument handling. Still, is there some way it could warn or error?
:-) I should probably take more note of the "Vaporware warning"!
So, when I compile from in the bsc repl, I get the error about the unwritable module because of where I've installed black hole. I'll see if I can fix that…
Thanks, Benjohn
Ah! I actually did read that :-) Erm, but when I used it on the command line like gsc, it seemed to work (no errors or warnings), so I assumed it had :-/ Thinking (a bit), I suppose there's not a lot of way it could work because the patch I put in my .gambcini was small and didn't mention anything to change the argument handling. Still, is there some way it could warn or error?
I don't know, I don't know of any way to tap into the batch stuff of Gambit. The proper way (and not too difficult either) to do it would be to create a separate command line app for BH, and not just tap into gsc. That way we could easily add batch compilation as well.
:-) I should probably take more note of the "Vaporware warning"!
Hehe.. The stuff you have been experiencing is a large reason to why I have pretty much given up working on Black Hole, it is so hard to integrate it into Gambit in a reasonable way.
It kindof works for me personally, for instance because I know that the warning messages you see are from Gambit and not BH, but there are so many small things that don't make sense unless you know the inner workings of BH (debugging from the REPL and attempting to access the hygienically renamed variables is a mess), and I haven't been able to get around it.
So, when I compile from in the bsc repl, I get the error about the unwritable module because of where I've installed black hole. I'll see if I can fix that…
If you get an error message about "~~lib/modules", and you have chosen to install BH somewhere else, it means that it is somehow misconfigured, and I would start at that end. Check if you've changed .gambcini to point to where BH is located and so on. "~~lib/modules" must be somewhere.
Cheers,
Per
2011/6/8 Per Eckerdal ..
Hehe.. The stuff you have been experiencing is a large reason to why I have pretty much given up working on Black Hole, it is so hard to integrate it into Gambit in a reasonable way.
It kindof works for me personally, for instance because I know that the warning messages you see are from Gambit and not BH, but there are so many small things that don't make sense unless you know the inner workings of BH (debugging from the REPL and attempting to access the hygienically renamed variables is a mess), and I haven't been able to get around it.
While indeed Black Hole doesn't 'swallow' Gambit and abstract it away completely, it is a good module system that delivers for practical use.
Re REPL debugging, the only limit I see is that the granularity of the code row&column numbering is decreased to the level of individual top-level procedure only.
Accessing the variables in their renamed form is fine also, as you have the names of all local variables from ,be all the time.
Brgds
2011/6/8 Mikael mikael.rcv@gmail.com
2011/6/8 Per Eckerdal ..
Hehe.. The stuff you have been experiencing is a large reason to why I have
pretty much given up working on Black Hole, it is so hard to integrate it into Gambit in a reasonable way.
It kindof works for me personally, for instance because I know that the warning messages you see are from Gambit and not BH, but there are so many small things that don't make sense unless you know the inner workings of BH (debugging from the REPL and attempting to access the hygienically renamed variables is a mess), and I haven't been able to get around it.
While indeed Black Hole doesn't 'swallow' Gambit and abstract it away completely, it is a good module system that delivers for practical use.
Re REPL debugging, the only limit I see is that the granularity of the code row&column numbering is decreased to the level of individual top-level procedure only.
^ Aha this one is fixed in the syntactictower branch.
Accessing the variables in their renamed form is fine also, as you have the names of all local variables from ,be all the time.
Brgds
On 7 Jun 2011, at 15:50, Benjohn Barnes about some issues with black hole.
The problems I had stemmed from using black hole with OS X incorrectly, and having it set up wrong. I've made a few changes that have fixed it [1], and it is now working nicely – thank you everyone, and sorry for all the noise.
Cheers, Benjohn
[1] I've changed Black hole so that its path comes from an environment variable BLACKHOLE_PATH, rather than being hard coded. I'll pass these on to Per so he can integrate them if he thinks they are useful. I use these changes to place BH under my home directory (/Users/benjohn/Library/Blackhole) where it can be written to by me without sudo permissions, while Gambit is installed in the default OS X binary installer location.
-
Benjohn Barnes -
Mikael -
Per Eckerdal