[Chicken-users] srfi-18 threads question
Hi All, New to this list and srfi-18 threads. I want to make use of parameters in a thread-safe way, but I have run into problems. It seems to me that parameters created in one thread cannot be manipulated in a persistent way from another thread. Here is some example code showing what I mean: (use srfi-18) ;; mutex-protect parameter (define (make-synchronized-parameter value) (let ((mutex (make-mutex)) (param (make-parameter value))) (lambda args (mutex-lock! mutex) (let ((result (apply param args))) (mutex-unlock! mutex) result (define *safe-param* (make-synchronized-parameter #f)) (define *unsafe-global* #f) (define (mutate-things) (set! *unsafe-global* 42) (*safe-param* 42) (print "2thread> unsafe-global is "*unsafe-global*" safe-param is "(*safe-param*)) (thread-sleep! 2) ;; make global safe for test (print "4thread> just before exit unsafe-global is "*unsafe-global*" safe-param is "(*safe-param*))) (define (main) (let* ((thread (make-thread mutate-things))) (print "1main> before thread-start unsafe-global is "*unsafe-global*" safe-param is "(*safe-param*)) (thread-start! thread) (thread-sleep! 1) ;; make global safe for test (print "3main> before thread-join unsafe-global is "*unsafe-global*" safe-param is "(*safe-param*)) (thread-join! thread) (print "5main> after thread-join unsafe-global is "*unsafe-global*" safe-param is "(*safe-param* (main) ;; actual stdout: ;; 1main> before thread-start unsafe-global is #f safe-param is #f ;; 2thread> unsafe-global is 42 safe-param is 42 ;; 3main> before thread-join unsafe-global is 42 safe-param is #f ;; 4thread> just before exit unsafe-global is 42 safe-param is 42 ;; 5main> after thread-join unsafe-global is 42 safe-param is #f ;; expected stdout for line 5: ;; 5main> after thread-join unsafe-global is 42 safe-param is 42 ;; Why does the mutation of a simple global in a thread become visible to the main thread, but the mutation of global parameter does not? ;; What is the right way to achieve an thread-safe parameter? Thank you! -Brandon___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Pass argument to function
I'm trying to learn Chicken and having issues. I'm trying to create a function that takes a docker container name and runs "docker inspect [container]." This works: (define test (capture "docker inspect hello-world")) This works: (define (str-concat str) (string-append "docker inspect " str)) This doesn't: (define (inspect str) (capture (string-append "docker inspect " str))) I get an error that string-append is not found. How do a call capture with the result of string-append? Thanks. Brandon
Re: Pass argument to function
Unquoting worked! I spent so much time trying different variations and this worked: (capture ,(string-append "docker inspect " str))) Thanks. Brandon
Re: [Chicken-users] Fwd: Queinnec's Lisp in Small Pieces for CAN$3.95+shipping
> -- Forwarded message -- > From: Bradley Lucier <[EMAIL PROTECTED]> > > http://www.amazon.ca/Lisp-Small-Pieces-Christian-Queinnec/dp/ > 0521545668/ref=pd_ts_b_1/702-2137623-1855264?ie=UTF8&s=books > > LiSP is now their #1 bestseller, bigger even than Harry Potter! That's a joke, right? How would I compare sales numbers of Amazon books? I'm reading the 7th Harry Potter book now. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Queinnec's Lisp in Small Pieces for CAN$3.95+shipping
On 8/9/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: > Hallo, > > On 8/9/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > > > > > LiSP is now their #1 bestseller, bigger even than Harry Potter! > > > > That's a joke, right? How would I compare sales numbers of Amazon > > books? I'm reading the 7th Harry Potter book now. > > > > http://www.amazon.ca/gp/bestsellers/books/ I'll be flobbered. Well I suppose the hardbound Harry Potter book is expensive. Still #3 given the expense though. There's an "adult version" at #6 also. I guess it's just different jacket covers for different markets. I wonder if the sales of both Harry Potter books were combined, if LiSP would still be #1? Pretty impressive to be up that high though, unless there's something about Amazon marketing I simply don't understand. BTW that site is showing LiSP for $CA 76.86, not exactly a deal. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Queinnec's Lisp in Small Pieces for CAN$3.95+shipping
On 8/10/07, Alejandro Forero Cuervo <[EMAIL PROTECTED]> wrote: > > I'm reading the 7th Harry Potter book now. > > My favorite part was when Voldemort tells Harry, after some magic > struggle, to nevermind James, that he, Lord Voldemort, is Harry's > father! > > And then it turns out Hermione is his sister! > > Who would have thought! I'd SemperSectum you if I believed you, for giving the plot away. Fortunately I know you're the victim of the Lucas Cinaema curse! Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Queinnec's Lisp in Small Pieces for CAN$3.95+shipping
On 8/10/07, Arto Bendiken <[EMAIL PROTECTED]> wrote: > On 8/10/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > > > BTW that site is showing LiSP for $CA 76.86, > > not exactly a deal. > > It's up to CDN$ 94.40, now, with that being a price increase of 90.45 > since yesterday when it was still selling for 3.95 I don't understand the mathematical behavior of this. Unless the point of a radical price drop is to temporarily catapult a book to the #1 spot. Then do you get to claim "#1 Bestseller!" on your cover or something? "#1 Bestseller for 24 hours!" > - guess you missed the deal... Wasn't planning to buy it. I don't need no steenkin' books to learn Lisp. I just wanted to know what could possibly be more popular than Harry Potter. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Scheme is dead, long live Scheme
On 8/17/07, Ivan Raikov <[EMAIL PROTECTED]> wrote: > > > > > The language is massively fragmented already, so this is nothing new. > > > >Well, a few of the people who voted yes on the R6RS proposal seemed > to believe that the new standard will bring about better compatibility > between existing implementations. My point was that you cannot alter > the existing state of Scheme by the sheer force of willpower. And what would? Money? >I most certainly do not consider ISO C or C++ to be good language > standards. In my opinion, a programming language standard should > encourage and support the proliferation of high-quality > implementations. Gee money and commercial interest are the dominant factors here. I guess Scheme sucks. > Compare with C++: despite the thousands of pages of > specification, I am not convinced that you can find two different C++ > compilers that implement all features of the language in the same > way. Coming from a Schemer? Pot. Kettle. Black. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake build
On 4/23/07, John Cowan <[EMAIL PROTECTED]> wrote: felix winkelmann scripsit: > I'm using CMake 2.5 (CVS head). Perhaps that is the culprit. Aha. I just found out something; when I thought I was installing on that system, I really wasn't, because I'm not root. So "make install" ran through all the install steps, doing nothing, and then crashed (unnoticed by me) on the first attempt to move things to the /usr/local hierarchy. When the sysadmin ran it as root, everything got rebuilt. Does this suggest anything to anyone? It suggests that CMake has bugs on Linux, and that people would have to resolve them by posting on the CMake mailing list. There could be 2 separate bugs here. At least now we have confirmation that the "make install" bug isn't just on Felix's box. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: [Chicken-hackers] VS support
On 4/27/07, Kon Lovett <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 27, 2007, at 6:22 AM, felix winkelmann wrote: > Hello! > > I finally managed to find the time to get chicken running under > mingw on Windows. This is a setup I can sort of support, so I wonder, > whether MSVC/Visual Studio support shouldn't be dropped altogether, > as we don't have a Windows maintainer (who can dig deeper into > MSVC-related problems, and who is willing to invest the time and > effort). This would mean that MSVC is not officially supported (even > if we try to keep the build files still compatible to it). > > Any opinions? Do not support. (Frankly, given the lack of a Windows maintainer I am pleased that it works as well as it does.) So far I've traveled 3000 miles from Seattle in the northwest USA to Cincinnati in the midwest. My destination is Winston-Salem, North Carolina. NC is part of "the South" and about halfway up the eastern seaboard. It'll probably be close to 4000 miles of driving by the time I'm done. I have family in W-S and will be using it as a stepping stone for a job search, possibly a national job search. I am on the move. I have no idea where I'm going to end up, or what I'll be doing for a livelihood. I'm writing this on a Pentium II laptop that I've inherited from my sister. Rah rah GMail. A Pentium II + web setup is slow enough that I've had some time to think over the build issues unemotionally, after reading about the Windows build problems that have recently come in. First the easy part. Felix, if you feel you can sorta support MinGW, then by all means do so. If between you and John Cowan you keep the MinGW and Cygwin builds working, then CMake will always have a decent foothold in the Windows world. The Visual Studio builds may or may not work, but they will never be terribly broken. Now, the political part. Since we're getting bug reports for Visual Studio, it's clear that people want to use it. "We don't support MSVC" is the wrong message. The correct message is "we can support MSVC if you're willing to do some testing and bug reporting." In a CMake build, the incremental cost of supporting MSVC is quite low. Also at last count, Visual Studio .NET 2003 (my system) worked just fine. Visual Studio 2005 Express SP1 is what's broken, because it's Microsoft's free cheapass stripped down not-a-real-compiler. Maybe it can be solved, or maybe the answer is "use a real compiler." I do know it's real work to figure out, and I still don't wanna do it. Seems nobody else wants to do it badly enough either. This is open source, so whatever. Once upon a time, I wanted MinGW to work badly enough that I Made It So [TM]. It cost me a man-year. Because I laid out that groundwork once upon a time, it would probably cost a completely ignorant person 1 week to diagnose the VS 2005 Express SP1 problem, and fix it if it can be fixed. Somebody has to actually want to spend that week though. Myself, I could probably solve the issue in 1..2 days, if I had those days. Right now I certainly don't, and it may be quite awhile before I'm willing to make the time. I just don't believe in this idea of a "Windows Maintainer." Framing it that way, just sounds like "we want 1 guy who's sucker enough to do all the gruntwork for us." I don't think open source should be organized that way, although it frequently is that way. I could be the Autoconf maintainer, frankly, if I wanted to be. I rolled up my sleeves and got my hands dirty once upon a time. I learned what was going on and refactored a lot of it. I had to do it to unify the build systems. I had a goal, something was in my way, so I solved it. Do I like Autoconf? No, not in the slightest. I think it's a complete waste of time. But so are lotsa things in computers. People just have to make decisions about what they want and what they're willing to do to get them. We shouldn't have a "Windows Maintainer" just to relieve everyone of would-be responsibilities. The whole point of a unified build system is you get the benefit of other people solving other bugs on other platforms. It's a distributed approach to open source. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] scheme, builds, and virtual appliances
On 4/21/07, bryan rasmussen <[EMAIL PROTECTED]> wrote: hi, I was reading the complaints of various luminaries over in the scheme hackers list as to why would one want to choose Chicken? I guess I would want to choose Chicken because I don't want to get dirty with C, but I want the portability of C. C is portably not just across platforms it is portable across languages and applications as platforms. Many languages allow interaction with C in some way, probably because the languages need to drop down to the C level to do some things. if you want to write a driver or extension module for python you may have to use Swig or distutils to get it to work with Python, that is to say there are a number of specialized applications you need to have working together. The same thing if you were to bind erlang to C libraries http://www.erlang-projects.org/Public/news/erlang_driver_toolki/view Now a virtual appliance is a prepackaged virtual machine that has everything setup that one needs to get started running a particular suite of applications, tools on an OS or similar things: http://www.vmware.com/vmtn/appliances/ what about Virtual appliances that are setup up with not just Scheme, Swig etc. but requisite tools and eggs to use Chicken for writing, say as one example Erlang drivers? To do this for a good number of scenarios, OS's etc. to demonstrate Chicken's portability as a tool for writing C easily and efficiently? I'm not understanding what you're getting at. The VMWare page seems to be about shipping your choice of OS to enterprise customers. If you're not doing enterprise development, I don't see how the concept applies, or has any kind of economy of scale. I've wondered if it would make sense to ship a game with its own OS to consumers, so that I wouldn't have to be enslaved to Windows issues or whatever. But the reality is, I can't see consumers cranking up a DVD just to play a game on their PC. That's very MS-DOS era usability, running 1 program on your PC at a time, and consumers aren't going back. It would make more sense to do it on a console, where people are used to just plugging in a CD or DVD and having it work. I worry though that the boot times might be completely unacceptable. Modern console users just plug their game in and start playing, it's an instant entertainment sort of thing. So the first question is, under what conditions does shipping an OS to a customer make any kind of sense? I don't think you've really answered this in your musings above. Perhaps you could elaborate. The second question is, who's going to do all the support work for such a thing? People doing enterprise development are investing big bucks in their undertakings. Does such an effort make sense for you personally? It definitely doesn't make sense for the Chicken community. We are merely a small community of volunteers, working on whatever projects are of most benefit to us personally. The community resources for pursuing very abstract "work everywhere" infrastructure simply don't exist. I can't even get people to do modest amounts of bughunting for the Visual Studio 2005 Express compiler. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake build
On 5/1/07, John Cowan <[EMAIL PROTECTED]> wrote: Brandon Van Every scripsit: > It suggests that CMake has bugs on Linux, and that people would have to > resolve them by posting on the CMake mailing list. There could be 2 > separate bugs here. At least now we have confirmation that the "make > install" bug isn't just on Felix's box. Okay, I've done a whole bunch of Linux installs under various conditions, and I've found that the problem arises if and only if the installation is going to replace the EXTANT_CHICKEN it was configured to use. If you keep a private copy of chicken-static around and always use that, you never have a problem with rebuilding on install. What's more, when building from a tarball, where EXTANT_CHICKEN is irrelevant, there is no problem. Does *that* suggest anything to anyone? Ew. Not a case use I remember thinking about, so wouldn't shock me if there's something wrong. I'll look into it. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake build
On 5/1/07, John Cowan <[EMAIL PROTECTED]> wrote: Brandon Van Every scripsit: > Ew. Not a case use I remember thinking about, so wouldn't shock me if > there's something wrong. I'll look into it. It's actually a pretty common circumstance when you are updating your Chicken regularly from the darcs head. In my case, Chicken is in /usr/local, so the EXTANT_CHICKEN winds up being /usr/local/bin/chicken-static. Then I darcs pull, ccmake, make, and make install, so the new version of chicken-static winds up overwriting the old. That's where the Linux version can't cope. A straightforward fix would be to always copy EXTANT_CHICKEN to /tmp (or C:\windows\temp) and run it from there. Why do I have a sinking feeling about that? Is it just that I don't want to write the code for the dynamic case, or some greater can of worms? I have found that on Cygwin, if I build with /usr/local/bin/chicken- static.exe, with the intent of installing Chicken in /usr/local, chicken-static.exe is never built and never installed. The static libs are built but not installed, which I find even more peculiar. I get the same behavior on MinGW with respect to C:\Program Files\Chicken\bin\chicken- static.exe. Perhaps CMake 2.4.6 has ad-hoc handling of circular installation dependencies. Linux is implementing a different policy than Cygwin and MinGW. I'll try out CMake CVS soon enough, but I can't make more progress on this until my internet connectivity is restored. I'm using someone else's computer to send this. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake build
On 5/4/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: On 5/1/07, John Cowan <[EMAIL PROTECTED]> wrote: > > Brandon Van Every scripsit: > > > Ew. Not a case use I remember thinking about, so wouldn't shock me if > > > there's something wrong. I'll look into it. > > It's actually a pretty common circumstance when you are updating > your Chicken regularly from the darcs head. In my case, > Chicken is in /usr/local, so the EXTANT_CHICKEN winds up being > /usr/local/bin/chicken-static. Then I darcs pull, ccmake, make, and > make install, so the new version of chicken-static winds up overwriting > the old. That's where the Linux version can't cope. > > A straightforward fix would be to always copy EXTANT_CHICKEN to /tmp (or > > C:\windows\temp) and run it from there. Why do I have a sinking feeling about that? Is it just that I don't want to write the code for the dynamic case, or some greater can of worms? I couldn't reproduce the behavior on MinGW when installing over EXTANT_CHICKEN. I think I probably did everything correctly in the 1st place, i.e. EXTANT_CHICKEN is not a dependency, and this is a Linux specific bug. I will try Cygwin later on to see if it's fine. I have found that on Cygwin, if I build with /usr/local/bin/chicken- static.exe, with the intent of installing Chicken in /usr/local, chicken-static.exe is never built and never installed. The static libs are built but not installed, which I find even more peculiar. I get the same behavior on MinGW with respect to C:\Program Files\Chicken\bin\chicken- static.exe. Perhaps CMake 2.4.6 has ad-hoc handling of circular installation dependencies. Linux is implementing a different policy than Cygwin and MinGW. I'll try out CMake CVS soon enough, but I can't make more progress on this until my internet connectivity is restored. I'm using someone else's computer to send this. Lack of static was an unrelated bug. There's a stray (SET MACOSX TRUE) statement in the 2.6 tarball, which turns off static exes and libs on all platforms, not just MACOSX. I've fixed it in Darcs head. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Mac OS X static library names
Apple has deliberately depreciated static linking of user executables on Mac OS X. Any time you try to link statically with Apple's ld, if a dynamic library of the same name is available, it grabs that instead. Not sure if the Autoconf build is affected by this, but the CMake build is. We worked around it by disabling the building and installation of static executables. The static libraries are built and installed, but a user has to pass some weird flags manually to ld to make use of them. Otherwise, since both the static and dynamic libraries have the same name and are in the same directory, the dynamic library will be picked up, rendering the results quite useless and broken. We could rename the static libraries on Mac OS X to things like libchicken-s.a. This would make it easy for users to avoid the ld behavior, as static and dynamic libs would have different names. Do Mac OS X users think this is worth doing? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/13/07, Thomas Christian Chust <[EMAIL PROTECTED]> wrote: I would only change the behaviour of the build if it doesn't mean a lot of work. If the library names were changed, though, I would try to keep them identical across all platforms to reduce confusion of the users ;-) Windows libraries are already gratuitously different, because in Windows-land, .lib is used as the suffix for both a dynamic stub library and a static library. So, a -s postifx is used to distinguish the static libraries. Other parts of the postfix are used to distinguish debug vs. release, i.e. libchicken-ds.lib. More postfixes will be added if we ever decide to compile single vs. multithreaded libraries and etc. Currently, Unix-y builds don't do any more than compile a static and a dynamic library. There's no debug version, there's no multithreaded version, etc. Since Unix-y / GCC suffixes are sane with respect to static vs. dynamic libraries, there's currently no reason to add postfixes to distinguish more cases. Current GCC / Cygwin / MinGW implement suffixes correctly with respect to static vs. dynamic libraries. This is the most convenient for the user. I see no reason to mess that up in the name of gratuitous uniformity. Mac OS X is just weird, so it's a case of whether it's worth doing something specific for their benefit, to make their lives easier when linking. Hey I just had a brilliant idea. We don't have to rename anything. We could just symlink libchicken-s.a to libchicken.a. Then the user can have his cake and eat it too. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/13/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: Hey I just had a brilliant idea. We don't have to rename anything. We could just symlink libchicken-s.a to libchicken.a. Then the user can have his cake and eat it too. On the other hand, we could eliminate all support for static linking, bowing to the One True Apple Way Of Doing Things [TM]. How do people feel about that? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/14/07, Thomas Christian Chust <[EMAIL PROTECTED]> wrote: Brandon Van Every wrote: > [...] > On the other hand, we could eliminate all support for static linking, > bowing to the One True Apple Way Of Doing Things [TM]. How do people > feel about that? I wouldn't mind if static linking was not supported. But in that case we can just as well leave the situation as is: Deliberately refusing to support static linking is a different policy statement. It's a difference between saying, "You can link stuff statically if you like" vs. "too bad, you're on your own, this isn't supposed to ever be done" The motive for such a policy, is a belief that things will break in weird and hard to track down ways if people do static linking against Apple's wishes. But, is there any actual evidence of that? Any static linking horror stories out there? The main advantage of a dynamic only policy is shorter build times. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote: On Mon, May 14, 2007 at 11:55:31AM -0400, Brandon Van Every wrote: > Any static linking horror stories out there? Sure, I have some that aren't necessarily apple related, but could happen on that platform. Ok Mac OS X users, what say you? Should we tie your hands for your own good, or give you the freedom to cut off your own fingers? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/14/07, Shawn W. <[EMAIL PROTECTED]> wrote: On May 14, 2007, at 10:24 AM, Brandon Van Every wrote: > > Ok Mac OS X users, what say you? Should we tie your hands for your > own good, or give you the freedom to cut off your own fingers? > I don't care about static linking. I've yet to hear any Mac user care about static linking. Better speak up if you do! I'm starting to favor killing all static builds on both Autoconf and CMake, even though Autoconf currently gets it right. This would (1) cut build times on Mac OS X in half. That's the primary benefit from my standpoint. (2) Prevent any possibility of weird bugs due to Mac issues. (3) It sets a uniform expectation for Chicken users on Mac OS X. As opposed to shipping libchicken.a and libchicken-s.a, which would invite variance in how people use Chicken under Mac OS X. For simplicity, I would also change libchicken-boot and chicken-boot to be dynamically linked on all platforms, not just Mac OS X. Originally I made the bootstrap static for fear of "complications" with a given system's dynamic linking. But, I've never observed dynamic linking complications in all the time that CMake has been tested. Peter Keller's post also seems to indicate that static linking is the case more likely to cause problems. What would be nice is an OS X framework for the chicken runtime. It'd be a lot easier to distribute to people who want to run a program written in chicken without having to install the full thing (Compiler, interpreter, runtime libraries, etc.). CMake doesn't have framework support. See http://www.cmake.org/Wiki/CMake:MacOSX_Frameworks The issue is known but isn't getting attention. Bill Hoffman is interested in moving forwards on the issue, but could use prodding and assistance from the Mac community. Does Autoconf have framework support? Universal binary support to go along with that would be nice too. The latter is easy to do. (Add '-arch i386 -arch ppc' to the cflags used by the chicken compiler, and I /think/ everything will work automagically. I'll test that.) This can be done, but we really need a person with a Mac who's interested in using CMake. I can advise but I can't test this issue, I have no Mac. An interested person could put the issue into the bug tracker and CC: bvanevery. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote: Dynamic libraries were created to solve upgradability and text size in the VM problems. However, they do have some nasty edge cases. Truth be told, you probably won't hit any of them unless you A) want multiple revisions of a tool coeexisting on the same machine Actually, I do think that's a worthwhile feature, especially on a Windows box with Cygwin, MinGW, and multiple versions of MSVC. This is coming from the perspective of a build engineer. :-) I don't know how worthwhile it is to anyone else. Myself, I just keep my shells and paths hermetically separated from one another. That makes my builds reliable, but it's not an accurate reflection of the state of the average user's box. I plan to add a task or enhancement ticket in the bug tracker about this someday, but right now, we don't even ship binaries. So first things first, I added tickets about that. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote: Example 1 - 1. You statically link the openssl libraries into your application because you can't guarantee that the target platform will have one. So, you move your executable to a machine, start it up, and here is what could happen 2. The program loads the executable, the initializers are run, now some global memory space is initialized for openssl. 3. The program decides to call getpwnam() later, which the administrator happens to have configured to use LDAP with an SSL backend. 4. The lazy load of the ldap resolver, which then brings in the ssl library cause the dynamic ssl library initialization routines to be run again. If the two version of the libraries were the same, then depending when this happens there might be no effect. If they are different versions, either of the two ssl libraries will get confused and probably segfault. 5. This is because the global variable space for both the static version of the library and the dynamic version (probably) resolve to the same symbol names, so they get trashed in the process space. This resembles the case of PCRE. We have our own code for this library. To create a dynamic libchicken, first we create a static libpcre. The static libpcre is compiled with shared flags, so that the .obj files are correct with respect to PIC and can be used in the dynamic libchicken. Can this static-within-dynamic approach cause problems? I did it this way because libpcre is used over and over again during the build, like 7 different times. libpcre itself doesn't need to change, as it's only C code not Chicken Scheme code, it isn't subject to Chicken Scheme notions of being safe or unsafe, nor GUI vs. console. What I really wanted, was a way to build .obj files and then reuse them in different permutations of dynamic libraries. I don't want the user to have to type -lpcre when using Chicken, it should just be -lchicken. Autoconf supports so-called "convenience libraries" that allow you to turn everything into 1 final library. CMake does not, you have to either fake it or recompile lotsa source files. I chose to fake it, and I wonder if there's anything incorrect or hazardous about the fake. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/15/07, Shawn W. <[EMAIL PROTECTED]> wrote: On May 14, 2007, at 1:39 PM, Brandon Van Every wrote: > On 5/14/07, Shawn W. <[EMAIL PROTECTED]> wrote: > ... > > CMake doesn't have framework support. See > http://www.cmake.org/Wiki/CMake:MacOSX_Frameworks > The issue is known but isn't getting attention. Bill Hoffman is > interested in moving forwards on the issue, but could use prodding > and assistance from the Mac community. > What is CMake? A replacement for generating makefiles with automake, or a whole new make derivative? Oh God. FELIX, this is why keeping the Autoconf build around makes me REALLY REALLY MAD. Not your fault, Shawn, for asking this question. You just walked into a debate that's raging in the bug tracker right now. http://trac.callcc.org/ticket/135 for those who want the gory details. CMake http://www.cmake.org is a native build system generator. It can generate makefiles, nmakefiles, Visual Studio project files, Borland makefiles, Watcom makefiles, all kinds of build system files, on all kinds of compilers on all the major operating systems. The primary advantage of CMake over Autoconf is it handles all of the Microsoft Visual Studio compilers. Autoconf, in contrast, deliberately avoids working with MSVC as a political agenda. CMake is a truly cross-platform tool. It is also significantly faster than Autoconf, as the builds are not driven by bloated shell scripts. We've had a feature complete, field tested, all but bug free CMake build for awhile now. It took 1 man year to produce. It is the only way to produce the MSVC versions of Chicken, and it is preferred for MinGW also. It works fine for all the builds on all the platforms, actually, which is why I want to retire the Autoconf system. > Universal binary support to go along with that would be nice > too. The latter is easy to do. (Add '-arch i386 -arch ppc' to the > cflags used by the chicken compiler, and I /think/ everything will > work automagically. I'll test that.) > > > This can be done, but we really need a person with a Mac who's > interested in using CMake. I can advise but I can't test this > issue, I have no Mac. An interested person could put the issue > into the bug tracker and CC: bvanevery. > libtool did not play well with my attempt to build chicken as a universal. I deeply detest libtool. I'd rather make an Xcode project for the chicken source than fight it -- and an Xcode project has the side benefit of making it easier to come up with a chicken framework for all the runtime libraries. The main reason I want Automake retired, is so that when people like you come along with energy for fixing things, that they will try their hand at CMake. I don't want the energies of the community split by Autoconf. At a first go, read INSTALL-CMake.txt and try to build Chicken on your Mac OS X. Then see the bugtracker ticket I've just added about universal binaries. http://trac.callcc.org/ticket/214 Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/15/07, Peter Keller <[EMAIL PROTECTED]> wrote: Given what I've seen above, I think the fake is unstable. Doesn't chicken already have a tool someon can run when linking with chicken applications? Like csc -libs? Why can't you just add -lpcre there if applicable? Then it'll just grab whatever the user wanted. I've created a bug tracker entry, complete with your comments. Anyone interested, let's move the conversation there. http://trac.callcc.org/ticket/215 Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/15/07, Peter Keller <[EMAIL PROTECTED]> wrote: I don't think there is ANYTHING that anyone can do which is the right answer since you basically have to bail at *runtime* if the linker loader notices two APIs of the same kind clashing in the program. I thought C# had a strong notion of versioning. I haven't really gone up the C# learning curve enough to recall whether an Assembly is a C# or a .NET concept though. Nor whether it provides an ultimate solution. Don't know if Java solves it either. The theme is to put versioning in the language though. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/15/07, John Cowan <[EMAIL PROTECTED]> wrote: Brandon Van Every scripsit: > We've had a feature complete, field tested, all but bug free CMake > build for awhile now. It took 1 man year to produce. It is the only > way to produce the MSVC versions of Chicken, and it is preferred for > MinGW also. And for Cygwin, thanks to the libffi support. > It works fine for all the builds on all the platforms, actually, > which is why I want to retire the Autoconf system. Almost. We still have to break the circular dependency that the Linux version (and possibly other Unix versions) think we have. Which one is that? If you're referring to http://trac.callcc.org/ticket/158I reopened it after Felix had closed it as "wontfix." Having the 2nd invocation of "make install" repeat the build from scratch is not that important a bug, and all evidence says it's a Linux specific bug. This level of defect is not a reason to keep the Autoconf build around. In the real world, build systems occasionally have minor bugs. How many bugs do you think people could report with Autoconf itself if they really really tried? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/16/07, John Cowan <[EMAIL PROTECTED]> wrote: Brandon Van Every scripsit: > Having the 2nd invocation of "make install" repeat the build from > scratch is not that important a bug, and all evidence says it's a > Linux specific bug. I'd like to see if it happens on a Solaris or BSD system. I've been wondering if it might not be a general bug that's hidden on Windows systems because of the ".exe" suffix. (I tried posting this to trac, but it kept telling me it was probably spam.) Meanwhile I'd be testing on Fedora Core 6 if it weren't such a !#$!#$%!%!%%!!@@#!!! Is galinha timing out for anyone else, or is it just my crappy cell phone support? And wny does Yum want to download 2MB of crap every time I type "yum list whatever" ? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] CMake make install bug on Linux (was Mac OS X static library names)
On 5/16/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: On 5/16/07, John Cowan <[EMAIL PROTECTED]> wrote: > > Brandon Van Every scripsit: > > > Having the 2nd invocation of "make install" repeat the build from > > scratch is not that important a bug, and all evidence says it's a > > Linux specific bug. > > I'd like to see if it happens on a Solaris or BSD system. I've been > wondering if it might not be a general bug that's hidden on Windows > systems because of the ".exe" suffix. (I tried posting this to > trac, but it kept telling me it was probably spam.) Meanwhile I'd be testing on Fedora Core 6 if it weren't such a !#$!#$%!%!%%!!@@#!!! Is galinha timing out for anyone else, or is it just my crappy cell phone support? And wny does Yum want to download 2MB of crap every time I type "yum list whatever" ? Using Darcs head, I cannot reproduce the bug on Fedora Core 6, even when overwriting an installed Chicken. "make install" does what it's supposed to do, no matter how many times invoked. So, now I need you Linux guys to see if the bug still exists in Darcs head. Also, if you can get Trac accounts working properly for yourselves, and add yourselves as CC: to ticket http://trac.callcc.org/ticket/158 , I'd be much obliged. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] is Mac OS X build working in Darcs?
Can someone please verify that the Mac OS X build in Darcs head is working properly? I don't have a Mac to test it on. Please also do a "make install, make uninstall, make install." There should be no static libraries or executables after that. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: is CMake Mac OS X build working in Darcs?
On 5/17/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: Can someone please verify that the Mac OS X build in Darcs head is working properly? I don't have a Mac to test it on. Please also do a "make install, make uninstall, make install." There should be no static libraries or executables after that. Er, the CMake build is what I'm interested in. I'm trying to close bug tracker ticket http://trac.callcc.org/ticket/106 The Autoconf build hasn't been altered, it still does static linkage. If anyone wants to alter it accordingly, that's ticket http://trac.callcc.org/ticket/217 Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] calling all Vista users
We have a bug report on Windows Vista that we need your help verifying. http://trac.callcc.org/ticket/183 Does chicken-setup work for you? If it doesn't, we need you to add yourselves as CC: in the bug tracker so we can fix this. I don't have a Vista box, I'm using Windows 2000, and things are working fine for me. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/17/07, Graham Fawcett <[EMAIL PROTECTED]> wrote: On 5/16/07, John Cowan <[EMAIL PROTECTED]> wrote: > Brandon Van Every scripsit: > > > Having the 2nd invocation of "make install" repeat the build from > > scratch is not that important a bug, and all evidence says it's a > > Linux specific bug. > > I'd like to see if it happens on a Solaris or BSD system. If someone else runs Solaris and has CMake installed, perhaps they could let me know if they're going to try this? Otherwise I'll do it when I have time. Not important anymore because the bug is closed. I believe that changing the dependencies for dynamic linkage during the bootstrap solved the problem. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] is Mac OS X build working in Darcs?
On 5/17/07, Kon Lovett <[EMAIL PROTECTED]> wrote: On May 17, 2007, at 9:17 AM, Brandon Van Every wrote: > Can someone please verify that the Mac OS X build in Darcs head is > working properly? I don't have a Mac to test it on. Please also > do a "make install, make uninstall, make install." There should be > no static libraries or executables after that. I am having core dumps & 'undefined variable |?|' from chicken components. However, this is not a "stock" build. I am removing the selections I made w/ ccmake to see what is causing the havoc. Please build from a pristine Darcs directory, no running of previous Autoconf or CMake in-directory. Please also build out-of-directory. This is just to ensure that you're not tripping over something left in your directory. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] is Mac OS X build working in Darcs?
On 5/17/07, Kon Lovett <[EMAIL PROTECTED]> wrote: On May 17, 2007, at 1:08 PM, Brandon Van Every wrote: On 5/17/07, Kon Lovett <[EMAIL PROTECTED]> wrote: > > > > I am having core dumps & 'undefined variable |?|' from chicken > components. However, this is not a "stock" build. I am removing the > selections I made w/ ccmake to see what is causing the havoc. Please build from a pristine Darcs directory, no running of previous Autoconf or CMake in-directory. Please also build out-of-directory. This is just to ensure that you're not tripping over something left in your directory. Did all of the above. Dang. If you still have problems with a "stock" build then we'll need to CC: you on the ticket. http://trac.callcc.org/ticket/106 Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Mac OS X static library names
On 5/17/07, Shawn W. <[EMAIL PROTECTED]> wrote: On May 15, 2007, at 7:35 AM, Brandon Van Every wrote: > > At a first go, read INSTALL-CMake.txt and try to build Chicken on > your Mac OS X. Then see the bugtracker ticket I've just added > about universal binaries. http://trac.callcc.org/ticket/214 > > (I tried putting this in trac, but it keeps getting rejected as spam. Huh?) I've added a ticket about this as John Cowan is having the same problem. http://trac.callcc.org/ticket/218 I installed cmake, and figured out how to make it produce an Xcode project file. Even though CMake came up with an option to specify which build architectures to use, the generated project file only did powerpc. After adding i386, I tried compiling... and it didn't work -- posixwin.c was included in the source, and, for some reason, it took 5 minutes for Xcode to respond to /anything/ -- which is NOT normal for it. I gave up fighting that before I got any results. I wouldn't expect the current CMake build to generate universal binaries just by adding flags. Currently we use a TRY_RUN with CStackGrowsDownward.c, and this should cause disaster when cross-compiling. This is noted in the ticket about universal binaries above. (I used cmake 2.4p6, which is what was in my package system. Dunno if there's a newer release that produces a project that doesn't cause the issue.) CMake 2.4.6 is the most recent stable release. To get more recent than that, you'd need to compile CMake from CVS sources. I am not presently up on CMake XCode issues so I don't know if that would be profitable for you. You could look in the CMake bug tracker or mailing list archives to see what they have to say about XCode. Next, I tried using cmake to generate makefiles. It came up with the same build architecture option, but, just as with the Xcode option, seems to ignore it. Initial impression of cmake after 10 minutes: I don't like it. It makes Xcode projects that do their best to break Xcode. It's not CMake's fault that we haven't implemented support for universal binaries yet. As for XCode, I don't know enough about it to separate CMake issues from Chicken issues. The makefiles it generates hide too much; That's the price you pay for a build system generator that works on all platforms. You were expecting the clarity of a hand-crafted makefile? I had to check ps and, after tracking down where it was putting object files, use file to confirm that it was only producing powerpc code. Well, things that are broken aren't terribly likeable. And it colorizes stuff! Icky. That's not important. Please don't get rid of the autoconf and automake and libtool way of building. (Which I like to use in decreasing order. autoconf is great. automake is ugly and I try to avoid using it for my own projects, preferring autoconf and hand-written makefiles. libtool is... I've already said what I feel about that. But the alternatives seem to be just as bad.) It's still better than cmake, at least for me. On the other hand, you said you put 10 minutes of work into CMake. That's enough to indicate there are problems, and thanks for doing it! It is not, however, enough to make a case for splitting the energies of the community between Autoconf and CMake. What we'd like is for Mac people to work on the CMake build so that these issues get fixed and go away. I'm point man on CMake, but I can only do so much because I don't have a Mac. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/17/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: On 5/17/07, Shawn W. <[EMAIL PROTECTED] > wrote: > > > On May 15, 2007, at 7:35 AM, Brandon Van Every wrote: > > > > At a first go, read INSTALL-CMake.txt and try to build Chicken on > > your Mac OS X. Then see the bugtracker ticket I've just added > > about universal binaries. http://trac.callcc.org/ticket/214 > > > > I wouldn't expect the current CMake build to generate universal binaries just by adding flags. Currently we use a TRY_RUN with CStackGrowsDownward.c, and this should cause disaster when cross-compiling. This is noted in the ticket about universal binaries above. I wouldn't expect the Automake build to perform any better either, as once upon a time I lifted the CStackGrowsDownward.c code from Automake's output. It probably uses the same try-run mechanism to determine the results. And if it doesn't, I'd like to know how, so that CMake can copy it. Can you actually make a universal binary with Automake? With XCode? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On 5/17/07, Kon Lovett <[EMAIL PROTECTED]> wrote: Compiling a universal binary is an exercise in x-compiling. Chicken cannot discover anything about the foreign platform, it must "know." All cpu specific configuration must be done via command-line options or a separate set of configuration headers. I am not saying "discover" bad, "know" good. Just that in the case of x-compiling "knowing" is the only way. Right. My point is, unless Automake "knows," it is no better than CMake at this. And I suspect the current Autoconf build does not "know." (BTW, Brandon I will get back to the CMake build on MacOS X PPC. Sorry, I need get some bugs fixed in other code first. The problem seems to be an issue w/ the extra-symbol-slot. Even though I turned on this options w/ ccmake, & the resulting 'csi' says it has 'extraslot', using an extension compiled w/ the autotools generated Chicken yields the undefined variable '||', which I think is an indication of an incompatible memory model. If so, that would be a new ticket entirely. I completely removed Chicken, got a fresh darcs, got a snapshot (for the boot/cfiles, which are not in the darcs repo!), boot/cfiles aren't supposed to be in the Darcs repo. They are supposed to be generated from the Darcs repo. Whose boot/cfiles would you use, canonically speaking? They're always going to be different, their changelog would be voluminous noise. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken manual in Texinfo format
On 5/18/07, Ivan Raikov <[EMAIL PROTECTED]> wrote: The current html parody of a manual is impossible to use. You're exaggerating. Please be specific about what's impacting your workflow. Please also be objective about how much time you're losing, rather than dwelling on matters of taste. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A Proposal for Texinfo Reference Manual, was: Re: Chicken manual in Texinfo format
On 5/21/07, Adhi Hargo <[EMAIL PROTECTED]> wrote: THE PROPOSAL: Important point first: I propose, in the long run, to spare the wiki for tutorials, introductions, cookbooks, FAQs, installation problem, or anything else any casual user could confidently contribute, and let the maintainer or at least experienced programmers (a number of you, I suppose) do the real manual in Texinfo. Wikis are for getting a community to gradually document stuff over time. Making people learn Texinfo isn't. Documentation is most programmers' least favorite thing to do, and they're not gonna do it. I believe the wiki needs to remain the primary source of documentation, with Texinfo a secondary format, if people want to put effort into that. Why? (1) Because I've seen this unfold in the CMake community. It's a much larger community, and yet very important stuff never gets documented, unless *I personally* go and add things. I don't have any particular responsibility for documentation. I just get really irked at documentation which cripples people, and I'm one of the few who will actually do something about it. Even I do very little. If lotsa people would do what I do, then CMake would have great documentation, but they don't. (2) Because Texinfo isn't relevant to all developers. The reality is there's an Emacs crowd, a Visual Studio crowd, an Eclipse crowd, and various other crowds. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] calling all Vista users
Can you please add yourself to http://trac.callcc.org so we can track this issue? Please make your report at ticket http://trac.callcc.org/ticket/183. You need to use the *SETTINGS* menu option to register, so that Trac doesn't think you're spam. Please also give the output of "csc -version" If there are any other Vista users out there, please also let me know. Cheers, Brandon On 5/24/07, Ian Oversby <[EMAIL PROTECTED]> wrote: Okay, I've tried reinstalling it. Still the same error - bad file number. csi itself seems to work, although I've only used it for trivial stuff. Ian On 19/05/07, Ian Oversby <[EMAIL PROTECTED]> wrote: > Yes, they work, although I suppose it is possible that it is choosing > some other version from a different path. Let me try to install it > again at some point (hopefully this week) and get back to you. > > Cheers, > > Ian > > On 19/05/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > Apparently for Trac to consider you legit, you must fill out your name and > > e-mail address on the Settings page. http://trac.callcc.org/settings I'd > > like Trac to report an error about this rather than leave people in the > > dark, but so far we don't have a mechanism. > > > > Do your tar, gzip, and gunzip actually work? Do they unpack stuff? I > > managed to obtain ones that didn't. > > > > Cheers, > > Brandon > > > > > > On 5/18/07, Ian Oversby <[EMAIL PROTECTED]> wrote: > > > I did have tar, gzip and gunzip in my path, yes. I've reinstalled > > > Vista since then though I've not tried to install Chicken again. I > > > was unable to submit a response to Trac as it told me "Submission > > > rejected as potential spam". > > > > > > Ian > > > > > > On 17/05/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > > > We have a bug report on Windows Vista that we need your help verifying. > > > > http://trac.callcc.org/ticket/183 Does chicken-setup > > work > > > > for you? If it doesn't, we need you to add yourselves as CC: in the bug > > > > tracker so we can fix this. I don't have a Vista box, I'm using Windows > > > > 2000, and things are working fine for me. > > > > > > > > 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] csc segfaults with certain recursive sources
What OS (Linux?), what distro, what build system (Automake, CMake, pre-packaged), what is output of "csc -version", building from tarball or Darcs head, what version? And, please put all this in the bug tracker http://trac.callcc.org . Note that you will need to enter stuff on the *SETTINGS* page so that Trac doesn't think you're spam. Cheers, Brandon Van Every On 5/26/07, Dan Muresan <[EMAIL PROTECTED]> wrote: $ cat x.scm (require 'y) (module x (fx) (define fx 10) ) $ cat y.scm (require 'x) (require-for-syntax 'x) (import x) (define fy 20) $ csc -R syntax-case -s x.scm $ csc -R syntax-case -s y.scm Error: (open-input-file) can not open file - Too many open files: "./x.so" Segmentation fault (core dumped) *** Shell command terminated with exit status 139: /opt/chicken/bin/chicken y.scm -output-file y.c -dynamic -feature chicken-compile-shared -quiet -require-extension syntax-case ___ 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] Re: [Chicken-bugs] #227: csc segfaults with certain recursive sources
On 5/26/07, Dan Muresan <[EMAIL PROTECTED]> wrote: I've submitted to Trac. Interesting... the ticket formatting got screwed up in Trac (it seems that single-newlines are treated as whitespace, while double newlines break paragraphs). Yet the automated e-mail that Trac sent has the correct newlines. I've noticed the messed up single-newline behavior as well. You could file an "infrastructure" bug. :-) Assign it to Arto, he deals with Trac stuff. Also let us know in ticket #164 whether you were able to assign it or not. If so, then #164 should be closed. If not, then #164 "can't assign stuff" is still a bug. :-) Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: [Chicken-bugs] #227: csc segfaults with certain recursive sources
On 5/26/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: Also let us know in ticket #164 whether you were able to assign it or not. If so, then #164 should be closed. If not, then #164 "can't assign stuff" is still a bug. :-) Sorry, didn't realize #164 is about *anonymous* people assigning stuff. You're not anonymous. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: [Chicken-bugs] #227: csc segfaults with certain recursive sources
On 5/26/07, Dan Muresan <[EMAIL PROTECTED]> wrote: > I've noticed the messed up single-newline behavior as well. You could > file an "infrastructure" bug. :-) Assign it to Arto, he deals with > Trac stuff. Also let us know in ticket #164 whether you were able to > assign it or not. If so, then #164 should be closed. If not, then #164 > "can't assign stuff" is still a bug. :-) Man, if you've noticed it first then maybe *you* should submit a new ticket, instead of asking me to do it. I think it's only fair. Thanks for registering in Trac and submitting what you've already submitted. Working with the Trac process helps all of us immensely and improves Chicken. But, let's not get into "you should do the work... no, you should!" An open source community grows by people pitching in, especially for very minor things that are easy enough for them to do. Putting things in bug trackers is work; it is my policy to condition as many people as possible in the Chicken community to do the work. Anything that can be delegated, especially really minor things like a bug of this stature, should be delegated so that the load on core Chicken developers is reduced. I've got 3 active tickets in Trac I should be working on; you do not. I don't expect anyone to volunteer to actually fix things, but my point is, I am carrying my weight and am sufficiently busy. That is not to mention projects / life priorities aside from Chicken, either. I'm sure you have yours as well. If you don't want to do something right this minute, I might suggest marking an e-mail as Unread and dealing with it later. But I do hope in general, people will take the time to submit issues to the bug tracker. Otherwise people forget. That's pretty much what a bug tracker is for, to aid memory. I don't know what #164 is (and I don't see a way to quickly jump to a ticket by number), Hm you're right, this isn't obvious. Typing "#164" into the Search field works, but how would anyone know to do that? I've added http://trac.callcc.org/ticket/229 about that. nor do I really care that much right now, to be honest... If so, why would you criticize me for not having filed the single-newline bug earlier? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Choosing chicken
On 6/2/07, Shawn W. <[EMAIL PROTECTED]> wrote: What schemes do you use, for what? Why? Know of a nifty feature or approach a particular scheme takes that most others don't? What do you think a particular version (Including chicken, of course) is best suited for? In summary: - Windows support - retargettability I think Chicken has got its foot in the door for real Windows support, because it has the CMake build system. That said, Felix doesn't actually develop for Windows, and there aren't many Windows programmers in the Chicken community. Visual Studio Express 2005 doesn't work, but that's most likely Microsoft's fault, for providing a crippled free compiler. All the other compilers work to my knowledge. I'm still trying to obtain Vista, to see if I can duplicate some MinGW problems on it, possibly related to permissions. Despite the problems, this is actually a lot farther along than a lot of Scheme implementations. They are all too frequently guilty of Unix-centrism and building poorly on Windows. In comparison, we're building on Windows all the time, it stays working. The advantage of Chicken is its build is not a hodgepodge. One build handles all platforms, using a standard tool. That should make it easy to retarget Chicken at any platform where CMake is available, which is a lot of platforms. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Choosing chicken
On 6/2/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: > > In summary: > - Windows support > - retargettability > Isn't PLT's Windows support as good as or better than Chicken's? Looks that way. For the Windows build, it looks like they're Visual Studio 2005 .sln files. I don't know how disciplined the PLT guys are about keeping their .sln builds working, but it is typical in such projects for the manually maintained Windows build to fall behind the Autoconf build. CMake is a unified build system and much less likely to fall behind on any given platform, although it is possible if a platform-specific build bug happens. Also for PLT if you want VS .NET 2003, or god forbid, VS 6, you're SOL. One advantage of CMake is you don't have to care which version of MSVC you're using. I'm not sure how their MinGW or Cygwin support is either. On the other hand, PLT ships binaries and we don't. That's a big advantage to most people. Once upon a time, PLT's performance wasn't as good as Chicken's. I don't know about now. Chicken has some inherent ability to talk to C++. As far as I know, PLT doesn't. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: Choosing chicken
On 6/2/07, Jens Axel Søgaard <[EMAIL PROTECTED]> wrote: [I am not on the Chicken mailing list, so I am responding directly - feel free to any response to the mailing list] Brandon Van Every wrote: > On 6/2/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: >> > >> > In summary: >> > - Windows support >> > - retargettability >> > >> >> Isn't PLT's Windows support as good as or better than Chicken's? > > Looks that way. For the Windows build, it looks like they're Visual > Studio 2005 .sln files. I don't know how disciplined the PLT guys are > about keeping their .sln builds working, but it is typical in such > projects for the manually maintained Windows build to fall behind the > Autoconf build. PLT has an automated build system that each night builds what is in the current SVN. You can download these builds from this page: <http://pre.plt-scheme.org/installers/> Build errors are therefore caught *very* quickly. Ouch well then they're certainly ahead in that respect. Nightly builds and automated testing systems are only wish list for Chicken. CMake has the infrastructure to do all of that elegantly, but nobody has the inclination to actually implement it. I've had it as a task in our bug tracker for awhile, but recently I abdicated responsibility for it, as it's a huge task and I must look to more $ things right now. > CMake is a unified build system and much less likely > to fall behind on any given platform, although it is possible if a > platform-specific build bug happens. Also for PLT if you want VS > .NET 2003, or god forbid, VS 6, you're SOL. I have a healthy scepticism of everything related to Microsoft, but if it builds with the free Microsoft compiler, why wouldn't it build with VS6? Because PLT has a VS 2005 build file, and those files are not backwards compatible to earlier versions of MSVC. You'd have to figure it out yourself. If you do figure it out, you'll have to maintain it yourself, as the canonical PLT build isn't dealing with it. With Chicken and CMake the choice of compiler is a non-issue. One build supports all compilers, including all the different MSVC versions. > Once upon a time, PLT's performance wasn't as good as Chicken's. I > don't know about now. > > Chicken has some inherent ability to talk to C++. As far as I know, > PLT doesn't. Are you thinking ABI here? No, I'm saying Chicken understands some C++ constructs. That's one of the reasons I went with Chicken over other things. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: Choosing chicken
On 6/2/07, Jens Axel Søgaard <[EMAIL PROTECTED]> wrote: Brandon Van Every skrev: >> > Chicken has some inherent ability to talk to C++. As far as I know, >> > PLT doesn't. >> >> Are you thinking ABI here? > > No, I'm saying Chicken understands some C++ constructs. That's one of > the reasons I went with Chicken over other things. You know me - I am curious. What type of constructs? templates, classes. I am not well versed in the limitations. http://chicken.wiki.br/Foreign%20type%20specifiers Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/4/07, felix winkelmann <[EMAIL PROTECTED]> wrote: On 6/4/07, Sunnan <[EMAIL PROTECTED]> wrote: > felix winkelmann wrote: > > > > A stalin-compat library? No problem. > > > It wasn't so much a request as an example of what people can do. > I was not suggesting to write such a thing. :-) Reading this thread, all I can say is man what a bunch of goofy noodlers you are! :-) I can't even fathom the practical motivation to do any of this, seeing as Stalin is the most user unfriendly and unsupported Scheme distribution out there. Where is Stalin's wiki, bug tracker, source code repository, extensions repository, mailing list, and user community? The question isn't how you would use Stalin with Chicken, but whether anyone uses Stalin at all. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
Speed, to the exclusion of all other considerations, is not the real world. I can understand compiling portable Scheme code under any 2 different compilers. I cannot fathom trying to get such code to interoperate. This thread reads like a Frankenstein support nightmare. Cheers, Brandon Van Every On 6/4/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: Hallo, On 6/4/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > Reading this thread, all I can say is man what a bunch of goofy > noodlers you are! :-) I can't even fathom the practical motivation > to do any of this, seeing as Stalin is the most user unfriendly and > unsupported Scheme distribution out there. Speed. -- -alex http://www.ventonegro.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/4/07, John Cowan <[EMAIL PROTECTED]> wrote: Brandon Van Every scripsit: > Speed, to the exclusion of all other considerations, is not the real > world. I can understand compiling portable Scheme code under any 2 > different compilers. I cannot fathom trying to get such code to > interoperate. This thread reads like a Frankenstein support > nightmare. Developing code under Chicken is fairly straightforward; developing code under Stalin is painful in the extreme. It therefore is plausible to have a Stalin-compatible library for Chicken that allows one to develop code that Stalin can handle after it is fully debugged under Chicken. You can then gain the advantages of Stalin's massive optimizations to gain execution speed. With no eggs. This is infrastructurally lame. Anyone who is that enamored with speed deserves what they get. Efforts would be better spent actually creating a community around Stalin and showing some leadership addressing its utter inadequacies. C'mon guys, if you want to develop with someone's FTP dump then you just don't appreciate what it takes to do software. Stalin properly exists as a research reference and nothing more. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken and stalin
On 6/5/07, John Cowan <[EMAIL PROTECTED]> wrote: Brandon Van Every scripsit: > This is infrastructurally lame. Anyone who is that enamored with > speed deserves what they get. Efforts would be better spent actually > creating a community around Stalin and showing some leadership > addressing its utter inadequacies. C'mon guys, if you want to develop > with someone's FTP dump then you just don't appreciate what it takes > to do software. Stalin properly exists as a research reference and > nothing more. Brandon, this is pure negativity, only one step up from "Don't do that, it won't help me develop games on Windows." If Stalin compatibility scratches someone's itch or tickles their fancy, it'll get done. If not, it won't. In either case, you are better off spending your time achieving your objectives than trying to tell other people not to achieve theirs. This goes far beyond games on Windows. This is about people completely wasting their time on projects that, if they have no academic context, are completely worthless. I've gone bankrupt chasing nonsense. I have delusions of grandeur that I *might* save some young buck from his/her utter cluelessness in the face of industrial reality. I don't want to invoke Felix as having an opinion on this issue, but why do you think he rolls his eyeballs when R6RS comes up? I'll wager, because there's a huge chunk of people in Scheme-land that DON'T GET IT when it comes to practical reality. That's why Scheme sucks as far as standardization, why it remains a research rather than practical language for most of the computer industry, and why it fails to gain any relevance. Too many smart, tweaky people with no clue working on things that don't matter. If Scheme were a mental disorder, it would be ADD. I don't really believe in software as a playground. I believe in software that gets important things done. That's why I was willing to put 1 man year into the Chicken build system, a fairly dull task, and other people generally aren't. My build system is going to be here years from now, unless something substantially better than CMake comes along, which I don't expect to happen anytime soon. Whereas Chicken and Stalin compatibility libraries and interop will *NEVER* be here. Not in any sense beyond 1 person's irreproducible homebrew that breaks the 1st month they have to go get a real job. I've spent 3 years evaluating what counts in open source. THIS DOESN'T COUNT. This isn't even about the prowess of any particular author who wishes to take Chicken-Stalin on. As cynical as I am about what well-intentioned people can actually accomplish, the real issue is LOOK AT YOUR PARTNER. Stalin is the biggest joke from an open source support standpoint that I've ever seen. You're never going to get anything out of its author. His compiler is out there so that people can do what they like with it, without bugging him about it. It is a research reference implementation and nothing more. Great stuff if you're getting your PhD in compiler design; otherwise, worthless. Stalin's author knows that he's contributing to an academic corpus, the "publish or perish" crowd. He has NO INCENTIVE WHATSOEVER to pursue the practical industrial things that we pursue in the Chicken community. This pattern is abundant in the academic language research community. You will find it with the SML/NJ crowd as well, to a lesser degree. They make no bones about being academic guys, not open source community building guys. Felix's language leadership is very different from the academic average. Be thankful and avail yourself of it. Nobody can tell anyone what to do in open source. But I sure hope someone out there is capable of learning from other people chopping off their fingers, rather than chopping off their own. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/5/07, Dan Muresan <[EMAIL PROTECTED]> wrote: > This goes far beyond games on Windows. This is about people > completely wasting their time on projects that, if they have no > academic context, are completely worthless. I've gone bankrupt > chasing nonsense. I have delusions of grandeur that I *might* save > some young buck from his/her utter cluelessness in the face of > industrial reality. Brandon, your penchant for getting involved in long, useless polemics is NOT a quality. Dispelling complacency is the only way you ever *get* any quality. Also, you may want to be more cautious when judging the difficulty level of various software platforms, especially when you haven't really tried using them. I think it's pretty well established that Stalin (and Gambit?) are faster than Chicken, but Chicken has a much better ecosystem (community, libraries etc). I just brushed up on what's out there for Stalin. Seems like it's whatever's on the Stalin FTP site, which is pretty narrow in focus. If you see people interested in Stalin, I'm pretty sure they know the deal they're getting. You're not adding value by trying to convince them otherwise; I don't expect the average language noob to have any idea why academics avoid doing certain things. Nor do I expect most people to have a sense of relevant strategic growth in open source. What I do expect, is for people to get carried away with "Wow it's fast!" because it sounds so kewl. Yes I have a low opinion of people's actual ability to steward open source projects to a successful conclusion. It comes from 14 years of experience watching the fireworks and falling on my own face more than enough times. I'll repeat what I said before. If Stalin is so great, then someone go start a Stalin community. That's what needs to happen for it to be relevant. and they certainly won't appreciate your suggestion that you know better what's good for them. People who are smart enough to learn from others' experience will pay attention. People who aren't, will suffer until they are. Let's stick to discussions that provide value to all participants. That's never generally true on any mailing list. Clearly you don't value this one. Keep in mind that when you feel like belaboring a random point to death, you can always reply in private. This discussion isn't random. As for belabored, it reminds me of the joke about 2 economists. They're walking down Wall Street and there's a $20 bill on the ground. One of them exclaims to the other, "Look, a $20 bill!" The other says, "No that's impossible, someone would have picked it up already" and they go right on walking. You think everyone's well aware of the implications of support. I don't. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/5/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: On 6/5/07, Dan Muresan <[EMAIL PROTECTED]> wrote: > Let's stick to discussions that provide value to all participants. That's never generally true on any mailing list. Clearly you don't value this one. That is to say, you don't value this discussion. I assume you value the mailing list. Just clarifying. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/5/07, John Cowan <[EMAIL PROTECTED]> wrote: Brandon Van Every scripsit: > I'll repeat what I said before. If Stalin is so great, then someone > go start a Stalin community. That's what needs to happen for it to be > relevant. There's not a huge development community around "ls" either. Some people might say it's already over-developed. The FSF has provided a huge community around "ls" and other binutils. That's why you can use them for free and they work well, without jerry rigged compatibility libraries. When Stalin's author, or a 3rd party community, takes on responsibility even remotely resembling what the FSF has done, I think you'll have a basis for comparison here. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] installing chicken using microsoft's .NET (2005)
On 6/10/07, Richard <[EMAIL PROTECTED]> wrote: I was able to install chicken form the zip file and compile most of it using "cmake" and "2005 vc++ .NET version". It compiled and generated and the "chicken-boot.exe" file. I can create a "c" file from a simple "scm" file. However, when I try to generate a "c" program from the "chicken.scm" file I get syntax error and a "stack overflow" error msg. This is the same thing that happens during the build using the project files generated by "cmake"... If you are using VS 2005 Express, then this is a known bug. Our assumption is that the Express compiler has been deliberately crippled so it can't compete with the professional products. http://trac.callcc.org/ticket/9 If you are using a professional or enterprise version of VS 2005, this is new. In that case, please add your compiler information to this bug. You'll need to configure your identity in Trac's "Settings" menu, as Trac assumes that anonymous contributions are spam. Also, that's how you'll know if the status of the bug changes. MinGW, Cygwin, and VS .NET 2003 are working fine, if you're willing to use those. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] install sdl.egg with mingw32?
On 6/25/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: Hallo, On 6/25/07, felix winkelmann <[EMAIL PROTECTED]> wrote: > On 6/24/07, Jong-Hyouk Yun <[EMAIL PROTECTED]> wrote: > > > > what's wrong, or more simple method there? anybody has succeed sdl.egg + > > mingw32? > > I think you are the first person who actually tries to use it on mingw. > sdl.scm should include if _WIN32 is defined and omit the > inclusion of netinet/in.h. > No, he's the second. :-) Third. I can't remember if I got it working or not. I remember doing it under MSYS, because compiling SDL under straight MinGW wasn't possible and I didn't know if I could just use MSVC binaries. Anyways it was a PITA because of all the needed SDL components. I've migrated mostly to a laptop now, and haven't set up MSYS there, nor do I want MSYS, or SDL for that matter, so I got lazy about responding to this. I suppose I could try the straight MSVC binaries and see if they work though. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] install sdl.egg with mingw32?
On 6/25/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: Third. I can't remember if I got it working or not. I remember doing it under MSYS, because compiling SDL under straight MinGW wasn't possible and I didn't know if I could just use MSVC binaries. Anyways it was a PITA because of all the needed SDL components. I've migrated mostly to a laptop now, and haven't set up MSYS there, nor do I want MSYS, or SDL for that matter, so I got lazy about responding to this. I suppose I could try the straight MSVC binaries and see if they work though. Actually there's a MinGW binary available for SDL itself, but not for all those other SDL extension libraries that the SDL egg monolithically requires. I think it would be better if there's a SDL egg that only does the base SDL library. I've added ticket #257 about this. I'm not volunteering to work on it, I'm just noting the idea for posterity. I'm also bowing out of setting up a MinGW SDL environment. Too much work for something I don't wish to use. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] install sdl.egg with mingw32?
On 6/26/07, Jong-Hyouk Yun <[EMAIL PROTECTED]> wrote: Is this fine link mingw libraries with vc6 libraries together into same executable image? Not sure. I'd Google about the issue if I were you. I do know that the different compilers have different mangling conventions. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Automated builds
On 6/28/07, Peter Bex <[EMAIL PROTECTED]> wrote: On Thu, Jun 28, 2007 at 10:54:59AM -0300, Mario Domenech Goulart wrote: > > Sugestions are welcome. It's not really feasible for everyone to keep checking back to the build log every time, but would it be possible to add a 'maintainer' field to an egg's meta file with an email address, so you can automatically email an author with his failing eggs? An even better alternative would be to set up an rss feed which can tell me in my rss reader when my egg failed. If these sorts of things are easy to do, that's great. Rock on. If not, I'll make note that CMake / CTest / Dart dashboard already has all these sorts of reporting capabilities in a lovely web format. Here's an example: http://www.vtk.org/Testing/Dashboard/20070628-0300-Nightly/Dashboard.html Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] preferred gui library
On 7/4/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: + Lightweight and *just* a GUI; Although the API is very small, the egg is far from finished though, so probably this is not what you want. Otherwise, feel free to ask more. Felix was intoning "lightweight" back when we had that GUI discussion. As I said then, the problem with that approach is, everyone wants different versions of "lightweight." So by the time you get done pleasing everybody, which is what needs to happen for projects to become standardized, stable, well supported, and widely adopted, it's not lightweight anymore. At best it's middleweight and more typically it becomes heavyweight. Consequently, I suggested you guys pick the One True GUI [TM] that's already out there and stick with it. Because you're going to end up reinventing such a thing yourselves anyways. Alternately, you guys could just each individually code up your own personalized "lightweight" stuff. Heck, I'm doing that with my 3D engine right now, because I'm working on a laptop with 8MB of VRAM and even if I wanted to bother to learn someone else's 3D engine, they don't do a particularly good job of handling such a low resource 3D card. "Lightweight" can be a valid design choice. I'm just pointing out the strategic consequences of fixating on that. I mean, let's face it, people intoned all those ideas and desires some months ago and nothing has come of it. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Fwd: [CMake] Deb and RPM package generation modules
New post on the CMake list, if someone wants to pursue it on Linux. -- Forwarded message -- From: Mehdi Rabah <[EMAIL PROTECTED]> Date: Jul 4, 2007 11:21 AM Subject: [CMake] Deb and RPM package generation modules To: [EMAIL PROTECTED] Hi everyone, In case someone is interested in linux package generation within cmake, I've started to improve the existing scripts (http://www.cmake.org/Wiki/CMakeUserUseRPMTools and http://www.cmake.org/Wiki/CMakeUserUseDebian) to make both debian and rpm packaging easier. Here is links to these modules with a concrete example: https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/CMake/DpkgDeb.cmake?root=cycabtk&view=markup https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/CMake/Rpmbuild.cmake?root=cycabtk&view=markup https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/Hugr/CMakeLists.txt?root=cycabtk&view=markup The differences with the original scripts are that: - you can customize the entire control or spec file directly from your cmake file (yet to finish for rpm) - it doesn't need cpack anymore (I don't know if it's a good thing or not) - the two modules have some common description variables (so it's easy to describe both rpm and deb packages) - for the deb generation : use dpkg-deb. (building the archive directly with ar seems to cause some weird problem, with gdebi or dpkg-scanpackages for example). it doesn't rely on Md5Sum module anymore - you can generate a package for each subproject (ie folders with a CMakeLists and a PROJECT() macro) of your cmake project. - can't generate the source package anymore :/ (yet) this was made using cpack, but It seems that cpack don't let you choose what do you want to put in your source package... so I'm trying to do it without cpack (btw, there is very really few documentation on cpack ^^) There are still a few part that needs to be finished, but I think the major improvement will be to autodetect the dependencies (like dh_makeshlibs for deb package building). So I think that's it. Do you have any thoughts on all this? CPack seems to have some cool feature like stripping binaries, so do you think it will be a good idea to *really* integrate these modules within cpack? Regards, -- Mehdi ___ CMake mailing list [EMAIL PROTECTED] http://www.cmake.org/mailman/listinfo/cmake ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] wxWidgets
Ok, so, like, refresh my memory why people object to wxWidgets. Because, you know, like, it seems a pretty obvious choice for cross-platform GUI work. http://www.wxwidgets.org Is this about C++? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] The Programmer Hierarchy
http://lukewelling.com/2006/08/03/java-programmers-are-the-erotic-furries-of-programming/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] FLTK and CEGUI
On 7/8/07, Adhi Hargo <[EMAIL PROTECTED]> wrote: Well then, either we focus on wxWidgets, or FLTK (!). I don't mind the latter, IMHO its interface is quite clean and simple, a total opposite to wxWidgets albeit somewhat limiting usage. Never encounter a buggy FLTK app either (lack of exposure?). I recently looked at Crazy Eddie's GUI System http://www.cegui.org.uk because my primary interest is games. FLTK screenshots are quite ugly in this regard and don't assure me that it's appropriate for games, although at least it's OpenGL based. CEGUI in contrast is used in the Ogre and Irrlicht 3d engines, which are pretty much the leading open source engines right now. It's got much better screenshots from a gamer's standpoint, clearly demonstrating skinning capabilities. Having development driven by major open source projects is also important IMHO. I realize that not everyone's a game developer or cares about such capabilities. But I thought I would mention it since it's something I might be interested in. It deserves consideration for those who think an OpenGL based GUI is the way to go. Also the license is better: CEGUI is MIT, FLTK is LGPL. Cheers, Brandon Van Every ___ 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] 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\chicken>make 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] operations
On 7/16/07, Robin Lee Powell <[EMAIL PROTECTED]> wrote: Before I kill myself trying to figure out WTH that page is about just because Felix thinks it's cool (which is sufficient reason, for the most part, but still) can anyone give me a precis of why this is interesting? Those who don't study history are doomed to repeat it? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] CMake 2.4.7 cross-compilation
The most important feature of CMake 2.4.7 is support for cross-compilation. I don't know my way around it yet, but I expect I will learn at some point. Perhaps some of you are more motivated presently. Cheers, Brandon Van Every -- Forwarded message -- From: Bill Hoffman <[EMAIL PROTECTED]> Date: Jul 18, 2007 10:05 AM Subject: [CMake] CMake 2.4.7 available for download To: CMake <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] On behalf of myself, Ken, Brad, Alex and the rest of the CMake team, we are pleased to announce that CMake 2.4.7 is available for download at: http://www.cmake.org/HTML/Download.html If you have any problems or find any bugs, please report them at www.cmake.org/Bug. A list of changes for the 2.4 release tree is included below. Thanks Bill (sorry for the duplicate email with the wrong subject.) Changes in CMake 2.4.7 --- RC 11 * Fix bug 5238 for cygwin versioned executables * Allow for platform choice of executable shared libs install * Fix @ONLY issues with RC 10 * Add -E make_directory to cmake executable --- RC 10 * Fix rebuild problem with makefiles and cmake vs CMakeSetup --- RC 9 --- * Fix problem with \@ in configure files bug# 5130 --- RC 8 --- * Fix bug 5121 crash with build test on and vs * Fix bug 5096 add_library and EXCLUDE_FROM_ALL not working --- RC 7 --- * Fix @ in Xcode projects * add some fixes for FindSWIG.cmake * Fix new line stuff in UsePkgConfig.cmake * Add new FindPkgConfig.cmake from CVS * improve docs for try_compile and list commands * fix for bug 4384, preserve sym links in install directory * Use platform variable for link path exclusion added in RC6 --- RC 6 --- * Fix stack reporting bug in macros and include * Fix double quote in -D flags for vs broken in RC 5 * Fix problem with newer curl and curl_getdate changes * Do not emit link paths /usr/lib32 and /usr/lib64 with -L ---RC 5 * Fix for bug# 4423, LANGUAGE property now works in VS IDE * Fix for RUN_TESTS running the tests twice in VS IDE * Do not create import libraries for modules on borland * Fix for FILE(RELATIVE_PATH) # 4482 * Fix for apple lack of support for isystem flag * Fix for Borland skipping make rules with no depends * Fix for bug #4423 set source file properties LANGUAGE not always working * Fix for bug #4462 isystem not supported on OSX * Fix bug in save of resize of CMakeSetup * Fix for @@ in file names * Fix for if command scope issues * Fix for relative path issue with paths ending in /. * CMakeSetup saves the size of the dialog from the last run * Fix for bug 4399, find qt designer on mac * Fix for bug 4420 include unicode libs in cpack for vs8 * Fix for bug 4414 add_dependencies and set_target_properties can set any target not just the ones in the current directory. * Add support for cygwin setup packages to setup * Fix uninstall with DESTDIR * If COMPILE_FLAGS is changed on a target the object files will now recompile * Fix Bug 3512 - precompiled header flag mapping on VS. * Do not run custom commands with relative paths if the working directory is set. * Fix bugs 3277, 4341, 4341 make pdb files match the target name correctly * handle user set NODEFAULTLIB correctly in VS projects * Fix external project for VS 2005 service pack 1 GUID not set correctly * Fix Kdevelop problem where files could end up duplicated Changes in CMake 2.4.6 * Remove svn test in ctestctest3 * Fix for FIND_* order and framworks with PREFIX usage. * Fix for FindDoxygen and quiet mode. * Find JavaVM as well as jvm * Look for ruby1.8 and ruby * Fix for cpack .tgz.sh and dash * Fix for finding custom commands from a full path with CMAKE_CFG_INTDIR. * Fix for Borland make and custom commands that do nothing Changes in CMake 2.4.5 * Fix for seg fault when a macro runs a bad command BUG# 3815 * Fix fix for foo.dll.lib that does not brea -L/usr/lib in link names * Fix problem with LIBRARY_OUTPUT_PATH and linking to a dll foo.dll.lib instead of foo.lib * Do not depend on optimized libraries for a debug build and visa versa. * Fix target name matching custom command output conflict. * Fix FindQt3 so that it does not find qt4 * Fix FindKDE4 so that it only looks for kde4-config Changes in CMake 2.4.4 * CMake Version numbers on module directory * elseif added * Fix docs in CheckCSourceCompiles CheckCXXSourceCompiles and diagnostic output. * added Check(C/CXX)SourceRuns.cmake, CheckCXXCompilerFlag.cmake, Check * add static and shared flags to make sure the specified versions of libraries are used with -static -lfoo -shared -lbar * Search for the compiler only once and store a full path. avoids problems with PATH changes in cmake re-runs. * make sure manifest files are generated with VS 8 * added FindASPELL.cmake, FindBZip2.cmake FindHPELL.cmake, FindJasper.cmake FindLibXml2.cmake, FindLibXslt.cmake, FindOpenSSL.cmake * fix for bug#3646 GLUT not Glut for framework name * many fixes f
[Chicken-users] does adding numbers stop spam?
Making a wiki users add some numbers before they commit an edit was instituted as an anti-spam measure. Did it work? I ask because the CMake authors recently adopted a draconian restriction on their bug tracker, that only the reporter and the owner of a bug would be able to make changes to it. Pretty bad idea I think, so I'm wondering if the adding numbers trick solved the spam problem. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken on the PS3
On 7/24/07, Peter Keller <[EMAIL PROTECTED]> wrote: config.guess seems to screw that up a bit, but it didn't seem to affect the compilation and/or function of Chicken. Does the CMake build work? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] mingw_libdir bug
I'm trying to build Chicken 2.0 using MinGW 3.4.4 on Windows 2000. When
running ./configure on clean sources, the following nonsensical line
appears in the output:
checking for
d:/lang/MinGW/bin/../lib/gcc/mingw32/3.4.4/../../../../mingw32/bin/ld.exe/libws2_32.a...
no
unknown MinGW configuration
ld.exe is an executable, not a directory. It appears that the following
lines are setting mingw_libdir to garbage:
if test -n "${mingw_system}"; then
mingw_libdir=`mingw32-gcc -print-prog-name=ld | sed
's%/lib/gcc-lib/.*%/lib%'`
as_ac_File=`echo "ac_cv_file_${mingw_libdir}/libws2_32.a" | $as_tr_sh`
Ultimately this causes errors in posix.c because posixwin.scm is never
used. A workaround is to set mingw_libdir explicitly at this point in
the ./configure script. I"m not enough of an autoconf guru to know how
to ultimately solve this problem.
Also, per the README, I:
2) edited Makefile to set BOOTSTRAP_PATH = /d/devel/mingw/chicken-2.0
3) edited libtool, change 'deplibs_check_method' value to "pass_all"
4) mkdir $MINGWDIR/lib/.libs;
cp $MINGWDIR/lib/libws2_32.a $MINGWDIR/lib/.libs
where MINGWDIR is the where MinGW is installed
Now I get:
/d/devel/mingw/chicken-2.0/chicken posixwin.scm -quiet -debug-level 0
-optimize-level 2 -include-path . -output-file posix.c -explicit-use
/bin/sh: /d/devel/mingw/chicken-2.0/chicken: No such file or directory
make[1]: *** [posix.c] Error 127
make[1]: Leaving directory `/d/devel/mingw/chicken-2.0'
make: *** [all] Error 2
So, have the dependencies for the bootstrap become cyclic? It's 4:15
am, I'm too tired to figure this out anymore...
Cheers,
Brandon J. Van Every
(cruise (director (of SeaFunc)
'(Seattle Functional Programmers)))
http://groups.yahoo.com/group/SeaFunc
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] mingw_libdir bug
felix winkelmann wrote: Thanks, Brandon. Not being an autotools person myself I'm a little confused. A distaste for autotools I can wholly understand and sympathize with. But how then are you using the tools? Just in the simplest way? Or did the configuration script work get done a long time ago, and you've forgotten, or the person who did them has moved on? I'm just trying to understand if I dig into autotools myself, what's a rational way to proceed. and not having a mingw environment to test this I must pass. MinGW, although not the essence of convenience, is not terribly difficult to set up. Certainly, no more difficult than setting up Chicken. :-) Do you personally do any of the other Windows configurations, i.e. Cygwin and MSVC, or is someone else in charge of that? Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] mingw_libdir bug
[apologies if this is a repost. I'm not seeing it on my end.] felix winkelmann wrote: Thanks, Brandon. Not being an autotools person myself I'm a little confused. A distaste for autotools I can wholly understand and sympathize with. But how then are you using the tools? Just in the simplest way? Or did the configuration script work get done a long time ago, and you've forgotten, or the person who did them has moved on? I'm just trying to understand if I dig into autotools myself, what's a rational way to proceed. and not having a mingw environment to test this I must pass. MinGW, although not the essence of convenience, is not terribly difficult to set up. Certainly, no more difficult than setting up Chicken. :-) Do you personally do any of the other Windows configurations, i.e. Cygwin and MSVC, or is someone else in charge of that? Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] re: mingw_libdir bug
[apologies if this is a repost. I've tried to send this 2 times now and am still not seeing it. Black hole?] felix winkelmann wrote: Thanks, Brandon. Not being an autotools person myself I'm a little confused. A distaste for autotools I can wholly understand and sympathize with. But how then are you using the tools? Just in the simplest way? Or did the configuration script work get done a long time ago, and you've forgotten, or the person who did them has moved on? I'm just trying to understand if I dig into autotools myself, what's a rational way to proceed. and not having a mingw environment to test this I must pass. MinGW, although not the essence of convenience, is not terribly difficult to set up. Certainly, no more difficult than setting up Chicken. :-) Do you personally do any of the other Windows configurations, i.e. Cygwin and MSVC, or is someone else in charge of that? Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] mailing list trouble
Shawn Rutledge wrote: On 9/25/05, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: [apologies if this is a repost. I've tried to send this 2 times now and am still not seeing it. Black hole?] It appears that gmail doesn't show messages in your inbox which you sent to a list. I guess they figure it's enough that it's in your Sent Mail folder. Gmail has that behavior? FYI, I don't use Gmail via the web. I use SMTP and POP with Mozilla Thunderbird. You have to use SSL; otherwise it's very simple, smtp.gmail.com and pop.gmail.com. I don't think Google advertizes this capability. Anyways, I do not see the behavior you describe on [Mingw-users], or any other mailing list I'm subscribed to. So I am more inclined to think it's the [chicken-users] mailing list settings. I tried flipping some things on/off and we'll see if I can see this e-mail of mine. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] mailing list trouble
Zbigniew wrote: The web interface to gmail will show (in your inbox) your replies to a thread already in your inbox. Thus it was surprising that no messages would appear at all, since the first response to a thread you initiate will pull that thread into your inbox. Now it makes sense, if the web client isn't being used. I would guess that Mr. Van Every does not have "Receive your own posts to the list?" set to Yes in the chicken-users list options. But I did. For funzies, I set it to No, saved my options, then set it to Yes, and saved my options, hoping that "flipping the switch" might set it to the correct state. Here's a rundown of my current settings: Receive your own posts to the list? YES Receive acknowledgement mail when you send mail to the list? YES Avoid duplicate copies of messages? NO ** Things are still broken. I did not see my original "mailing list trouble" post, but I did get a confirmation that I had posted. I got your direct e-mail to me, but *not* a copy from the mailing list, which I should have. This leads me to believe that the Chicken mailing list software is ignoring 2 of my user settings? Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] mingw_libdir bug
felix winkelmann wrote: BTW, IMO why not use the free Windows tools? 'Cuz I have the licensed ones. :-) The real issue is that Eclipse does not support MSVC. My tentative toolchain is Eclipse 3.1 with the Schemeway plugin http://schemeway.sourceforge.net/ . If I were to go the MSVC route, I'd have to get the Eclipse MSVC plugin working http://cdt-msvc.tigris.org , and it is broken and abandoned. Complicating matters *further* is I may end up doing Alias Maya SDK C++ projects, and that will probably require MSVC. Complicating matters *further still* is my potential business partner says all the high end animation market is on Linux. So there are several routes, all with gruntwork attached to them. The reason Windows people would want MinGW rather than Cygwin is that the latter sticks you with the GPL anytime you use cygwin1.dll. Which in the real world, with all the deeply stacked open source libraries, is always. You can invoke -mno_cygwin to get rid of it, but then generally speaking the builds break, as noobdy is ever rigorously building anything with -mno_cygwin. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MinGW build
Patrick Brannan wrote: I'm trying to build chicken 2.2 with mingw and am having a small problem. It looks like it is trying to build posix.c and is having some difficulty. Should posix.c even be built on windows? Any suggestions would be appreciated. No it shouldn't be. This is the same bug as I have been referring to in my post about mingw_libdir. Prior to this error there was an error building tcp.c. Swapping the following two lines fixed that one. // # include #include Hm, well at least you've found a workaround for 1 error. It looks like I may have a configuration variable out of wack. The configuration is simply not working well for MinGW. Felix has said he's amenable to a better system. I'm not sure what that would mean exactly. A conservative approach would be to try the latest version of autoconf, autotools, and company, and see if that doesn't solve problems. A more bold approach would be to try some other configuration tool, but I don't know what's available. I'm imagining "works with a C compiler" is a requirement, as opposed to, say, a Python based tool? Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] vcbuild.bat not in list of distributed files
In Chicken 2.2: if the README section "2. Files distributed with CHICKEN:" is meant to be precise, I have noticed, vcbuild.bat is not listed. Perhaps it belongs just before the listing for win-install.bat. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] alternate build tools
felix winkelmann wrote: Originally the autotools integration is by Doug Quale, with additions by various people. I just learned enough to maintain the scripts (badly). I despise the whole stuff, but admittedly it works quite ok. If I were to start again, I'd not use it. I think that's the rational way to proceed. 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) Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ 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 suggested SCons, a Python thing. Also Ant + ant-contrib CC Task, a Java thing.] Further digging has yielded an option which, at first glance, looks better than either. CMake. http://www.cmake.org . CMake was borne out of frustration with the GNU Autoconf / Autotools toolchain. It is meant to replace it, and to be truly cross-platform rather than Unix-centric. It would introduce no new language dependencies, people would just need to download a CMake binary or else compile it themselves first. If CMake actually works as advertized, this is a slam dunk. SCons and Ant are good Make replacements, but IIUC, they don't perform automagical system configurations. Whereas, CMake was purpose built to replace autoconf / autotools. Anyone got CMake experience? "Visualization Toolkit" (VTK) uses CMake, and I did build it on Windows once. VTK is a huge piece of software for scientific visualization. I recall the build being uneventful and problem free, although I'm sure CMake can't take all the credit for that. BTW I still can't see my own posts, which is a bit annoying. I only see this behavior on this list. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] alternate build tools
Thomas Chust wrote: of the suggested system I have only tried ant so far and I instantly disliked it: It didn't run out of the box, although it is a Java program, it is a rather big package which makes it a heavy dependency and in my opinion it is very clumsy to handle, partly because of the xml format of the build control files. Of course that's only my personal opinion -- some Java programmers I know do like it. Apparently it integrates very nicely with Eclipse. I looked into Ant and CC Task mainly because I'll soon be doing an Alias Maya project with Eclipse. In the process I sorta forgot that these concerns are mostly irrelevant to Chicken. I mean, just because I'll be using Eclipse and Schemeway doesn't mean other people will be. Well I suppose if Ant was simple to use, and it worked, then nobody would complain. But I've been leery of it myself because it doesn't sound simple to use. Rather, it's politically correct if you're going to be working with the Eclipse developers. They'll pay attention to it, and likely won't be interested in SCons or CMake. For Chicken, I think CMake is the way to go. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] alternate build tools
Thomas Chust wrote: Am 30.09.2005, 17:29 Uhr, schrieb Brandon J. Van Every For Chicken, I think CMake is the way to go. as I need something to build my own projects as well from time to time, I threw a look at both CMake and SCons and I think both have all the necessary and convenient features... 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. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] alternate build tools
Tony Garnock-Jones wrote: Ashley Bone wrote: 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. The crucial question is going to be libtool-type support. How well do any of these tools cope with building different styles of shared library/DLL? CMake has built some pretty huge software systems like the Visualization Toolkit http://www.vtk.org/ so I don't see this as a big deal. I'm more worried about the quality of the MinGW support. I heard "somewhere in passing" that CMake can handle MinGW now, but the CMake webpage and the docs still don't explicitly mention it. So that makes me worry that it's not a well-exercised target (gee, much like Chicken and so many other open source projects.) Still, I cannot worry unduly. I've already made the decision that I will attempt CMake. But, I have to go get a job or get tossed out of my apartment, so I can't put much effort into this right now. If it's easy, then suddenly I'll say Hey Presto. If it's hard, either because of CMake or the Chicken architecture itself, then I probably won't get it done. Like, if I had to bang on something for a month to get it to work, I wouldn't bother. I'd just concentrate on other projects of mine that are easier to make progress on. If anyone wants to team up with me to try to bang out a CMake, that would be welcome. More likely to stay focused that way. In any event, realistically it's gonna be CMake or SCons. I doubt anyone believes that Ant ant-contrib CC Task is going to be pleasant. The only reason I brought it up is because I'm doing Eclipse stuff. Anyways, if the SCons crowd wants to get together and bang something out, and it's easy to do, then by all means go for it. But that's not the road I will travel for now. I believe CMake is the ticket, as it's meant to replace GNU Autotools and be cross-platform. It doesn't add a language dependency, so if all else is equal between CMake and SCons, that's a win. It's all going to be about actually attempting a build, since it seems none of us really have the experience at these tools to know what they can handle. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] alternate build tools
Thomas Chust wrote: Am 03.10.2005, 15:47 Uhr, schrieb Patrick Brannan <[EMAIL PROTECTED]>: [...] 1. Note that I had to name the exe chicken_d. I could easily rename it in a later step, but the point is that CMake doesn't seem to easily support custom file names. Files will be named for the target plus the appropriate extension. 2. Setting source file properties is a global operation where the last set wins. So I haven't found an easy way to combine both static and dynamic linking. I even tried listing the source files twice and setting properties differently on each listing. The file sets seem to be global entities that can accept only one set of properties. [...] However promising CMake looked to me, this doesn't sound like a terribly well designed core of the system... Aren't you being rather premature in your pronouncement? There's probably some way to do it, it probably just requires different output directories or something. It takes time to RTFM. I think you're not paying enough attention to a more basic point: Thomas got this thing actually working with ease in a weekend. That's highly encouraging. If debug versions really do have to be called *_d, so what? If it's otherwise an easy, reliable, high quality build system, that's a good tradeoff. Nothing in open source is perfect. Chicken is *hardly* perfect on Windows off-the-shelf. Does that mean I run around giving up on stuff, saying it's a "not terribly well designed core system?" In the worst case, if we want it to be perfect, we submit a patch to the CMake authors. It's open source after all. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] syntax-case Egg license
The syntax-case Egg available at http://www.call-with-current-continuation.org/eggs/index.html#lang-exts says its license is "Unknown." However, the web entry http://www.call-with-current-continuation.org/eggs/syntax-case.html has an essentially MIT license at the bottom of it. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake testing
I will give cmake a shot on VC++ and MinGW, but for the next 2 weeks I'm crazy busy with a short-term job. Things will return to sanity after November 8th. Graham Fawcett wrote: Running `cmake -G "NMake Makefiles"` didn't Just Work. I used cmakesetup.exe, which is a GUI for writing a configuration cache. Before running this, I had to add the MSVC toolchain to my PATH. I don't normally have them on PATH; and without them, cmakesetup wouldn't work properly. IOW, you cannot just run cmakesetup from the Start..Programs menu unless you have your tools on the PATH. In Windows-land, generally the programmer has to take responsibility for running vcvars32.bat to get the command line path, include, and lib variables set up correctly. No harm in reminding the Windows programmer of this in a README, however. Note that `cmake -G "NMake Makefiles"` did not work even when my tools were on the path. How about after running vcvars32.bat? Testing the built binaries: csi and csc worked fine. Chicken_setup worked, but this is MSVC-land, and the lack of gzip et. al. means that chicken_setup usually fails to build anything. (These GNU-toolchain dependencies are something I would *love* to see fixed for the MSVC platform, if I had my two cents, or enough time to tackle it!). Do you mean a gzip.exe or a gzip library? The former is available with a bit of hunting around, for instance http://gnuwin32.sourceforge.net/ The latter, I'm fuzzy about. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake testing
Graham Fawcett wrote: Running `cmake -G "NMake Makefiles"` didn't Just Work. I used cmakesetup.exe, which is a GUI for writing a configuration cache. Before running this, I had to add the MSVC toolchain to my PATH. I don't normally have them on PATH; and without them, cmakesetup wouldn't work properly. IOW, you cannot just run cmakesetup from the Start..Programs menu unless you have your tools on the PATH. Note that `cmake -G "NMake Makefiles"` did not work even when my tools were on the path. I used the Chicken 2.2 tarball as a guinea pig, just adding CMakeLists.txt to it and no other actions. When I use my fully licensed retail version of VC++ 7.1, 'cmake -G "NMake Makefiles"' generates its output without a hitch. When I use the free VC++ Toolkit, I get a bunch of errors. So, the problem is surely that the retail compiler has all sorts of tools and paths configured properly, and the free version doesn't. Probably there is more work to get a valid build environment going with the free version. I did run the appropriate vcvars32.bat with the free version, but that isn't enough to solve the problem. I bet I don't have the Platform SDK set up properly to work with the free version; for instance, I don't see any includes or paths for it in the envioronment. Also beware of the 'csi' shadowing gotcha, as the Platform SDK has its own csi.exe apparently. After that, cmakesetup ran fine. I had to specify EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH; I also built the binaries in the source directory. Trying to specify a different output directory seemed to cause problems; it looked like the cache was written to the build directory rather than the source directory when I tried this. I haven't tried this yet. I haven't gone up the learning curve of cmake's theory of operation. Sorry I'm just way too tired from the physically demanding work of signature gathering. Yes I am lame. I'm only good at getting people interested in better build systems. :-) I'll make more stabs as time and energy allow. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake testing
Patrick Brannan wrote: If you have the free c++ environment set up as described in vctk-install.txt then you should be able to run CMake after generating a command prompt with the batch file above. Of course if you don't have things where they are expected things will probably not work too well. Once I installed the Platform SDK, I was able to do 'cmake -G "NMake Makefiles"' without problem. However, I did have to delete the cmakecache.txt from an old run, from when things weren't working. This is a minor gotcha that may be worth noting in the instructions. Otherwise you can get errors about various tools missing their paths and etc. I have never run cmakesetup.exe, it does not appear to be necessary for anything so far. I have yet to actually try to build Chicken from the generated makefiles. Still busy with signature gathering, but it was drizzling today so I took a stab at Chicken problems. So in summary: if you have VC++ 7.1 full licensed version correctly installed, *or* if you have the VC++ Toolkit and the Platform SDK correctly installed, then cmake should generate makefiles without problem. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake testing
felix winkelmann wrote: On 10/22/05, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: I used the Chicken 2.2 tarball as a guinea pig, just adding CMakeLists.txt to it and no other actions. When I use my fully licensed retail version of VC++ 7.1, 'cmake -G "NMake Makefiles"' generates its output without a hitch. When I use the free VC++ Toolkit, I get a bunch of errors. So, the problem is surely that the retail compiler has all sorts of tools and paths configured properly, and the free version doesn't. Probably there is more work to get a valid build environment going with the free version. I did run the appropriate vcvars32.bat with the free version, but that isn't enough to solve the problem. I bet I don't have the Platform SDK set up properly to work with the free version; for instance, I don't see any includes or paths for it in the envioronment. Also beware of the 'csi' shadowing gotcha, as the Platform SDK has its own csi.exe apparently. Very good. Thanks, Brandon! Do you have the full Platform SDK, or just the core part installed? I downloaded the Full SDK and did a Custom install. The only thing I customized is I had the SDK register its environment variables. Now when I type 'nmake -f Makefile', both the Retail and the Toolkit version die looking for libchicken.lib. Building RC object CMakeFiles/chicken_exe.dir/chicken.res Linking C executable chicken.exe LINK : fatal error LNK1104: cannot open file 'libchicken.lib' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio .NET 2003\ VC7\BIN\nmake.exe"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio .NET 2003\ VC7\BIN\nmake.exe"' : return code '0x2' Stop. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake testing
Regarding my missing libchicken.lib: there is perhaps nothing amiss in cmake. I tried 'nmake chicken_lib' and it doesn't build because of tcp.c errors. If the tarballs can be updated with people's patches, so that they build on Windows, that would be nice. I have downloaded the Darcs repository but I have yet to figure out how to bootstrap it. I ran into problems with my MinGW environment; maybe I'll have better luck with a VC++ bootstrap. I am wondering if the CMakeLists.txt is really set up for a Darcs bootstrap? I'm thinking it isn't; I wonder if it's within the scope of what CMake could do. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake testing
felix winkelmann wrote: Regarding the tcp problems: change the #include's for winsock2.h to ws2tcpip.h. That should fix the build problems. Now I get a bazillion errors for things undefined in WS2tcpip.h itself. I think it is easier to wait for the tarballs to be patched, or to attempt a bootstrap. Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Bootstrapping VC++
How do I bootstrap using VC++? I've built the Chicken 2.0 tarball using the full retail version of VC++ 7.1. The toolkit version failed for some reason. I'm not using Chicken 2.2 because it doesn't build with VC++. Updates of the tarballs so that it builds with VC++ would be welcome. I've got the darcs repository, but README.darcs says nothing about how one would bootstrap with VC++. Also I am unclear on how vcbuild.bat and makefile.vc are generated. Are they just done by manual labor? Cheers, Brandon J. Van Every (cruise (director (of SeaFunc) '(Seattle Functional Programmers))) http://groups.yahoo.com/group/SeaFunc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] sharp-sign read syntax ruins bootstrap?
I've built the Chicken 2.0 tarball using VC++ full retail. I'm trying to build the Chicken Darcs repository with MinGW, using Chicken 2.0 as the bootstrap. I get the following error: /d/devel/msvc/chicken20boot/chicken lolevel.scm -quiet -no-trace -optimize-level 2 -include-path . -output-file lolevel.c -explicit-use Error: invalid sharp-sign read syntax in line 268: #\+ make[1]: *** [lolevel.c] Error 70 make[1]: Leaving directory `/d/devel/mingw/chicken' make: *** [all] Error 2 README.darcs says that any Chicken tarball 1.92 or greater should be sufficient for a bootstrap. Is this not true in practice anymore? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] mingw bootstrap posix.c errors
Ok, I've built Chicken 2.2 tarball with Cygwin. I tried to use this to do the Chicken darcs bootstrap using MinGW. Many many errors in posix.c and uposix.c, although everything else seems to build ok. I am thinking that a MinGW build should be trying to build posixwin.c, not posix.c. Didn't someone already submit a patch for this? Or is this a known and less-than-trivial problem in the darcs repository? Or, is this a subtlety of attempting a Cygwin --> MinGW boot? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] sharp-sign read syntax ruins bootstrap?
felix winkelmann wrote: On 11/1/05, Brandon J. Van Every <[EMAIL PROTECTED]> wrote: README.darcs says that any Chicken tarball 1.92 or greater should be sufficient for a bootstrap. Is this not true in practice anymore? Indeed - you'll need a newer version of Chicken. I'll upload a new tarball tonight, I promise! What time zone are you in? :-) As I write this, it's 4 am Wednesday Nov. 2nd in Seattle. I don't see any new tarball on the Chicken homepage. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] 2.207 tarball doesn't build on MinGW or VC++
Felix, thanks for the new tarball. I've tried it out on several permutations of MinGW, VC++, ./configure, and cmake, using clean source trees in all cases. The summary is, neither compiler builds correctly. I notice that the ChangeLog only goes through Sept. 24th. Perhaps it is not a priority for a tarball. However, if ChangeLogs are generated by a script, then perhaps it is an error, so I mention it. I notice that README.darcs is not present in the tarball. Is that because it's being revised? If it's to keep people from getting confused, then I think it would be better to include it. For instance, the main reason I need a newer tarball is to bootstrap from darcs. In my VC++ full retail environment, vcbuild.bat has many type errors in pip.h. This is related somehow to WS2tcpip.h. In my MinGW environment, ./configure still does the following odd path: checking for d:/lang/MinGW/bin/../lib/gcc/mingw32/3.4.4/../../../../mingw32/bin/ld.exe/libws2_32.a... no As a directory, ld.exe is weird. Previously I've reported this as likely a sed problem, but I didn't provide a patch. It probably causes problems later in the build. The build dies in posix.c with many errors; looks like it's not building posixwin.c as it should. I notice that CMakeLists.txt is not present in the tarball. I've tried adding it from the latest darcs and running cmake as per below. In my MinGW environment, when I do 'cmake -G "Unix Makefiles"', makefiles are generated without error. However, 'make' dies looking for -llibchicken. It seems the dependency to build libchicken is broken. I can issue 'make chicken_lib', and this looks like it may almost be working, but then it dies. 'nologo' could be some kind of a sed error; maybe it's cmake's fault. gcc.exe: d:/app/msys/1.0/nologo: No such file or directory gcc.exe: /implib:libchicken.lib: No such file or directory gcc.exe: d:/app/msys/1.0/dll: No such file or directory make[3]: *** [libchicken_lib.dll] Error 1 In my VC++ retail environment, If I do 'cmake -G "NMake Makefiles"',, makefiles are generated without error. However, 'nmake' dies looking for libchicken.lib. As before, the dependency to build libchicken is broken. I can issue 'make chicken_lib', but this dies with many undefined types in pip.h. It seems to be related to WS2tcpip.h. I have no solutions at this time. Must go gather signatures; shoulda done so already. Consider all of this a field report and food for thought. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
