Gambit-list Décembre 2005

gambit-list@iro.umontreal.ca

13 participants
25 discussions

Compiler internal error (variable conflict)
by Christian 26 Déc '05

26 Déc '05

Hello With Beta 15 I'm seeing "Compiler internal error .. variable conflict" in about every fifth file or so. I've now realized that it is tied to using the '(debug) option (used by default in chjmodule) and the standard-bindings declaration. IIRC, older betas didn't have that problem. Here's an example: (declare (standard-bindings)) (define (flat ll) (letrec ((flatten (lambda (l r) (cond ((pair? l) (flatten (car l) (flatten (cdr l) r)) ) ((null? l) r) (else (cons l r)))))) (flatten ll '()))) > (compile-file "foo" '(debug)) (slots: (l ret l r #f #f #f #f 0 1 r #f #f return #f) source: (car l)) *** ERROR -- Compiler internal error detected *** in procedure targ-add-first-class-label!, variable conflict #f Thanks Christian.

1 0

Re: simple unoptimized gsc nontail recursion
by Bill Richter 25 Déc '05

25 Déc '05

I made a tail recursion improvement (using mutation, as Christian suggested), and Brad Lucier's conjecture of Feb 6, 2005 becomes true. Now, on a machine with 2GB memory, I can "differentiate" my polynomial of length 75299 in 8.2 minutes, with essentially *no* garbage collection: (time (pretty-print (Poly-first (D X)))) 495310 ms real time, 8.2 minutes 495314 ms cpu time (494923 user, 391 system) 35 collections accounting for 2568 ms real time, 0.0 minutes 1193260824 bytes allocated 10180 minor faults no major faults Brad replied to me on Feb 6: > (time (pretty-print (Poly-first (D X)))) > 998093 ms real time, 16.6 minutes > 997940 ms cpu time (997840 user, 100 system) > 3204 collections accounting for 365525 ms real time (365690 user, > 30 system) > 112648202368 bytes allocated > 13318 minor faults > 3 major faults > > Did I really use 112.6 gB? My machine "only" has 1 gB of memory. Probably, yes. Each of the 3204 garbage collections collected on average about 30+ megabytes of data, which it could reuse until the next GC, etc. My guess is that if you doubled the amount of real memory to 2GB the number of collections would drop to a few hundred. The improvement I made was to replace this non-tail recursive merge function ;; merge-1 : (listof X)^2 (X X -> boolean) -> (listof X) ;; to merge two sorted lists into a longer sorted list, deleting ;; repetitions, using less-than?. (define (merge-1 shortlist longlist less-than?) (cond [(empty? shortlist) longlist] [(empty? longlist) shortlist] [else (let ([a (first shortlist)] [x (first longlist)]) (cond [(equal? a x) (merge-1 (rest shortlist) (rest longlist) less-than?)] [(less-than? a x) (cons a (merge-1 (rest shortlist) longlist less-than?))] [else (cons x (merge-1 shortlist (rest longlist) less-than?))]))])) with this tail-recursive merge function (which I then renamed): ;; merge-sort : (listof X)^2 (X X -> boolean) -> (listof X) ;; to merge two sorted lists into a longer sorted list, deleting ;; repetitions, using less-than?. ;; Tail recursive with mutation. (define (merge-sort shortlist longlist less-than?) (let ([M (cons 'start longlist)]) ;; we need a kludge because when we consume longlist, ;; there's no pointer left to attach shortlist to. (let loop ([shortlist shortlist] [p M]) (cond [(empty? shortlist) (rest M)] [(empty? (rest p)) (and (set-rest! p shortlist) (rest M))] [else (let* ([a (first shortlist)] [R (rest p)] [x (first R)] [RR (rest R)]) (cond [(equal? a x) ;; delete x by replacing R by RR (and (set-rest! p RR) (loop (rest shortlist) p))] [(less-than? a x) (and (set-first! R a) (set-rest! R (cons x RR)) (loop (rest shortlist) R))] [else (loop shortlist (rest p))]))])))) I feel like there ought to be a more elegant way to code this...

1 0

Conflicting c-lambda definitions in Gambit generated C code
by TJay 23 Déc '05

23 Déc '05

Another problem I've found while porting OpenGL to Gambit-C 4 b15. I have 3 functions in C which take a function pointer, which has this prototype in C: void (*fn)() I defined the 3 functions in Gambit by using the followinf c-lambda special forms: (define gluTessCallback (c-lambda (GLUtriangulatorObj* GLenum (function () void)) void "gluTessCallback")) (define gluNurbsCallback (c-lambda (GLUnurbsObj* GLenum (function () void)) void "gluNurbsCallback")) (define gluQuadricCallback (c-lambda (GLUquadricObj* GLenum (function () void)) void "gluQuadricCallback")) When I compile, I get the following errors: /tmp/cc4tArz0.o: In function `___converter0': gluQuadricCallback.c:(.text+0x0): multiple definition of `___converter0' /tmp/ccnNcStz.o:gluNurbsCallback.c:(.text+0x0): first defined here /tmp/ccicCqhJ.o: In function `___converter0': gluTessCallback.c:(.text+0x0): multiple definition of `___converter0' /tmp/ccnNcStz.o:gluNurbsCallback.c:(.text+0x0): first defined here collect2: ld returned 1 exit status It seems there is a problem having multiple "(function () void)"s. Even if I create a (c-define-type voidFunc* (function () void)) in another file and include it in the three files containing tose 3 functions, it still gives me the same error. If I move all 3 functions to the same file, however, the error disappears. (Because the ___converter0 function only appears in 1 C file.) ~ TJay ~

1 0

Efficient support for delimited continuations?
by Newcombe, Chris 21 Déc '05

21 Déc '05

Marc, Does (or will) Gambit v4 have native support for shift/reset or splitter/abort/call/pc? And if so, can the resulting partial continuations be serialized? I read your paper on 'A Better API for First-Class Continuations" (http://repository.readscheme.org/ftp/papers/sw2001/feeley.pdf), and I see that Gambit v4 does have continuation-graft. But that paper doesn't mention partial continuations. Rationale: I am eager to make use of Oleg Kiselyov's 'Zipper In Scheme': http://okmij.org/ftp/Scheme/zipper-in-scheme.txt Interestingly, at the end of that article, Oleg says "It doesn't matter which particular delimited continuation operator (shift, control, shift0, splitter, cupto, etc) is supported -- all of them are equally expressible", and cites a paper by Chung-chieh Shan which I haven't read yet. However, Christian Queinnec seems to make a good case that his own splitter operator is less dangerous/confusing than shift/reset when nested: http://www-spi.lip6.fr/~queinnec/PDF/contlib.pdf There's a discussion thread here: http://lambda-the-ultimate.org/node/view/606 Thanks, Chris

3 2

RE: [gambit-list] Efficient support for delimited continuations?
by Newcombe, Chris 21 Déc '05

21 Déc '05

Or perhaps Hieb & Dybvig's 'spawn' operator would be a better match for Gambit's threading system? http://www.cs.indiana.edu/~dyb/papers/LaSC-7-1-pp83-110.pdf "In the presence of concurrency, the effect of a control operation must be defined in terms of the branches of a process tree. By "process tree," we mean simply a tree-structured continuation record. Since traditional continuation control operators are derived from the notion of representing continuations as stacks, it is not surprising that such operators are inadequate for controlling concurrency. The spawn operator, on the other hand, is designed specifically for the control of tree-structured concurrency." -----Original Message----- From: gambit-list-bounces(a)iro.umontreal.ca [mailto:gambit-list-bounces@iro.umontreal.ca] On Behalf Of Newcombe, Chris Sent: Wednesday, December 21, 2005 5:35 PM To: gambit-list(a)iro.umontreal.ca Subject: [gambit-list] Efficient support for delimited continuations? Marc, Does (or will) Gambit v4 have native support for shift/reset or splitter/abort/call/pc? And if so, can the resulting partial continuations be serialized? I read your paper on 'A Better API for First-Class Continuations" (http://repository.readscheme.org/ftp/papers/sw2001/feeley.pdf), and I see that Gambit v4 does have continuation-graft. But that paper doesn't mention partial continuations. Rationale: I am eager to make use of Oleg Kiselyov's 'Zipper In Scheme': http://okmij.org/ftp/Scheme/zipper-in-scheme.txt Interestingly, at the end of that article, Oleg says "It doesn't matter which particular delimited continuation operator (shift, control, shift0, splitter, cupto, etc) is supported -- all of them are equally expressible", and cites a paper by Chung-chieh Shan which I haven't read yet. However, Christian Queinnec seems to make a good case that his own splitter operator is less dangerous/confusing than shift/reset when nested: http://www-spi.lip6.fr/~queinnec/PDF/contlib.pdf There's a discussion thread here: http://lambda-the-ultimate.org/node/view/606 Thanks, Chris _______________________________________________ Gambit-list mailing list Gambit-list(a)iro.umontreal.ca http://mailman.iro.umontreal.ca/mailman/listinfo/gambit-list

1 0

Re: [gambit-list] Trying to get gambc40b15 compiled and running under Visual Studio 2003 (p.s.)
by Mark Shirley 21 Déc '05

21 Déc '05

[I meant to add, I'm trying to see whether Gambit would work as an extension language to this environment: http://www.digitalspace.com/projects/lunar-telerobotics/. I used gambit 3.0 in a previous robotics simulation framework, and it worked very nicely. I'm hoping the lightweight threads in version 4 will be even better. - Mark] Marc, The sln files didn't work as is, but adding HAVE_STDIO_H;HAVE_ERRNO_H to the preprocessor definitions for the lib project was all that was needed. I ran through the tests. They basically work. There were minor problems, e.g., the file sizes of error.scm and newdir2/bbb changed, and there's something odd going on with the r4rstest.scm. (I can't get the test to work using the commandline as in tests/makefile.in, but running it by hand works fine.) Thank you very much to all who sent suggestions. If anyone wants the sln files, let me know, although they're exactly what Marc just sent plus the two preprocessor definitions above added to the lib project. A final question: has anyone used Gambit as an extension language for another program? Is there an example of building it as a dll or .so and making the call to initialize scheme? (I remember that being pretty easy in version 3, but so much has changed.) - Mark

1 0

Trying to get gambc40b15 compiled and running under Visual Studio 2003
by Mark H. Shirley 21 Déc '05

21 Déc '05

Hello, I'm trying to get gambc40b15 running under Visual Studio 2003. I haven't found Visual studio project files that work with any of the versions of gambit that I have (12-15), so I'm trying to role my own. I've gotten it to compile and link with no errors, but when I run the executable, I get repeated errors like these: (peek-char '#<input-output-port #2 (console)>) > *** ERROR -- Error code 11 Has anyone seen this before? I believe code 11 here is EAGAIN which is the value that a non-blocking socket read should return when there's no data. I think think is and should be happening here, but I don't understand why it's treated as an error. It appears to me to be a problem with my preprocessor directives s.t. the USE_PUMPS code isn't working. Here are the preprocessor definitions I'm using (the full build log is at the end). HAVE_STDIO_H;HAVE_ERRNO_H;_DEBUG;WIN32;_CONSOLE;___SINGLE_HOST I don't know whether other HAVE+xxx declarations are needed. I've inserted pragmas that print messages which show that USE_PUMPS is getting defined. (I focused on that because I'm guessing they're relative to the peek.) I also had to insert the extern "C" declaration in this code from os_tty.c so that GetConsoleWindow would link: #ifdef USE_WIN32 // Shirley - kludge here to make this work. I don't understand why we're using C++ extern "C" { HWND WINAPI GetConsoleWindow(void); } ___HIDDEN BOOL WINAPI console_event_handler ___P((DWORD dwCtrlType), ()); #endif The the build log is below. I'd very much appreciate any suggestions or directions to try. Thanks, Mark Shirley ---------------------------------------- ------- Build started: Project: msc_gsi, Configuration: Debug|Win32 ------- Command Lines Creating temporary file "c:\Documents and Settings\Mark Sh\Desktop\gambc40b15\Debug\RSP000003.rsp" with contents [ /Od /I ".\lib" /I ".\include" /D "HAVE_STDIO_H" /D "HAVE_ERRNO_H" /D "_DEBUG" /D "WIN32" /D "_CONSOLE" /D "___SINGLE_HOST" /D "_MBCS" /Gm /EHsc /MLd /Fp".\Debug/MSC_GSI.pch" /Fo".\Debug/" /Fd".\Debug/" /W1 /c /ZI /TP ".\lib\setup.c" ".\lib\os_tty.c" ".\lib\os_time.c" ".\lib\os_shell.c" ".\lib\os_io.c" ".\lib\os_files.c" ".\lib\os_dyn.c" ".\lib\os_base.c" ".\lib\os.c" ".\lib\mem.c" ".\lib\main.c" ".\lib\c_intf.c" ".\lib\_thread.c" ".\lib\_system.c" ".\lib\_std.c" ".\lib\_repl.c" ".\lib\_num.c" ".\lib\_nonstd.c" ".\lib\_kernel.c" ".\lib\_io.c" ".\gsi\_gsi_.c" ".\gsi\_gsi.c" ".\lib\_gambc.c" ".\lib\_eval.c" ] Creating command line "cl.exe @"c:\Documents and Settings\Mark Sh\Desktop\gambc40b15\Debug\RSP000003.rsp" /nologo" Creating temporary file "c:\Documents and Settings\Mark Sh\Desktop\gambc40b15\Debug\RSP000004.rsp" with contents [ /OUT:".\Debug/GSI.exe" /INCREMENTAL:NO /DEBUG /PDB:".\Debug/GSI.pdb" /SUBSYSTEM:CONSOLE /MACHINE:X86 ws2_32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ".\Debug\_eval.obj" ".\Debug\_gambc.obj" ".\Debug\_gsi.obj" ".\Debug\_gsi_.obj" ".\Debug\_io.obj" ".\Debug\_kernel.obj" ".\Debug\_nonstd.obj" ".\Debug\_num.obj" ".\Debug\_repl.obj" ".\Debug\_std.obj" ".\Debug\_system.obj" ".\Debug\_thread.obj" ".\Debug\c_intf.obj" ".\Debug\main.obj" ".\Debug\mem.obj" ".\Debug\os.obj" ".\Debug\os_base.obj" ".\Debug\os_dyn.obj" ".\Debug\os_files.obj" ".\Debug\os_io.obj" ".\Debug\os_shell.obj" ".\Debug\os_time.obj" ".\Debug\os_tty.obj" ".\Debug\setup.obj" ] Creating command line "link.exe @"c:\Documents and Settings\Mark Sh\Desktop\gambc40b15\Debug\RSP000004.rsp"" Output Window Compiling... setup.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h os_tty.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h os_time.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h os_shell.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h os_io.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h os_files.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h os_dyn.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h os_base.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h os.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h mem.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h main.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h c_intf.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h _thread.c _WIN32 is defined! _system.c _WIN32 is defined! _std.c _WIN32 is defined! _repl.c _WIN32 is defined! _num.c _WIN32 is defined! _nonstd.c _WIN32 is defined! _kernel.c _WIN32 is defined! defining USE_PUMPS! INCLUDE_errno_h is defined! including errno.h _io.c _WIN32 is defined! c:\Documents and Settings\Mark Sh\Desktop\gambc40b15\lib\_io.c(65536) : warning C4049: compiler limit : terminating line number emission Compiler limit for line number is 65535 Generating Code... Compiling... _gsi_.c _WIN32 is defined! _gsi.c _WIN32 is defined! _gambc.c _WIN32 is defined! _eval.c _WIN32 is defined! Generating Code... Linking... Microsoft (R) Incremental Linker Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. "/OUT:.\Debug/GSI.exe" /INCREMENTAL:NO /DEBUG "/PDB:.\Debug/GSI.pdb" /SUBSYSTEM:CONSOLE /MACHINE:X86 ws2_32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ".\Debug\_eval.obj" ".\Debug\_gambc.obj" ".\Debug\_gsi.obj" ".\Debug\_gsi_.obj" ".\Debug\_io.obj" ".\Debug\_kernel.obj" ".\Debug\_nonstd.obj" ".\Debug\_num.obj" ".\Debug\_repl.obj" ".\Debug\_std.obj" ".\Debug\_system.obj" ".\Debug\_thread.obj" ".\Debug\c_intf.obj" ".\Debug\main.obj" ".\Debug\mem.obj" ".\Debug\os.obj" ".\Debug\os_base.obj" ".\Debug\os_dyn.obj" ".\Debug\os_files.obj" ".\Debug\os_io.obj" ".\Debug\os_shell.obj" ".\Debug\os_time.obj" ".\Debug\os_tty.obj" ".\Debug\setup.obj" LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification Results Build log was saved at "file://c:\Documents and Settings\Mark Sh\Desktop\gambc40b15\Debug\BuildLog.htm" msc_gsi - 0 error(s), 2 warning(s) Dr. Mark Shirley NASA Ames Research Center MS 269-2 Moffett Field, CA 94035 650 604 3389 Mark.H.Shirley(a)nasa.gov

4 4

Directory of executable?
by TJay 15 Déc '05

15 Déc '05

How do I get the path to the directory that contains the executable file of my program? If I was coding in C, under Linux, I'd get the path as argv[0] in my main() function. -- ~ TJay ~

2 1

Re: simple unoptimized gsc nontail recursion
by Bill Richter 15 Déc '05

15 Déc '05

Christian & Marc, my problems are not all of a tail-recursion nature. I just made a very dramatic speedup in a different way, which more or less cuts my cons-cell usage in half. First the drama: My "Curtis algorithm" calculation for t = 73, s = 14 (included below) formerly took more than 3 hours, on a machine with 2 GB memory. With the new code (now on my web page), it's less than 5 minutes! I was thinking about what Marc wrote Feb 8, 2005: on a 32 bit machine, each call to "cons" counts for 24 bytes (each field of the pair takes 4 bytes (header, car, cdr) and there is an extra factor of 2 for the space reserved in the to-space so that the garbage collector can copy the pair if it is live when the GC is performed). The speedup was simple: I changed my definition of tree from ;; Tree ::= empty | (listof (n Tree)) to ;; Tree ::= empty | (append (n Tree) Tree) so a tree is now an alternating list of numbers & trees, so that's half the cons cells. First let's go back to Marc's cons = 24 B. Let's see how much storage a large "polynomials" might use. I include on on my web page tar file a polynomial of length 75299 which starts: (4 8 4 5 3 5 9 3 5 7 7) (4 8 4 5 3 5 6 6 5 7 7) (4 8 4 5 3 5 3 5 9 7 7) OK. A list of 11 numbers is 10 cons cells, so 24*10 B, so in the whole polynomial, that's 24*10*75299, but it's also a list, which means 75298 cons cells, so that's (* 24 (+ 75298 752990)) = 19878912 B = 20 MB not counting how much space is needed to store the actual numbers (all small integers, as you see). That's a lot, considering that the whole data file takes 1856775 B = 1.8 MB, but 20 MB won't make me page out to disk, with 2 GB RAM (or even 1 GB RAM). But somehow differentiating my polynomials and merging them together takes a lot of memory. So I just differentiated this large polynomial, and it took 12.7 minutes, including 3.8 minutes GC, and allocated 112648198848 B = 112.6 GB So a lot of calculation is done on that original 20 MB of data, but my point is that we don't want to double the cons cell usage on such a calculation. Now this code doesn't use trees anyway. I just noticed that the "derivative" of this polynomial of length 75299 has itself the smaller length of 56570. Here's my output: 75299 (4 8 4 5 3 5 9 3 5 7 7) (time (D X)) 765468 ms real time, 12.7 minutes 765522 ms cpu time (765256 user, 266 system) 3203 collections accounting for 228700 ms real time, 3.8 minutes 112648198848 bytes allocated 13276 minor faults no major faults 56570 (3 4 4 2 3 5 3 5 9 7 7 7) Notice that Brad's conjecture of Feb 6, 2005 seems false, as I'm still getting 3203 collections. Brad wrote: > (time (pretty-print (Poly-first (D X)))) > 998093 ms real time, 16.6 minutes > 997940 ms cpu time (997840 user, 100 system) > 3204 collections accounting for 365525 ms real time (365690 user, > 30 system) > 112648202368 bytes allocated > 13318 minor faults > 3 major faults > > Did I really use 112.6 gB? My machine "only" has 1 gB of memory. Probably, yes. Each of the 3204 garbage collections collected on average about 30+ megabytes of data, which it could reuse until the next GC, etc. My guess is that if you doubled the amount of real memory to 2GB the number of collections would drop to a few hundred. OK, back to my new slim trees: gsi adem - (define zeta '((4 4 1 1 1) (4 2 2 2 1) (4 1 1 2 3) (3 3 2 2 1) (3 2 4 1 1) (3 1 2 4 1) (2 2 4 2 1) (2 2 2 2 3) (1 1 2 4 3))) (D zeta) (Poly->Tree zeta) gives the output > (D zeta) () > (Poly->Tree zeta) (4 (4 (1 (1 (1))) 2 (2 (2 (1))) 1 (1 (2 (3)))) 3 (3 (2 (2 (1))) 2 (4 (1 (1))) 1 (2 (4 (1)))) 2 (2 (4 (2 (1)) 2 (2 (3)))) 1 (1 (2 (4 (3))))) So zeta is a "cycle", i.e. D(zeta) = 0, and turning zeta into a tree just factors out the first coefficients 4 & 3 terms. But previously I had double the number of parentheses: > (Poly->Tree zeta) ((4 ((4 ((1 ((1 ((1))))))) (2 ((2 ((2 ((1))))))) (1 ((1 ((2 ((3))))))))) (3 ((3 ((2 ((2 ((1))))))) (2 ((4 ((1 ((1))))))) (1 ((2 ((4 ((1))))))))) (2 ((2 ((4 ((2 ((1))))) (2 ((2 ((3))))))))) (1 ((1 ((2 ((4 ((3)))))))))) That was really dumb coding on my part. I should say that for me, it was a pain to modify the code to use half the parentheses, and I failed before, but I did it this time with the debugger! Every time I goofed it up, I got the debugger to print out a variable for me, and gradually sense dawned on me. The calculation for t = 73, s = 14 doesn't produce much: (B 15 73 ((1 1 2 2 4 3 5 5 6 5 2 3 5 7 7) (2 3 2 4 3 5 5 6 5 2 3 5 7 7)) ((3 2 2 2 2 4 3 5 6 5 2 3 5 7 7) (6 2 2 2 4 3 5 6 5 2 3 5 7 7)) ((3 5 2 2 2 2 4 5 5 5 3 6 6 5 3) (4 7 2 2 2 4 5 5 5 3 6 6 5 3)) ((5 10 2 2 2 2 2 4 3 3 3 6 6 5 3) (6 11 5 6 2 2 2 2 2 3 5 7 3 3)) ((7 14 2 2 2 2 2 2 2 2 3 5 7 3 3) (8 15 6 2 2 2 2 2 2 4 5 3 3 3)) ((9 2 2 4 1 1 2 4 7 3 3 6 6 5 3) (16 2 2 2 2 2 4 3 3 3 6 6 5 3)) ((10 1 2 4 1 1 2 4 7 3 3 6 6 5 3) (12 2 4 1 1 2 4 7 3 3 6 6 5 3)) ((11 22 2 4 1 1 2 4 1 1 2 4 1 1 1) (12 24 4 1 1 2 4 1 1 2 4 1 1 1)) ((19 2 2 2 2 2 2 2 2 2 3 5 7 3 3) (20 3 6 2 2 2 2 2 2 4 5 3 3 3)) ((25 2 2 4 1 1 2 4 1 1 2 4 3 3 3) (26 3 6 2 3 4 4 1 1 2 4 1 1 1)) ((26 1 2 4 1 1 2 4 1 1 2 4 3 3 3) (28 2 4 1 1 2 4 1 1 2 4 3 3 3)) ((27 6 2 4 1 1 2 4 1 1 2 4 1 1 1) (28 8 4 1 1 2 4 1 1 2 4 1 1 1)) ((28 3 4 4 1 1 2 4 1 1 2 4 1 1 1) (34 2 4 1 1 2 4 1 1 2 4 1 1 1)) ((31 2 2 4 1 1 2 4 1 1 2 4 1 1 1) (32 4 4 1 1 2 4 1 1 2 4 1 1 1)))

1 0

network-info unimplemented?
by Kevin Smith 14 Déc '05

14 Déc '05

Playing around with some networking code in Gambit 4.0b15 this evening and I came across the following: > (network-info "127.0.0.1") *** ERROR IN (console)(a)1.1 -- Unimplemented operation (network-info "127.0.0.1") 1> (network-info "sourceforge.net") *** ERROR IN (console)(a)2.1 -- Unimplemented operation (network-info "sourceforge.net") 2> I'm running Gambit on the latest Kubuntu Linux release. Is network-info not implemented or does this indicate a problem in my local Gambit install? --Kevin

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Décembre 2005