Re: [Chicken-users] chicken-setup failure with gmp
On Jul 22, 2005, at Fri, Jul 22, 7:22 42 PM, Dale Jordan wrote:Change to: (map (lambda (s o) (list o (list s) (lambda () (run (csc -s -O2 -d0 -R syntax-case s -L -lgmp) (Ignore line breaks above). You will need the syntax-case egg. Did the trick - thanks for your help.regards,Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] xosd:delete?
On Fri, 22 Jul 2005 21:21:33 + Mario Domenech Goulart <[EMAIL PROTECTED]> wrote: > In the xosd egg example > (http://www.call-with-current-continuation.org/eggs/xosd.html) there's a > `xosd:delete' function, but it's not provided by the egg. Shouldn't it > be `xosd:destroy'? (Just a guess -- I don't know the xosd API) One more detail: the function `xosd:set-shadow-colour' is documented as `xosd:set-shadow-color'. Best wishes, Mario ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] xosd:delete?
Hello, In the xosd egg example (http://www.call-with-current-continuation.org/eggs/xosd.html) there's a `xosd:delete' function, but it's not provided by the egg. Shouldn't it be `xosd:destroy'? (Just a guess -- I don't know the xosd API) Best wishes, Mario ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup failure with gmp
Raffael Cavallaro wrote: When I try to use chicken-setup to install the gmp egg, I get the error: csc: invalid option `-H' (map (lambda (s o) (list o (list s) (lambda () (run (csc -sH -O2 - d0 ,s -L -lgmp) Change to: (map (lambda (s o) (list o (list s) (lambda () (run (csc -s -O2 -d0 -R syntax-case s -L -lgmp) (Ignore line breaks above). You will need the syntax-case egg. Dale. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken-setup failure with gmp
When I try to use chicken-setup to install the gmp egg, I get the error: csc: invalid option `-H' which I believe comes from this form in gmp.setup: (make/proc (map (lambda (s o) (list o (list s) (lambda () (run (csc -sH -O2 - d0 ,s -L -lgmp) sfiles ofiles) (list->vector ofiles) ) Is there any way to correct this? FWIW, I built and installed the gmp library from sources prior to trying to setup the gmp egg if that makes any difference. Here is the full terminal transcript: raffaelc$ sudo chicken-setup -keep gmp The extension gmp does not exist. Do you want to download it ? (yes/no/abort) [yes] yes downloading catalog ... downloading catalog from www.call-with-current-continuation.org ... downloading gmp.egg from (www.call-with-current-continuation.org eggs 80) ... mkdir -p gmp.egg.dir gunzip -c ../gmp.egg | tar xvf - gmp.setup gmp_types.scm gmp_test.scm gmp_integer.scm gmp_test_rational.scm gmp_rational.scm gmp_test_utils.scm gmp_test_integer.scm gmp.scm gmp_test_float.scm gmp_utils.scm gmp_float.scm gmp_random.scm /usr/local/bin/csc -feature compiling-extension -sH -O2 -d0 gmp_float.scm -L -lgmp csc: invalid option `-H' make: Failed to make gmp_float.so: shell invocation failed with non- zero return status Error: shell invocation failed with non-zero return status "/usr/local/bin/csc -feature compiling-extension -sH -O2 -d0 gmp_float.scm -L -... 64 Error: shell invocation failed with non-zero return status "/usr/local/bin/csc -feature compiling-extension -sH -O2 -d0 gmp_float.scm -L -... 64 Thanks in advance, Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] minor documentation fix
Hi, The manual entry for (define-foreign-record) should indicate that, when using the (TYPENAME FOREIGNNAME) version of NAME, the FOREIGNNAME should be quoted. I actually only figured this out by vague recollection of other FFI behaviour, since if you try to compile this (as I did at first): (define-foreign-record (CRrectf CRrectf) (GLfloat x1) (GLfloat x2) (GLfloat y1) (GLfloat y2)) ..the chicken compiler hangs! (presumably in an infinite recursion) - but if you quote the foreignname it works fine. cheers, Daniel ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] signed-char* not handled correctly
Hello,
I've been encountering problems using the FFI with functions that take a
(signed char *). For example, with this short program:
---
(define-foreign-type GLbyte signed-char)
#>!
typedef signed char GLbyte;
int call_fn(GLbyte x, GLbyte *y);
<#
chicken generates this C stub (fragment):
/* from k38 in call_fn in k27 in k24 in k21 */
static C_word C_fcall stub6(C_word C_buf,C_word C_a0,C_word C_a1)
C_regparm;
C_regparm static C_word C_fcall stub6(C_word C_buf,C_word C_a0,C_word
C_a1){
C_word C_r=C_SCHEME_UNDEFINED,*C_a=(C_word*)C_buf;
char t0=(char )C_character_code((C_word)C_a0);
char * t1=(char * )C_string_or_null(C_a1);
C_r=C_int_to_num(&C_a,call_fn(t0,t1));
return C_r;}
which causes this compiler error (with csc+gcc on Kanotix/Linux):
tst.c: In function 'stub6':
tst.c:31: warning: pointer targets in passing argument 2 of 'call_fn'
differ in signedness
This error message is due to the fact that chicken is passing 'char *'
instead of 'signed char *. (I guess passing 'char' for 'signed char' is
silently ignored)
They are different; according to the GCC man-page:
"""
-funsigned-char
Let the type "char" be unsigned, like "unsigned char".
Each kind of machine has a default for what "char" should be. It is
either like "unsigned char" by default or like "signed char" by
default.
Ideally, a portable program should always use "signed char" or
"unsigned
char" when it depends on the signedness of an object. But many
programs
have been written to use plain "char" and expect it to be signed, or
expect it to be unsigned, depending on the machines they were written
for. This option, and its inverse, let you make such a program work
with the opposite default.
The type "char" is always a distinct type from each of "signed char"
or
"unsigned char", even though its behavior is always just like one of
those two.
"""
(and I didn't know this until just now :)
thanks noch einmal,
Daniel
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] static compile with eggs
This may be a faq, but I could not find related subjects in the mailing list archive. Is it possible to build a static excecutable that uses eggs? I'm trying with a simple example, which turned to be not working. Here is the log what I've done. 8<--8<--8<--8<--8<--8<--8<-- %cat foo.scm #!/usr/local/bin/csi -script (require-extension gdbm) (define db (gdbm-open "foo.db")) (gdbm-store db "knock knock" "who's there") (display (gdbm-fetch db "knock knock")) (newline) (gdbm-close db) %./foo.scm who's there %csc -static foo.scm %./foo Error: (load) unable to load compiled module "/usr/local/lib/chicken/gdbm.so" "can not load compiled code dynamically - this is a statically linked executable" ##sys#require <-- %chicken foo.scm -feature chicken-compile-static compiling `foo.scm' ... generating `foo.c' ... %chicken gdbm.scm -feature chicken-compile-static compiling `gdbm.scm' ... Warning: global variable `make_string_with_len' is never used generating `gdbm.c' ... %gcc foo.c -g -DHAVE_CHICKEN_CONFIG_H -c -DC_NO_PIC_NO_DLL -I /usr/local/chicken/include %gcc gdbm.c -g -DHAVE_CHICKEN_CONFIG_H -DC_EMBEDDED -c -DC_NO_PIC_NO_DLL -I /usr/local/chicken/include %gcc foo.o gdbm.o /usr/local/chicken/lib/libchicken.a /usr/lib/libgdbm.a -L/usr/local/chicken/lib -Wl,-R/usr/local/chicken/lib -static -ldl -lpcre -lm gdbm.o: In function `C_toplevel': .../gdbm.c:261: multiple definition of `C_toplevel' foo.o:.../foo.c:48: first defined here /usr/bin/ld: Warning: size of symbol `C_toplevel' changed from 698 in foo.o to 923 in gdbm.o collect2: ld returned 1 exit status 8<--8<--8<--8<--8<--8<--8<-- I also tried to include gdbm.scm into foo.scm, but it gives me an error. Any clue? Daishi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] C_alloc OK before C_invoke? (was Re: Constructing parameter lists in C)
On Fri, 22 Jul 2005, felix winkelmann wrote: > On 7/21/05, Daniel B. Faken <[EMAIL PROTECTED]> wrote: > > > > On a related note: is it OK to call C_alloc() to construct data to be > > passed via CHICKEN_invoke()? > > Yes, that should work. > > > The manual entry for C_alloc() says "..Note that stack-allocated data > > objects have to be passed to Scheme callback functions... This is really > > only usable for callback procedure invokations, make sure not to use it in > > normal code..." > > - but I'm not sure if the point is to not re-use C_alloc() memory or if > > this really means 'only proper callbacks' i.e. after entering scheme. > > What this means is that the storage used for the Scheme data may not be > popped from the stack if it hasn't been copied/gc'd into the major > heap yet. This may happen if you C_alloc in normal C procedures (which > subsequently return). CHICKEN_invoke runs in proper CPS mode, and > allocates merrily on the stack, so passing stack-allocated data to it should > be fine. OK. >From what I see in chicken.h, we have: # define C_alloca alloca #define C_alloc(n) ((C_word *)C_alloca((n) * sizeof(C_word))) And as I undestand, alloca() is the same as allocating things on the stack directly, via C variable declarations. So does this mean instead of (for example): C_word *data = C_alloc(N*C_SIZEOF_FLONUM); C_word one = C_flonum(&data, 1.0); C_word two = C_flonum(&data, 2.0); C_word three = C_flonum(&data, 3.0); etc. I could do C_word realdata[N*C_SIZEOF_FLONUM]; C_word *data = realdata; C_word one = C_flonum(&data, 1.0); C_word two = C_flonum(&data, 2.0); etc. ?? That is to say: * is C_alloc() just a convenient way of avoiding getting the compiler to understand &realdata (above) as a pointer-to-a-pointer? (not sure if this is an ANSI-C issue - just know my compiler thought &realdata was a pointer-to-a-C_word). * are the issues of when to use C_alloc()-ated data identical to those for the storing of data in the C stack? - or is there more complexity hiding somewhere? Maybe this should be obvious.. but the documentation for C_pair(), C_list(), etc. saying "ptr should be the address of an allocation pointer created with C_alloc" made it seem like it was doing something special (beyond what just declaring the memory in a C local-variable would do). If not, maybe this could be clarified in the documentation. Again, thanks! cheers, Daniel ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Recipe for distributing C files problematic
felix winkelmann scripsit: > The example in the manual is simply wrong. The chicken invocation should > be > > % chicken hello.scm -explicit-use -uses library -optimize-level 2 > -debug-level 0 Thanks. That makes considerably more sense. Reminder: don't forget to fix the manual before the next release. -- John Cowan [EMAIL PROTECTED] www.ccil.org/~cowan www.reutershealth.com If I have seen farther than others, it is because I am surrounded by dwarves. --Murray Gell-Mann ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] C_alloc OK before C_invoke? (was Re: Constructing parameter lists in C)
On 7/21/05, Daniel B. Faken <[EMAIL PROTECTED]> wrote: > > On a related note: is it OK to call C_alloc() to construct data to be > passed via CHICKEN_invoke()? Yes, that should work. > The manual entry for C_alloc() says "..Note that stack-allocated data > objects have to be passed to Scheme callback functions... This is really > only usable for callback procedure invokations, make sure not to use it in > normal code..." > - but I'm not sure if the point is to not re-use C_alloc() memory or if > this really means 'only proper callbacks' i.e. after entering scheme. What this means is that the storage used for the Scheme data may not be popped from the stack if it hasn't been copied/gc'd into the major heap yet. This may happen if you C_alloc in normal C procedures (which subsequently return). CHICKEN_invoke runs in proper CPS mode, and allocates merrily on the stack, so passing stack-allocated data to it should be fine. > > The C_parameter type taken by CHICKEN_invoke() has a C_word/scheme-object > field, which would seem to indicate there is some way to pass general > scheme-objects.. > If NOT with C_alloc(), then how would one construct a non-immediate > object? (e.g. where would the first arg to C_list() come from?) You could pass Scheme data to CHICKEN_invoke, that has previously been created from a different invocation of it. But as I said above, allocating some data on the stack with C_alloc and passing that should be ok. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Problem with Syntax Case in 2.0
On 7/21/05, Dale Jordan <[EMAIL PROTECTED]> wrote: > I have been experimenting with the implementation of srfi-57 which uses > syntax-case and its module system. Under Chicken-1.89 I had added (at > toplevel) a procedure definition to srfi-57.scm that was used in most of > the modules. To be precise it was the following: > > (define symbolic-identifier=? >(lambda (x y) > (eq? (syntax-object->datum x) >(syntax-object->datum y > > I also changed the references in the rest of the egg from > literal-identifier=? to symbolic-identifier=?. > > This compiled fine under 1.89. Under 2.0 I get >Error: unbound variable: symbolic-identifier=? > > I have tried putting the definition in its own module and importing it > and various permutations of eval-when, thinking it might be phase issue, > but nothing seems to work. Any clues for the perplexed? Hm. Can you send me your code? Normally that should work. > > Unrelated, I note that the run command in srfi-57.setup has a "-R > srfi-57" directive. Is this correct? It would seem to be either > redundant or harmful (referencing a previously installed version). > Actually, you're right. srfi-57 needs srff-57 to compile, so on the first installation, you take the source file (at compile-time), and on all subsequent builds, you use the previously installed, which is a bit questionable (but works most of the time). You can change the "-R" to "-X" to force loading srfi-57.scm from the current directory. It might be that this is in fact related to the problem you describe above. Perhaps the compile- and run-time incarnations of srfi-57 get mixed up again. I will play around with it. BTW, I fixed a little problem with this code just the other day - srfi-57 should from now on be usable inside psyntax modules as well. I'll upload a new version, once I've figured out this problem. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Recipe for distributing C files problematic
On 7/20/05, John.Cowan <[EMAIL PROTECTED]> wrote: > I'm using chicken-2.0. > > I'm having trouble distributing C files correctly using the "hello world" > example in section 3.5 of the manual. The host system is Cygwin and > the target is Solaris 8 with gcc 2.95.2. > > I compiled hello.scm with the specified options to "chicken" and then > transported "hello.c", "library.c", "runtime.c", and "chicken.h" as > specified to the Solaris host and compiled successfully. > > However, specifying "-explicit-use -uses hello.c" when running "chicken" > bought me a linker error saying that C_hello_c_toplevel was undefined. > Omitting these options told me instead that C_eval_toplevel and > C_extras_toplevel were undefined. The example in the manual is simply wrong. The chicken invocation should be % chicken hello.scm -explicit-use -uses library -optimize-level 2 -debug-level 0 Sorry about that. My head bows in shame. (Alternatively, remove the "-explicit-use" and add extras.c and eval.c to the Makefile). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
