Re: [dwm] OT : suckless foreign function interface
On 11/20/08, Christoph Lohmann [EMAIL PROTECTED] wrote: Good evening, Am Tue, 18 Nov 2008 20:18:10 + schrieb Anselm R Garbe [EMAIL PROTECTED]: The advantage is, 9P can be used in an universal way, network transparently and without any platform/language boundaries. The only tricky part is defining a sane synthetic fs for abstracting the RPCs you are looking for. However, there are non-Plan9ish examples in the procfs (might not be the best reference though). For 9P you need a system support, so you can use local calls, which are fast. If you intend to run it over network (resp. Unix sockets), you have the problem of latency and lazy implementations of 9P. 9P can be implemented asynchronously, but for a simple library/module inter- face it's too much of a hassle. Christoph Lohmann The 9p idea made me think that there may be some simple way of doing it in plan9. I wrote a plumber interface. Its probably suboptimal, but it seems to work. plumber will even loads the handler :) Doing it this seems to suggest a removal of some of the stuff from the interpreter itself, because you only file io. Another way is to use plumber code to write a dedicated ffi server mount it into the file system, but I dont know if it's any better. I guess doing it this way is very close to the system() call approach. sorry about the OT. but thanks a lot. -- http://www.fernski.com
Re: [dwm] OT : suckless foreign function interface
Good evening, Am Tue, 18 Nov 2008 20:18:10 + schrieb Anselm R Garbe [EMAIL PROTECTED]: The advantage is, 9P can be used in an universal way, network transparently and without any platform/language boundaries. The only tricky part is defining a sane synthetic fs for abstracting the RPCs you are looking for. However, there are non-Plan9ish examples in the procfs (might not be the best reference though). For 9P you need a system support, so you can use local calls, which are fast. If you intend to run it over network (resp. Unix sockets), you have the problem of latency and lazy implementations of 9P. 9P can be implemented asynchronously, but for a simple library/module inter- face it's too much of a hassle. Sincerely, Christoph Lohmann
Re: [dwm] OT : suckless foreign function interface
Hi Fernan, 2008/11/15 Fernan Bolando [EMAIL PROTECTED]: 1. Generate small C programs and call them via system() inside the scheme interpreter. 2. Add custom code into the scheme interpreter and link in the lib 3. Develop some sort of foreign function interface What about a 9P interface? Here is a scheme implementation: http://www.ohloh.net/projects/chicken-9p If you guys have an example of implementing some sort of suckless approach to foreign function that would be cool. The advantage is, 9P can be used in an universal way, network transparently and without any platform/language boundaries. The only tricky part is defining a sane synthetic fs for abstracting the RPCs you are looking for. However, there are non-Plan9ish examples in the procfs (might not be the best reference though). Kind regards, --Anselm
[dwm] OT : suckless foreign function interface
Hi all I am not sure if there are any specific mailinglist that is dedicated to bieng suckless so I am posting it here. i am trying to extend a scheme interpreter so that I can use it for certain type of problems that I think that a marriage of scheme and C would be the best option. I was wondering what you guys think of the approaches below 1. Generate small C programs and call them via system() inside the scheme interpreter. 2. Add custom code into the scheme interpreter and link in the lib 3. Develop some sort of foreign function interface If you guys have an example of implementing some sort of suckless approach to foreign function that would be cool. fernan -- http://www.fernski.com
Re: [dwm] OT : suckless foreign function interface
Greetings, 1. Generate small C programs and call them via system() inside the scheme interpreter. well, if speed is a non-issue... ... how about dlopen/dlsym? that's pretty simple and rather usual. Callable C functions should export a standard API (like the builtins in your interpreter?), you designate an initialization function that registers these in the namespace, and you're set. As for writing a custom ffi, how about looking at libffi or gnu lightning instead? Regards, Mate
