Black Hole and C source
Is there a way to get the generated C (or assembly) from bh? I can't find one. Thanks! -Jason
Afficher les réponses par date
I made a branch a few months ago trying to solve that exact problem (trying to cross-compile to Android?). It works... until you need modules which use non-interpreter functions such as those used by FFI code (c-declare, etc...). The main reason is that the macro expander needs to load the code in interpreted mode. I abandoned because Blackhole is not a piece of cake to understand and refactor. I'll tackle this problem again, but it will need some mental energy and time. I plan to do it in 2-3 months. cheers! ps: I think this is more important than writing about syntax-rules, so I'll probably work on this soon. On Mon, Jan 21, 2013 at 9:36 PM, Jason Felice <jason.m.felice@gmail.com>wrote:
Is there a way to get the generated C (or assembly) from bh? I can't find one.
Thanks! -Jason
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
To my experience it works. (module-compile! 'yourmodulename to-c: #t) is the way. Works? I checked many times that this works in the BH distro I posted here on the ML with a ref to a .tar.gz put on the dumping grounds ~2 months ago. This should be all you need. (The status of this in syntactictower-BH (master on GITHUB) I'm not aware of at the current moment and intend to look into within a foreseeable-enough future.) Brgds 2013/1/21 Jason Felice <jason.m.felice@gmail.com>
Is there a way to get the generated C (or assembly) from bh? I can't find one.
Thanks! -Jason
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
I should clarify: 2013/1/22 Mikael <mikael.rcv@gmail.com>
To my experience it works. (module-compile! 'yourmodulename to-c: #t) is the way.
Works?
I checked many times that this works in the BH distro I posted here on the ML with a ref to a .tar.gz put on the dumping grounds ~2 months ago. This should be all you need.
^ In this BH distro (aka nonsyntactictower-BH, called "legacy" in the GITHUB repo) it has worked perfect every single time I can remember.
(The status of this in syntactictower-BH (master on GITHUB) I'm not aware of at the current moment and intend to look into within a foreseeable-enough future.)
^ This BH distro is the one to be tweaked into good functioning - better macro expansion algorithm used but not satisfactorily tested and tried till now.
Brgds
2013/1/21 Jason Felice <jason.m.felice@gmail.com>
Is there a way to get the generated C (or assembly) from bh? I can't find one.
Thanks! -Jason
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
ok, if that's the case then it works with non-syntactic-tower branch, I can't tell at the moment since it's been long... On Tue, Jan 22, 2013 at 12:19 AM, Mikael <mikael.rcv@gmail.com> wrote:
I should clarify:
2013/1/22 Mikael <mikael.rcv@gmail.com>
To my experience it works. (module-compile! 'yourmodulename to-c: #t) is the way.
Works?
I checked many times that this works in the BH distro I posted here on the ML with a ref to a .tar.gz put on the dumping grounds ~2 months ago. This should be all you need.
^ In this BH distro (aka nonsyntactictower-BH, called "legacy" in the GITHUB repo) it has worked perfect every single time I can remember.
(The status of this in syntactictower-BH (master on GITHUB) I'm not aware of at the current moment and intend to look into within a foreseeable-enough future.)
^ This BH distro is the one to be tweaked into good functioning - better macro expansion algorithm used but not satisfactorily tested and tried till now.
Brgds
2013/1/21 Jason Felice <jason.m.felice@gmail.com>
Is there a way to get the generated C (or assembly) from bh? I can't find one.
Thanks! -Jason
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
I've recalled that the issue happened when trying to compile with ffi code that couldn't be linked with native libs and loaded, ie depends on libraries for another platform. I believe this is true for BH old branch as well unless the code expansion doesnt load code in the interpreter (I doubt it). Please correct me if you can fix that, I'll be very happy :-) Anyway, this is something that we need to get working, besides cleaning up and documenting Blackhole because ATM is barely maintanable IMO. BH should become a community project. Currently is maintained be Per but he doesn't have much interest on it right now. Contributions had been just a few api changes and small improvements. We can't just let the syntactic branch sit there unmaintained. I just can't live without syntax-rules. Alexpander is great, but modules are a must for big projects and shareable libs. Best regards, Álvaro El 22/01/2013 01:07, "Álvaro Castro-Castilla" < alvaro.castro.castilla@gmail.com> escribió:
ok, if that's the case then it works with non-syntactic-tower branch, I can't tell at the moment since it's been long...
On Tue, Jan 22, 2013 at 12:19 AM, Mikael <mikael.rcv@gmail.com> wrote:
I should clarify:
2013/1/22 Mikael <mikael.rcv@gmail.com>
To my experience it works. (module-compile! 'yourmodulename to-c: #t) is the way.
Works?
I checked many times that this works in the BH distro I posted here on the ML with a ref to a .tar.gz put on the dumping grounds ~2 months ago. This should be all you need.
^ In this BH distro (aka nonsyntactictower-BH, called "legacy" in the GITHUB repo) it has worked perfect every single time I can remember.
(The status of this in syntactictower-BH (master on GITHUB) I'm not aware of at the current moment and intend to look into within a foreseeable-enough future.)
^ This BH distro is the one to be tweaked into good functioning - better macro expansion algorithm used but not satisfactorily tested and tried till now.
Brgds
2013/1/21 Jason Felice <jason.m.felice@gmail.com>
Is there a way to get the generated C (or assembly) from bh? I can't find one.
Thanks! -Jason
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
2013/1/22 Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com>
I've recalled that the issue happened when trying to compile with ffi code that couldn't be linked with native libs and loaded, ie depends on libraries for another platform. I believe this is true for BH old branch as well unless the code expansion doesnt load code in the interpreter (I doubt it). Please correct me if you can fix that, I'll be very happy :-)
Can you tell how to reproduce this?
Anyway, this is something that we need to get working, besides cleaning up and documenting Blackhole because ATM is barely maintanable IMO. BH should become a community project.
..
We can't just let the syntactic branch sit there unmaintained.
Agree 100%. I'll get into tweaking the syntactic branch into good functioning and bringing order to documentation of surface aspects for all BH in a while. Re BH internals, documentation and adding comments, and perhaps even reimplementation of some bit just in case needed for high code clarity, I guess would be completely relevant. Also, what about documentation of these macro facilities in general, as you Alvaro proposed in an email ~2w ago? I just can't live without syntax-rules. Alexpander is great, but modules
are a must for big projects and shareable libs.
Best regards,
Álvaro
Brgds
El 22/01/2013 01:07, "Álvaro Castro-Castilla" < alvaro.castro.castilla@gmail.com> escribió:
ok, if that's the case then it works with non-syntactic-tower branch, I
can't tell at the moment since it's been long...
On Tue, Jan 22, 2013 at 12:19 AM, Mikael <mikael.rcv@gmail.com> wrote:
I should clarify:
2013/1/22 Mikael <mikael.rcv@gmail.com>
To my experience it works. (module-compile! 'yourmodulename to-c: #t) is the way.
Works?
I checked many times that this works in the BH distro I posted here on the ML with a ref to a .tar.gz put on the dumping grounds ~2 months ago. This should be all you need.
^ In this BH distro (aka nonsyntactictower-BH, called "legacy" in the GITHUB repo) it has worked perfect every single time I can remember.
(The status of this in syntactictower-BH (master on GITHUB) I'm not aware of at the current moment and intend to look into within a foreseeable-enough future.)
^ This BH distro is the one to be tweaked into good functioning - better macro expansion algorithm used but not satisfactorily tested and tried till now.
Brgds
2013/1/21 Jason Felice <jason.m.felice@gmail.com>
Is there a way to get the generated C (or assembly) from bh? I can't find one.
Thanks! -Jason
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On Tue, Jan 22, 2013 at 3:12 PM, Mikael <mikael.rcv@gmail.com> wrote:
2013/1/22 Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com>
I've recalled that the issue happened when trying to compile with ffi code that couldn't be linked with native libs and loaded, ie depends on libraries for another platform. I believe this is true for BH old branch as well unless the code expansion doesnt load code in the interpreter (I doubt it). Please correct me if you can fix that, I'll be very happy :-)
Can you tell how to reproduce this?
I'll be able to tell you when I come back to BH. At the moment I use my own system with Alexpander. But you can take a look at my branch: https://github.com/alvatarc/blackhole/commits/master
I'll get into tweaking the syntactic branch into good functioning and bringing order to documentation of surface aspects for all BH in a while.
If you plan on doing this, we should coordinate.
Re BH internals, documentation and adding comments, and perhaps even reimplementation of some bit just in case needed for high code clarity, I guess would be completely relevant.
Yes it is relevant. Especially the packages part needs some review. The macros part is too scary for me to dive into it ATM.
Also, what about documentation of these macro facilities in general, as you Alvaro proposed in an email ~2w ago?
Well, that's a completely different topic: I planned on writing about techniques for developing syntax-rules macros, but not about implementation details or any other gory details. Just some practical tutorial. I don't have time to do this if I get into BH though! Best regards, Álvaro
2013/1/22 Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com>
On Tue, Jan 22, 2013 at 3:12 PM, Mikael <mikael.rcv@gmail.com> wrote:
2013/1/22 Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com>
I've recalled that the issue happened when trying to compile with ffi code that couldn't be linked with native libs and loaded, ie depends on libraries for another platform. I believe this is true for BH old branch as well unless the code expansion doesnt load code in the interpreter (I doubt it). Please correct me if you can fix that, I'll be very happy :-)
Can you tell how to reproduce this?
I'll be able to tell you when I come back to BH. At the moment I use my own system with Alexpander. But you can take a look at my branch: https://github.com/alvatarc/blackhole/commits/master
I'll get into tweaking the syntactic branch into good functioning and bringing order to documentation of surface aspects for all BH in a while.
If you plan on doing this, we should coordinate.
Ok I'll do this. Basically I made almost-all of the documentation that's out there, and at the time it was made, nonsyntactictower/legacy was the newest one and syntactictower/master was just an idea. Since then, the combination of documentation on Gambit's wiki + the BH manuals uploaded there + the readme shown on the Github repo page kind of got a bit out of sync with each other, and I just want to bring order to that so it's all clear. And apart from this, I'm interested in tweaking syntactictower/master to work as good as nonsyntactictower does, for the things that nonsyntactictower does (i.e., the central stuff). And last, I'm interested in updating both syntactictower and nonsyntactictower so both have a (srfi ) 'package'/'module resolver', that in that resolver the SRFI:s are identifier _primarily_ by name and that there's secondarily a 'proxy' module by a printed name ("strings" for 13, "list" for 0 etc.) that re-exports the primary module. This is, I believe, the primary cause for compatibility issues for code projects using BH, between the two branches currently. And last, I may want to make the requirement in syntactictower of all symbols used in code being defined, optional through a configuration option. :) We already know how to do this. Can be a PITA to have a requirement of code being perfect sometimes that's why.
Re BH internals, documentation and adding comments, and perhaps even
reimplementation of some bit just in case needed for high code clarity, I guess would be completely relevant.
Yes it is relevant. Especially the packages part needs some review.
Yes I agree on that one, that probably is where there's most space for actual improvement, the design there is not cemented. For instance currently I believe package names and available packages are hardcoded in a user-global file, obviously that can't scale well across projects, am curious to see a solution to that that scales better, must be one. If you have any ideas for how this could be done nicely, please feel free to share. As for the central functionality (the import form, dependency loading and calculation, actual code expansion including coloring and expansion of define-macro and SC) I believe it's all in a very good form already in the syntactic/master repo and that just needs some minor tweaking like firing it up, see if anything clearly misbehaves like exceptions etc., and if so fix it.
The macros part is too scary for me to dive into it ATM.
Hehe ok, also of course it would be good to have a specification of what the macro expander *really does* (in terms of exact macro forms), supposedly there's people around who know this very well though I didn't stumble on any concise and easy-enough-to-read guide on all the involved macro facilities yet. Might be a good thing to have before trying to understand the source of a probably-not-over-commented expander.
Also, what about documentation of these macro facilities in general, as
you Alvaro proposed in an email ~2w ago?
Well, that's a completely different topic: I planned on writing about techniques for developing syntax-rules macros, but not about implementation details or any other gory details. Just some practical tutorial. I don't have time to do this if I get into BH though!
Best regards,
Álvaro
Brgds
I've done a few tests with BH (both legacy and master). Currently, I'm more cautious about Blackhole's maturity. - BH "legacy" actually supports (module-compile! <module> to-c: #t) for C output. Then you can produce link files just from the list of produced C files, I'd expect. But BH master doesn't support to-c compilation, that's some functionality that I tried to implement (in my github fork) that fails with FFI code as I explained before. If there is some solution for this I'd be the happiest possible and earn back some of my lost hair in my head. I have an idea of how it could be fixed, but... (next point) - Both legacy and master branches fail to pass the syntax-rules stress test designed by Oleg Kiselyov. While at this level, macrology might look like alchemy for deities, is humanly useful and I trust this code in judging BH macro system's maturity, since it just usses continuation-passing-style macros and some "essential" macros I myself use in my code. Reference: http://okmij.org/ftp/Scheme/macros.html#syntax-rule-stress-test I'd be happy to improve Blackhole's master branch in all the aspects like packages, modules and compilation (I have my own ideas that differ a bit from what have been talked here, but that's ok). But I can't devote the time to understand and fix the macro system at the moment. When this part is working flawlessly (ie. passes this stress test) I'll switch to BH from Alexpander (or Psyntax, which also passes the test) and contribute to its maintenance. If I find the time and energy to tackle the whole macro system, I'll do it, but I can't really do that in the near future. Honestly, I think Blackhole is essential to Gambit's ecosystem. However, at the moment isn't as mature and flexible as Gambit with Alexpander, even though I very much miss the module system. Best regards, Álvaro On Tue, Jan 22, 2013 at 4:39 PM, Mikael <mikael.rcv@gmail.com> wrote:
2013/1/22 Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com>
On Tue, Jan 22, 2013 at 3:12 PM, Mikael <mikael.rcv@gmail.com> wrote:
2013/1/22 Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com>
I've recalled that the issue happened when trying to compile with ffi code that couldn't be linked with native libs and loaded, ie depends on libraries for another platform. I believe this is true for BH old branch as well unless the code expansion doesnt load code in the interpreter (I doubt it). Please correct me if you can fix that, I'll be very happy :-)
Can you tell how to reproduce this?
I'll be able to tell you when I come back to BH. At the moment I use my own system with Alexpander. But you can take a look at my branch: https://github.com/alvatarc/blackhole/commits/master
I'll get into tweaking the syntactic branch into good functioning and bringing order to documentation of surface aspects for all BH in a while.
If you plan on doing this, we should coordinate.
Ok I'll do this.
Basically I made almost-all of the documentation that's out there, and at the time it was made, nonsyntactictower/legacy was the newest one and syntactictower/master was just an idea.
Since then, the combination of documentation on Gambit's wiki + the BH manuals uploaded there + the readme shown on the Github repo page kind of got a bit out of sync with each other, and I just want to bring order to that so it's all clear.
And apart from this, I'm interested in tweaking syntactictower/master to work as good as nonsyntactictower does, for the things that nonsyntactictower does (i.e., the central stuff).
And last, I'm interested in updating both syntactictower and nonsyntactictower so both have a (srfi ) 'package'/'module resolver', that in that resolver the SRFI:s are identifier _primarily_ by name and that there's secondarily a 'proxy' module by a printed name ("strings" for 13, "list" for 0 etc.) that re-exports the primary module. This is, I believe, the primary cause for compatibility issues for code projects using BH, between the two branches currently.
And last, I may want to make the requirement in syntactictower of all symbols used in code being defined, optional through a configuration option. :) We already know how to do this. Can be a PITA to have a requirement of code being perfect sometimes that's why.
Re BH internals, documentation and adding comments, and perhaps even
reimplementation of some bit just in case needed for high code clarity, I guess would be completely relevant.
Yes it is relevant. Especially the packages part needs some review.
Yes I agree on that one, that probably is where there's most space for actual improvement, the design there is not cemented. For instance currently I believe package names and available packages are hardcoded in a user-global file, obviously that can't scale well across projects, am curious to see a solution to that that scales better, must be one.
If you have any ideas for how this could be done nicely, please feel free to share.
As for the central functionality (the import form, dependency loading and calculation, actual code expansion including coloring and expansion of define-macro and SC) I believe it's all in a very good form already in the syntactic/master repo and that just needs some minor tweaking like firing it up, see if anything clearly misbehaves like exceptions etc., and if so fix it.
The macros part is too scary for me to dive into it ATM.
Hehe ok, also of course it would be good to have a specification of what the macro expander *really does* (in terms of exact macro forms), supposedly there's people around who know this very well though I didn't stumble on any concise and easy-enough-to-read guide on all the involved macro facilities yet.
Might be a good thing to have before trying to understand the source of a probably-not-over-commented expander.
Also, what about documentation of these macro facilities in general, as
you Alvaro proposed in an email ~2w ago?
Well, that's a completely different topic: I planned on writing about techniques for developing syntax-rules macros, but not about implementation details or any other gory details. Just some practical tutorial. I don't have time to do this if I get into BH though!
Best regards,
Álvaro
Brgds
I'm curious how do you actually use alexpander with gambit (without blackhole) Does it take much efforts to hook it into the gambit system in order to use it by default or e.g. using the -:s flag? Or Are you still have a modified blackhole environment where you replaced the macro expansion routines. I've looked into the alexpander packages itself and there wasn't unfortanetely a clear help to hook it in (Only using it explicitly). I haven't looked into the source of blackhole yet, but if someone already figured it out, i would be glad for any hints :) Chris Am 23.01.2013 01:47, schrieb Álvaro Castro-Castilla:
Honestly, I think Blackhole is essential to Gambit's ecosystem. However, at the moment isn't as mature and flexible as Gambit with Alexpander, even though I very much miss the module system.
Best regards,
Álvaro
participants (4)
-
Chris Müller -
Jason Felice -
Mikael -
Álvaro Castro-Castilla