[Chicken-users] C_word type / Cython (warning: passing argument 2 from incompatible pointer type)
Here's the solution on the Cython side. Is C_word a long (or int) though? > Here's my setup: > > OSX 10.6.6 > Chicken 4.6.0 > Python 2.7.1 > Cython 0.14 > > ** The Chicken part: > > What type is C_word? The only thing I see is this in chicken.h > > #ifdef C_SIXTY_FOUR > # define C_word long > # define C_u32 uint32_t > # define C_s32 int32_t > #else > # define C_word int > # define C_u32 unsigned int > # define C_s32 int > #endif > > but I get the following warning: > > warning: passing argument 2 of ‘CHICKEN_eval_string’ from incompatible > pointer type > > > ** The Cython part: > > I'm trying to use this with Cython, so I have (in my *.pxd): > > ctypedef long C_word (Note: I tried ctypedef int C_word also.) > Please add the ctypedef inside the cdef extern block below, and you should be done... > cdef extern from "chicken.h": > int CHICKEN_eval_string(char *, C_word *) > > cdef inline C_word C_chick_eval_s (char *IN_STR): > cdef C_word OUT_RESULT > status = CHICKEN_eval_string(IN_STR, &OUT_RESULT) > if (status == 0): > print "Chicken evaluation failed" > elif (str(OUT_RESULT) == '#'): > pass > else: > print OUT_RESULT > return OUT_RESULT > > > Thanks! > > -Dave > -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] C_word type / Cython (warning: passing argument 2 from incompatible pointer type)
Here's my setup: OSX 10.6.6 Chicken 4.6.0 Python 2.7.1 Cython 0.14 ** The Chicken part: What type is C_word? The only thing I see is this in chicken.h #ifdef C_SIXTY_FOUR # define C_word long # define C_u32uint32_t # define C_s32int32_t #else # define C_word int # define C_u32unsigned int # define C_s32int #endif but I get the following warning: warning: passing argument 2 of ‘CHICKEN_eval_string’ from incompatible pointer type ** The Cython part: I'm trying to use this with Cython, so I have (in my *.pxd): ctypedef long C_word (Note: I tried ctypedef int C_word also.) cdef extern from "chicken.h": int CHICKEN_eval_string(char *, C_word *) cdef inline C_word C_chick_eval_s (char *IN_STR): cdef C_word OUT_RESULT status = CHICKEN_eval_string(IN_STR, &OUT_RESULT) if (status == 0): print "Chicken evaluation failed" elif (str(OUT_RESULT) == '#'): pass else: print OUT_RESULT return OUT_RESULT Thanks! -Dave ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Using a macro definition within a explicit renaming macro.
On Fri, Feb 11, 2011 at 03:13:36PM -0500, Patrick Li wrote: > Hello, > I'm working with explicit renaming macros, and I'm having a lot of trouble > using macros within them. > > (define-syntax say-hi > (syntax-rules () > ((say-hi) (display "Hello!" > > (define-syntax my-renaming-macro > (lambda (expression rename comparison) > (say-hi) <-- Attempt to call predefined macro > '(quote output-expression))) > > When I run (my-renaming-macro) I get : > Error: during expansion of (my-renaming-macro ...) - unbound variable: > say-hi That's a phasing problem. Macros can use only macros that are imported for the macro expansion process using import-for-syntax because all macros are defined in the macro environment, which differs from the macro *expansion* environment. This works though: (module foo (say-hi) (import chicken scheme) (define-syntax say-hi (syntax-rules () ((say-hi) (display "Hello!") (import-for-syntax foo) (define-syntax my-renaming-macro (lambda (expression rename comparison) (say-hi) '(quote output-expression))) (my-renaming-macro whatever) There may be a shorter way involving begin-for-syntax or something. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Using a macro definition within a explicit renaming macro.
Hello, I'm working with explicit renaming macros, and I'm having a lot of trouble using macros within them. (define-syntax say-hi (syntax-rules () ((say-hi) (display "Hello!" (define-syntax my-renaming-macro (lambda (expression rename comparison) (say-hi) <-- Attempt to call predefined macro '(quote output-expression))) When I run (my-renaming-macro) I get : Error: during expansion of (my-renaming-macro ...) - unbound variable: say-hi Is there anyway around this? -Patrick ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Implementing a macroexpand-all
If you figured it out that would be amazing. I'm not sure myself what the core binding forms are, but this is a very interesting problem, I'm enjoying reading about you digging it up. -Alan On Fri, Feb 11, 2011 at 03:10:03PM -0500, Patrick Li wrote: >Great. Thanks for that tip! I think I will try and figure it out. >As long as I can figure out what the core binding-introducing forms are, I >think I can do it. >-Patrick >On Fri, Feb 11, 2011 at 2:56 PM, Peter Bex <[1]peter@xs4all.nl> wrote: > > On Fri, Feb 11, 2011 at 02:46:58PM -0500, Patrick Li wrote: > > > > The "when" should not be macroexpanded because it is a local binding > > introduced by the let form. In that context, it is actually *not* a > macro. > > > > Does anyone know which forms introduce new bindings? How can I check > this > > up? > > I'm afraid to really do this properly you'd need to implement your own > macro-expander. You need to do all sorts of bookkeeping to get your > syntactic environments straight. The macro-expander needs to know about > core forms like LET and extend the environment accordingly when those > are > used. See expand.scm in Chicken core (hairy!), or alexpander in the > Chicken 3 egg repo (cleaner, but still rather tricky) for an example of > such things. > > Cheers, > Peter > -- > [2]http://sjamaan.ath.cx > -- > "The process of preparing programs for a digital computer > is especially attractive, not only because it can be economically > and scientifically rewarding, but also because it can be an aesthetic > experience much like composing poetry or music." > -- Donald Knuth > > References > >Visible links >1. mailto:peter@xs4all.nl >2. http://sjamaan.ath.cx/ > ___ > Chicken-users mailing list > Chicken-users@nongnu.org > http://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Implementing a macroexpand-all
Great. Thanks for that tip! I think I will try and figure it out. As long as I can figure out what the core binding-introducing forms are, I think I can do it. -Patrick On Fri, Feb 11, 2011 at 2:56 PM, Peter Bex wrote: > On Fri, Feb 11, 2011 at 02:46:58PM -0500, Patrick Li wrote: > > > > The "when" should not be macroexpanded because it is a local binding > > introduced by the let form. In that context, it is actually *not* a > macro. > > > > Does anyone know which forms introduce new bindings? How can I check this > > up? > > I'm afraid to really do this properly you'd need to implement your own > macro-expander. You need to do all sorts of bookkeeping to get your > syntactic environments straight. The macro-expander needs to know about > core forms like LET and extend the environment accordingly when those are > used. See expand.scm in Chicken core (hairy!), or alexpander in the > Chicken 3 egg repo (cleaner, but still rather tricky) for an example of > such things. > > Cheers, > Peter > -- > http://sjamaan.ath.cx > -- > "The process of preparing programs for a digital computer > is especially attractive, not only because it can be economically > and scientifically rewarding, but also because it can be an aesthetic > experience much like composing poetry or music." >-- Donald Knuth > ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Implementing a macroexpand-all
On Fri, Feb 11, 2011 at 02:46:58PM -0500, Patrick Li wrote: > > The "when" should not be macroexpanded because it is a local binding > introduced by the let form. In that context, it is actually *not* a macro. > > Does anyone know which forms introduce new bindings? How can I check this > up? I'm afraid to really do this properly you'd need to implement your own macro-expander. You need to do all sorts of bookkeeping to get your syntactic environments straight. The macro-expander needs to know about core forms like LET and extend the environment accordingly when those are used. See expand.scm in Chicken core (hairy!), or alexpander in the Chicken 3 egg repo (cleaner, but still rather tricky) for an example of such things. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Implementing a macroexpand-all
I've checked out expand* from the expand-full egg. And it contains the same problem as my macroexpand-full. It doesn't take into account local names that could shadow macro definitions. eg. (define-syntax when (syntax-rules () ((when predicate body ...) (if predicate (begin body ...) '() (macroexpand-all '(let ((when 2)) (when (< i 3) (display i The "when" should not be macroexpanded because it is a local binding introduced by the let form. In that context, it is actually *not* a macro. Does anyone know which forms introduce new bindings? How can I check this up? Thank you very much. -Patrick On Fri, Feb 11, 2011 at 12:15 PM, Patrick Li wrote: > No I didn't. > Thank you. I will check that out! > > > On Fri, Feb 11, 2011 at 11:42 AM, Christian Kellermann < > ck...@pestilenz.org> wrote: > >> * Patrick Li [110211 17:20]: >> > Hello everyone, >> > >> > I'm trying to write a simple macroexpand-all function (a function to >> > recursively macroexpand all subforms in a form until there are >> absolutely no >> > macros left in the form), and realized that my naive implementation has >> a >> > serious bug in it, namely that it doesn't keep track of local bindings >> > within an expanded form. >> > >> > Naive implementation: >> > (define (macroexpand-all expression) >> > (let ((expanded (expand expression))) >> > (if (pair? expanded) >> > (map macroexpand-all expanded) >> > expanded))) >> > >> > I want the function to obey this property: >> > (eval some-expression) is *always* equivalent to (eval (macroexpand-all >> > some-expression)) >> > >> > Is there an easy or existing way to do this? I have tried to write my >> own, >> > but do not know which special forms actually introduce new bindings. >> >> Are you aware of expand* from the expand-full egg? >> >> Kind regards, >> >> Christian >> >> > ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Implementing a macroexpand-all
Hello everyone, I'm trying to write a simple macroexpand-all function (a function to recursively macroexpand all subforms in a form until there are absolutely no macros left in the form), and realized that my naive implementation has a serious bug in it, namely that it doesn't keep track of local bindings within an expanded form. Naive implementation: (define (macroexpand-all expression) (let ((expanded (expand expression))) (if (pair? expanded) (map macroexpand-all expanded) expanded))) I want the function to obey this property: (eval some-expression) is *always* equivalent to (eval (macroexpand-all some-expression)) Is there an easy or existing way to do this? I have tried to write my own, but do not know which special forms actually introduce new bindings. eg. I thought everything reduces down to (lambda ( ... )) eventually. But calling (expand '(let ((x 1)) (display x))) still yields (let ((x 1)) (display x)) Thanks very much for your help! -Patrick ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Implementing a macroexpand-all
* Patrick Li [110211 17:20]: > Hello everyone, > > I'm trying to write a simple macroexpand-all function (a function to > recursively macroexpand all subforms in a form until there are absolutely no > macros left in the form), and realized that my naive implementation has a > serious bug in it, namely that it doesn't keep track of local bindings > within an expanded form. > > Naive implementation: > (define (macroexpand-all expression) > (let ((expanded (expand expression))) > (if (pair? expanded) > (map macroexpand-all expanded) > expanded))) > > I want the function to obey this property: > (eval some-expression) is *always* equivalent to (eval (macroexpand-all > some-expression)) > > Is there an easy or existing way to do this? I have tried to write my own, > but do not know which special forms actually introduce new bindings. Are you aware of expand* from the expand-full egg? Kind regards, Christian ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Implementing a macroexpand-all
No I didn't. Thank you. I will check that out! On Fri, Feb 11, 2011 at 11:42 AM, Christian Kellermann wrote: > * Patrick Li [110211 17:20]: > > Hello everyone, > > > > I'm trying to write a simple macroexpand-all function (a function to > > recursively macroexpand all subforms in a form until there are absolutely > no > > macros left in the form), and realized that my naive implementation has a > > serious bug in it, namely that it doesn't keep track of local bindings > > within an expanded form. > > > > Naive implementation: > > (define (macroexpand-all expression) > > (let ((expanded (expand expression))) > > (if (pair? expanded) > > (map macroexpand-all expanded) > > expanded))) > > > > I want the function to obey this property: > > (eval some-expression) is *always* equivalent to (eval (macroexpand-all > > some-expression)) > > > > Is there an easy or existing way to do this? I have tried to write my > own, > > but do not know which special forms actually introduce new bindings. > > Are you aware of expand* from the expand-full egg? > > Kind regards, > > Christian > > ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] development snapshot 4.6.5 available
Hello! A development snapshot for CHICKEN 4.6.5 is now available at http://code.call-cc.org/dev-snapshots/2011/02/09/chicken-4.6.5.tar.gz What's new: - Build system - the PROGRAM_PREFIX and PROGRAM_SUFFIX configuration settings are applied to generated files and directories which allows to install differently named chicken builds into the same PREFIX - increased binary-compatibility version from 5 to 6, which means installed extensions in an existing installations will have to be re-installed - bugfixes in mingw/msys makefiles - Sven Hartrumpf contributed a bugfix to the internal helper script for creating distribution directories - Compiler - the `-accumulate-profile' option did not provide a way to specify the target profile data file - now `-profile-name' must always be given when accumulated profiling is done (thanks to Tayler Venable) - added `-module' option, which wraps the code into an implicit module - removed check for unsafe toplevel calls in safe mode - intrinsic handling of `exact->inexact' and `string->number' is now more efficient - fixed bug in leaf-routine optimization (thanks to David Dreisigmeyer) - unit-toplevel entry-points are now named differently, which may break binary-compatibility with existing compiled Scheme code modules - fixed invalid dropping of unused external entry-points in block-mode - fixed incorrect lambda-list check in scrutinizer (thanks to Alan Post) - Kon Lovett reported numerous bugs in the type-database used by the scrutinizer - Syntax expander - `syntax-rules' now supports tail-patterns and is now fully SRFI-46 compatible - many thanks to Peter Bex for implementing this - Peter Bex provided a bugfix for resolution of primitive imports - handling of internal definitions with shadowed defining forms is now done correctly - fix once again from Peter Bex - corrected non-standard behaviour of quasiquote with respect to nested quasiquotations - another bugfix by our mighty macro master - removed stub-implementation of `define-macro' - handled case where a global redefinition of `cons' influenced a non-inlined internal use in the expander (thanks to David Steiner) - Foreign function interface - removed deprecated `pointer', `nonnull-pointer', `byte-vector' and `nonnull-byte-vector' types - added missing result-type handling for `unsigned-integer64' (thanks to Moritz Heidkamp) - added `foreign-type-size' macro - Runtime system - `equal?' does not compare procedures recursively anymore - fixed incorrect use of alloca.h on OpenBSD (thanks to Christian Kellermann and Alan Post) - checks for NaN and infinity are now done using ISO C99 operations, which required various changes to `chicken.h' to make the code compile in ISO C99 mode - remaining debris regarding MSVC builds has been removed - fixed bug in argument-type check for 64-bit integer (thanks to Kon Lovett) - increased default trace-buffer size from 10 to 16 - fixed bug in low-level termination routine (thanks to Jeronimo Pellegrini) - the scheduler handles violations of internal invariants regarding threads slightly more gracefully (thanks to Jim Ursetto) - fixed broken sleep-time conversion (thanks to Karel Miklav) - repaired broken handling of multiple finalizers that referred to the same object (reported by Moritz Heidkamp) - fixed problem with reader and escaping of single-char symbols - Tools - chicken-bug - removed disabled e-mail support - csc - removed `-static-extension' option - removed deprecated `-windows' option - fixed incorrect use of `chicken.rc' on non-Windows platforms in `-gui' mode (thanks to "ddp") - csi - fixed broken `,g' toplevel command - deprecated `script' feature identifier (use `chicken-script' instead) - Libraries - unit `library' - added `condition->list', contributed by Christian Kellermann - added `equal=?' - removed deprecated `getenv', `left-section', `right-section', `project', `c-runtime' and `noop' - added missing import-library entry for `vector-copy!' (thanks to Jules Altfas) - circular or excessively deeply nested data generates a more useful error message when encountered by `equal?' - unit `files' - fixed bug in `normalize-pathname' - unit `lolevel' - removed deprecated `global-bound?', `global-make-unbound', `global-ref' and `global-set!' procedures - unit `posix' - added `file-creation-mode' (suggested by Mario Domenech Goulart) - unit `srfi-18' - removed deprecated `milliseconds->time' and `time->milliseconds' procedures - `make-mutex' incorrectly created mutexes as initially owned by the current threads (thanks to Joerg Wittenberger) - unit `utils' - `compile-file' now returns `#f' when the compilation fails, instead of raising
