Re: [Chicken-users] libffi and cmake on gnu/linux again
Hi! Try passing -DWITHOUT_LIBFFI=TRUE to ccmake (or cmake). I don't know why this fails. cheers, felix On 7/13/07, Sunnan [EMAIL PROTECTED] wrote: I haven't compiled chicken for a while, but now I'm trying to compile darcs head. The first step is to run ccmake . , right? Well, it says that it can't compile the libffi test. I don't know where to go from there or troubleshoot this further; I've got these files: /. /usr /usr/share /usr/share/doc /usr/include /usr/include/ffi.h /usr/include/ffitarget.h /usr/lib /usr/lib/libffi.a /usr/lib/libffi.la /usr/lib/libffi_pic.a /usr/lib64 /usr/lib64/libffi.a /usr/lib64/libffi.la /usr/lib64/libffi_pic.a /usr/share/doc/libffi4-dev /usr/lib/libffi.so /usr/lib64/libffi.so Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] octave egg version 0.3
Hi, version 0.3 of the octave egg is now available. New stuff include: - support for over 50 file formats to save your graphs, including postscript, png, gif, and jpeg. - argument length checks for 2D plot functions. - octave:legend function I added some screenshots on this page: http://carretechnologies.com/octave-egg/screenshots.html Comments are welcomed! -- Pierre-Alexandre ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] libffi and cmake on gnu/linux again
BTW, in ccmake you can simply press e and continue. It should still be able to generate a makefile. cheers, felix On 7/13/07, Sunnan [EMAIL PROTECTED] wrote: I haven't compiled chicken for a while, but now I'm trying to compile darcs head. The first step is to run ccmake . , right? Well, it says that it can't compile the libffi test. I don't know where to go from there or troubleshoot this further; I've got these files: /. /usr /usr/share /usr/share/doc /usr/include /usr/include/ffi.h /usr/include/ffitarget.h /usr/lib /usr/lib/libffi.a /usr/lib/libffi.la /usr/lib/libffi_pic.a /usr/lib64 /usr/lib64/libffi.a /usr/lib64/libffi.la /usr/lib64/libffi_pic.a /usr/share/doc/libffi4-dev /usr/lib/libffi.so /usr/lib64/libffi.so Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] libffi and cmake on gnu/linux again
I haven't compiled chicken for a while, but now I'm trying to compile darcs head. The first step is to run ccmake . , right? Well, it says that it can't compile the libffi test. I don't know where to go from there or troubleshoot this further; I've got these files: /. /usr /usr/share /usr/share/doc /usr/include /usr/include/ffi.h /usr/include/ffitarget.h /usr/lib /usr/lib/libffi.a /usr/lib/libffi.la /usr/lib/libffi_pic.a /usr/lib64 /usr/lib64/libffi.a /usr/lib64/libffi.la /usr/lib64/libffi_pic.a /usr/share/doc/libffi4-dev /usr/lib/libffi.so /usr/lib64/libffi.so Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] libffi and cmake on gnu/linux again
On 7/13/07, felix winkelmann [EMAIL PROTECTED] wrote: Hi! Try passing -DWITHOUT_LIBFFI=TRUE to ccmake (or cmake). I don't know why this fails. It fails on MinGW also, but I assumed that was because it wasn't supported on MinGW. Is it supposed to work? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] stack direction test
On 7/13/07, Kon Lovett [EMAIL PROTECTED] wrote: ( the stack direction test still fails to build for me - at least I can patch the CMakeLists file to get around this.) Can you please point me at a Trac entry for that, or else create one? I can't seem to access Trac right now. This functionality is trivial and should always be working, very strange if it is not. Please give platform, compiler, make VERBOSE=1 output, etc. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Suggestion for new egg: Wings!
On 6 Jul 2007, at 1:23 am, Alaric Snell-Pym wrote:
I propose to create an egg called 'wings' to contain general utility
functions for access .wings metadata files (there'll be other uses
for the files in future, so I plan to create a generic framework),
the definition of the wings-environment parameter and utility
procedures for accessing same, utility and support functions for the
data source API using the wings environment, then the aforementioned
page argument handling tools.
Here's a progress report:
- Wings environment works. You can bind stuff into the global
environment, access bindings with (wings:get 'foo), and dynamically
bind things with (wings:let (('foo 'bar)) (wings:get 'foo)).
- Metadata file parsing works. (wings:call-with-metadata /path/to/
file thunk) will look for a file called /path/to/file.wings (the
extension being configurable with a parameter). If it's not present,
it just calls the thunk.
But if it is present, it loads it and evals it within a quasiquote -
so it's literal data, except you can use , to include bits of live
Scheme code. It's treated as an alist of things to bind into the
Wings environment during the dynamic scope of calling the thunk. If
there's a entry in the alist called 'wrapper' then it's expected to
be a closure, and is applied to the thunk. If not, the thunk is just
invoked as-is.
The wrapper key is meant as a catch-all to control the dynamic
environment of the thunk, where parameters other than the wings
environment can be changed, exceptions handled, etc.
Now, the normal use of wings:call-with-metadata is to wrap Spiffy's
handling of files, so we provide a function called wings:handler-
wrap. If a Spiffy file extension handler is passed to this function,
it returns a new one that wraps invocation of the original handler in
a wings:call-with-metadata. So you can have .wings metadata handling
added to your web-scheme, ssp, cgi, or whatever.
- URL argument parsing is in progress. I've talked with Peter Bex
about how to get Spiffy to support path info so I can have positional
parameters in URLs, and while he's looking into that, I've pressed
ahead with named query-string params.
This is quite cool. I've written it so that it can handle nested
compound argument types.
Here's a sample argument declaration that demonstrates the atomic types:
'((a a optional string)
(b b symbol)
(c c symbol a b c)
(d d number)
(e e integer)
(f f string)
(g g boolean)
(h h boolean yeah nope)
)
The symbol at the head of each list is the name the argument will be
bound to; the next element, the string, is the name to expect in the
URL query string. The rest is typing information.
If optional is not specified, then failing to provide this argument
signals a condition that will, when I've written the higher-level
driver, cause a 400 Bad Request to be sent back. If optional is
specified, as with the a argument above, then omitting it causes #f
to be bound to the name.
Declaring something to be of type string just means that whatever
the URL contains is passed back, unchanged. Type symbol on its own
just passes it through string-symbol, but symbol a b c constrains
it to be a symbol from the list (a b c). This is useful for things
like the available options in a select form field. Anything outside
of the list signals a condition, again.
number causes a string-number, and if it returns #f, signals a
condition.
integer does the same as number, but also requires the result to
be an exact integer. This is useful for IDs of things in SQL
databases, mainly.
boolean alone interprets 1, t, yes, and y (case insensitive) as #t
and 0, f, no, and n as #f, and signals a condition on anything else.
Or you can write 'boolean yeah nope' to provide your own yes/no
strings. Or you can provide lists of yes/no strings: 'boolean (yeah
sure) (nope)'.
But where we start to leave Rails in the dust is with the compound
types.
The simplest compound type is set. Set just collects multiple
instances of the argument in the query string and makes a list. If
you declare an argument x to be of type set symbol a b c, for
example, then the parser will interpret a query string such as
x=ax=c as '(a c) - possibly in some other order. Set arguments are
implicitly optional; no instances of an argument makes for an empty
list.
The next one I got working was list, which looks for multiple
arguments of the form argname[index] and collects them into a
list, with the integer indices starting at 0. The list is long enough
to fit the highest index, and any missing positions in the list are
filled with #f.
So if you defined an argument x as list symbol then the parser
would see x[2]=foox[0]=bar as '(bar #f foo).
But if you define an argument x as list set symbol then the
parser will see x[2]=foox[0]=barx[2]=baz as '((bar) #f (foo baz)) -
it's a list of sets, apart from the #f.
And you can do things like list list list integer, which will
Re: [Chicken-users] stack direction test
I'm going to guess you have a bad build environment. Please give your PATH and the output of make --version. I'll see if I can reproduce on my own real XP SP2 box. Cheers, Brandon On 7/13/07, Kon Lovett [EMAIL PROTECTED] wrote: On Jul 13, 2007, at 11:35 AM, Brandon Van Every wrote: On 7/13/07, Kon Lovett [EMAIL PROTECTED] wrote: ( the stack direction test still fails to build for me - at least I can patch the CMakeLists file to get around this.) Can you please point me at a Trac entry for that, or else create one? I can't seem to access Trac right now. This functionality is trivial and should always be working, very strange if it is not. Please give platform, compiler, make VERBOSE=1 output, etc. VirtualPC with Windows XP Professional SP2, MSYS MinGW gcc 3.4.2 But, after deleting the build directory re-running CMakeSetup I get: C:\msys\build\chickenmake VERBOSE=1 /C/Program\ Files/CMake\ 2.4/bin/cmake.exe -H/C/msys/src/chicken -B/C/ msys/build/chicken --check-build-system CMakeFiles/Makefile.cmake 0 /C/Program\ Files/CMake\ 2.4/bin/cmake.exe -E cmake_progress_start /C/ msys/build/chicken/CMakeFiles 72 make -f CMakeFiles/Makefile2 all make[1]: Entering directory `/c/msys/build/chicken' make -f boot/CMakeFiles/chicken-boot-c.dir/build.make boot/CMakeFiles/ chicken-boot-c.dir/build make[2]: Entering directory `/c/msys/build/chicken' boot/CMakeFiles/chicken-boot-c.dir/build.make:42: *** target pattern contains no `%'. Stop. make[2]: Leaving directory `/c/msys/build/chicken' make[1]: *** [boot/CMakeFiles/chicken-boot-c.dir/all] Error 2 make[1]: Leaving directory `/c/msys/build/chicken' make: *** [all] Error 2 Oh well. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] stack direction test
On 7/13/07, Kon Lovett [EMAIL PROTECTED] wrote: On Jul 13, 2007, at 4:27 PM, Brandon Van Every wrote: I'm going to guess you have a bad build environment. Please give your PATH and the output of make --version. I'll see if I can reproduce on my own real XP SP2 box. Thank you for your time. The last Chicken I built was: Version 2.629 - windows-mingw32-x86 - [ dload ptables applyhook ] - cmake Then I had C:\msys\src\chicken C:\msys\src\chicken\build. Now it is C:\msys\src\chicken C:\msys\build\chicken. (Which should be cleaner, yes?) The latter is the way I've always done it. But people do it also with the \build directory underneath their \src tree. It shouldn't cause anything to blow up. PATH=C:\Program Files\CMake 2.4\bin;C:\msys\1.0\bin;C:\msys\1.0\mingw \bin;C:\msys\1.0\mingw\mingw32\bin;C:\msys\1.0\local\bin;C:\msy s\1.0\local\wbin;C:\Program Files\CMake 2.4\bin;C:\Program Files \PuTTY;C:\Program Files\darcsdir-w32;C:\Chicken\bin;C:\WINDOWS\syste m32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Microsoft SQL Server\80\Tools\BINN;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin\.;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin\WinNT\.;C:\Program Files\cvs nt;C:\Program Files\Subversion\bin GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i686-pc-msys I wonder if your MinGW and MSYS toolchains are fighting each other somehow. What happens when you use the MinGW only generator, and then use mingw32-make at a Windows command prompt? It would be best if there's no MSYS at all in your PATH for that. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] anonymous enums
On Jul 12, 2007, at 1:29 PM, Martin DeMello wrote: Could someone give me an example of wrapping and using an anonymous c enum? The manual isn't too clear on that point. 'define-foreign-enum' needs a defined type identifier, so anonymous enums won't work. I use 'foreign-value' or 'define-foreign-variable', depending on the context. Ex: (define-macro (foreign-mask-set? ?bits ?c-nam) `(not (zero? (bitwise-and ,?bits (foreign-value ,?c-nam unsigned- integer32 ) (foreign-mask-set? sab sessionIsRoot) Here 'sab' is some integer and 'sessionIsRoot' is the ident of some elm of an anon enum. A bit(s) not zero test. In this case the value of 'sessionIsRoot' is only used once. (MacOS X frameworks use a lot of anonymous enums.) Ex: (define-foreign-variable c-sessionIsRoot unsigned-integer32 sessionIsRoot) Here a compilation unit local Scheme variable 'c-sessionIsRoot' is created that shadows the C identifier 'sessionIsRoot'. (In this case do not (set! c-sessionIsRoot ..) since the C compiler will not like.) In this case I assume that the value of 'sessionIsRoot' is only used once so repeating (foreign-value sessionIsRoot unsigned- integer32) is a pain . NOTE: there is nothing special about the use of 'unsigned-integer32' as the type above. I am assuming all 32 bits are significant. HTH, Kon martin ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: SXML Project updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 26, 2007, at 8:55 PM, Zbigniew wrote: Hi Kon, If you make your code available in SVN, I would be happy to help out, if you don't mind me messing around =). I've wanted to update this egg for a while but lacked the impetus as the current version still works perfectly for my purposes. Sorry about being so slow on this; fatigue illness are my only excuse. I didn't want to take the detailed time to review what has been done so I have only been tackling small projects. I will (really) create an svn entry by close of business Jul 16. It will be called SSAX-Project; unless there are objections. And, yes, it will follow the proper subdir form. (Unlike my earlier stuff.) Sorry, Kon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iEYEARECAAYFAkaYU4cACgkQJJNoeGe+5O6qIgCfRM7aLJgl7/BXhaPLSzmJptCP 9aUAnRm6sPqGNQA4ZgHE+HZw3+k7DtbV =r797 -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
