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

C++ build for visual c++
by Seth Burleigh 30 Jan '10

30 Jan '10

How do I force a build in c++ for visual c++? Ive read the readme file which states how to do it using a makefile but I do not have MKS toolkit 5.1 and it isn't free. Ive managed to embed c++ in a linux g++ build of gambit-c and now I would like to do the same for visual c++!

1 0

[newbie] about libraries distribution
by Marco Maggi 28 Jan '10

28 Jan '10

Ciao, I have some acquaintance with R5RS, I have successfully compiled a hello-world program with GSC, I have skimmed through the "Link Files" node of Gambit's documentation. Can someone point me to a small, non-advanced, Gambit-only, does-the-right-thing, shared-library oriented package which precompiles and installs a library for Gambit, so that I can understand what does it mean in terms of compilation commands, installation conventions, etc.? Also, what's the difference between a Gambit's source distribution and a "-devel" source distribution? (I was not able to find it on Gambit's site.) TIA P.S. I cannot make the grammar-nazi in me shut up: sometimes in the doc, the variants of the word "separate" are spelled "seperate". -- Marco Maggi

2 1

Re: [gambit-list] What is required to port gambit to a new cpu?
by Marc Feeley 27 Jan '10

27 Jan '10

I've seen exactly this behaviour when the include/gambit.h.in file determines the wrong endianness for the CPU. Given that the ARM can either be little or big-endian, chances are good that the #ifdefs in the gambit.h.in file are not sufficient to detect the endianness on the Nokia platform. Usually the C compiler or development environment will define a symbol that indicates the endianness of the CPU, and the gambit.h.in file needs to be modified to test this symbol. Here is an excerpt of the gambit.h.in file which determines the endianness when the CPU is an ARM: #ifndef ___BIG_ENDIAN #ifndef ___LITTLE_ENDIAN ... #ifdef ___CPU_arm #ifdef _LITTLE_ENDIAN #define ___LITTLE_ENDIAN #endif #ifdef __LITTLE_ENDIAN__ #define ___LITTLE_ENDIAN #endif #ifdef __LITTLE_ENDIAN_DATA__ #define ___LITTLE_ENDIAN #endif #endif ... #endif #endif Note that by default the gambit.h.in file assumes the endianness is big-endian. So I'm pretty sure none of the symbols _LITTLE_ENDIAN, __LITTLE_ENDIAN__, and __LITTLE_ENDIAN_DATA__ are defined and the gambit.h.in file will assume incorrectly that the endianness is big-endian. There are two solutions. #1, the clean way, is to check the compiler documentation to see which symbol is defined by the C preprocessor to indicate the endianness, and to modify the above sequence of #ifdefs to take that into account. #2, the brute force way, is to add #define ___LITTLE_ENDIAN at the top of the gambit.h.in file. I propose you try #2 first, and if that solves the problem, then try #1 and send me a patch so I can modify my source code. Note that after modifying the include/gambit.h.in file, you will have to do a ./configure and probably a "make mostlyclean" before "make". Marc On 2009-12-29, at 3:49 AM, Frederick LeMaster wrote: > Thanks! > > I tried it out and some things work great, such as cons and most of > the list functions, but the reader seems to be having some serious > issues: > >> 0 > 3 >> 1 > 2 >> 2 > 1 >> 3 > 0 >> 4 > 7 >> 5 > 6 >> 6 > 5 >> 7 > 4 >> 8 > *** ERROR IN (console)(a)9.1 -- Unbound variable: 8 > 1> > > It seems like it is failing to read the digits properly as numbers. > The arithmetic routines seem okay though, >> (number->string (+ (string-length "elephant") (string-length ""))) > "8" > > Is the reader making an unsafe assumption? > -Fred LeMaster > > On Mon, Dec 28, 2009 at 6:40 AM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote: >> >> On 2009-12-28, at 3:04 AM, Frederick LeMaster wrote: >> >>> Hello Dr. Feeley, >>> I am interested in using gambit on the nokia n900 tablet, which >>> features an ARMv7 cpu. What changes would I need to make in the gambit >>> sources to allow it to function correctly on this architecture? >> >> Nothing! It should work "out of the box". >> >> Marc

4 3

Linux Build 4.6
by David N Murray 27 Jan '10

27 Jan '10

Hi, I just built 4.6.0 from source on my linux box and I ran into a problem. It seems I don't have makefile in my home directory with an 'all' target, so the build failed. I fixed lib/makefile to stop it from looking in ~: --- makefile.~1~ 2010-01-26 18:03:32.000000000 -0500 +++ makefile 2010-01-26 18:11:23.000000000 -0500 @@ -286,7 +286,7 @@ all-recursive: @if test -n " guide"; then \ - for subdir in "" guide; do \ + for subdir in guide; do \ (cd $$subdir && $(MAKE) all) || exit 1; \ done \ fi All tests ran successfully. Configured with: $ ./configure --enable-single-host --enable-guide --enable-profile \ --enable-coverage --enable-shared --enable-cplusplus Thanks, Dave p.s. Should this be a bug report, or is the list OK? I'm about to send another one for problems I'm having building on OpenBSD 4.4/AMD.

1 0

Building Gambit with the native Microsoft compiler suite
by Ben Goetter 20 Jan '10

20 Jan '10

Folks, In the "vs2008" branch of the Gambit fork at http://github.com/goetter/gambit I have an nmake-compatible set of Makefiles that build Gambit with Microsoft Visual Studio 2008, that is, without the tools of mingw or msys. It supports make bootstrap and make bootclean, but not yet make update (I have a suitable script that I'll test once the master branch advances a couple more releases). To use, from the topmost Gambit source directory, type misc\winbuild. You may need to edit this batch file if your copy of VS2008 is installed to a drive other than C: winbuild currents knows the following targets: clean, bootclean, realclean, bootstrap, all. This environment will build a native Win64 Gambit as well. You will need to edit misc\winbuild.bat and misc\winconf.mak per the comments in each. I will fix bugs in this branch as I find them (win64 + wide character system calls is good for flushing out such), and will offer those fixes to Marc for possible incorporation into "master" as appropriate. (If I've erred, please let me know. My git-fu is weak.) Ben

1 0

Re: [gambit-list] swank-gambit backend for SLIME
by REPLeffect 19 Jan '10

19 Jan '10

On Mon, Jan 18, 2010 at 12:51 PM, REPLeffect <repleffect(a)gmail.com> wrote: > On Mon, Jan 18, 2010 at 12:09 PM, REPLeffect <repleffect(a)gmail.com> wrote: >> On Mon, Jan 18, 2010 at 12:00 PM, REPLeffect <repleffect(a)gmail.com> wrote: >>> On Mon, Jan 18, 2010 at 11:41 AM, James Long <longster(a)gmail.com> wrote: >>>> >>>> >>>> On Mon, Jan 18, 2010 at 12:28 PM, REPLeffect <repleffect(a)gmail.com> wrote: >>>>> >>>>> Yeah, this morning I found the REPL-OUTPUT-REDIRECT in the previous >>>>> version of swank-gambit.scm and had set it to #f to get the error >>>>> messages to the terminal. Just now I downloaded the lastest version >>>>> and set it up with SWANK-DEBUG to #t, and I get the same error message >>>>> as I did with the previous version of swank-gambit.scm (here I typed >>>>> in the undefined symbol 'sdf'): >>>>> ------------------------------------------ >>>>> (emacs==> (:emacs-rex (swank:listener-eval "sdf >>>>> ") "???" :repl-thread 3)) >>>>> ------------- REPL is now in #<thread #2 #<input-output-port #3 >>>>> (tcp-client)>> ------------- >>>>> *** ERROR IN exception-message, "swank-gambit.scm"@340.14 -- Wrong >>>>> number of arguments passed to procedure >>>>> (call-with-output-string "" '#<procedure #4>) >>>>> >>>> >>>> Great. I don't know why that's erroring. I'm using Gambit v4.5.2, has that >>>> procedure changed? Can you try to evaluate something like this: >>>> (call-with-output-string "" (lambda (p) (display "sdfd" p))) >>>> See if it works? I don't have time to look into it right now, but it looks >>>> like it might be easy to fix if you want to have a crack at it. >>>> - James >>>> >>> >>> Wow, I hadn't tried running call-with-output-string separately, I'd >>> just looked at the code that called it and didn't see anything wrong >>> with it. However, when I ran your suggested code I got the exact same >>> error. Then I tried it on the Mac Mini, and it printed out the >>> results with no errors. I'm using the exact same source code of >>> gambit on both machines, so the results surprise me a little. I'm >>> going to try building that version of gambit on another Linux machine >>> I have and see if the results are the same. >>> >> >> Interestingly enough, the rebuilt code on the other Linux machine has >> the exact same error message. I'm going to try downloading the latest >> version of Gambit and see if the problem goes away. >> > > Nope. Gambit 4.6.0 gives the exact same error message under Linux. > It was compiled using gcc 4.3.2 (from the current Debian 5.0 package). > I ran configure only with the --enable-single-host option. I did run > 'make check' before installing, and all of the tests passed. > > I am now recompiling without the --enable-single-host option, to see > if that makes any difference. > And nope, configuring without --enable-single-host made no difference (I wasn't really expecting it to, but I thought it was worth trying). Sorry, I thought I had been sending all of this to the list and instead was just sending/replying to James' email. I have filled in the missing messages above.

2 2

repl-output-port as dynamic variable for SLIME?
by James Long 19 Jan '10

19 Jan '10

Marc and others, I'm having a bit of trouble integrating proper output handling in swank-gambit. Gambit's special REPL ports (repl-input-port and repl-output-port) conflicts with what we want to do since SLIME is handling the REPL now and makes things difficult. For example, when I eval code in swank-gambit, it does something like this: (let ((result #f)) (let ((output (with-output-to-string "" (set! result (eval form))))) ...)) Yes, it's a bit awkward because I want both the output and the result for the evaluation. So we capture any output from the evaluation in the `output` variable so that we can send it to SLIME. The problem is that `pp` by default prints to `repl-output-port`. `repl-output-port` is not a dynamic variable; it is a hardcoded special port. So I cannot in any way capture its output when I'm evaluating forms, unless users specifically pass `current-output-port` to `pp` as the port, which is confusing. Now, I have successfully redirected the repl ports to the current ports with the following code: (define (thread-make-swank-repl-channel thread) (##make-repl-channel-ports (current-input-port) (current-output-port))) (set! ##thread-make-repl-channel thread-make-swank-repl-channel) This lets me capture anything to `repl-output-port` because it sends it to `current-output-port`. However, now we have a problem. Any thread *outside* of SLIME evaluations (say, any part of the application we are debugging) needs to have different behavior. If a slime client is connected, I think all output from an application should be redirected to SLIME in some fashion, and this could be done by overriding ##thread-make-repl-channel. The solution is to set ##thread-make-repl-channel to create ports which forward output to a SLIME connect if connected. But when I'm evaluating code sent from SLIME, I want to capture the output sent to `repl-output-port`, so I want to treat it as a dynamic variable like so: (let ((result #f)) (let ((output (with-output-to-string "" (parameterize ((repl-output-port (current-output-port))) (set! result (eval form)))))) ...)) Either we need to rethink that fact that `pp` sends output to `repl-output-port` by default, treat `repl-output-port` as a dynamic variable, or do something to make all this clearer. It's very confusing. - James

1 0

swank-gambit backend for SLIME
by REPLeffect 19 Jan '10

19 Jan '10

I am trying to use James' swank implementation on Debian Linux 5.0 (Lenny). I've been using Gambit 4.4.4 there for a while now with no problems. I'm using the Debian-packaged emacs (22.2.1) and the latest cvs of slime. I can connect fine to the swank instance and can evaluate valid symbols fine. The problem that I have is that when I enter a symbol that has not been defined, I don't get an error when I press enter. The prompt simply does not come back, and gsi acts like it is still trying to complete the read. With this same setup on my Mac Mini (same versions of slime and gambit) everything works fine. Interestingly enough, I had the same problems when using Jame's modified version of Marc's simple debugging repl. (I had to make Marc's suggested modifications to the debugging stuff to get the sockets to work at all in Linux, but after that that it worked fine, except for this problem with invalid symbols). OK, well, it probably isn't just invalid symbols, the problem seems to occur any time gsi would normally return an error. In my testing prior to the SLIME backend, I've had to start up multiple REPLs in case I ever hit enter after a typo :-D Anyone got any ideas why this is happening under Linux? I'd be more than happy to try out any suggestions to get it to work properly.

2 1

Get OS file descriptor of TCP socket port Re: Location
by Mikael 17 Jan '10

17 Jan '10

Taylor, The code attached at the bottom does what you want, without need for linking to os_io.c . In case Gambit would change it might need update. Mikael 2010/1/17 Taylor Venable <taylor(a)metasyntax.net> > Hi, I've been hacking a lot the last couple days to try to figure out > how to get the file descriptor for a socket created with open-tcp-client > on Linux. I've finally got it figured out, and to do it I obtain the > rdevice for the port via the condition variable and in C cast it to a > ___device_tcp_client_struct to extract the 's' field (the file descrip- > tor). There's only one problem: whereas ___device_stream_struct is > defined in os_io.h and I can conveniently include it from my C code, the > definition of ___device_tcp_client_struct is in os_io.c and I had to > copy it out and paste it into my code. Is there something about that > definition that makes its location in the C source (rather than the > header) necessary? I'd prefer to just #include something, but if the > only way is to copy/paste those lines then I'll just continue to do > that. Thanks for any advice. > > -- > Taylor Venable > http://metasyntax.net/ > > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list > - (c-declare " #include <unistd.h> #include <errno.h> #include <string.h> #include <fcntl.h> #include </usr/local/Gambit-C/current/lib/os_io.h> // I'm well aware this is not the default installation directory for this file. // Though let's use it for convention. Requires os.h and os_time.h . ") ; How to get file descriptor of TCP socket port: ; ##make-device-port on _io.scm 1202 puts its rdevice and wdevice parameters ; as condition-variable-name of ##vector-ref 44 and 45 of the port. ; ##make-device-port is invoked by ##make-device-port-from-single-device of row 1560, ; which is in turn invoked by ##make-tcp-client-port 5767, which is in turn invoked ; by ##open-tcp-client on row 5816. Please note that rdevice and wdevice are the ; same variable. It is generated by ##os-device-tcp-client-open invoked on ; row 5807, that's declared in _kernel.scm row 3966, which calls ___os_device_tcp_client_open ; that's declared in os_io.c row 7272. So the return value contains this. ; The return value is generated by ___NONNULLPOINTER_to_SCMOBJ (defined in c_intf.c 4617) that convers an arbitrary pointer ; to a SCMOBJ. In this case it's the ___device_tcp_client structure dev. ; ; The socket (i.e. the file descriptor) is generated by a call to the OS function socket ; on row 3407 in the function create_tcp_socket. The result is written to the SOCKET_TYPE ; pointer argument that's the first parameter of the function. The function is called by ; ___device_tcp_client_setup_from_sockaddr declared on row 3559. After generation it passes ; the socket into ___device_tcp_client_setup_from_socket declared on row 3472, as third parameter. ; As first parameter, the function takes the ___device_tcp_client. It copies the socket into the ->s ; property of the structure. ; ; ___device_tcp_client is declared on row 2960 in os_io.c . The structure is designed like that first ; in it, there's a ___device_stream, then the socket comes. ___device_stream is defined in os_io.h row 414. ; SOCKET_TYPE is declared in os_io.c and is defined to int on USE_POSIX systems, and to SOCKET on USE_WIN32 ; systems. ; ; Thus, to get the socket file descriptor of an open TCP socket port, take the int sizeof(___device_stream) ; bytes into (condition-variable-name (##vector-ref port 44)) . ; ; ** In case this function stops working with a new version of Gambit, ; ** First check if the ___device_tcp_client structure has been changed, that is, if the first property is not ; ** a ___device_stream and the second the socket anymore. ; ** Second, check if the name parameter of vector-index no. 44 of TCP connection ports aren't ; ** (see macro-device-port-rdevice-condvar's definition) ; ** foreign-objects in general, and ___device_tcp_client values in particular, anymore. Use (##vector->list port). (define (tcp-socket-port->fd port) (let* ((___device_tcp_client (condition-variable-name (util#device-port-rdevice-condvar port))) (ptr (foreign-address ___device_tcp_client))) ((c-lambda (unsigned-long) int #<<C int ptrv = ___arg1; // fprintf(stderr,"In C now, the pointer value is %i. sizeof(___device_stream) is %i.\n\n",ptrv,sizeof(___device_stream)); // ___device_stream* v = ___CAST(___device_stream*,(int*) ptrv); // fprintf(stderr,"v is %i.\n",(int) v); ptrv += sizeof(___device_stream); int* ptr = (int*) ptrv; // fprintf(stderr,"In C now, after having added to the pointer, it's %i (%i). The value found at its location is %i.\n\n",(int) ptr,ptrv,*ptr); ___result = *ptr; C ) ptr)))

2 2

Location of ___device_tcp_client_struct definition
by Taylor Venable 17 Jan '10

17 Jan '10

Hi, I've been hacking a lot the last couple days to try to figure out how to get the file descriptor for a socket created with open-tcp-client on Linux. I've finally got it figured out, and to do it I obtain the rdevice for the port via the condition variable and in C cast it to a ___device_tcp_client_struct to extract the 's' field (the file descrip- tor). There's only one problem: whereas ___device_stream_struct is defined in os_io.h and I can conveniently include it from my C code, the definition of ___device_tcp_client_struct is in os_io.c and I had to copy it out and paste it into my code. Is there something about that definition that makes its location in the C source (rather than the header) necessary? I'd prefer to just #include something, but if the only way is to copy/paste those lines then I'll just continue to do that. Thanks for any advice. -- Taylor Venable http://metasyntax.net/

1 0