Re: [Chicken-users] SRFI compliance
Vincent Manis wrote: I've put together a table of the various SRFIs and the state of Chicken support for each (builtin, egg available, etc). I'd appreciate any corrections you can make to it, either for things that are flat-out wrong or simply incomplete. I'm not sure where in the manual it should go (perhaps an appendix?). The page is at http://chicken.wiki.br/SRFI-conformance. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users That's great, thanks! ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Revised Chapter 1 (reminder)
John Cowan wrote: Ashley Bone scripsit: The mingw and mingw-msys builds are pretty much the same. Both give you a chicken built against the mingw headers and import libraries. The only difference is the environment where you actually run make. Makefile.mingw is can be used in cmd.exe with the version of make that comes with mingw. Makefile.mingw-msys requires the msys shell since it uses unix command (cp, rm, etc). The end product is the same. So in that case what use is the mingw-msys build? I had thought that the result of the mingw-msys build was code parts of which (chicken-setup, chicken-bug, or whatever) could only be used if msys was present at run time. If that's not the case, it seems pointless to maintain both builds, since anyone with or without msys can use the mingw build. The only advantage I can see is that if you use msys you don't have to fiddle with the windows command shell. I'm not sure Makefile.mingw will work in msys because some of the unix utilities like mkdir are actually built-in commands in cmd.exe so they are treated a little differently in the plain mingw build. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Revised Chapter 1 (reminder)
John Cowan wrote: Vincent Manis scripsit: 1. Someone added TODOs suggesting a discussion of MinGW and MinGW/ MSys builds; I would ask whoever did that to add a small amount of content, or perhaps a pointer to somewhere else, on those topics. I asked because I myself want to know the answer! When I used Windows (I don't run it any more), I always used Cygwin builds, so the difference between mingw and msys builds is a mystery to me. Can someone enlighten us either on the wiki or here on the list (in which case I will transport it to the wiki?) The mingw and mingw-msys builds are pretty much the same. Both give you a chicken built against the mingw headers and import libraries. The only difference is the environment where you actually run make. Makefile.mingw is can be used in cmd.exe with the version of make that comes with mingw. Makefile.mingw-msys requires the msys shell since it uses unix command (cp, rm, etc). The end product is the same. I'd suggest combining the paragrapsh on the MinGW/msys builds and just noting that makefiles exist for cmd.exe and msys. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MSVC makefile and patches
A couple of notes on the msvc build I forgot to mention previously: - When specifying PREFIX during the build, use /: make PLATFORM=msvc PREFIX=c:/development/chicken-msvc Backslashes will cause problems and aren't used internally anyway. - Currently, you have to compile with -DPIC or you'll get linker errors for 5 or 6 variables declared in chicken.h (C_fromspace_limit, C_fromspace_top, etc). Without -DPIC, the variables are not declared "dllimport", and microsoft's linker requires variables (though not functions) from a dll to be declared that way. Unfortunately, this will cause your unit toplevel functions to be declared as dllimports, and the linker will issue warnings about locally-defined functions being declared as imports. I'd like to modify the declarations in chicken.h to prevent this, but for now I'm just suppressing the warning in my own builds. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MSVC makefile and patches
felix winkelmann wrote: On Thu, Feb 21, 2008 at 11:44 PM, Ashley <[EMAIL PROTECTED]> wrote: > The build runs on msys with no problems. Tomorrow I plan to add a setup for cmd.exe, so a user only needs to have gnu make installed to build chicken for visual c. That seems like a pretty low barrier for windows users. Very good, Ashley. I'll integrate your stuff into the trunk ASAP. cheers, felix Sounds great. I have posted a new version of the patch (still against the chicken-3.0.0 distribution) at: http://tripolar-games.com/scheme/msvc-build.patch if you don't mind grabbing that one. In the future I'll work against the repository sources. The changes from the first version are: - Used - instead of / for compiler and linker options. I was doing this about half the time anyway, so I changed it for consistency and because my csc -cflags -ldflags -libs parser wants dashes :). - The build now works with MSVC 2008 and should work with 2005. Starting with 2005, the linker creates these ridiculous "manifest" files for any non-static target. The manifests for the executables must reside in the same directory as the executable, so I modified the install, uninstall, and clean targets to handle them. There is a post-linker tool that can embed them in the executable but I chose the simplest solution for now. I've tested the changed build w/ MSVC 2003 and 2008, mingw-msys, cygwin, and on linux. thanks, ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MSVC makefile and patches
John Cowan wrote: Ashley scripsit: Attached is a patch (which hopefully the list software allows) with a makefile and some related mods for building chicken with Visual C. This is a gnu makefile and is integrated with the regular build system, so you'll need cygwin or something similar to do the build. "Or something similar", as in msys? Or should this be called cygwin-cross-msvc just for truth in advertising? I think it's important to find out whether the installation can run on msys. The build runs on msys with no problems. Tomorrow I plan to add a setup for cmd.exe, so a user only needs to have gnu make installed to build chicken for visual c. That seems like a pretty low barrier for windows users. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MSVC makefile (was Errors building eggs in mingw/msys)
John Cowan wrote: Ashley scripsit: Actually, the problem turned out to be my misunderstanding of the intent of the mingw-msys makefile. I assumed it was similar to the cygwin build, but I realize now that doesn't make much sense as mingw uses the microsoft runtime. So things like chicken-setup, which ultimately call system(), need paths windows can understand. I was using it as if /home referenced the root of the file system, when in fact it sits at c:\msys\1.0\home. Do remember though that the Windows kernel is perfectly happy with / rather than \, which makes things much simpler. CMD insists on \; I don't know about MSVC makefiles. Yeah, the problem in the case above wasn't the use of / or \, it was simply the fact that "home" in the msys shell (and in my mind at the time) sat at /, while Windows saw it (correctly) as residing in c:/msys/1.0. The "slash" issue has caused an issue w/ the MSVC build I'm working on, though, because chicken-setup calls "del" to remove most files during an uninstall, and del chokes on / even when the path is quoted. On the other hand, (delete-file* ...) is called to remove the .setup-info file, which works because as you say the windows runtime handles / just fine. The makefile I'm working on is a gnu makefile, and is integrated with the normal build system for chicken. You'll need cygwin or some other posix-like environment to do the actual build, but you can run all the tools in plain cmd.exe once done. At least the tools I've tested so far. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MSVC makefile (was Errors building eggs in mingw/msys)
John Cowan wrote: All builds on Windows (cygwin, mingw, mingw/msys) have the same issue: Windows doesn't have a separate search path for DLLs, so all DLLs have to be on $PATH. However, the working directory is *always* on $PATH whether explicitly so or not. Actually, the problem turned out to be my misunderstanding of the intent of the mingw-msys makefile. I assumed it was similar to the cygwin build, but I realize now that doesn't make much sense as mingw uses the microsoft runtime. So things like chicken-setup, which ultimately call system(), need paths windows can understand. I was using it as if /home referenced the root of the file system, when in fact it sits at c:\msys\1.0\home. Anyway, the main reason I was playing with this was to get familiar with the build system so I could develop a makefile for the visual C compiler. I use chicken at work and I must have MSVC support. The old version I've been using for a couple of years supports it, but I'd like to upgrade to a newer version. I've got my new makefile (Makefile.msvc) working for all targets in chicken-3.0.0, and I've modified chicken-setup.scm and csc.scm to handle the MSVC compiler. Most of the eggs I've tried build successfully, though a couple seem to have some minor unix assumptions that cause problems. The easyffi egg won't build, at least with MSVC 2003, because it contains a literal string larger than 65535 characters. I assume that's a heap though I haven't looked at it. Maybe the newer MS compilers won't have that stupid limitation, or maybe I can pass some flag to chicken to deal with it. I'm going to do some more work on it today. Right now uninstall doesn't work and it doesn't clean up properly in the main build or when using chicken-setup. Assuming people are interested, I'll post a patch later today. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Errors building eggs in mingw/msys
I don't seem to be able to build any eggs in the mingw/msys environment. I built chicken using the mingw-msys makefile. When I run chicken-setup, eg: $ chicken-setup -v easyffi I get this: executing silex.setup ... "/home/ashley/local/bin/csc" -feature compiling-extension -v -s -O2 -d1 silex.scm The system cannot find the path specified. Error: shell invocation failed with non-zero return status "\"/home/ashley/local/bin/csc\" -feature compiling-extension -v -s -O2 -d1 sile... If I go into silex.egg-dir and run csc manually on silex.scm, I get a similar problem: $ csc -feature compiling-extension -v -s -O2 -d1 silex.scm /home/ashley/local/bin/chicken silex.scm -output-file silex.c -dynamic -feature chicken-compile-shared -quiet -feature compiling-extension -optimize-level 2 -debug-level 1 The system cannot find the path specified. *** Shell command terminated with exit status 1: /home/ashley/local/bin/chicken silex.scm -output-file silex.c -dynamic -feature chicken-compile-shared -quiet -feature compiling-extension -optimize-level 2 -debug-level 1 However, if I run chicken directly, it outputs a C file with no problem: $ /home/ashley/local/bin/chicken silex.scm -output-file silex.c -dynamic -feature chicken-compile-shared -quiet -feature compiling-extension -optimize-level 2 -debug-level 1 That works fine and produces silex.c when run manually. I had what seemed to be this EXACT same problem when I built chicken for cygwin, which I solved by copying the cygchicken dll's to the path containing chicken (or adding the lib directory to the path, not sure at this point). I'm at a loss in this case, though I'm convinced it's something trivial. Thanks for any help, ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] How easy is it to use Chicken in Windows XP
Sean D wrote: After struggling horribly, trying (and failing) to get ECL running in Windows I am really looking for a better experience. I tend to use "pure" Windows XP and free C/C++ tools so either GNU gcc is fine or MS Visual C++ 2005. Note that I don't have access to MSVC the commercial version. Is it possible to install and build a good working version of Chicken on Windows XP: 1. At all. 2. Yes if you are a MAKE, Linux, Windows and C++ expert and have the patience of Job 3. Yes, but only under Cygwin etc. (of which I know very little except they can be a pain to use/maintain as well) 4. Yes but only with the commercial MSVC or very specific versions of certain software. 5. Yes but with some combination I haven't mentioned or thought of. 6. YES Easily!! 7. YES - I can download latest virus-free executable version for Windows from (please supply URL) Please let me know in detail how I go about this as I am not an expert in any of the above 1-5. (prays for 6 or 7 ...) I've never had any problem building Chicken with MSVC, using nmake and the included windows makefile. I believe I also built it once with gcc and cygwin, but only as a test. I use cygwin for its tools, not as a development target. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] alternate build tools
Brandon J. Van Every wrote: Does SCons have the ability to abstract away the compiler details? A friend of mine said it didn't, that you had to specify all the flags manually yourself. The most common settings are handled by scons (for instance, things like -fPIC for gcc or /MD for msvc). Special flags like optimizations and so forth have to be explicitly added, but I think that's true of any tool. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] alternate build tools
Brandon J. Van Every wrote: How do you feel about either a Python or a Java dependency? I've been looking into the problem of targeting multiple C/C++ compilers on multiple platforms. 2 tools look like they may be "industrial strength" solutions to the problem: scons, a Python script based build system http://www.scons.org/ Ant with the ant-contrib cc Task http://ant.apache.org/ http://ant-contrib.sourceforge.net/ http://ant-contrib.sourceforge.net/cc.html (list of supported compilers) Thought I'd add my experiences to this idea. I've been using scons for 2 or 3 years now to build software on IRIX, linux, and windows. It's a very nice tool once you get familiar with its idiosyncracies. The build scripts are nearly 100% portable - typically you just need a few lines listing any platform specific libraries to link with and any non-standard compiler flags, such as optimizations. scons also has some sort of built-in autoconf-like facility (called sconsf, I believe). I've never used it and am not sure what its features are, though. I believe there is also some kind of stand-alone version that you can package with distributable files if you don't want to force users to download and install scons separately. Currently I use scons to build all my scheme libraries and programs using chicken on both linux and win32 (with msvc). I have a simple chicken scanner, and builders for chicken libraries, programs, and embedded programs, along with some utility functions such as a function to parse the output from chicken-config. I don't have any experience with ant, but if there's interest in going the scons route, I'd be happy to lend a hand. ashley ** ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] softscheme, srfi-76
Felix, you rock. Very cool stuff. Now I just have to find time to play with these new toys. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] srfi-13 patch
The implementation of string-concatenate-reverse/shared from SRFI-13 has a small bug which the attached patch fixes. To see the bug, just try: (use srfi-13) (string-concatenate-reverse/shared (list "longerstring" "short")) You'll see some unexpected padding in the result. later, ashley --- srfi-13-orig.scm2005-09-08 15:21:40.325260800 -0500 +++ srfi-13.scm 2005-09-08 15:22:18.329908800 -0500 @@ -1689,7 +1689,7 @@ ;; string starts. (let lp ((len 0) (nzlist #f) (lis string-list)) (if (pair? lis) - (let ((slen (string-length (car string-list + (let ((slen (string-length (car lis (lp (+ len slen) (if (or nzlist (zero? slen)) nzlist lis) (cdr lis))) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A few questions...
felix winkelmann wrote: Hello, all! Q1: should `signum' be exactness-preserving? (i.e. should inexactness be contagious) Probably so. Not a big deal to me either way. Q3: What are you missing most desperately from Chicken, or better: if there is one thing that you really want it to have, what would that be? Chicken seems to do almost everything I need right now, so only a couple of minor things come to mind. Is there a built-in way now to get the filename and line-number at compile time? I see get-line-number in the manual, but I don't think that can give me the current line number. I'd like to have that info so my test- infrastructure can format emacs-style error messages. It would also be great if eggs could be built statically w/o any modification. I have a client now who's kind of insane on the subject of shared libraries, so build everything statically is a necessity. It's not a big deal, though - the eggs I'm using have been fairly easy to massage into static libraries. ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Ported opengl egg to windows
Hi, For those who are interested, I have ported the OpenGL egg to windows/MSVC. The port uses the glprocs package from Intel/SGI to access OpenGL 1.2+ functions that aren't supported by the the stock windows library. If your underlying graphics driver does not provide a particular function, it will assert if you call it. I think most vendors support GL 1.2 and 1.3 - my 3-year old ATI mobility had all the functions in gl.scm. MS only provides GLU 1.2, so the this port doesn't provide GLU 1.3 functions. The egg built with no problems on our two windows machines. I was able to run our test program and gears.scm with no trouble. I also built the modified egg on my gentoo linux box with no problems. Unfortunately, I don't have a mac to try it on. You can get the modified egg at: http://www.tripolar-games.com/scheme/opengl/ There is also a readme file in that directory explaining all the changes I made in excessive detail. Briefly, I: - Added glprocs.c and the glprocs header files (the license allows this without restriction). - opengl.setup: Added a windows/msvc build clause. - gl.scm: Added a cond-expand expression to pull in the gl.h and glprocs.h. gl.h is necessary so that the correct calling convention is used. - glu.scm: Added a cond-expand expression to pull in windows.h/glu.h. Moved the eight functions from GLU 1.3 into a cond-expand expression since windows only provides GLU 1.2. Wrote separate code to handle the tesselator, quadric and nurbs callbacks with MSVC. I had problems with pointers to __stdcall functions. I couldn't figure out how to declare them as parameters in the Easy FFI without choking the parser. Using foreign-safe-lambda w/ (function void () "__stdcall") gets me to C code, but the MS compiler doesn't like the way the function pointers are declared. See the readme for more details. The only change I made that could affect builds on other platforms was the inclusion of GL/gl.h in gl.scm and GL/glu.h in glu.scm. Since I had to include those files on windows, I changed the opening of the Easy FFI section to #>? from #>!, and I couldn't figure out a way only do that on a particular platform. The alternative is to create a separate file for windows, I suppose. thanks, ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] process-run return value on windows
Hi, It appears that process-run does not return a PID on windows. The attached patch modifies process-spawn in posixwin.scm so that it returns the handle from spawnpv. It is possible that I'm just going crazy, though, because I could have sworn that I used process-run on windows a few days ago without any trouble. ashley --- posixwin.scm.orig 2005-07-12 05:48:49.0 -0500 +++ posixwin.scm2005-08-07 16:01:49.883948880 -0500 @@ -1286,7 +1286,8 @@ (##sys#update-errno) (when (fx= r -1) (freeargs) -(##sys#error 'process-spawn "can not execute process" filename) ) ) ) +(##sys#error 'process-spawn "can not execute process" filename) ) + r)) (let ([s (car al)]) (##sys#check-string s 'process-spawn) (setarg i s (##sys#size s)) ) ) ) ) ) ) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] the (##sys#call-host) FFI trick
I've now managed to port about half our bigloo libraries to chicken using define-external combined with ##sys#call-host to provide the C entry points and to transfer control to the host C++ program. So far I've only encountered one very minor problem. I'm able to build static or shared libraries on all platforms with no problem, but on freaking windows we rely on import libraries when linking with C/C++ code. define-external doesn't declare the generated function as dllexport, so it's not exported from the DLL. I tried using qualifiers with define-external, eg: (define-external "__declspec(dllexport)" (string_length (c-string str)) int which generates: C_extern int __declspec(dllexport) string_length(char * t0); Depending on the function's return type, the MS compiler is picky about where the __declspec is placed: the above seems to work ok, but change the return type to char* and the compiler pukes. It really wants the __declspec before the return type. So, I did the easiest thing possible and modified c-backend.scm: (define (generate-foreign-callback-stub-prototypes stubs) (for-each (lambda (stub) (gen #t) (generate-foreign-callback-header "C_externexport " stub) (gen #\;) ) stubs) ) I just changed C_extern to C_externexport in the above function and rebuilt chicken. Now when _MSC_VER and PIC are defined, the function is exported. Anyway, except for this one minor side issue, this "FFI trick" is working perfectly. later, ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
