- Gambit-list - mailman.iro.umontreal.ca

extracting information from socket ports
by david rush 30 Oct '05

30 Oct '05

Maybe I'm just missing it in the documentation, but how can I extract some of the core networking information from a tcp-port returned from reading a port opened with open-tcp-server? I'm hoping to extract at least the IP address and port number of the inbound connection for authorization purposes. david rush -- DIsruptive Technology!

2 1

Re: Calling blocking C libraries from scheme threads
by Christian 28 Oct '05

28 Oct '05

At 15:45 Uhr +0200 18.10.2005, Johannes Groedem wrote: >The libraries often have provisions for this. See for example >PostgreSQL's client library and its PQconsumeInput, PQisBusy, etc. >But I guess the C libraries you're using don't support this, then? The MySQL client library doesn't seem to support this. >It could be that the best solution is to just implement the protocol >in Scheme. It might be tempting to try this and see how fast Gambit can get with it. And see whether one is able to grok and imitate the protocol. But I think that doesn't scale in two ways: first, if Mysql is extended with new functionality, that interface might be going to break much sooner than if it did use the C libs. Second, there are more libraries than only this one. Imagine if you could run all of Perl's CPAN without change and not block any other scheme thread. Christian.

2 1

Need different compiler behavior to debug arithmetic
by Bradley Lucier 26 Oct '05

26 Oct '05

Marc: Here's something to think about for later. I know of no way, at the Scheme level, to debug incorrect declarations of fixnum or flonum. If you run an application interpreted, it just works, which is OK. If you run something compiled in safe mode, then it works whether the declarations are correct or not. And when you run it in unsafe mode then it generally fails with a segmentation fault. The only way I know to debug this type of fault is to compile Gambit and the application itself with - g, run the application inside gdb, then determine (a) what operation is failing and (b) the location of that operation in the scheme code by diagnosing the C output of gsc. Not fun, even for me ;-). I'l like to suggest the following compilation model for compiling numerics in safe mode: Declaration: generic, mostly-* Result: Generates code to determine the types of arguments and do the correct thing, including calling the generic operations if necessary. Declaration: fixnum, flonum Result: check the types of arguments, and generate an exception of the arguments do not match the correct types. I don't think there needs to be any change in unsafe mode. This way I could debug mistaken declarations without going through gdb. Brad

2 4

Calling blocking C libraries from scheme threads
by Christian 18 Oct '05

18 Oct '05

Hello For writing interfaces to C libraries which have socket function calls hard wired (like database client libraries), how can I make foreign calls so that they don't block other scheme threads? At first, I've thought about hacking those libraries so that they allow the socket functions to be replaced by callbacks (to functions which go into the gambit scheduler / select loop), but then I realized that this won't solve the problem, since for each scheme thread that is calling a foreign function a separate C stack would be necessary, or there would be no way to let threads continue which don't have their C call frame at the top of the stack. So the only solution seems to be using a separate pthread for each foreign function call done by a scheme thread. (The pthread could be cached and reused for subsequent foreign calls by the same scheme thread, or even be reused for different scheme threads after the scheme thread has finished.) I don't know yet the details about how to set up the connection between those pthreads and the scheme calls. I guess by using some mutex which can be accessed by both scheme and C and passing the arguments through some thread-local storage. (I've read that the GHC Haskell compiler does something like this. I could take a more detailed look there.) Has anyone done something like this already? Any hints, ideas, suggestions? (Would there be interest to include a solution into the Gambit distribution?) Thanks Christian.

2 1

Changing the name of the compiler
by Pupeno 06 Oct '05

06 Oct '05

Hello Gambiters, This may be a strange thing to ask, but could you change the name of the compiler, that is, the binary (I would put this a bug tracker, but there's none for Gambit, am I wrong ?). The problem is that there's another widely used program with a binary with the same name: $ gsc ESP Ghostscript 7.07 (2003-07-12) ... In my distro, Gambit's gsc is renamed to gsc-gambit. This makes writting automated building software very hard. I have to check if gsc exists, then check if it is Gambit or not, if it is not, check if gsc-gambit exist, and so on. Do you think it'll be possible to change the name of the compiler with something that won't conflict with something as common as Ghostscript ? Thank you. -- Pupeno <pupeno(a)pupeno.com> (http://pupeno.com)

1 0

What license ?
by Pupeno 06 Oct '05

06 Oct '05

What license is Gambit released under ? I see that LGPL and Apache's license are included in the tarball, but it doesn't specify which licenses are used and for what (all source code ? part of it ?). Thank you. -- Pupeno <pupeno(a)pupeno.com> (http://pupeno.com)

1 0

newbie feedback (this time from a non-official account)
by Vijay Kumar Varanasi 03 Oct '05

03 Oct '05

erm, realized that my last email got appended with a "This message contains confidential information and..." blah... So here we are again. Please excuse if you feel this is spam...I was hoping the lack of "confidentialy" threats would do more towards eliciting a response. Johannes Groedem, thanks for the gmane tip, by the way! ==== Dear creators of Gambit, I'm a newbie to Gambit. I'm thrilled with the emacs-key friendly gsi, and the performance of gsc. Gambit seems to be a real winner in the making. A couple of suggestions: 1. Communication : Please clarify the intent and future direction of Gambit so that potential users do not turn away due to not being kept in the loop. Is Gambit going to be an active, open-sourced project Maybe a blog by the developers with a weekly update, so that you guys dont waste too much time communicating... 2. Community : Encourage newbies, as well as keeping a separate forum for the experts. What do you think? Look forward to future releases! :) - Vijay

1 0

some feedback from a newbie
by Vijay-Kumar.Varanasi＠ubs.com 01 Oct '05

01 Oct '05

Dear creators of Gambit, I'm a newbie to Gambit. I'm thrilled with the emacs-key friendly gsi, and the performance of gsc. Gambit seems to be a real winner in the making. However, I couldn't help wonder why the mailing list interface at http://mailman.iro.umontreal.ca/mailman/listinfo/gambit-list is so.....dry. For example, the lack of a Search function and "Prev in Thread/Next in Thread" functionality (though the latter is not much of a problem). It unfortunately gives a very dry feel about Gambit as a whole. A couple of suggestions: 1. Communication : One gets the feel that the creators must be really good at what they are doing, and know how much better Gambit is going to get! It's exciting, I tell you, my imagination!! :)) However, this knowledge of direction is not clear to users like me. Clarify the intent and future direction of Gambit so that potential users do not turn away due to not being kept in the loop. I mean things like : Who are you? No need of photos, even just a brief description of who the authors of Gambit are, clearly mentioned, on http://www.iro.umontreal.ca/~gambit/ would do some good. (The current alternative is to figure out by reading the archives). Is Gambit going to be an active, open-sourced project? What are you working on right now? etc; Maybe a blog by the developers with a weekly update? So that you guys dont waste too much time communicating. 2. Community : Encourage multiple levels of communication and knowledge. New users need to be unafraid to ask silly questions and get expert advice while you, the creators, maintainers and experts of Gambit can remain "higher order" in a separate forum to discuss the big issues and hairy complications. Maybe a "gambie" (gambit newbie :) ) list can help? Again, I'm hoping that you guys can do this without wasting too much time. Maybe shift to Google groups or use BB Forum, etc;... What do you think? Look forward to future releases! :) - Vijay Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.

2 1

letrec in the interpreter
by Christian 01 Oct '05

01 Oct '05

Hello I've noticed a discrepancy between the interpreter and the compiler: in both of these cases: (define (run n) (letrec ((x (+ n 1)) (y (+ x x))) (display y) (newline))) (define (run n) (define x (+ n 1)) (define y (+ x x)) (display y) (newline)) (run 1) outputs 4 when compiled. When interpreted, it gives a "number expected, (+ #!unbound #!unbound)" exception. (Thanks to Rickdangerous on irc for the example.) Christian.

2 2

[ANN] SCons-Gambit 0.1.0
by Pupeno 27 Sep '05

27 Sep '05

Hello, I have just released SCons-Gambit 0.1.0. SCons[1] is a build system like make and autotools, alltogether in one easy to use package. SCons-Gambit adds support to SCons to build Gambit projects, currently: - Programs. - Loadable Libraries. I plan to add support for the various Shared Libraries soon. The code can be obtained on http://pupeno.com/eng/fs/scons-gambit-0.1.0.tar.bz2/file_view It contains some documentation in the form of a README and INSTALL file and some examples. For you to get an idea, the examples from the manual, being three files: - m1.c - m2.scm - m3.scm can be build by writing a file named SConstruct with these contents: env = Environment(tools = ['default', 'gsc']) env.GambitProgram(env, 'm', Split('m1.c m2.scm m3.scm')) and it con be built by simply running scons, for example: $ scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... gsc -c -o m2.c m2.scm gcc -c -o m2.o m2.c gsc -c -o m3.c m3.scm gcc -c -o m3.o m3.c gcc -c -o m1.o m1.c gsc -o m-linkfile.c m2.c m3.c gcc -c -o m-linkfile.o m-linkfile.c gcc -o m m2.o m3.o m1.o m-linkfile.o -lgambc -lm -ldl -lutil scons: done building targets. Enjoy! -- Pupeno <pupeno(a)pupeno.com> (http://pupeno.com) [1] http://www.scons.org

2 1