Re: [Chicken-users] Fix for bug in url egg
I realized there was a separate bug that also affected url-encode (though the other bug was in uri-encode, this one is in url-encode instead). I fixed it, creating revision 4014. Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Fix for bug in url egg
Hey, Kon. I just made a fix for a simple bug I found in the url egg that made url-encode unusable when CHARLIST is specified. This resulted in revision 4013. Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] scheme, builds, and virtual appliances
Brandon Van Every scripsit: > 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 not what VMWare is about. The VMWare Player (which can be installed on Linux or Windows, and is free as in beer) allows you to execute a foreign operating system concurrently with the host one. Thus one can run Windows on Linux or vice versa, or Windows XP on Windows 2000, or FreeBSD on Windows or Linux, etc. etc. etc. The disk and memory of the guest OS are represented on the host by a set of files which can be copied from one host to another by CD or DVD or FTP or whatever. So instead of porting a Linux program to Windows, one can provide a stripped down version of Linux including the program as a VMWare image, and then anybody can run it from Windows using the VMWare Player. Guests can run in a window of the host or using the full screen. In principle, you could do this the other way about, distributing Windows guests, except that most people don't have Windows licenses to distribute in this fashion, as you need a separate Windows license for every guest copy of Windows. -- They do not preach John Cowan that their God will rouse them[EMAIL PROTECTED] A little before the nuts work loose.http://www.ccil.org/~cowan They do not teach that His Pity allows them --Rudyard Kipling, to drop their job when they damn-well choose. "The Sons of Martha" ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake build
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? -- John Cowan[EMAIL PROTECTED]http://ccil.org/~cowan The present impossibility of giving a scientific explanation is no proof that there is no scientific explanation. The unexplained is not to be identified with the unexplainable, and the strange and extraordinary nature of a fact is not a justification for attributing it to powers above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913) ___ 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
[Chicken-users] Define-external error
Hi, I don't know if this is a Ramsay, a Chicken, an easyFF, or a GTK error, but I get the following when I use g_signal_connect, which is supposed to call back to Scheme when a button is pressed. The command (g_signal_connect button "color-set" #$setColor 1) Should call back to: (define-external (setColor ((pointer "GtkColorButton") widget) (c-pointer data)) void (printf "got data = ~A~%" data) ) But it gives me a type error: Error: (location) bad argument type - locative can not refer to objects of this type: # If I change the pointer to "GtkWidget" I get the same error. I use this exact same mechanism in other calls and everything works fine.When I do it with a GtkColorButton or a GtkFontButton I get this error.Both buttons are defined as class GtkWidget, the same at the buttons that work. I'm sort of lost, so any help will be greatly appreciated. Bill ___ 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] 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] build irritations on windows xp
okay well, I started building with msys, had some problems with CMAKE at first, when building got to the following part: Linking C static library libchicken-boot.a [ 62%] Built target libchicken-boot Scanning dependencies of target libpcre-for-static [ 66%] Building C object pcre/CMakeFiles/libpcre-for-static.dir/chartables.obj [ 66%] Building C object pcre/CMakeFiles/libpcre-for-static.dir/pcre_compile.obj c:/programminglanguages/scheme/chicken-2.6/pcre/pcre_compile.c: In function `compile_branch': c:/programminglanguages/scheme/chicken-2.6/pcre/pcre_compile.c:3263: `MAX_DUPLENGTH' undeclared (first use in this function) c:/programminglanguages/scheme/chicken-2.6/pcre/pcre_compile.c:3263: (Each undeclared identifier is reported only once c:/programminglanguages/scheme/chicken-2.6/pcre/pcre_compile.c:3263: for each function it appears in.) c:/programminglanguages/scheme/chicken-2.6/pcre/pcre_compile.c:3869: `MAX_NAME_COUNT' undeclared (first use in this function) c:/programminglanguages/scheme/chicken-2.6/pcre/pcre_compile.c:3877: `MAX_NAME_SIZE' undeclared (first use in this function) make[2]: *** [pcre/CMakeFiles/libpcre-for-static.dir/pcre_compile.obj] Error 1 make[1]: *** [pcre/CMakeFiles/libpcre-for-static.dir/all] Error 2 make: *** [all] Error 2 Any explanation? Wrong PCRE? Cheers, Bryan Rasmussen On 4/24/07, felix winkelmann <[EMAIL PROTECTED]> wrote: On 4/22/07, bryan rasmussen <[EMAIL PROTECTED]> wrote: > Hey, > > I recently had to do some cleaning on my system, I am sitting here > with some time for some programming and trying to get Chicken running > again. Not going good for recompiling. Get half of the way in any > compile but get thrown by PCRE, this is the case using MSys, MingGW, > and Open Watcom. From OpenWatcom the error report starts with: > >[...] > > any help on these? > Sergey Khorev started trying to get chicken with Open Watcom to work, but it turned out to be pretty hard. We had some issues fixed, but there still were loads of problems with dynamic linking (IIRC). So consider Open Watcom currently unsupported. > by the way, didn't there used to be a Windows binary on the front page > of the Chicken Scheme site? > Yes, but we removed it - since the installation path is compiled into the executables, one has to build chicken from source. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] easyffi missing foreign-parse
Mark Carter scripsit: > Hi, I'm a n00b to scheme, and I thought I'd check out Chicken. I tried > to get the readline egg installed, which is dependent on easyffi. I > installed the easyffi egg, but if I type > foreign-parse > I get the response > Error: unbound variable: foreign-parse That's because foreign-parse is not a procedure but a new element of syntax, like "if" or "do" or "lambda". It is only recognized when in the operator position of a form. In general, it makes no sense to use easyffi in the interpreter; it is meant to extend Chicken's ability to handle embedded C, which is only available in the compiler. In addition, nobody uses "foreign-parse" directly anyhow; it is normally invoked through the #>...<# read-syntax for embedded C. The only reason that the readline egg depends on the easyffi egg is that the readline egg makes use of this read-syntax to parse the C header for getline. -- We are lost, lost. No name, no business, no Precious, nothing. Only empty. Only hungry: yes, we are hungry. A few little fishes, nassty bony little fishes, for a poor creature, and they say death. So wise they are; so just, so very just. --Gollum[EMAIL PROTECTED] http://ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] easyffi missing foreign-parse
Hi, I'm a n00b to scheme, and I thought I'd check out Chicken. I tried to get the readline egg installed, which is dependent on easyffi. I installed the easyffi egg, but if I type foreign-parse I get the response Error: unbound variable: foreign-parse All the other easyffi procedures seem to exist, as evidenced by the following transcript: #;3> register-ffi-macro # #;4> check-c-syntax # #;5> foreign-parse Error: unbound variable: foreign-parse #;5> Error: unbound variable: foreign-parse So, what gives? ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
