dear list,
i'm a new hacker on board. i'm planning to use gambit on an embedded device. i have many years of CL experience, but i'm open for anything good. i have quite some background with slime and been using it and hacking on it for long years, so i'd like to use it with gambit.
i've seen this mail, but noone answered: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2011-August/005262.ht...
what is the status of swank-gambit?
who is the current maintainer?
where is its official repo? i've found two, but neither seems anything like 'official', but rather a random repo on github.
https://github.com/jlongster/swank-gambit https://github.com/shortsightedsid/swank-gambit
i'm planning to invest time into making it more useful, but i don't want to waste efforts on something that has already been done, just hidden from my google skills.
any answers/hints are greatly appreciated,
Afficher les réponses par date
On Tue, Dec 06, 2011 at 11:10:43AM +0600, Attila Lendvai wrote:
i've seen this mail, but noone answered: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2011-August/005262.ht...
I tried to reach this site, but my browser (Chromium) told me
: This is probably not the site you are looking for! : You attempted to reach mercure.iro.umontreal.ca, but instead you : actually reached a server identifying itself as : localhost.localdomain. This may be caused by a misconfiguration on : the server or by something more serious. An attacker on your network : could be trying to get you to visit a fake (and potentially harmful) : version of mercure.iro.umontreal.ca. You should not proceed.
Now I suspect this is more serious than the usual expired certificate. Perhaps a misconfiguration on the site?
-- hendrik
Hallo,
On Tue, Dec 6, 2011 at 4:44 PM, Hendrik Boom hendrik@topoi.pooq.com wrote:
Now I suspect this is more serious than the usual expired certificate. Perhaps a misconfiguration on the site?
It works for me from Switzerland.
On 2011-12-06, at 12:10 AM, Attila Lendvai wrote:
dear list,
i'm a new hacker on board.
Nice to have you on board!
i'm planning to use gambit on an embedded device.
Cool!
i have many years of CL experience, but i'm open for anything good. i have quite some background with slime and been using it and hacking on it for long years, so i'd like to use it with gambit.
i've seen this mail, but noone answered: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2011-August/005262.ht...
what is the status of swank-gambit?
who is the current maintainer?
As far as I know, no one is maintaining swank-gambit at the moment. James Long, Julian Scheid, and I have worked on it, but it has suffered some bit rot.
where is its official repo? i've found two, but neither seems anything like 'official', but rather a random repo on github.
https://github.com/jlongster/swank-gambit https://github.com/shortsightedsid/swank-gambit
i'm planning to invest time into making it more useful, but i don't want to waste efforts on something that has already been done, just hidden from my google skills.
any answers/hints are greatly appreciated,
It seems Scheid's repo is the latest code. But when I tried it with the latest slime I got an error concerning an unsupported coding system. I looked at the code and it is due to a change in the protocol, so I fixed it up so that at least it gives a prompt after a M-x slime-connect . The code is attached to this message.
Many of the swank protocol functions are not yet implemented. So the "user experience" might be a little rough if you are used to a full implementation of SLIME. Most of the functionality is implementable, but I don't have the time to actually do it (this is mostly because I haven't found a clear description of the swank protocol). Anyway, if you need help improving swank-gambit I can explain how to implement some of the non-trivial functionality. If you improve it, please post it on the Gambit Dumping Grounds!
Marc
https://github.com/jlongster/swank-gambit https://github.com/shortsightedsid/swank-gambit
for the sake of completeness, this is the network of the github repos:
https://github.com/jlongster/swank-gambit/network
and this one seems to hold the latest commit:
https://github.com/pablomarx/swank-gambit/commits/master
It seems Scheid's repo is the latest code. But when I tried it with the latest slime I got an error concerning an unsupported coding system. I looked at the code and it is due to a change in the protocol, so I fixed it up so that at least it gives a prompt after a M-x slime-connect . The code is attached to this message.
i couldn't stop yesterday, and used it as a first scheme hacking session opportunity to fix it myself... looks like i joined wasting effort on scheme swank. how will i be able to complain about it now...? :)
my plan is to first coordinate the swank effort, because swank-chicken seems to be more functional and also kept updated. my plan for now is to set up a swank-scheme repo that brings these efforts together (official slime has some r6rs code, swank-gambit, and swank-chicken at least, maybe others not on my radar yet).
so, my first question: what's the situation with r6rs? my impression is that the scheme crowd is not too keen on jumping the bandwagon...
is the situation something like this: having a portable swank-scheme *based* on r6rs is a good thing to pursue on the long term (with backend specific extensions ala official slime on various CL's), but I should expect bugs and headaches along the way due to r6rs immaturities of various scheme VM's?
if the above holds, then i'd go that way and hunt down and/or workaround the bugs i meet along the way.
Hallo,
On Wed, Dec 7, 2011 at 6:05 AM, Attila Lendvai attila.lendvai@gmail.com wrote:
so, my first question: what's the situation with r6rs? my impression is that the scheme crowd is not too keen on jumping the bandwagon...
My understanding is that neither Chicken nor Gambit-C are going to fully adopt R6RS, so I wouldn't invest time in making swank-r6rs work if those were my preferred Schemes (incidentally, they are).
Hi Attila,
2011/12/7 Attila Lendvai attila.lendvai@gmail.com
so, my first question: what's the situation with r6rs? my impression is that the scheme crowd is not too keen on jumping the bandwagon...
Indeed.
Go with R5RS and check out R7RS more as it progresses. You have the R7RS core spec out there already, ought be all you need.
R5RS and R7RS core code are compliant with each other, save for some easy to implement yourself procedures and forms introduced by the latter.
The procedures R7RS core adds to R5RS, is things most R5RS impls have already; now they're just taken into the standard.
is the situation something like this: having a portable swank-scheme
*based* on r6rs is a good thing to pursue on the long term (with
backend specific extensions ala official slime on various CL's), but I should expect bugs and headaches along the way due to r6rs immaturities of various scheme VM's?
R7RS is the long term thing as it stands, and you already have a mature draft of the core spec out for it. Afaik the great majority of Scheme implementations today are R5RS.
For an implementation-portable app you'd need to sit down and look at exactly what language and runtime functionality you need, and then keep your code to use exactly that only. I'd advise you to do this originating from the R5RS spec.
Availability of unicode/char encoding, binary data handling and theading, numeric tower, and how to do networking and run external OS processes would be examples of differences in the runtime, availability of namespaces, DSSSL and what macro facilities there are would be examples of things that differ language-wise.
In case you really want to squeeze your code into just about any environment out there, you might want to make your own code preprocessor (that processes away macro-specific things i.e. macro expansion and any kind of cond-expands or alike you have to produce different code for different impls, and code handling specific things i.e. includes) that produces code runnable for respective Scheme impls.
if the above holds, then i'd go that way and hunt down and/or workaround the bugs i meet along the way.
-- attila
Mikael
On 2011-12-07, at 12:05 AM, Attila Lendvai wrote:
i couldn't stop yesterday, and used it as a first scheme hacking session opportunity to fix it myself... looks like i joined wasting effort on scheme swank. how will i be able to complain about it now...? :)
my plan is to first coordinate the swank effort, because swank-chicken seems to be more functional and also kept updated. my plan for now is to set up a swank-scheme repo that brings these efforts together (official slime has some r6rs code, swank-gambit, and swank-chicken at least, maybe others not on my radar yet).
I think coordinating development efforts of various swank implementations for Scheme is a good idea. It will help motivate the people interested in using SLIME with Scheme.
However I'm not sure it will reduce the total man-hours needed to develop the swank implementations. That's because a lot of the code is system dependent, and the hard part is finding out how to implement a particular SLIME feature for a particular Scheme system. For example, how to access threads (get list of threads, interrupt a thread, create a new REPL, etc), or get debugging information (source location of error, backtrace, content of frame, etc), or select a coding system for I/O. All of these things and more are possible with Gambit, but other systems don't implement these features, or implement them differently.
so, my first question: what's the situation with r6rs? my impression is that the scheme crowd is not too keen on jumping the bandwagon...
is the situation something like this: having a portable swank-scheme *based* on r6rs is a good thing to pursue on the long term (with backend specific extensions ala official slime on various CL's), but I should expect bugs and headaches along the way due to r6rs immaturities of various scheme VM's?
if the above holds, then i'd go that way and hunt down and/or workaround the bugs i meet along the way.
Support for R6RS is not widespread among the main implementations of Scheme. You are better off targeting R4RS/R5RS with an eye on R7RS-small which has a better chance of widespread acceptance (especially if Alex Shinn completes his Snow revival...). In your code, you could use the cond-expand form to conditionalize your code on the Scheme system. For those systems without cond-expand, a file specific to that Scheme system can define it as a macro. Alternatively (but harder I think), abstract the operations you need from the Scheme system, and have the common swank code call into the system specific implementation of the interface.
Marc
Alternatively (but harder I think), abstract the operations you need from the Scheme system, and have the common swank code call into the system specific implementation of the interface.
i don't think it would be harder. this is how the official slime codebase is organized, and there are major chunks of code that are shared (e.g. the entire inspector). and this kind of separation (common stuff + one file for each CL backend) is also easier to understand than a code full of cond-expand (IMHO).
it's also beneficial to mimic the official organization to make it easier to follow its future changes.
i asked the maintainer of swank-chicken (Nick Gasson) what he thinks about this, but no answer yet. swank-chicken is the most alive and maintained on my radar.
On 2011-12-09, at 2:07 AM, Attila Lendvai wrote:
Alternatively (but harder I think), abstract the operations you need from the Scheme system, and have the common swank code call into the system specific implementation of the interface.
i don't think it would be harder.
The swank protocol is the primary interface that each Scheme/Lisp system must implement. So I'm not sure how much can be gained by a different interface. That's why I say it is hard (i.e. to come up with a lower-level interface that is different from swank, is powerful enough to implement swank, and allows for more code sharing between swank implementations).
this is how the official slime codebase is organized, and there are major chunks of code that are shared (e.g. the entire inspector). and this kind of separation (common stuff + one file for each CL backend) is also easier to understand than a code full of cond-expand (IMHO).
I totally agree, given the volume of different code (which will be substantial, i.e. in the high hundreds of lines of code if not more).
Marc
Hello Attila. I was wondering how your swank for Gambit project was coming along.
I remember that you were interested in running Scheme on an embedded device. Have you considered the picobit compiler and VM I wrote? I have used it quite successfully for real-time control of a custom robot (picture below) which has a PIC microcontroller and a few KB of RAM.
Finally, talking about embedded devices, I've recently come across a cheap ($40) and super compact wifi module which contains 2 embedded ARM processors and a few hundred kilobytes of RAM. It sounds like the perfect embedded platform for wireless sensors, tiny robots, etc (here's a link: http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=47055). I'm thinking of installing picobit on one.
Marc
hallo Marc,
Hello Attila. I was wondering how your swank for Gambit project was coming along.
it's stalled while i'm further exploring the possibilities.
when i was asking around compiler authors about having a single swank-scheme project with backend-specific code in separate files, i've found little enthusiasm. and as i'm not sure how deep/long i will delve into scheme, i don't want to start yet another project that will end up being abandoned and merely be noise in the scheme universe...
as of my embedded device: in fact it's not that much embedded... it has 32MB ram and the OS on it is a linux distribution, so picobit is probably not what i need.
so far i've played with gambit, chicken, and chibi-scheme, and for now i'm further experimenting with chibi, which compiles out of the box on my target environment (cygwin based gcc cross compiler, bleh! they run linux and the SDK is windows+cygwin based... "for the convenience of the programmer")
basically what i need: - little headache porting the scheme VM to the device (i must admit, the gambit build infrastructure was a bit intimidating regarding this) - modular compilation, because e.g. there's no floating point on the device - a http client - preferably bytecode support (but text representation is also ok), that i can http get to the device and eval (the actual program)
what is secondary: - speed - fancy features (the most complex stuff i need is an http client)
my plan for now is to compile the scheme VM and a smaller loader/bootstrap code that can download, signature check and eval scheme bytecode/text, which will be the program implementing the actual business logic.
Finally, talking about embedded devices, I've recently come across a cheap ($40) and super compact wifi module which contains 2 embedded ARM processors and a few hundred kilobytes of RAM. It sounds like the perfect embedded platform for wireless sensors, tiny robots, etc (here's a link: http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=47055). I'm thinking of installing picobit on one.
sounds like fun! :)
i'm keeping an eye on http://www.raspberrypi.org/ and will most probably order one when it comes out...
as of swank-gambit: i'm not sure when i will get back to it, so i've attached my version of swank-gambit.scm that i've done parallel with you. it may have something useful, e.g. a basic code to load slime modules similar to how the CL swank does it.
but anyways, i'll be around, and let you know how things are progressing.
thanks for all the help!
-- attila
Notice the erosion of your (digital) freedom, and do something about it!
PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06
On 2012-01-19, at 10:48 PM, Attila Lendvai wrote:
hallo Marc,
Hello Attila. I was wondering how your swank for Gambit project was coming along.
it's stalled while i'm further exploring the possibilities.
when i was asking around compiler authors about having a single swank-scheme project with backend-specific code in separate files, i've found little enthusiasm. and as i'm not sure how deep/long i will delve into scheme, i don't want to start yet another project that will end up being abandoned and merely be noise in the scheme universe…
That sounds familiar.
as of my embedded device: in fact it's not that much embedded... it has 32MB ram and the OS on it is a linux distribution, so picobit is probably not what i need.
so far i've played with gambit, chicken, and chibi-scheme, and for now i'm further experimenting with chibi, which compiles out of the box on my target environment (cygwin based gcc cross compiler, bleh! they run linux and the SDK is windows+cygwin based... "for the convenience of the programmer")
Gambit also builds on cygwin "out of the box".
basically what i need:
- little headache porting the scheme VM to the device (i must admit,
the gambit build infrastructure was a bit intimidating regarding this)
If the configure script and makefiles are not working for you in your environment, you could simply call the C compiler on all the .c files. An example of this is in misc/vcexpress.bat (that's for Visual C++ Express, but just use it as a template to call the C compiler in your SDK).
- modular compilation, because e.g. there's no floating point on the device
What do you mean by "modular compilation"? This might be a problem because Gambit represents time information (such as timeouts) using floating point numbers. Isn't there a floating point software emulation of some sort?
- a http client
Do you mean client, or server? A server is in examples/web-server. A client is easy to write (for example see examples/iOS/wiki.scm) or the one I wrote for Snow (http://snow.iro.umontreal.ca/?viewpkg=http).
- preferably bytecode support (but text representation is also ok),
that i can http get to the device and eval (the actual program)
Gambit does not use bytecode. But it can serialize interpreted closures, which makes them easy to send over the net.
what is secondary:
- speed
- fancy features (the most complex stuff i need is an http client)
my plan for now is to compile the scheme VM and a smaller loader/bootstrap code that can download, signature check and eval scheme bytecode/text, which will be the program implementing the actual business logic.
Sounds neat!
Finally, talking about embedded devices, I've recently come across a cheap ($40) and super compact wifi module which contains 2 embedded ARM processors and a few hundred kilobytes of RAM. It sounds like the perfect embedded platform for wireless sensors, tiny robots, etc (here's a link: http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=47055). I'm thinking of installing picobit on one.
sounds like fun! :)
i'm keeping an eye on http://www.raspberrypi.org/ and will most probably order one when it comes out...
as of swank-gambit: i'm not sure when i will get back to it, so i've attached my version of swank-gambit.scm that i've done parallel with you. it may have something useful, e.g. a basic code to load slime modules similar to how the CL swank does it.
Thanks! I'll have a look. Can I suggest you put it up on Gambit's Dumping Grounds? (http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Dumping_Grounds)
Marc
If the configure script and makefiles are not working for you in your environment, you could simply call the C compiler on all the .c files. An example of this is in misc/vcexpress.bat (that's for Visual C++ Express, but just use it as a template to call the C compiler in your SDK).
thanks, that's good to know!
- modular compilation, because e.g. there's no floating point on the device
What do you mean by "modular compilation"? This might be a problem because Gambit represents time information (such as timeouts) using floating point numbers. Isn't there a floating point software emulation of some sort?
not a properly setup one for sure. they only give me years old gcc versions compiled for cygwin... argh!
to be honest, i'm amazed by the incompetency of the support they have. how do they want to sell their devices??? e.g. i need to send 5 mails to get all the tools needed to compile and flash the example app. then they send me out of sync stuff, doc newer then the API libs and incompatible, etc...
my plan for now is to compile the scheme VM and a smaller loader/bootstrap code that can download, signature check and eval scheme bytecode/text, which will be the program implementing the actual business logic.
Sounds neat!
it may sound neat, but it's a much more rough road than what i expected...
for now i've managed to compile chibi for the better vega5000 device, write some bootstrap code in C that reads and executes a main.scm file that prints hello world.
but the edit/compile/run turnaround circle is still some 5 mins with everything possible automated. and that's unbearable for my mind spoiled using CL and slime... :)
if i can reach a point where the bootstrap code can download and run scheme from the net, and log stuff to the net which shows up on my laptop, then this will go down a lot lower, but seems like there's still a long way there.
i'm planning to try lua also, because it has a history of embedded device use, so maybe the roads that way are more cleared.
as of gambit, it's still on my radar, but the float issue is quite a bit of headache. i may try to ask for the gcc config/sources so that i can compile a properly configured one for myself on linux, but given the incompetency of the SDK itself, i have doubts about whether i should even ask for it...
On 2012-02-13, at 8:25 AM, Attila Lendvai wrote:
If the configure script and makefiles are not working for you in your environment, you could simply call the C compiler on all the .c files. An example of this is in misc/vcexpress.bat (that's for Visual C++ Express, but just use it as a template to call the C compiler in your SDK).
thanks, that's good to know!
- modular compilation, because e.g. there's no floating point on the device
What do you mean by "modular compilation"? This might be a problem because Gambit represents time information (such as timeouts) using floating point numbers. Isn't there a floating point software emulation of some sort?
not a properly setup one for sure. they only give me years old gcc versions compiled for cygwin... argh!
to be honest, i'm amazed by the incompetency of the support they have. how do they want to sell their devices??? e.g. i need to send 5 mails to get all the tools needed to compile and flash the example app. then they send me out of sync stuff, doc newer then the API libs and incompatible, etc...
my plan for now is to compile the scheme VM and a smaller loader/bootstrap code that can download, signature check and eval scheme bytecode/text, which will be the program implementing the actual business logic.
Sounds neat!
it may sound neat, but it's a much more rough road than what i expected...
for now i've managed to compile chibi for the better vega5000 device, write some bootstrap code in C that reads and executes a main.scm file that prints hello world.
but the edit/compile/run turnaround circle is still some 5 mins with everything possible automated. and that's unbearable for my mind spoiled using CL and slime... :)
Do you need to compile at every iteration of the development cycle, or can you use an interpreter? With Gambit I typically compile the files which implement the FFI, and then I use the interpreter to develop the main application.
if i can reach a point where the bootstrap code can download and run scheme from the net, and log stuff to the net which shows up on my laptop, then this will go down a lot lower, but seems like there's still a long way there.
i'm planning to try lua also, because it has a history of embedded device use, so maybe the roads that way are more cleared.
as of gambit, it's still on my radar, but the float issue is quite a bit of headache. i may try to ask for the gcc config/sources so that i can compile a properly configured one for myself on linux, but given the incompetency of the SDK itself, i have doubts about whether i should even ask for it..x.
Gambit used to work without the need for a floating point unit. Eventually Gambit started using floats to simplify some things (like fine granularity timeouts, and multiplication of large bignums using FFT). In general, there are few dependencies on floating point, so if you don't need these things, you can probably provide a floating point emulation layer that always returns 0.0 as a result for all operations and I'm 99% sure that Gambit will still "work".
Marc
-
Alex Queiroz -
Attila Lendvai -
Hendrik Boom -
Marc Feeley -
Mikael