Re: How to get help on commands
The mode arguments are documented http://wiki.call-cc.org/man/5/Module%20scheme#ports -elf On 24 August 2023 19:55:35 GMT+03:00, Lewis Levin wrote: >After installing r7rs, ‘open-output-port’ is a more complete implementation >with this signature: > >open-output-file name . mode > > >I need documentation for what is allowed in mode. There is no functions >documentation anywhere for Chicken. I don’t think is satisfactory to say >“Chicken is standard” as there is no standard. A function may or may not be >provided. The function if provided may or may not work as it does in any >other scheme. Keyword arguments may or may not exist. Each implementation may >allow different optional arguments.
Re: Botan bindings
Thanks! I'll try to look into it and run some tests and speed comparisons in about a week. (Lots of weddings right now, so it's unlikely i can do anything earlier than that.) Have you made bindings for all the hashes and block ciphers? -elf On 11 June 2023 02:59:23 GMT+03:00, Thomas Chust wrote: >Hello, > >Botan [1] is a pretty nice cryptographic library that I use from time to >time. Its documentation page on language bindings mentions that a CHICKEN >binding is "wanted", so I thought: Why not ☺ > >You can find the code for the new egg here: > > https://chust.org/repos/chicken-botan > >Documentation is still minimal, but one can easily refer to the Botan >documentation itself. Before adding the egg to the coop, I would like to >write more tests and give you all a chance to play with the code. > >So feedback is welcome! > >Ciao, >Thomas C. >
Re: Need GUI (again), gauging interest in an alternative approach.
Perhaps something more like wx would be better? Excellent cross-platform support, including all necessary support structures, and iirc it can give you lower-level graphics access too? Plus, of course, there are already bindings for a large num of languages, and a guide to writing new bindings, so... -elf On 23 March 2023 13:43:10 GMT+02:00, Matt Welland wrote: >Tk is great, no doubt about it. I still miss Eric Gallesio's STk. The >reasons I decided against tk include: > > 1. Clunky 1980's look and feel. (i) > 2. No IOS or Android support. (ii) > 3. I seemed to fight the widget layout model a lot when I used it. (iii) > 4. Two of the projects I'm starting are more game than normal app, > including plans to have a VR view. > >(i) has been addressed with the latest tk, including themes apparently. >(ii) it does appear possible to use tk on android but there is no touch >support as best I can tell. >(iii) Godot seems somewhat similar to IUP with hboxes, vboxes etc. >hopefully easier for me to learn. > >#2 is a big concern but #4 is the deciding factor. I really need something >that works and where I can reuse what I learn in many projects. I'd >strongly prefer to use 100% Chicken but I also need to get things done and >if I have to learn and use gd script for some of my projects I'll deal with >it. I am also starting to see the value of a well done gui designer. > >What I want is a button in Godot that switches out gd script for Chicken >Scheme. That would be an awesome tool! I'll settle for doing the >communications, logic and other heavy lifting in a Chicken program and bolt >on Godot for the user interface (via tcp for now). > >Just my $0.02 > >On Wed, Mar 22, 2023 at 11:37 PM elf wrote: > >> Erm, what's wrong with the tk bindings, which should work everywhere >> already? >> >> -elf >> >> On 23 March 2023 02:36:43 GMT+02:00, Matt Welland >> wrote: >> >That would be great Thomas. For my part, I'll start working on my project >> >using what I can, learning Godot along the way. When you get to working on >> >this please let me know how I can help. >> > >> >Regarding the approach, I like the tooling to generate a loadable module >> >idea. I figure leverage as much of Godot as a tool as possible. >> > >> >Thanks. >> > >> >On Wed, Mar 22, 2023 at 12:27 PM Thomas Chust >> >wrote: >> > >> >> Hello, >> >> >> >> a combination of CHICKEN and Godot sounds very interesting! I've been >> >> meaning to experiment more with that engine for a while, and with Godot >> 4.0 >> >> just out the door the time is probably perfect to try out the new >> extension >> >> APIs. >> >> >> >> I'm not completely sure how the CHICKEN/Godot hybrid should look like >> and >> >> suspect that embedding Godot in a CHICKEN egg would at least be >> cumbersome. >> >> Maybe some kind of tooling to streamline the task of rolling CHICKEN >> code >> >> into a single loadable module for Godot to use would be most promising >> 樂 >> >> >> >> I think I've just found a project for the upcoming CHICKEN summer >> workshop >> >> >> >> >> >> Ciao, >> >> Thomas C. >> >> >> >> >> >> Am Mi., 22. März 2023 um 15:28 Uhr schrieb Matt Welland < >> >> mattrwell...@gmail.com>: >> >> >> >>> I've been using IUP with Chicken for years. I really enjoy using it >> >>> (thanks Thomas!). But, here we are, over 10 years later and IUP is >> still >> >>> not available as an official Debian package and it is a burden to >> deploy. >> >>> It is also still not supported on Mac. >> >>> >> >>> So, I'm scouting around (again) for alternatives and I'm starting to >> lean >> >>> towards using Godot for my next project. Godot + Chicken scheme that >> is. >> >>> I'm hoping that I can deploy to mac, Linux and Windows and maybe even >> >>> android without too much pain. >> >>> >> >>> Here is an article that makes the case for using Godot for graphical >> user >> >>> interfaces: >> >>> >> >>> >> >>> >> https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b >> >>> >> >>> I can achieve what I need with any one of three approaches: >> >>> >> >>> 1. Godot <==> chicke
Re: Need GUI (again), gauging interest in an alternative approach.
Erm, what's wrong with the tk bindings, which should work everywhere already? -elf On 23 March 2023 02:36:43 GMT+02:00, Matt Welland wrote: >That would be great Thomas. For my part, I'll start working on my project >using what I can, learning Godot along the way. When you get to working on >this please let me know how I can help. > >Regarding the approach, I like the tooling to generate a loadable module >idea. I figure leverage as much of Godot as a tool as possible. > >Thanks. > >On Wed, Mar 22, 2023 at 12:27 PM Thomas Chust >wrote: > >> Hello, >> >> a combination of CHICKEN and Godot sounds very interesting! I've been >> meaning to experiment more with that engine for a while, and with Godot 4.0 >> just out the door the time is probably perfect to try out the new extension >> APIs. >> >> I'm not completely sure how the CHICKEN/Godot hybrid should look like and >> suspect that embedding Godot in a CHICKEN egg would at least be cumbersome. >> Maybe some kind of tooling to streamline the task of rolling CHICKEN code >> into a single loadable module for Godot to use would be most promising 樂 >> >> I think I've just found a project for the upcoming CHICKEN summer workshop >> >> >> Ciao, >> Thomas C. >> >> >> Am Mi., 22. März 2023 um 15:28 Uhr schrieb Matt Welland < >> mattrwell...@gmail.com>: >> >>> I've been using IUP with Chicken for years. I really enjoy using it >>> (thanks Thomas!). But, here we are, over 10 years later and IUP is still >>> not available as an official Debian package and it is a burden to deploy. >>> It is also still not supported on Mac. >>> >>> So, I'm scouting around (again) for alternatives and I'm starting to lean >>> towards using Godot for my next project. Godot + Chicken scheme that is. >>> I'm hoping that I can deploy to mac, Linux and Windows and maybe even >>> android without too much pain. >>> >>> Here is an article that makes the case for using Godot for graphical user >>> interfaces: >>> >>> >>> https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b >>> >>> I can achieve what I need with any one of three approaches: >>> >>> 1. Godot <==> chicken executable, where the connection could be tcp, http >>> or similar. >>> >>> 2. Godot <==> chicken .so file >>> >>> 3. Chicken <==> godot egg >>> >>> I don't have time or expertise to do an egg without help. Before I start >>> working using option 1 or 2 I wanted to ask the chicken community if there >>> was interest in collaborating on creating a godot egg. >>> >>> Thanks! >>> >>> NOTE: If hypergiant had a widget library with a decent text widget (line >>> wrapping, copy/paste to the OS etc.) I'd have considered it. Raylib was >>> also interesting and it's text support might have been adequate but the egg >>> was never published and seems abandoned. >>> >>> >>> -- >>> Complexity is your enemy. Any fool can make something complicated. >>> It is hard to keep things simple. - Richard Branson. >>> >> >
Re: Partial automation of egg dependencies
It's ambiguous. There can be (and are) eggs that export procedures of the same name. Dependencies shouldn't get out of sync, and updated versions may change what is exported... so I would question exactly what you are doing that would require such functionality and whether there would be a better development methodology that wouldn't shift the burden from paying attention to what one is using to a psychic programme that does what you mean (not what you tell it). -elf On 20 November 2022 20:55:09 GMT+02:00, Lassi Kortela wrote: >I have a .egg file for a portable Scheme program substantial enough and >fast-moving enough that the dependencies are constantly getting out of sync. > >Would it be possible to add a feature something like this? > >(extension foo.bar > (source "bar.sld") > (auto-dependencies) ; <-- The new feature. > (csc-options "-R" "r7rs" "-X" "r7rs")) > >auto-dependencies would compute the deps by traversing the given source file. >It would look at csc-options and notice that r7rs is being used. Then expect >an R7RS-style define-library form in bar.sld, look at (import ...) libraries >matching those in the .egg and add those to component-dependencies, as well as >traverse all (include "...") and add those to (source-dependencies ...). > >If csc-options doesn't say r7rs, it would do the same, but expect Chicken >module syntax instead. > >I wrote some code to grovel r7rs libraries, and there's probably similar stuff >in csm and Akku.scm too. So if the feature is ok we could stitch together the >implementation from these. >
Re: Request for feedback: Chicken as a self-contained AppImage
Hi! I love the idea, but a few questions: 1) How does this handle egg installation/updates? 2) Do both the compiler and interpreter work? 3) How do binaries built with csc work, in terms of linking and including? 4) How do eggs handle finding external dependencies? All of these should make it (painfully) obvious that I don't know anything about AppImage, so if you can explain in more detail or send links to clarify, it would be most appreciated. Thanks! -elf From: Daniel Ziltener To: chicken-users@nongnu.org Date: 28 Sep 2022 22:37:59 Subject: Request for feedback: Chicken as a self-contained AppImage > Hello Chickeners! > > I had a "why not?" idea recently. I'm maintaining the RPM packages for > Chicken, and I thought "why not pack Chicken into an AppImage?" - and that's > what I did! > > For those who don't know AppImages: they are single-file volumes (think ISO > or DMG) but executable, and they work, without any further requirements apart > from FUSE (to mount the embedded SquashFS), on every Linux distribution. You > download an AppImage, rename it if you want, make it executable, and it's > ready for use. (if you have AppImageUpdate installed, you can even > automatically check for and get updates). > > So in this case, I packed a little script into the AppImage, since Chicken > has a whole bunch of executables. The AppImage is being built on OpenSUSE's > OBS service, and a download page is on https://www.appimagehub.com/p/1911578/ > , where you'll also find further description on how to use it. > > Try it out if you like, and let me know about your thoughts, bugs to fix, or > improvements to make. A bit later I will link it on the installation page of > the Chicken wiki. > > Best regards, > Daniel signature.asc Description: PGP signature
Re: [Chicken-users] Is Android not unix?
I had no problem compiling chicken in termux (though occasionally there are linkage warnings on android6). My understanding is that android is basically stripped down linux with a java overlord layer. No compatibility layer necessary. This is borne out by my current work on cross-system randomness - it behaves exactly like a linux machine, with the same syscalls, etc. (Which reminds me. If anyone has a bsd box i can get a login for, it would be much appreciated. Im trying to do a chicken wrapper for true randomness using sidechannel effects... so something that looks platform independent.) -elf On 26 November 2018 5:15:03 GMT+02:00, Matt Welland wrote: >Isn't Termux similar to UserLand - a compatibility layer of sorts >similar to LXC or LXD? If so, I would not be surprised to see >incompatibilities. I had to do several hacks to get IUP working on >UserLand. > >On Mon, 2018-11-19 at 13:10 +0100, Thomas Chust wrote: >> On Mon, 19 Nov 2018 13:19:10 +0300 Kristian Lein-Mathisen > i...@gmail.com> wrote: >> >> > >> > [...] >> > I was trying tweetnacl on Termux on Android 9 and ran into this >> > problem: >> > >> > u0_a191@localhost ~/p/chicken-5.0.0> >> > csi -R tweetnacl -p '(make-symmetric-sign-key)' >> > >> > Error: (read-u8vector) bad argument type - not a port: #f >> > >> > >> > This happens because tweetnacl creates its current-entropy-port >> > using >> > cond-expand with unix, windows or else, the latter which is >> > yielding the #f >> > error above. >> > [...] >> Hello, >> >> interesting, I would have thought that Android would qualify as a >> unixoid system since it has a Linux kernel! If there is some other >> feature identifier I should use that would indicate the system likely >> supports /dev/random, please let me know so I can adapt the tweetnacl >> code. >> >> Anyway, as a workaround to get tweetnacl running, you can simply do >> >> (current-entropy-port (open-input-file "/dev/random")) >> >> by hand. >> >> I hope that helps :-) >> >> Ciao, >> Thomas >> >> >> ___ >> Chicken-users mailing list >> Chicken-users@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/chicken-users > >___ >Chicken-users mailing list >Chicken-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] redefining cons,car,cdr in SICP
On Sat, 4 Dec 2010, Leonardo Valeri Manera wrote: 2010/12/4 Jim Ursetto zbignie...@gmail.com: On Dec 3, 2010, at 11:57, Hans Nowak zephyrfal...@gmail.com wrote: Chicken's internals (entrails?) That's the spirit! Are chicken developers witch-doctors, then? :) The ones who mash the bugs with plants and apply them to cuts are which doctors? The ones who read entrails are clearly haruspex. (That would be a great name for a debugging egg.) -elf who goes 'poof' and reappears on the list ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Announcing call-cc.org
Should the chicken*scheme.* sites be updated to point to call-cc then? -elf On Sat, 7 Aug 2010, Mario Domenech Goulart wrote: Hi We have a new server for the CHICKEN infrastructure: http://www.call-cc.org www.call-with-current-continuation.org is still the official CHICKEN home site. call-cc.org is the official infrastructure services site. Here's a quick summary about what call-cc.org has to offer: * http://www.call-cc.org: The main page for the CHICKEN project (same page as www.call-with-current-continuation.org, but a shorter URI) * http://bugs.call-cc.org: The CHICKEN bug and feature tracking system. * http://chickadee.call-cc.org: API (CHICKEN core + eggs) browser and search engine. See http://wiki.call-cc.org/egg/chickadee * http://code.call-cc.org: VCS repositories for CHICKEN and eggs code and release tarballs. * http://wiki.call-cc.org: The CHICKEN wiki * http://tests.call-cc.org: Results for daily eggs tests executed by salmonella (http://wiki.call-cc.org/egg/salmonella) chicken.wiki.br is still available, but deprecated (it points to wiki.call-cc.org via DNS). Use wiki.call-cc.org for the CHICKEN wiki and code.call-cc.org for the CHICKEN source repositories. See http://wiki.call-cc.org/infrastructure-migration for information about how to adapt your copy of the repositories to the new adresses. We are now using qwiki (http://wiki.call-cc.org/egg/qwiki) for the CHICKEN wiki. Qwiki is a lightweight svnwiki-compatible wiki implementation which runs on top of Spiffy for CHICKEN 4. The automatic publishing of eggs for CHICKEN 3 has been disabled. You can still use chicken-setup to install CHICKEN 3 eggs, but the publishing of new eggs and eggs updates is no longer automatic. If you need to publish something for CHICKEN 3, contact me. I'd like to thank the infrastructure team (Felix Winkelmann, Ivan Raikov, Jim Ursetto, Moritz Heidkamp and Peter Bex -- see http://wiki.call-cc.org/maintainers) for all the (amazing!) hard work, as well as the folks on freenode's #chicken for all the suggestions, tests and collaborative and fun work. I'd also like to thank Alejandro Cuervo for svnwiki, which served us pretty nicely for years. Best wishes. Mario ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Happy 10th birthday!
On Tue, 20 Jul 2010, Mario Domenech Goulart wrote: Hey July 20th, 2010, marks the 10 year anniversary of the CHICKEN announcement message Felix wrote to c.l.s: http://groups.google.com/group/comp.lang.scheme/msg/edfb2da16fd89fae Thanks to all the contributors for making CHICKEN such a nice project! Best wishes. Mario Minus fourscore and threescore ten years ago, our Felix brought forth a new implementation, concieved in poultry, and dedicated to the proposition that all CONS are created equal time. Happy birthday, Chicken! -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Happy 10th birthday!
On Tue, 20 Jul 2010, Mario Domenech Goulart wrote: Hey July 20th, 2010, marks the 10 year anniversary of the CHICKEN announcement message Felix wrote to c.l.s: http://groups.google.com/group/comp.lang.scheme/msg/edfb2da16fd89fae Thanks to all the contributors for making CHICKEN such a nice project! Best wishes. Mario Minus fourscore and threescore ten years ago, our Felix brought forth a new implementation, concieved in poultry, and dedicated to the proposition that all CONS are created equal time. Happy birthday, Chicken! -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Proposed procedure movement in Chicken 4
On Wed, 9 Sep 2009, Peter Bex wrote: On Wed, Sep 09, 2009 at 10:51:35AM -0700, Kon Lovett wrote: Hi Folks, These are planned changes to the unit structure of Chicken 4: 1) Unit utils 'read-all' - Unit extras. 2) Unit utils 'qs', 'system*', 'compile-file-options', 'compile- file' - Unit files. 3) Unit extras random stuff - Unit utils 4) Unit files pathname stuff - Unit pathname 5) Unit extras - Unit io 6) Unit data-structures functionals+combinators - combinators I want to perform 1 - 3 soon, and 4 - 6 after. Comments? It seems a bit gratuitous, especially the creation of new units like pathname, io and combinators. That will break a _lot_ of code. I am afraid we will get the same situation we had a while back when unit files was first created; lots of eggs breaking and confusion all around. How can we ensure eggs keep working on systems with Chicken 4.1 and Chicken 4.2 (assuming these will be made into 4.2)? We can only distinguish between major versions of Chicken in chicken-setup and other egg tools. I don't really understand the rationale between splitting up stuff even more, while Felix proposed to join more stuff together. Also, what's the difference between unit extras and unit utils? They both sound like miscellaneous stuff to me. If we are changing things around so radically, we should take the opportunity and get rid of one of those. Cheers, Peter +1 i don't think arbitrary moves are worthwhile. whats the rationale for moving things in this way? -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] stressing the new hygienic macros
perhaps the addition of a let-syntax would be useful above the internal syntax-rules? -elf On Tue, 28 Apr 2009, Michele Simionato wrote: I have subscribed again the list after a few years of absence, because I wanted to try the new and improved hygienic Chicken ;-) As first experiment, I tried to stress a bit syntax-rules. I tried the following at the REPL: (define-syntax very-static-table (syntax-rules () ((_ (name value) ...) (syntax-rules (names name ...) ((_ names) '(name ...)) ((_ name) value) ... (define-syntax color (very-static-table (red 0) (green 1) (blue 2))) Error: unbound variable: red Call history: syntax (define-syntax color (very-static-table (red 0) (green 1) (blue 2))) syntax (very-static-table (red 0) (green 1) (blue 2)) syntax (red 0) syntax (green 1) syntax (blue 2) eval(very-static-table (red 0) (green 1) (blue 2)) eval(red 0) -- What's happening here? Notice that (define-syntax color (syntax-rules (names red green blue) ((_ names) '(red green blue)) ((_ red) 0) ((_ green) 1) ((_ blue) 2))) works as intended. ___ 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] stressing the new hygienic macros
ignore previous comment -elf On Tue, 28 Apr 2009, Michele Simionato wrote: I have subscribed again the list after a few years of absence, because I wanted to try the new and improved hygienic Chicken ;-) As first experiment, I tried to stress a bit syntax-rules. I tried the following at the REPL: (define-syntax very-static-table (syntax-rules () ((_ (name value) ...) (syntax-rules (names name ...) ((_ names) '(name ...)) ((_ name) value) ... (define-syntax color (very-static-table (red 0) (green 1) (blue 2))) Error: unbound variable: red Call history: syntax (define-syntax color (very-static-table (red 0) (green 1) (blue 2))) syntax (very-static-table (red 0) (green 1) (blue 2)) syntax (red 0) syntax (green 1) syntax (blue 2) eval(very-static-table (red 0) (green 1) (blue 2)) eval(red 0) -- What's happening here? Notice that (define-syntax color (syntax-rules (names red green blue) ((_ names) '(red green blue)) ((_ red) 0) ((_ green) 1) ((_ blue) 2))) works as intended. ___ 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] Lisp puzzles
are you counting '() (the empty list) as an atom or not? in lisp it traditionally isnt an atom, but your definition below indicates it is. -elf On Tue, 21 Apr 2009, John Cowan wrote: These are some very old Lisp puzzles I dug up and translated to Scheme. The idea is to figure out what they do, ideally without testing them, but if you *want* to test them, nobody can stop you. ;; What do these functions do? (define (greussay l r) (cond ((atom? l) #f) ((memq l r) #t) ((greussay (car l) (cons l r)) #t) (else (greussay (cdr l) (cons l r) (define (allen l) (cond ((null? l) '()) ((null? (cdr l)) l) (else (cons (car (allen (cdr l))) (allen (cdr (allen (cdr l (define (samet x y) (if ( x 2) (+ y 1) (samet (- x 1) (samet (- x 2) y (define (goossens-moby l) (if (null? (cdr l)) (car l) (goossens-moby (cddr (append l (car l)) (define (hofstadter-g n) (if (= 0 n) 0 (- n (hofstadter-g (hofstadter-g (- n 1)) (define (hofstadter-q n) (cond ((= n 1) 1) ((= n 2) 1) (else (+ (hofstadter-q (- n (hofstadter-q (- n 1 (hofstadter-q (- n (hofstadter-q (- n 2 (define (goossens l x) (if (null? l) x (goossens (reverse (cdr l)) (car l ;; Utility function #;(define (atom? x) (not (pair? x))) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] IPhone
On Mon, 13 Apr 2009, Alex Queiroz wrote: snip I am not agreeing with Apple at all, but they might be afraid of GC pauses. how would they know its a gc pause? it would just look like a bunch of memory accesses to them. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] IPhone
On Mon, 13 Apr 2009, Alex Queiroz wrote: Hallo, On 4/13/09, Elf e...@ephemeral.net wrote: I am not agreeing with Apple at all, but they might be afraid of GC pauses. how would they know its a gc pause? it would just look like a bunch of memory accesses to them. They might be afraid of how GC pauses may give the user the impression of slowness. opposed to how the browser, window collapser, window expander, history, and general ui give the user an impression of slowness? :) -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] IPhone
On Mon, 13 Apr 2009, Alex Queiroz wrote: Hallo, On 4/13/09, Elf e...@ephemeral.net wrote: I am not agreeing with Apple at all, but they might be afraid of GC pauses. how would they know its a gc pause? it would just look like a bunch of memory accesses to them. They might be afraid of how GC pauses may give the user the impression of slowness. let's be honest with ourselves. when gc happens, its not like a little flag comes up going 'GC in progress! please wait!'... its very rare that it 'feels' any different from a normal procedure call. slightly longer, perhaps, but almost indistinguishable in the general case. the reason for their (apparent? potential?) disapproval of gc isnt because of the user experience. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] trac instancesy
The new trac instances run by Ivan are at www.chicken-scheme.org and www.chickenscheme.org . Thanks be to Eric for the redirect. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] trac instancesy
Done. Praise be to Eric, who watcheth over the redirects. -elf On Tue, 7 Apr 2009, Alex Queiroz wrote: Hallo, On 4/7/09, Elf e...@ephemeral.net wrote: The new trac instances run by Ivan are at www.chicken-scheme.org and www.chickenscheme.org . Thanks be to Eric for the redirect. Good work, but I believe it would be better to redirect here: http://www.irp.oist.jp/trac/chicken ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Trac moving to new server
As soon as I can get ahold of Eric, we can give it one (or more) chicken domain names :) -elf On Mon, 6 Apr 2009, Ivan Raikov wrote: I have set up a Trac instance that is synchronized with the Chicken SVN repository; however, it is installed on the web server of my institute, because currently we do not have an available public IP address. I will be happy to administer this Trac instance, and I can be sure that any downtime will be minimized, because I have administrative access to the machine it runs on; however, I cannot use a Chicken-related domain name for it. If this is acceptable, we can make my Trac instance the primary one. -Ivan felix winkelmann bunny...@gmail.com writes: Hi! Thanks, Arto. I must admit that I'm not using the trac anymore - it is often not reachable (usually when I needed it most). Ivan is going to set up a new one on a dedicated server. Will we still need the current trac instance? What do others think? ___ 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] Ann.: CHICKEN 4.0.0 released
Erm, i wasnt aware i was supposed to fix the msvc mess, as i dont have access to a machine running msvc. i thought felix was working on msvc. sorry :) -elf On Mon, 6 Apr 2009, Leonardo Valeri Manera wrote: \o/ ... again! \o/ Also: kitten-technologies? :3 Finally: elf, did you fix the msvc mess? :D Cheers, Leo ___ 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] testing release candidate for 4.0.0
i have. look at the difference between the chicken3 branch and the other. the problem is that the msys environment is NOT the same as the mingw environment. period. msys is a fork of cygwin 1.3 (when it was still free) with the compilers kept mildly up to date with mingw. msys is a full build environment, though, and mingw installed in conjunction with msys will try using pieces of it all the time. mingw installed without msys uses windows paths, etc. the confusions here stem primarily from the poor explanations given in the mingw/msys documentation. it also explains why its fairly rare for devs to target both mingw and msys building :) bottom line: to test a mingw build, have a mingw installation without msys. to test a msys build, do a full mingw/msys installation. do not combine them, cause you will get peculiar behaviour. (this particular bug comes from using type (or cat) to try to read a file with shell redirects. it works fine in msys. in mingw its using cmd.exe, not bash.exe, and the behaviour is broken even for windows, so it gives a broken directory listing. you can see exactly where the break happens from where the slashes go from the front of each word to the back of each word (eg /a /b /foo bar/ c/ d/). this is not a problem in the chicken3 branch mingw makefile, as i had fixed it previously.) -elf On Thu, 26 Mar 2009, felix winkelmann wrote: On Wed, Mar 25, 2009 at 10:11 PM, Elf e...@ephemeral.net wrote: no. what happened is that the quoting rules are screwed up. i forgot to backport the makefile from 3. ill do it in a few. Please don't touch it, unless we have figured out what exactly goes wrong. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] testing release candidate for 4.0.0
no. what happened is that the quoting rules are screwed up. i forgot to backport the makefile from 3. ill do it in a few. (youre seeing what happens when the 'cat' or 'type' goes horribly wrong. note how the slashes go from one side to the other.) -elf On Thu, 26 Mar 2009, Ivan Shcheklein wrote: Hi Felix, MSVC+Cygwin's tools. Build failed since both chichen-defaults and chicken-config contain something like this: /backup /bin /cygdrive /cygwin.bat /cygwin.ico /dev /etc /home /lib /proc /tmp /usr /var generated benchmarks/ html/ scripts/ tests/ Is it expected? Seems that it's caused by echo commands without quotes, like: echo #define HAVE_INTTYPES_H 0 $@ The following works: echo #define HAVE_INTTYPES_H 0 $@ Ivan Shcheklein On Wed, Mar 25, 2009 at 6:31 PM, felix winkelmann bunny...@gmail.comwrote: Hi! The current release candidate can be found at: http://www.call-with-current-continuation.org/chicken-4.0.0.tar.gz I tested it on several systems (mingw(+msys), linux), but would appreciate if others could give it a try. Note that some minor recent trunk changes didn't make it, due to unclear portability. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] re: platform development
Sorry, i just realised i forgot to add the link to the page: http://chicken.wiki.br/platforms-used -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] platform development
Hi all, As I've been working on cross-platform compatibility shtuff for Chicken, it would be appreciated if I knew what platforms/architectures are actually being used or are desired so I know what requires the most thought. (Example: I rather doubt AIX is in widespread use, although it's theoretically supported by one of the build systems formerly used.) Can everyone please edit the platforms-used wiki page and add their names and platform(s)/architecture(s) used and/or desired, as a rough survey? Thanks very much! -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: platform development
On Mon, 16 Mar 2009, Aleksej Saushev wrote: Elf e...@ephemeral.net writes: I rather doubt AIX is in widespread use, although it's theoretically supported by one of the build systems formerly used. If you want build log, contact me, maybe I'll find a way. You're running on AIX? (I honestly just pulled an example out of my hat for an uncommon architecture, no offence was intended.) Please update the page, then. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: platform development
I'd like a copy of the build log, too, please. -elf On Mon, 16 Mar 2009, Aleksej Saushev wrote: Elf e...@ephemeral.net writes: I rather doubt AIX is in widespread use, although it's theoretically supported by one of the build systems formerly used. If you want build log, contact me, maybe I'll find a way. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chmod a+rw indeed
um, changing to 644 is almost certainly incorrect for executables. methinks you want 0755. -elf On Mon, 24 Nov 2008, felix winkelmann wrote: On Sat, Nov 22, 2008 at 1:36 PM, Drake Wilson [EMAIL PROTECTED] wrote: Sorry for the short pre-message research time, but this seems bogus enough to warrant it. I just built Chicken 3.4.0 from source in /usr/local/src/chicken-3.4.0 on Debian GNU/Linux x86_64 (sid), and at the end of the [make install] output, I see: $ sudo make PLATFORM=linux PREFIX=/usr/local USE_HOST_PCRE=yes install [...] chmod a+rw chicken csi \ csc chicken-profile chmod a+rw chicken-setup Uh. Why is this making the executables world-writable? Who said I wanted other UIDs on this machine to be able to write to those files? It seems like a pretty bad idea to be doing that without user consent, or at the very least a prominent notice! A few searches on chicken.wiki.br, the Web, and the user manual turn up nothing relevant about world-writable or chmod a+rw, so here I post. Thanks for reporting this. I changed the invocation to use 0644 instead. cheers, felix ___ 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] Bug in canonical-path?
On Wed, 29 Oct 2008, Peter Bex wrote: On Wed, Oct 29, 2008 at 11:03:30AM +0100, felix winkelmann wrote: On Wed, Oct 29, 2008 at 9:04 AM, Ivan Raikov [EMAIL PROTECTED] wrote: Hi all, I have been meaning to port the Haskell FilePath library to Chicken, because I find its API to be quite elegant and better organized than the existing file name manipulation routines in Chicken. This discussion has prompted me to create the filepath egg, which is an almost verbatim transliteration of the Haskell code, with a few Chicken-specific idioms here and there. I have included a flag parameter, which can be used to enable Posix mode or Windows mode for path name parsing and manipulation. The Windows mode supports weird things like UNC names and is aware of the DOS reserved names (CON, PRN, etc). I would appreciate it if people look at it, as I would like to see some variant of this API supersede the existing Chicken path manipulation stuff. That library looks useful - nice port, Ivan. I would keep these things in extensions, though. There is already too much stuff in the core (I know I keep repeating this, but I'm really concerned about it). I think Ivan is not suggesting _adding_ this to core, but rather _replacing_ what we have in core with this. In total, this should have the net effect of adding nothing (though I don't know how big both libraries are). filepath is fairly large. canonical-path and friends, together, are tiny. they are not addressing the same set of issues, regardless. again: canonical-path does not do existence checking. it is not meant to. it is intended to create localised canonical forms of a path in any representation as an aid to installation and naming portability. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] basic Scheme question
erm, have you looked at the remote-repl egg? fwiw, i don't see why this is an issue at all... just send quoted lists (stringified, of course), and eval it on whichever end is desired. -elf On Fri, 24 Oct 2008, Shawn Rutledge wrote: On Fri, Oct 24, 2008 at 1:00 AM, Drake Wilson [EMAIL PROTECTED] wrote: Quoth Shawn Rutledge [EMAIL PROTECTED], on 2008-10-23 23:54:03 -0700: Eval only sees the top-level environment. It may be possible to use the environments egg to construct your own environment containing v. I thought of that, but also thought there must be a generic Scheme way to do this. From someone with admittedly limited Scheme knowledge: The generic Scheme way wouldn't involve passing around quoted names and expecting them to retain their associations to the original lexical symbols at runtime, because they generally don't. The generic Scheme way would probably be to have a function encapsulate the idea of reading and writing the variable inside a location structure of some sort (pair of get+set function, likely) and then have the other function interact with that. Right that's the usual pattern. But I'm trying to call it remotely. A client REPL opens an SSH connection to a server and starts a server REPL. Each of them evaluates what the other sends. So if the server sends (let ([v (make-thing)]) ...) and the client evaluates it, then later the server wants to ask the client to do any operation on the previously-created v, how can the client now access the variable v, which exists only in that environment created by let? Just binding it to a top-level name would pollute the namespace. Having to bind the accessor is not so bad, because the same accessor can be used to modify multiple remote objects. ___ 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] Bug in canonical-path?
On Sun, 26 Oct 2008, Peter Bex wrote: On Sun, Oct 26, 2008 at 01:19:42AM -0700, Elf wrote: ~$ touch abc\\298.test csi (find-files . regular-file? (lambda (x y)(print x) (print (file-stat (canonical-path x) ./abc\298.test Error: (file-stat) cannot access file - No such file or directory: /home/matt/stuff/tools/lmbk/abc/298.test this isn't a bug; it has to handle both windows and unix paths. i can add optional flags for specifying behaviour of slash and backslash, if desired. It would be better to make the behaviour be system-specific, instead of adding flags. On Windows, *always* treat slashes as backslashes. On Unix, *only* accept slashes with no additional translation steps. (I'm not sure Windows doesn't allow slashes in filenames, but I don't think it does) the idea was to allow for system-independent handling of pathnames with proper resolution. since the system for which a given path string was written is not knowable, it properly converts any relative (or absolute) path into the proper form for the local architecture. Also, why does file-stat interpret the backslash in the first place? AFAIK you can mix slashes and backslashes in Windows, so you shouldn't have to do anything at all. file-stat doesnt interpret the backslash, its canonical-path which does. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Sun, 26 Oct 2008, John Cowan wrote: Peter Bex scripsit: It would be better to make the behaviour be system-specific, instead of adding flags. On Windows, *always* treat slashes as backslashes. On Unix, *only* accept slashes with no additional translation steps. (I'm not sure Windows doesn't allow slashes in filenames, but I don't think it does) Unix, of course, treats \ as an ordinary filename character. In Windows, \ and / are interchangeable in system calls, although the command shell, the desktop, and other file windows and dialogue boxes don't accept \ but only /. Inside Chicken, therefore, / is entirely portable and no translation is ever necessary. this is not strictly true; during installation of files (eg for chicken-setup) some calls are done through the command shell. the / notation has certain other concerns as well, mostly involving drive letter. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Tue, 28 Oct 2008, John Cowan wrote: Elf scripsit: In Windows, \ and / are interchangeable in system calls, although the command shell, the desktop, and other file windows and dialogue boxes don't accept \ but only /. I should have said don't accept / but only \, of course. this is not strictly true; during installation of files (eg for chicken-setup) some calls are done through the command shell. In which case the code should be specialized for that purpose. this was the original intent. the / notation has certain other concerns as well, mostly involving drive letter. Well, yes: a path beginning [A-Za-z]:[/\\] is absolute on Windows but not on Unix. That too is a special case. see above. i will be adding flags to it for handling special cases at my earliest convenience. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] basic Scheme question
On Thu, 23 Oct 2008, Shawn Rutledge wrote: #;10 (begin (define update #f) (let ([v 'foo]) (set! update (lambda (d s) (printf ~s was ~s~% d (eval d)) (set! d s) #;11 (update 'v 'bar) Error: unbound variable: v What I'm trying to do is pass the name of a let-bound variable in to a lambda defined within the let context, in order to tell that lambda to access that let-bound variable. eval doesn't work because it looks in the outer environment, right? (in which v is not bound) unless there's some way to add new bindings to an arbitrary env (ie, extend a let at runtime), then youd be better served by either explicit setting procs for each let-bound var, or by having some form of dispatch from a single name. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Sat, 25 Oct 2008, Matthew Welland wrote: ~$ touch abc\\298.test csi (find-files . regular-file? (lambda (x y)(print x) (print (file-stat (canonical-path x) ./abc\298.test Error: (file-stat) cannot access file - No such file or directory: /home/matt/stuff/tools/lmbk/abc/298.test this isn't a bug; it has to handle both windows and unix paths. i can add optional flags for specifying behaviour of slash and backslash, if desired. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] command-line-arguments
On Sat, 11 Oct 2008, Jörg F. Wittenberger wrote: Am Freitag, den 10.10.2008, 11:19 -0700 schrieb Elf: i'd recommend the r5rs primitive 'write' instead of 'display', 'printf', etc, if you want the external representation of your code. :) That's what would have recommended until a few weeks ago, when I found write to be the source of an incompatibility between two Scheme systems. there is no guarantee in r5rs that the external representations (outside of a few specific cases) will be the same, and the differences between implementations that allow slashification within symbols and those that do not are specifically mentioned within the rationale. write gives an external representation. the external representation is machine-readable back in. for the cases of strings, (write string) always displays string whereas (display string) always displays string ... and as (command-line-arguments) returns a list of strings, write is exactly what will display the objects. (furthermore, the other methods described by various people all become calls to write. eg printf ~S = output object using write (vs ~A, output using display)) -elf /Jörg -elf On Fri, 10 Oct 2008, Wietse Jacobs wrote: 2008/10/10 Peter Bex [EMAIL PROTECTED]: On Fri, Oct 10, 2008 at 04:04:13PM +0200, Wietse Jacobs wrote: (display (command-line-arguments)) That's (kind of) a limitation of how 'display' works. #;1 (display (list foo bar)) (foo bar) Instead, you want: #;2 (printf ~S (list foo bar)) (foo bar) Thanks everyone! Note to self: Don't rely on `display` to tell you what your code does. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chi#0; ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] command-line-arguments
i'd recommend the r5rs primitive 'write' instead of 'display', 'printf', etc, if you want the external representation of your code. :) -elf On Fri, 10 Oct 2008, Wietse Jacobs wrote: 2008/10/10 Peter Bex [EMAIL PROTECTED]: On Fri, Oct 10, 2008 at 04:04:13PM +0200, Wietse Jacobs wrote: (display (command-line-arguments)) That's (kind of) a limitation of how 'display' works. #;1 (display (list foo bar)) (foo bar) Instead, you want: #;2 (printf ~S (list foo bar)) (foo bar) Thanks everyone! Note to self: Don't rely on `display` to tell you what your code does. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Why is the format egg redundant or unsupported?
fwiw, the dependency on numbers should probably be removed in eformat. i believe thats the only external dependency it has? -elf On Sat, 27 Sep 2008, Matthew Welland wrote: While I really like eformat I tend to use the format egg quite a bit. It has no external dependancies and works everywhere (i.e. at work, on the nokia n800 etc.). I hope that being down in that section of the eggs page doesn't imply that the format egg is at risk of going away? If so is there another format implementation with minimal dependencies that I should be using instead? Matt -=- ___ 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] Expanding ellipsis on lists of different length
On Thu, 28 Aug 2008, Tobia Conforto wrote: I believe it's only a matter of using a version of map that checks this condition: that all its arguments become '() at the same time. Maybe it would be useful to modify map itself in this way? ;; correct, this is an error (map list '(1 2 3) '(10 20)) = Error: (map) lists are not of same length: (()) ;; not so correct, this should be an error too (map list '(1 2) '(10 20 30)) = ((1 10) (2 20)) this is a problem, because this technically is correct behaviour, if we're going to allow this (what i consider broken but understand from my betters is merely unspecified) behaviour. it is consuming all of the tokens from the list. yay ambiguity. i dont think that trying to solve the case in the general form by the extra checks would be a good idea because a) most forms will be correct in more than an unspecified sense, and b) the vast majority of forms would get a fairly nasty slowdown in order to error for something outside the spec. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Local documentation [was: Re: [Chicken-users] hygienic egg PORT-A-MANIA!]
On Wed, 27 Aug 2008, felix winkelmann wrote: Hi! Ok, how are we going to proceeed? One can convert and install eggdoc-based documentation in the setup script (manually). Or we just handle it like in the old chicken-setup. But we need a new idea for online docs that are based on eggdoc. egg-post-commit should go (or only be kept for pre 4 chickens), so this has to be handled by a different periodical task. Any suggestions or preferences? my 2c. i dont think that it should be too difficult to set properties on the svn commit itself and configure the server to handle them in realtime (at commit), rather than via a periodical task. this could allow significantly faster update of eggs when fixes are made, and give some added flexibilities. if a scheme like this were implemented, getting the docs from the wiki would actually be more of a pain than the upload... -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Expanding ellipsis on lists of different length
On Wed, 27 Aug 2008, Tobia Conforto wrote: (define-syntax test (syntax-rules () ((test (a ...) (b ...)) (quote ((a b) ...) What happens if one calls this macro on two lists of different lengths? According to various online tutorials, the expansion should abort with an error. In current hygienic Chicken the behaviour depends on which list ends first: i believe that this is an error in chicken. there are two ellipses in the pattern and only one in the output spec, so in both cases it should error with an invalid transformer spec notice. additionally, the 'a' isnt followed by an ellipsis, nor is the 'b' followed by an ellipsis, which is specifically the error referred to here: 'pattern variables that occur in subpatterns followed by one or more instances of the identifier ... are allowed only in subtemplates that are followed by as many instances of ... . they are replaced in the output by all of the subforms they match in the input, distributed as indicated. it is an error if the output cannot be built as specified.' (test (1 2) (10 20 30)) = ((1 10) (2 20)) (test (1 2 3) (10 20)) Error: (map) during expansion of (test ...) - lists are not of same length: (()) R5RS is pretty vague, but does hint at an error condition in the last sentence: Pattern variables that occur in subpatterns followed by one or more instances of the identifier ... are allowed only in subtemplates that are followed by as many instances of They are replaced in the output by all of the subforms they match in the input, distributed as indicated. It is an error if the output cannot be built up as specified. imho this isnt vague at all. conceptually, this means you cant drop out tails arbitrarily, nor reattach them arbitrarily. (it does leave open the question if '((test (a b ...) c ...) (test a c ...))' is valid, though. (or even if the transformer was just 'a', for that matter.) -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Expanding ellipsis on lists of different length
apparently its neither invalid nor valid. according to riastradh and others, if i understood correctly, such behaviour is not covered in r5rs at all, and some implementations do allow it , and some dont. the untest case is always valid, the test case is only valid when input is of the same length. i am confused. are you proposing that it should always signal an error when getting the split ellipses like this, or when the lists are mismatched? (the second case is a bit unpleasant to try to catch all the time, and would probably have performance unplesantnesses.) -elf On Wed, 27 Aug 2008, Tobia Conforto wrote: Elf wrote: Tobia Conforto wrote: (define-syntax test (syntax-rules () ((test (a ...) (b ...)) (quote ((a b) ...) i believe that this is an error in chicken. there are two ellipses in the pattern and only one in the output spec, so in both cases it should error with an invalid transformer spec notice. I beg to differ. This is a perfectly valid syntax-rule. The number of ellipses in the pattern doesn't need to match those in the template, not in this way. For example this is valid too--it does the opposite of test: (define-syntax untest (syntax-rules () ((untest (a b) ...) (quote ((a ...) (b ...)) (untest (1 10) (2 20) (3 30)) = ((1 2 3) (10 20 30)) additionally, the 'a' isnt followed by an ellipsis, nor is the 'b' followed by an ellipsis, which is specifically the error referred to here: 'pattern variables that occur in subpatterns followed by one or more instances of the identifier ... are allowed only in subtemplates that are followed by as many instances of ... . they are replaced in the output by all of the subforms they match in the input, distributed as indicated. I think you are reading it wrong. Let's apply it to test: (define-syntax test (syntax-rules () ((test (a ...) (b ...)) (quote ((a b) ...) Pattern variables [for example, the 'b inside (b ...)] that occur in subpatterns [the same 'b is also the subpattern in this case] followed by one or more instances of the identifier ... [one instance] are allowed *only* in subtemplates [(a b) is the subtemplate] that are followed by as many instances of ... [again one instance.] Applied to untest: (define-syntax untest (syntax-rules () ((untest (a b) ...) (quote ((a ...) (b ...)) Pattern variables [for example, the 'a in (a b)] that occur in subpatterns [(a b) is the subpattern] followed by one or more instances of the identifier ... [one instance] are allowed *only* in subtemplates [the 'a inside (a ...) is the subtemplate] that are followed by as many instances of ... [again one instance.] AFAICS, the only possible error that can happen at macro expansion time, related to the ellipsis, is to take a macro combining several pattern-ellipses into one template-ellipsis (such as test above) and apply it to lists of different length. What I'm proposing is to always signal it as an error, not just half of the times. Tobia ___ 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] Good way to code the equivalent to this?
i got almost the same time as with my previous (incorrect) method by using a
single hash table and an alist instead of a hash for the inner structure.
memory usage isnt so good though. :(
using a sparse multiple-alist structure seems to work nicely in small space
and good time. i can post the code if interested.
-elf
On Sun, 24 Aug 2008, Jim Ursetto wrote:
Note that your solution effects a mapping of x - y, not from x - y
- #t. That gets the job accomplished correctly, but doesn't reflect
the original Perl code. For a fair comparison, you have to change the
perl code to match, and then it runs in 1/3 of the memory and 1/2 the
time of the original perl code.
This is what I mean concretely:
print Filling the array with 25 entries.\n;
foreach $n (0 .. 25) {
$x = int(rand(50));
$y = int(rand(50));
$a{$x} = $y; # change to one-level hash
}
print Reading from the array 1 times\n;
$hits=0;
foreach $n (0 .. 1) {
$x = int(rand(50));
$y = int(rand(50));
if (exists $a{$x} and $a{$x} == $y) { # quell warning on undef
$hits++;
}
}
print Done (hits $hits)\n;
On Sun, Aug 24, 2008 at 5:56 AM, Elf [EMAIL PROTECTED] wrote:
for an improvement in time (surprisingly), use
(define a
(alist-hash-table
(let loop ((i 0)
(r '()))
(if (fx= 25 i)
r
(loop (fx+ 1 i)
(cons (cons (random 50) (random 50)) r
=))
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Good way to code the equivalent to this?
On Mon, 25 Aug 2008, Tobia Conforto wrote: Elf wrote: (define a (alist-hash-table (let loop ((i 0)) (if (fx= 25 i) '() (cons (cons (random 50) (random 50)) (loop (fx+ 1 i) =)) for an improvement in time (surprisingly), use (define a (alist-hash-table (let loop ((i 0) (r '())) (if (fx= 25 i) r (loop (fx+ 1 i) (cons (cons (random 50) (random 50)) r =)) ...there are a lot more minor GCs this way Why is it surprising that the tail-recursive version performs better? And why do you say it has more GC? Isn't it supposed to produce less garbage? well, i say it has more cause thats what the stats said :) the reason why it would be more in large cases like this is because it has to repeatedly copy a large structure in the iterative-tail-recursion version, whereas in the stacking recursion it just has to copy the frames onto the heap every so often. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hygienic egg PORT-A-MANIA!
On Tue, 26 Aug 2008, Ivan Raikov wrote: snip Could you describe in more detail what you mean by eggdoc documentation option? And what sweeping changes exactly are you talking about? The eggdoc option was the ability to generate online HTML documentation from an eggdoc script. The sweeping change is that the eggdoc option was dropped by decree. So, if I understand you correctly, you would like to have an automated method of generating wiki pages from eggdoc (automated on commit, that is)? Yes, but I also want the HTML pages generated from wiki pages to have the same look and feel as HTML pages generated by eggdoc. Maybe this is just a matter of using the right style classes in the HTML, but take a look for example in the documentation for digraph and formular. eggdoc seems to do a much better job at delineating the sections and highlighting the procedure headers, and it also has neat boxes for the code examples and the license text, while the wiki pages use this weird dashed line thing. i second this motion, wholeheartedly. i can generate properly formatted tables, and inner tables, and whatever else i feel like with eggdoc. plus, its nicer to view in lynx. :) im not necessarily sold on eggdoc itself, only because its amazingly annoying to change certain properties (unlike the wiki, where they cant be changed at all). i know that a few months back i said i would come up with something. i totally dropped the ball here, apologies. im a bit swamped. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hygienic Chicken's desftruct issue
On Mon, 25 Aug 2008, Alan Post wrote: On Mon, Aug 25, 2008 at 04:31:42PM -0400, John Cowan wrote: Peter Bex scripsit: Perhaps you (or someone else on the list?) can think of a better name that can be prefixed, to remove all confusion? Ideally it'd be something which has been done before in Scheme, or failing that, something people would have absolutely no preconceptions about. clone-type would fit the latter description, or how about make-duplicate-type? I'll also propose transmogrify-type and make-duplicate-with-ethicator-type. a clone by any other name is no defeat. -elf who wants to know why we're babbling about procedure names when there's porting to be done ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hygienic egg PORT-A-MANIA!
On Tue, 26 Aug 2008, Ivan Raikov wrote: snip I can not remember that anybody ever used it I use it for the majority of the eggs written and maintained by me. i wasnt aware that we weren't supposed to document eggs that way anymore, i thought it was just wiki preferred. all of my eggs are documented via eggdoc, not the wiki. only times i use the wiki for my own egg documentation is to spend hours bashing my head against the hideous css. Doesn't svnwiki allow heavy customization of single pages via svn properties? egg-post-commit (which is still running, and will do so for as long as chicken 3.x.x is supported) could do the eggdoc-wiki conversion (possibly with embedded HTML) and set custom css or template for these pages. Do you want to do that? I'd rather be writing new code and porting old code to the hygienic code, rather than messing around with CSS. The least amount of effort is to simply permit the generation of online HTML documentation from eggdoc scripts in the release/4 branch. erm, as far as i can tell, svnwiki doesnt allow you to anything. it took me around 9 hours to figure out how to get tables lined up so the rows all started in the same place. solution ended up being: use nowiki tags. i think the big difference between the two, for me... well, i spent 9 hours getting a single table to work, and ended up having to subvert the wiki to do so. (even in nowiki the css mangled things.) if i wanted to do another table, id have to go through the same process again. i read all the documentation available at the time (and edited it, cause even the docs werent displaying tables properly), and a chunk of the code. conversely, i spent 6 hours working on a macro for eggdoc generation, and most of that was cause i didnt read the documentation carefully and got confused... once i realised how the eggdoc tag-macros worked, it only took a few minutes. now i have a simple, schemey format in a small number of lines of code that works for any of my documentation. it doesnt make sense, to me, to use something less powerful, slower, and more brittle when there are better options. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Good way to code the equivalent to this?
my solution :) its faster (at least on chicken 3.3.something). timing on this box put this at just under 8s. -elf --- (use extras) (print filling ...) (define a (alist-hash-table (let loop ((i 0)) (if (fx= 25 i) '() (cons (cons (random 50) (random 50)) (loop (fx+ 1 i) =)) (print reading ...) (define hits (let loop ((i 0) (r 0)) (if (fx= i 1) r (if (fx= (random 50) (hash-table-ref/default a (random 50) -1)) (loop (fx+ 1 i) (fx+ 1 r)) (loop (fx+ 1 i) r) (print done.) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Good way to code the equivalent to this?
for an improvement in time (surprisingly), use (define a (alist-hash-table (let loop ((i 0) (r '())) (if (fx= 25 i) r (loop (fx+ 1 i) (cons (cons (random 50) (random 50)) r =)) instead. personally, id test both on whatever box youre running, as there are a lot more minor GCs this way. the alist-hash has an interesting property, though... the first value (if there are duplicate keys) seems to be the one thats used, the others are ignored. however, its a lot faster to build the list than to do the hash-table-set!, interestingly. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Good way to code the equivalent to this?
i've been testing various solutions, which ill be happy to post if interested. all of them involve alist-hash-table. so far, the fastest solution, on average, has been list-tabluate to generate the list. (map! was a close contender, though.) the solution with the least GCs, on average, uses unfold for generation. all of these have been run in the interpreter, not compiled. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Good way to code the equivalent to this?
one final note: the time and memory usage for the list-tabulate, map!, and unfold solutions, on my box, are approximately 0.4s slower than perl, with slightly better memory usage stats (in chicken, that is). hope this helps. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg announcement: remote-repl
On Tue, 19 Aug 2008, Jörg F. Wittenberger wrote: Am Montag, den 18.08.2008, 09:19 -0700 schrieb Elf: On Mon, 18 Aug 2008, Jörg F. Wittenberger wrote: snip as a sidenote, i cannot think of any legitimate reason to change timeouts dynamically. So you probably never had to debug a larger amount of communicating machines? I consider it legitimate to test for behavioral changes of the whole system, when timing changes and/or node become uncooperative. Apart from wild guesses I can't even see another way to find out good values. ive had to debug a ridiculous amount of HA machines. ive helped optimise the physical layout on the bloody disk to improve seektimes over clusters that were simultaneously parsing insane amounts of data while being queried at tens of thousands of times per second, and needed to generate consistent constraints over the data simultaneously. i have never had an application improve its characteristics from dynamic timeout changes. the closest reasonable things that i HAVE needed to do are 1) figure out what the system was doing beforehand, so i could find sane timeouts and quanta, and 2) very rarely, have the machine repeat a loop before it 'should', to give it an extra chance. its not a particularly difficult set of algos to work out... its essentially a modification of starvation prevention algos. changing the timeouts while the system is running can have any number of bad effects, if you have carefully timed and optimised machines. every repl session is in its own thread. as tcp timeouts are parameters, if you want to change the timeouts for that particular thread, all you have to do is: That's what I have been able to do bevor. That's not the aim. I need to change all timeouts for all thread which are started after the change. then all you have to do is use the environments egg to make or copy the base env before starting the server, and define an evaler to eval certain expressions in that environment rather than the local. if you would read the docs, it might save us both a lot of time, as this is explained, and examples are given. -elf___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken with VIM
#; is a very special sort of case. it would be a minimum of several lines to perform syntax highlighting correctly with it. give me a full list of whats missing from vim, and ill look at it. i dont use vim, but i do use vi :) -elf On Mon, 18 Aug 2008, Wang Xin wrote: 2008/8/18 Tobia Conforto [EMAIL PROTECTED]: Yes, it's the new version shipped with Vim 7.2 and it's giving me trouble with the s-expr comment #; I cannot get it to work, no matter where I place it. S-expr comment hightlighting doesn't work well for me also. The patch pasted in the wiki is rather dirty and may cause some other problems. Still I can't find a proper way to do the job. I fixed a couple of problems with it: - some shell metacharacters were not quoted properly, try to \es on (print $HOME) for example; - csi's current-directory needs to be changed to that of the file being loaded, otherwise include statements and other stuff will fail. For the latter, we need the posix library in the running csi. This happens implicitly if one loads the readline egg in .csirc (as I suppose everybody does?) otherwise one will need to (use posix) I also added a new command to send the highlighted text in visual mode to csi, rewrote Send() to be more general, and used shorter mappings (a matter of taste, I guess.) Here is my version, I'll put it on the wiki if it's ok with you: Tobia Wow, a good work. I have tried those commands, and they work well. BTW, the way using screen to interact with Chicken is poor. Elf has just released his remote-repl egg. I think it is possible to use VIM's foreign language interface(e.g. Python) to connect to the server side. So that we can get the result back, then we can do much more things in VIM. Or even a repl? Any thoughts? Xin ___ 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] egg announcement: remote-repl
On Mon, 18 Aug 2008, Alaric Snell-Pym wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17 Aug 2008, at 3:53 am, Elf wrote: many people on #chicken and the list have requested a simple remote- repl egg. some people have requested a not-so-simple remote-repl egg, too. :) Oh, yay! Will this do the job of the thing I was considering, that one could easily incorporate into a daemon (spiffy, etc) so you can 'telnet' in to monitor/reconfigure/test/shut down/etc? yes. read the doc for it, i released a set of updates yesterday that include usage examples. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Possible formating Bug in SRFI-19?
srfi-19 is broken in several ways right now and will be refactored soon. -elf On Mon, 18 Aug 2008, Jörg F. Wittenberger wrote: Hi Kon, I ran into a problem with SRFI-19 formatting. (Being lazy) I'm not (yet) using the chicken egg, but the version I made up years ago. Now I found this bug, which - if there are no other tricks in your code - should affect the egg too: in date-string the ~s should hit (cons #\s (lambda (date pad-with port) (display (time-second (date-time-utc date)) port))) (which stems from the reference implementation). Right now (time-second (date-time-utc (current-date))) is 1219068469. Let's try: $ csi CHICKEN (c)2008 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 3.3.8 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook hostpcre ] SVN rev. 11663 compiled 2008-08-17 on debian (Linux) #;1 1219068469 1219068469.0 #;2 Too bad: there is an extra #\. in the output, which will certainly confuse the corresponding string-date parser. Could you check if this applies to the egg's version? best regards /Jörg ___ 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] Possible formating Bug in SRFI-19?
chicken doesnt have bignums at the moment. it doesnt matter if other schemes can do it or not, the manual explicitly states that the full numeric tower is not present by default. the only way currently to represent integers larger than fixnum, without using the numbers egg, is to use doubles, which happens automatically. if you're seriously proposing modifying all of the output procedures, you're mad. if you need bignum support in the short term, use the numbers egg. if you dont, wait until the compat lib is out, which has a full numeric tower. -elf On Mon, 18 Aug 2008, Jörg F. Wittenberger wrote: Am Montag, den 18.08.2008, 11:15 -0400 schrieb John Cowan: Jörg F. Wittenberger scripsit: Right now (time-second (date-time-utc (current-date))) is 1219068469. Which is bigger than a Scheme fixnum. That's the source of the trouble. Chickens's fixnum on 32bit platform, to be precise. But that doesn't matter much. (Letting alone, that other Schemes will display 1219068469 without .0; wich, according to R5RS are both ok.) The point is the trouble is there, SRFI-19 date-string should print without .0 - it really disturbs, if used in HTTP/SMTP headers and the like. For the time being, I'm using string-index-right and substring to get rid of it. Something, which works, but it leaves a bad feeling in the stomach. I had no better idea, sorry. /Jörg ___ 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] egg announcement: remote-repl
On Mon, 18 Aug 2008, Jörg F. Wittenberger wrote: Hi Elf, first of all: sorry about not having had the time to read your egg but anyway asking questions about it. please read the docs in the future, as this issue is addressed. Actually having such a facility and not being able to use it as I *want* to, made me ask for shared parameter objects at the first place in the other tread over there. My context: several servers spread across the country talking TCP to each other. There are several timeout, counter and other parameters - within chicken and elsewhere in my program - if I want to set them from a remote-repl, which presumably runs in it's own thread (since it would be otherwise just a demo). as a sidenote, i cannot think of any legitimate reason to change timeouts dynamically. every repl session is in its own thread. as tcp timeouts are parameters, if you want to change the timeouts for that particular thread, all you have to do is: (rrepl-client-send client-obj '(tcp-read-timeout 5)) as an example, assuming that client-obj is a client previously defined by rrepl-client-connect, and that you wanted to set the read timeout to 5. it is generally inadvisable to do this, however, in the current implementation of the remote-repl egg. first, timeouts need to exist. second, part of how the thread-quantum values are set is from the timeouts, to optimise thread flow. the rrepl-server-start procedure takes in optional (keyworded) values for the timeouts, so you can set it sanely upon initial creation of the server, which will propagate to the sessions. third, remote-repl egg handles the timeouts gracefully, either looping if timeout is reached (in cases like clients waiting for the return value from a command, since its unknown how long the evaluation will take) or by yielding their timeslice and restarting from the top (in cases like waiting for initial input to read, accepting new connections, etc). in other words, the remote-repl behaves the way you would expect a repl to behave. while completely generalised and completely configurable, everything is wrapped, so all of the intricate condition handling and error handling and thread semantics are completely hidden from the user, and you don't need to worry about it. -elf___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Dual-format macros
On Mon, 18 Aug 2008, Tobia Conforto wrote: On 6 Aug 2008, Jörg F. Wittenberger wrote: So far I've got (from watching the mailing list) the feeling that define-macro and define-syntax don't play well together. If it was better to have both versions available, the define-macro version for compatibility and define-syntax for the upcoming hygienic chicken, then: how should this be handled? Two eggs? I've found this in the amb egg, it solves the problem nicely: (cond-expand (hygienic-macros ;;put here a bunch of define-syntax + syntax-rules macros ) (else ;;put here the same macros written in un-hygienic define-macro )) define-macro will no longer exist in chicken4 (aka hygienic chicken). -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Embedded Chicken
On Mon, 18 Aug 2008, John Van Enk wrote: Has any one attempted to get Chicken working in an embedded environment? Mainly, something running directly on the hardware without an OS between Chicken and the registers. I've been quite interested in putting together a Scheme variant to replace C in embedded systems. Any input/suggestions/knowledge would be much appreciated. you want chicken to be the kernel? -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Race condition in scheduler.scm
On Sun, 17 Aug 2008, Jörg F. Wittenberger wrote: Hi all, in this message http://lists.gnu.org/archive/html/chicken-users/2008-08/msg00094.html I posted a patch to scheduler.scm, which fixes a race condition wrt. bad file descriptors in the waiting queue. (Attached is a slightly brushed up version.) I have not seen any replies to this message (which is sort of strange on this list). Did anyone consider to roll it in? If not, why? Anything bad about it? The race originally arose in a somewhat strange setup, which might not be even repeatable for everyone, since it involved accidentally changing the scheduling sequence (using more or fewer exception handlers), which may have different results on different machines. But the issue as such is easy to recreate, if you make a thread wait asynchronously on any file descriptor and close that fd from a second thread. (Something, which may or may not be intentional, but easy to do.) i'm not understanding why this would cause a 'race condition', nor why your patch is necessary. the lines which you deleted from the scheduler (the -1 check and forced-primordial) accomplish the same thing without raising an exception or causing modifications to the signal/condition/exception handler in unsafe ways. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] egg announcement: remote-repl
many people on #chicken and the list have requested a simple remote-repl egg. some people have requested a not-so-simple remote-repl egg, too. :) your requests have been answered. there is a new remote-repl egg as soon as the repo gets updated. it should be plugin-able to any existing code without modification. it doesnt require any knowledge of threads or conditions. its highly configurable: it uses the tcp egg by default, but you can tell it to use any type of sockets or wrappers that you'd like. it supports authentication, if you want it. it supports evaluation in any type of environment; everything is hooked on a per-session/per-server basis. for those of you who dont want or need anything so fancy, the defaults are (like i said) tcp and no auth, so you only NEED to specify a port and hostname. errors are handled nicely, so you dont have to worry about some typo in the repl erroring out your whole process. all of that is handled under the hood, even if you do use the hooks. hope this satisfies the requests. let me know if it doesnt. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: S11n Egg Problem
the problem is the procedures starting at lines 146 and 148 in svn head, getb and getw. theyre not checking for eof-object, which would cause this behaviour. fetch isnt checking either, but it needs to be at getb level, cause char-integer against eof-object isnt so good. the weird question is why is this not failing at the char-integer ? -elf On Wed, 13 Aug 2008, Joshua Griffith wrote: The following lines demonstrate the problem: (use s11n) (deserialize (open-input-string \f)) -Josh On Aug 13, 2008, at 4:30 AM, felix winkelmann wrote: On Wed, Aug 13, 2008 at 8:38 AM, Joshua Griffith [EMAIL PROTECTED] wrote: Hello, When a serialized object gets corrupted or truncated (which often occurs when it is transmitted over a TCP connection), attempting to deserialize that object results in a Bus error and immediate program termination, rather than a raised exception. How difficult would it be to modify the s11n egg so that it fails gracefully upon receipt of corrupted data? It shouldn't be too hard, one just would have to precede a chunk of data with a checksum. I can look into this (unless you need a quick solution, because I can't exactly say when I get around doing so). cheers, felix ___ 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] are additional make-input-port's argument ok to use
its not stable in the sense that most everything about ports will be changing very soon because of problems with windows and certain other OSes. -efl On Wed, 13 Aug 2008, Jörg F. Wittenberger wrote: Hi all, me again :-( I'm inclined to use those undocumented arguments to make-input-port (for read-line and read-string). However before I go ahead I'd like to know how stable the interface is. Or may it be even ok to make them official? Thanks /Jörg ___ 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] svn bootstrap broken?
ubuntu is using Chicken 2.4 or 2.5, thats why it doesnt work. http://chicken.wiki.br/dev-snapshots/2008/08/07/chicken-3.3.8-linux-x86.tar.gz is a linux binary. somewhere on the wiki theres a page with updated debian packages. -elf On Mon, 11 Aug 2008, Jörg F. Wittenberger wrote: Am Montag, den 11.08.2008, 05:27 -0700 schrieb Elf: do you already have chicken installed? if so, pass it a CHICKEN=/path/to/chicken arg. Let's try. I f*ed my chicken up. apt-get install chicken-bin on Ubuntu installed a version, which did not compile the current source. Eventually - but don't ask me how - I ended up with some executables. But those run into segfauls upon startup. Currently building once again... if not, install it. its a known problem with the make system, and will stp being a problem soon. other builds that wont work atm: cygwin: missing several -Wl options from the program linker var mingw: same thing msys: same thing (plus msys needs some major work, as its closer to cygwin than to mingw.) something that works sometimes to create builds is to manually unpack the bootstrap.tar.gz , touch *.c , and try again. -elf On Mon, 11 Aug 2008, Jörg F. Wittenberger wrote: Hi, a few minutes ago I checked out a fresh copy of the chicken source from svn but failed to build it. Neither dpkg-buildpackage nor make ... bootstrap got the job done. I wanted to fix this in the make process, but failed to understand why the bootstrap target is always build after chicken, not before. /Jörg ___ 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: make-parameter, parameterize SRFI-39
absolutely not. first, why will it be difficult for you to set up a clean build environment? second, your patches will flat out not work in default chicken. A) why are you sending a patch of the debian rules customised for your box? B) you are fundamentally changing the representation of parameters. C) redundant/unnecessary code - you duplicated a case. D) inconsistent naming scheme E) there are around 300 occurences of parameters in chicken core. many eggs use large numbers of paramters. have you tested fully, or even partially, the effects of changing structure? mucking about with parameters can and will break just about everything. third, there has been no consensus and very little discussion regarding parameter models yet, so methinks you may be jumping the gun. if you want a shared variable between threads, dont make it a parameter. if you want a thread-local variable, parametrise it. i dont see why this requires changing core structure. -elf On Mon, 11 Aug 2008, Jörg F. Wittenberger wrote: Hi all, since there where no more responses on my last post to this thread, I decided that it might be the best to supply a patch to this list, which adds a procedure make-shared-parameter extending the existing make-parameter in a compatible way. The attached diff (against svn revision 11597) should have no impact on the standard procedure make-parameter and the parameterize macro. However if the parameter is a shared parameter, only parameterize will create a local binding for that parameter (or the to-be-undocumented interface: call the parameter procedure with a second argument). I'd appreciate if this could make it into the chicken core - otherwise it's going to be a pain to set up a clean build environment in my case. Best regards /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: make-parameter, parameterize SRFI-39
On Mon, 11 Aug 2008, Jörg F. Wittenberger wrote: Am Montag, den 11.08.2008, 07:28 -0700 schrieb Elf: absolutely not. first, why will it be difficult for you to set up a clean build environment? Because I'll have to rebind parameterize, which is then going to be available to eval, where it could access parameter objects, which where created with the default make-parameter since I do not know how to rebind make-parameter and be sure to do so before any other parameters are set. Also code compiled with the standard implementation would not work correctly anymore, if those shared parameters where passed in. This all looks to me like the box of pandora full of sources of confusion. second, your patches will flat out not work in default chicken. B) you are fundamentally changing the representation of parameters. Really? At least that (supposed to be - modulo bugs I made) all compatible with the old version. It introduces just two more comparison in the value look up. And one more optional parameter to make-parameter. Does this already qualify as a fundamental change? no, but changing from a cons structure to a slotted structure does. changing the meaning of the cells in the cons does as well. C) redundant/unnecessary code - you duplicated a case. I can't see that one. sorry, my error on that one. D) inconsistent naming scheme Which one would be better? is it guard or guard+type? this was more of a personal pet peeve rather than a fundamental flaw, as you changed it one place but kept the previous behaviour in the new case. i must add two that i missed originally as well, which is 'breaking backward compatibility' and 'inconsistent semantics of the cons cell handling' E) there are around 300 occurences of parameters in chicken core. many eggs use large numbers of paramters. have you tested fully, or even partially, the effects of changing structure? mucking about with parameters can and will break just about everything. I have tested the implementation. But to which extend should this be done. The new case applies only if there's a shared parameter object and it is called from the modified parameterize. I had preferred to pass some special key, which the user can not produce, but I don't know how to express that in chicken. The standard case will just ignore the additional argument. Against which possible impact should I test? if youre mucking about with parameters, you should test things like http, spiffy, various sql bindings, some of the format eggs, sxml, etc. almost everything uses paramters. you should test to see what happens when you use certain declarations. you should test all of the functionality listed on the 'parameters' page of the manual. full testsuite. third, there has been no consensus and very little discussion regarding parameter models yet, so methinks you may be jumping the gun. if you want a shared variable between threads, dont make it a parameter. The point is: there is a large code base, which is supposed to run under different Schemes. I'm trying to find the minimal diff. It's already hard enough and I'm a not entitled to break the deployed version at any time. (I just spent 3 days without success trying to figure why this test case http://lists.gnu.org/archive/html/chicken-users/2008-08/msg00029.html fails if and only if the thread hangs on tcp *and* there are two nested condition handlers (while other ways to hang or just one condition handler will work as to be expected). are you using thread-signal or thread-terminate, btw? it DOES matter, very much, which you use, i think. it would probably be advisable to read the bloody manual for tcp as well, as there are parameters in place for setting timeouts already. i would also suggest rtfm for srfi-18, as it has timeout args to most of the procedures as well. if you want a thread-local variable, parametrise it. i dont see why this requires changing core structure. All I need: a thread-local variable and a way to set it's default value from a thread, while accessing the thread-local one within parameterize. How should I do that? this sentence does not make sense. does setting the global default change the values on all the copies currently in threads? if so, its not local. how does setting the global value affect those already around? i would probably do something like: (make-parameter (vector data)) for shared parameters, since only a shallow copy is done, all values would be synchronised. then you (vector-ref (param)) and (vector-set! (param) 0 val). -elf___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: An alternative thread system?
not exist in the other. -elf terminating your threads since you bought them last week, boyy ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: An alternative thread system?
On Mon, 11 Aug 2008, Shawn Rutledge wrote: However what about the case where there is a UI event loop and the same program also has to poll one or more event sources, such as dbus, or a socket or a pipe, for output from one of those helper processes that you redesigned to be a process rather than a thread? In C your main choices are to use select() to wait for an event from any of those sources (only as long as your program has nothing else to do while it's waiting, and as long as you can gather all the file descriptors into one list to be able to use select), or use non-blocking I/O and poll each source manually, or use threads to pretend that you can poll everything in parallel. this is one of the good uses of threading, yes :) it is possible to design an equivalent structure using neither threads nor polling (Except when theres nothing else to do), its just a hideous thing. (also, select Does Not Do What You Think It Does in Windows) In the dbus egg I use a polling thread (a Chicken thread not a native one). This hides the complexity nicely: the user of the egg does not need to care about polling, it appears instead that the appropriate callback function can be called spontaneously when a DBus event occurs. If I wish to preserve that interface, do I really have any no, of course not. this is one of the few areas where threads are a clear win. theres a reason... the worker threads dont have effectively limitless extent. replace 'thread' with 'procedure' and youll get the same results :) this type of threading, for x gooey stuff... thats one of the few really clear wins. this may have something to do with threading and parallelism getting lots of attention partially due to this idea of 'event loops' for 'graphical interfaces' ... in 1983 or so :) Maybe Chicken could have a higher level abstraction for callbacks. It would then have the choice of using either select() or threads under the covers. theres a much higher-level waiting semantics for io that is nearly complete (because select doesnt do what you think it does on all systems. particularly windows.) explain more about what you want from callback abstraction? A long time ago (when working at my first software job, which happened to be on OS/2) You'd admit to working on OS/2? Brave man. it struck me I would have too. :) that it's too bad events which originate from hardware often have to be polled in software. E.g. a UART generates an interrupt when a character is received; the OS handles it and puts the character in a buffer, and the application must poll the buffer to see when there is data available. Maybe the OS could tell the interested application each time a character is received (and still do the buffering, in case the app doesn't want to handle each character one-at-a-time). Of course it works well enough, it's just a philosophical thing. (And maybe in fact when using select(), maybe breaking out of this blocking call is in fact triggered directly by the interrupt?) So I guess I'm thinking along the same lines about callbacks in general: tell me when X happens should not have to mean waste a bunch of cycles polling until X happens and then call me. But as long as polling threads are the only practical way to do callbacks, there is no chance to even try to do an optimization like that.a first, its not a practical optimisation. for a keyboard, or a small-payload character oriented device, sure. how about a network card? single byte input isnt useful unless you only have one potential reader and one potential writer. it also would make it very hard to handle things like packet defrag. second, are you familar with the various distributed programming efforts? termite may be a good place to start. theres ivan raikov's excellent mpi eggs. theres all sorts of parallelism and synchronicity eggs in the repo. theres also smart scheduling of threads, which im trying to work out. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: An alternative thread system?
On Tue, 12 Aug 2008, Aleksej Saushev wrote: Elf [EMAIL PROTECTED] writes: On Mon, 11 Aug 2008, Aleksej Saushev wrote: snip is shared access to memory, which you can easily avoid. Pipes are not that simple actually, to pass some complex structure through pipe, you need to pack it to some structure on one end, parse and unpack on the other end (note all those XML/YAML encodings), while with _some_ shared memory you could just pass the reference. Again, the problem isn't in threads or shared memory, it is in abstractions used. It is like modular programming vs. the ancient non-modular one (with lots of shared variables c). Disagreed absolutely. Threads can be incredibly complex to debug, even ignoring shared memory issues. Threads can get stuck in dependency loops very quickly while waiting on I/O, even from possibly different sources. How does it differ from communicating processes in this respect? Single threaded processes cant get stuck in mutual dependency loops. Oh, really? Create socket, start two processes, and wait on input on both sides. Of course, the OS will save you, it magically knows how to reschedule them. a) thats not a deadlock. thats gino programming. (garbage in, nothing out) b) a realistic, feasible version of this (say, three threads, one writer and two readers) is trival to avoid in the process model, but incredibly complex at best in the thread model. plus in the thread model, youd have one fd repeated twice in a single select call, which is always entertaining. The OS can reschedule them. Single threaded processes can be written in such a way to guarantee that whatever is being waiting for is the next thing that needs to be run. Threads generally cannot do either of these. There is no general purpose method of breaking deadlocks in pure thread models that does not violate consistency of one or more of the deadlockers. Have you ever used operating system with no MMU? Processes and threads are the same in relevant parts here. There's no difference in behaviour of multiple processes and multiple threads, in both cases you see deadlocks, races and contention. All relevant mechanisms are just the same. the first sentence made no sense. processes all work in their own space, with their own interrupt and error handling, with a completely deterministic state. threads share space but more importantly they share the timeslice for the same process. the order of the threads being run is indeterminate. it is not possible to absolutely determine the control flow of the threaded model as soon as more than one thread is active. This is the biggest difference between threads and processes, from a user viewpoint. Processes only have to know about themselves, and how they operate, to maintain consistency/correctness. That's not true. If processes operate cooperatively, they should know about each other. E.g. SMTP and NNTP server and client, ssh server and client, etc. If some SMTP goes wild, the other has to drop connection after timeout. Database replication daemons are even more dependent on mutual communication protocol. no, they can follow a scripted protocol. they dont need to know anything about the other's actual internal state. they dont need to know what else its doing, or if its waiting, or if it can talk right then, because they KNOW it can talk right then, cause theyve either received the message or exceeded the timeout. designing deterministic protocols is an entirely separate issue and one you yelled at me about below. Threads can get interrupted in all kinds of unpleasant ways without being detectable as such. Irrelevant again, so are processes. No, they cant. There isnt a per-thread signal handler The original topic has nothing with signal handlers, OS scheduler can just stop process and swap it off for a while, you have rather limited control over it, unless you're doing real-time job. i said that threads can get interrupted in all kindso f unpleasant ways that processes werent susceptible to. the original topic had to do with thread model vs process model. signal handling is an important aspect of this, as thread-kill/thread-signal are signal-oriented and thread-terminate/thread-suspend are condition-handler oriented, and the ORIGINAL topic was thread-terminate. i have no idea why youre talking about os scheduler swapping, which is totally invisible to the process, whhereas i was saying that even which thread a given signal is applied to is indeterminate in the current model, because theres only one handler for the entire process, not one per thread. do you actually read the entire thing i write, or just half of the first sentence? (at least not at the moment) in chicken, there is one signal handler that accepts everything. Which signal may be aimed at whom is for the signal sender to know and the scheduler to guess. (Do you feel lucky, punk? :) ) That's the limitation of particular virtual machine
Re: [Chicken-users] Re: An alternative thread system?
On Tue, 12 Aug 2008, Aleksej Saushev wrote: Shawn Rutledge [EMAIL PROTECTED] writes: I'm inclined to agree with the argument that as long as forking has a low enough overhead, processes are better than threads for general-purpose parallelism. Especially considering that if you are using memory to share state between threads, you will always be limited to a shared-memory architecture - you cannot move the program unmodified onto a cluster. But there is more data-copying involved with message-passing, compared to just accessing the same memory. Safety and portability have their price. Your attitude to threads is just a prejudice with no support behind it. Irrelevant personal attack without basis. Most overhead originates not from fork, it comes from copying and IPC. Passing data between threads may be as simple, as assignment. Note: no context switch involved. Passing data between processes is almost always two context switches, synchronization in kernel, and copying passed data at least twice, unless you use some very system-specific hack. Sometimes you can avoid redundant copying by mmaping common file, which still brings you to shared-memory and all the stuff connected. There's the price of your prejudices in terms of performace lost. Show me some numbers to back this up. Show me also how to pass data between threads without mutexes (which block) (which cause context switches) in a safe way. Show me data. If you work within properly choosen framework, you may care very little about what you are running actually, a thread or a process on another machine. Having one subroutine, that merely passes the pointer to locals and communicate over network to remote, is easy enough, if you don't pass linked structures. Generally, you can only work on processes on some other machine, cause the thread model is going to be different and 9/10 times incompatible, with a generous estimate. Properly chosen framework find me a portable properly chosen framework that works more on $(OS OF CHOICE). two unixes, macosx, and at least one modern (post 98) version of windows. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Please do not drop 'thread-terminate!' from the SRFI 18 impl
On Sat, 9 Aug 2008, John Cowan wrote: Kon Lovett scripsit: I guess I just prefer social rather than legal prescriptions. Prohibition is an attack on symptoms not causes. Why have we eliminated dynamic binding of lambda variables? Why don't we allow you to take the car or cdr of (), or of a symbol? Why are uncontrolled define-macro macros on their way out? Because having them does more harm than good. Uncontrolled use of threads is the same story. not really. you cant take the car or cdr of an atomic object: the slots dont exist. threads do exist, and they can be killed. define-macro is a subject of much contention. it doesn't seem to be on the way out for CL, or for any of the r4 implementations, and note that RSC macros are basically the same thing... these arent relevant comparisons. more relevant comparisons would be other thread/concurrency systems: do any not allow threads to be killed? pth has suspend and cancel, with certain restrictions to prevent inconsistency. posix.1 does as well. nspr seems to. winapi does. a more relevant comparison (and answer) might be 'why don't we get rid of 'kill -9'?' i dont think removing necessary, albeit dangerous (atm), functionality is a good idea. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Please do not drop 'thread-terminate!' from the SRFI 18 impl
On Sun, 10 Aug 2008, John Cowan wrote: Elf scripsit: you cant take the car or cdr of an atomic object: the slots dont exist. And yet in CL and all the way back to Lisp 1.5, (car nil) = (cdr nil) = nil. In pre-CL Lisps, the CDR of a symbol was its property list; CL finally abolished that. [3] (car 'foo) *** - CAR: FOO is not a list in clisp's implementation. car and cdr did work, though. the NIL is way, way too overloaded in CL. these arent relevant comparisons. more relevant comparisons would be other thread/concurrency systems: do any not allow threads to be killed? As I pointed out before, Java has deprecated suspend and terminate: http://java.sun.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html java's thread model has been broken from the start. also note that its 'deprecated' rather than 'removed'. Here's Microsoft's own discussion of why ThreadSuspend should not be used (except by debuggers that need to freeze threads so it can inspect their contents, something Scheme doesn't support): http://msdn.microsoft.com/en-us/library/ms686345(VS.85).aspx actually, we do have breakpoints... Consequently, the .NET version is deprecated. (Note that thread-terminate! is the same as a thread-suspend! that is never resumed, so one argument applies to both.) TerminateThread is still in Vista, according to MSDN. POSIX threads have no suspend at all. (Some implementations add it.) i havent found a posix1003 implementation that DOESNT have it. Cygwin provides its own threading package, documented at http://www.navosha.com/ecos/c/cyg_thread.html . The suspend and terminate functions are marked dangerous, for the same old reasons. dangerous, yes. deprecated/removed, no. big difference. the srfi marks them as dangerous as well, as does the chicken documentation. In short, everyone provides suspension for backward compatibility with their thread-naive definitions, everyone deprecates it or strongly discourages its use. It is Considered Harmful. It should go. it is not 'Considered Harmful'. its dangerous if used randomly. the functionality is still necessary. furthermore, it should be possible to create a threading model that would NOT leave processing in an inconsistent state (and in fact i am working on such a thing). a more relevant comparison (and answer) might be 'why don't we get rid of 'kill -9'?' Because there are very few shared resources between processes, and the kernel knows how to clean them up (with the exception of terminal settings). Threads, by contrast, in principle share everything, and nobody knows how to clean up. have you ever had mozilla (or firefox, or whatnot) crash? and then run ipcs? and had to clean up 3 or 4 shared memory segments and usually 1 or 2 semaphores by hand? srfi-18 threads do NOT share everything. and it is fairly easy to write code in such a way that any damage from termination etc is cleanup-able (or at least does not leave things in an inconsistent state). use your parameters. call lambdas that create threads with all the vars they can access. use ports to communicate between threads. its not that bloody difficult. i dont think removing necessary, albeit dangerous (atm), functionality is a good idea. Lispers spent decades thinking dynamic binding of lambda variables was necessary functionality even after they were finally convinced it was dangerous. Part of what made Scheme revolutionary was that it threw that functionality away (and CL followed, breaking with the past). what are you talking about? fexprs? im confused here. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] An alternative thread system?
We are not doing native threads. Period. Brief explanation: I've been spending most of the last 6 months, now, just trying to get I/O working properly on the various platforms we support. Threading is right out of the question. There are too many threading models on our supported platforms, very few of which have compatible semantics. Just trying to keep the bugs from a multiplatform threading implementation under control would be a more-than-fulltime job. This is why NO KNOWN MULTIPLATFORM LANGUAGE IMPLEMENTATIONS HAVE WORKING NATIVE THREADING. NO KNOWN MULTIPLATFORM LIBRARY IMPLEMENTATIONS HAVE WORKING NATIVE THREADING. There is a reason for this. If you don't believe me, delve into the source and bugtree of whatever language you claim does support native threading on windows, macosx, and at least two unixes. If you want to take advantage of multiprocessing, spawn new processes. There are already all kinds of synchronisation and communication and distributed programming eggs out there. The blocking I/O issues will be cleaned up very shortly, and I agree they are annoying. :) -elf (thread-terminate! [Chicken-Users]: re: thread-terminate!) too bad :) On Sun, 10 Aug 2008, Adam C. Emerson wrote: Good evening, gentle creatures, Whatever overhaul the interface and model get, I think the implementation needs some work, too. I/O blocking everything (with the exception of TCP and the REPL) is somewhat annoying. Having green threads keeps Scheme programs from taking advantage of multiple processors. And, while dangerous, it would also be nice to have other threads continue running while one is blocked in a C library call, though obviously the programmer would have to know his library and not schmutz things up. Thank you. ___ 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] Segfault - a hard one
On Sat, 9 Aug 2008, felix winkelmann wrote: 4) Make the worker thread check a global (or thread-local, but accessible from outside) status and let it terminate itself. this is the way suggested in the srfi-18 docs, iirc, using the slot. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Please do not drop 'thread-terminate!' from the SRFI 18 impl
On Fri, 8 Aug 2008, Vincent Manis wrote: My preference is the same as John Cowan's: kill it. If not, put warnings in the manual. I don''t find SRFI-18's warning (in the paragraph headed NOTE:) strong enough, as it uses the phrase `may be a problem', not `is virtually guaranteed to be a problem'. Further, I don't know what fraction of Chicken users actually go and read the SRFIs. its fairly hard to use the threading in chicken without reading the srfi first, as thats where its documented :) im against removing thread-terminate! and friends because theyre useful. id rather deprecate mutexes and the like for a cleaner system of currency, or (at the very least) augment thread-terminate! in such a way that it waits to terminate until the held mutexes (mutii? mutices?) are dropped. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
#;1 (condition-case (with-input-from-string ) read) (var () no prob)) no prob #;2 (condition-case (call-with-input-string ) read) (var () no prob)) no prob #;3 On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: Am Dienstag, den 29.07.2008, 18:06 +0900 schrieb Ivan Raikov: What version of Chicken is this on? Your code works fine on my system (Chicken 3.3.0): $ ./tg condition-case-does-a-better-job-than-guard chicken -version CHICKEN (c)2008 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 3.3.4 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook hostpcre ] SVN rev. 11356 compiled 2008-07-19 on debian (Linux) Ivan, could you try this one too (precondition: chicken-setup srfi-34 ): --- % --- tg.scm --- (require-extension srfi-34 ports) (print (guard (ex (else 'success)) (call-with-input-string ) read))) --- % --- If this works too, I'll tear my chicken apart not my application. thanks a lot /Jörg BTW: Does anybody know how the Debian packages are being built? I installed binary from ubuntu 8.04 and got some newer version than what dpkg-buildpackage in my local copy produces (which claims Version: 3.2.0-0.2 for the very same thing as above). ___ 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] catching exceptions
#;1 (use srfi-34) ; loading /usr/lib/chicken/3/srfi-34.scm ... ; loading /usr/lib/chicken/3/syntax-case.so ... ; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ... ; loading library srfi-18 ... #;2 (print (guard (ex (else 'success)) (with-input-from-string ) read))) success #;3 (condition-case (with-input-from-string ) read) (val () no prob)) no prob #;4 (condition-case (call-with-input-string ) read) (val () no prob)) no prob #;5 wasnt srfi-34. -elf On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: ERR Double checked: it's SRFI-34, which is in the way! I accidentally left (require-extension srfi-34) in the code I compiled to test condition-case. Once removed, the error get caught. So we have the bug in srfi-34.egg - definately. Am Dienstag, den 29.07.2008, 11:35 +0200 schrieb Jörg F. Wittenberger: Am Dienstag, den 29.07.2008, 18:06 +0900 schrieb Ivan Raikov: What version of Chicken is this on? Your code works fine on my system (Chicken 3.3.0): $ ./tg condition-case-does-a-better-job-than-guard thanks anyway. still wondering about the way .deb's are build. /Jörg ___ 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] catching exceptions
srfi-34 is meaningless without srfi-35 and srfi-36. nothing in srfi-34 details the actual format of exceptions/conditions. all of this is self-contained in srfi-12. the reason for srfi-12's withdrawl was not because of any flaws inherent in srfi-12, but because william clinger, the author, disappeared apparently for a bit and therefore there was no discussion. srfi-34 and related srfis are brittle and encode things in a nonschemelike way, with a lot of extra parsing and ridiculousness involved. -elf On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: Am Dienstag, den 29.07.2008, 04:48 -0700 schrieb Elf: the reason for the incompatibilities is that chicken uses the srfi-12 exception model, not the srfi-34, as the srfi-12 model is cleaner, more flexible, and doesnt require six other srfis in order to work. I'm not (yet) interested in arguing about the pro's and con's of various exception systems. At least not until I get the one working, which is an accepted SRFI. I just can't believe that chicken is too weak to implement that one. Furthermore I fail to see, which six other srfi's are needed by srfi-34. The srfi document claims dependencies on srfi-9 and srfi-23. But I can see only srfi-23 (error) being used. The problem I do have has actually nothing to do with exception handling and advantages of either srfi. It has to do with some magic, which prevents setting variables as Scheme is supposed to allow. That might be ok, if and only if, I can break through this fence. BTW: once I got SRFI-34 working, I'd really be interested to learn about your opinion and what is a) cleaner and b) more flexible in srfi-12. I'm not religious about the exception system. There are exactly two reason, why I insist and going to insist on srfi-34: I) standard is better than better and II) I depend on it for portability. best regards /Jörg -elf On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: Am Dienstag, den 29.07.2008, 03:21 -0700 schrieb Elf: #;1 (use srfi-34) ; loading /usr/lib/chicken/3/srfi-34.scm ... ; loading /usr/lib/chicken/3/syntax-case.so ... ; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ... ; loading library srfi-18 ... #;2 (print (guard (ex (else 'success)) (with-input-from-string ) read))) success #;3 (condition-case (with-input-from-string ) read) (val () no prob)) no prob #;4 (condition-case (call-with-input-string ) read) (val () no prob)) no prob #;5 wasnt srfi-34. True. Was the old version of srfi-34, which I could not get replaced because of some network errors and probably some confusion on my part. Those - and my workaround - revealed some confusion wrt. chicken related resources: I fetched manually http://www.call-with-current-continuation.org/eggs/srfi-34.egg This is still version 0.1 at this time. chicken-setup - which refused to download last time (yesterday I think) - now finds version 0.2 as changed by Elf recently. However version 0.2 seems non-functional too. Though it catches exceptions, which the 0.1 version prevented to catch, it failes on several tests from the SRFi-34 examples. (print (guard (ex (else 'success)) (call-with-input-string ) read))) = success OK 1st example from srfi-34: (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display condition: ) (write x) (newline) (k 'exception)) (lambda () (+ 1 (raise 'an-error)) PRINTS: condition: an-error = exception chicken prints: condition: #condition: (exn) 5th example: (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display reraised ) (write x) (newline) (k 'zero)) (lambda () (guard (condition ((positive? condition) 'positive) ((negative? condition) 'negative)) (raise -1)) = positive chicken: reraised #condition: (exn type) Ergo: raise from SRFI-18 - i.e., ##sys#signal from library.scm is not compatible with SRFI-34 (btw: this is obvious from the source) and needs to be replaced. But I'm not entirely clear what the problem actually is. To me it seems to be related to my disability to change some of chickens variables as I want to and apparently the chicken library.scm happens to have the same problem. Let's see: (condition-case (with-exception-handler (lambda (ex) (print Toplevelhandler: ex)) (lambda () ((current-exception-handler) 1))) (var () (print Backstop: var))) prints: Toplevelhandler: 1 (condition-case (with-exception-handler (lambda (ex) (print Toplevelhandler: ex)) (lambda () (raise 1))) (var () (print Backstop: var))) Loops printing: Toplevelhandler: #condition: (exn) Assembling the relevant definitions from chicken's source we find: srfi-18.scm: (define raise ##sys#signal) library.scm: (define (##sys#signal x) (##sys#current-exception
Re: [Chicken-users] catching exceptions
furthermore, srfi-34 can be written entirely in terms of srfi-12, while the reverse is not true. -elf On Tue, 29 Jul 2008, Elf wrote: srfi-34 is meaningless without srfi-35 and srfi-36. nothing in srfi-34 details the actual format of exceptions/conditions. all of this is self-contained in srfi-12. the reason for srfi-12's withdrawl was not because of any flaws inherent in srfi-12, but because william clinger, the author, disappeared apparently for a bit and therefore there was no discussion. srfi-34 and related srfis are brittle and encode things in a nonschemelike way, with a lot of extra parsing and ridiculousness involved. -elf On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: Am Dienstag, den 29.07.2008, 04:48 -0700 schrieb Elf: the reason for the incompatibilities is that chicken uses the srfi-12 exception model, not the srfi-34, as the srfi-12 model is cleaner, more flexible, and doesnt require six other srfis in order to work. I'm not (yet) interested in arguing about the pro's and con's of various exception systems. At least not until I get the one working, which is an accepted SRFI. I just can't believe that chicken is too weak to implement that one. Furthermore I fail to see, which six other srfi's are needed by srfi-34. The srfi document claims dependencies on srfi-9 and srfi-23. But I can see only srfi-23 (error) being used. The problem I do have has actually nothing to do with exception handling and advantages of either srfi. It has to do with some magic, which prevents setting variables as Scheme is supposed to allow. That might be ok, if and only if, I can break through this fence. BTW: once I got SRFI-34 working, I'd really be interested to learn about your opinion and what is a) cleaner and b) more flexible in srfi-12. I'm not religious about the exception system. There are exactly two reason, why I insist and going to insist on srfi-34: I) standard is better than better and II) I depend on it for portability. best regards /Jörg -elf On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: Am Dienstag, den 29.07.2008, 03:21 -0700 schrieb Elf: #;1 (use srfi-34) ; loading /usr/lib/chicken/3/srfi-34.scm ... ; loading /usr/lib/chicken/3/syntax-case.so ... ; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ... ; loading library srfi-18 ... #;2 (print (guard (ex (else 'success)) (with-input-from-string ) read))) success #;3 (condition-case (with-input-from-string ) read) (val () no prob)) no prob #;4 (condition-case (call-with-input-string ) read) (val () no prob)) no prob #;5 wasnt srfi-34. True. Was the old version of srfi-34, which I could not get replaced because of some network errors and probably some confusion on my part. Those - and my workaround - revealed some confusion wrt. chicken related resources: I fetched manually http://www.call-with-current-continuation.org/eggs/srfi-34.egg This is still version 0.1 at this time. chicken-setup - which refused to download last time (yesterday I think) - now finds version 0.2 as changed by Elf recently. However version 0.2 seems non-functional too. Though it catches exceptions, which the 0.1 version prevented to catch, it failes on several tests from the SRFi-34 examples. (print (guard (ex (else 'success)) (call-with-input-string ) read))) = success OK 1st example from srfi-34: (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display condition: ) (write x) (newline) (k 'exception)) (lambda () (+ 1 (raise 'an-error)) PRINTS: condition: an-error = exception chicken prints: condition: #condition: (exn) 5th example: (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display reraised ) (write x) (newline) (k 'zero)) (lambda () (guard (condition ((positive? condition) 'positive) ((negative? condition) 'negative)) (raise -1)) = positive chicken: reraised #condition: (exn type) Ergo: raise from SRFI-18 - i.e., ##sys#signal from library.scm is not compatible with SRFI-34 (btw: this is obvious from the source) and needs to be replaced. But I'm not entirely clear what the problem actually is. To me it seems to be related to my disability to change some of chickens variables as I want to and apparently the chicken library.scm happens to have the same problem. Let's see: (condition-case (with-exception-handler (lambda (ex) (print Toplevelhandler: ex)) (lambda () ((current-exception-handler) 1))) (var () (print Backstop: var))) prints: Toplevelhandler: 1 (condition-case (with-exception-handler (lambda (ex) (print Toplevelhandler: ex)) (lambda () (raise 1))) (var () (print Backstop: var))) Loops printing: Toplevelhandler: #condition: (exn) Assembling the relevant definitions
Re: [Chicken-users] poached, scrambled, boiled, sunny-side-up, omelette...
YAY! Grats Tony! -elf On Sat, 26 Jul 2008, felix winkelmann wrote: On Sun, Jul 20, 2008 at 3:45 PM, Elf [EMAIL PROTECTED] wrote: or any other way you'd like, i think we're reached 400 eggs, with Ivan's WebDAV egg and a SOAP egg contributed by someone who wishes to remain anonymous and added by myself. yay!!! Rejoice! The winner has been pseudo-randomly selected and is named (oh, the SUSPENSE): Tony Sidaway The necessary formalities will be taken care of by yours, truly. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] tinyclos and the repl
are you using the eval unit and using the repl function contained therein, or did you roll your own repl? also, you should be able to require the chicken-more-macros via (require 'chicken-more-macros) at the top. -elf On Thu, 24 Jul 2008, Jörg F. Wittenberger wrote: Am Donnerstag, den 24.07.2008, 12:57 +0200 schrieb Thomas Chust: Rene Sansman wrote: [...] Chicken has worked wonderfully for me so far, but now I have run into a problem I don't know how to solve. I want to use tinyclos from the repl, but it does not work. I can use it from compiled code or from the interpreter, but not from a repl that I start from a compiled scheme file. [...] Hello, the REPL started from your program doesn't have access to the same macros as the compiled source. There are at least two possible solutions to this problem: You can explicitly load the tinyclos support macros at runtime or you can instruct the compiler to retain all macros for runtime using a (declare (run-time-macros)) form. There must be at least one more trick. I failed to get the latter working. Or better say: I got it half working: macros *defined* in the unit, which did (declare (run-time-macros)) where available, but I failed to get chicken-more-macros included. How would I do that? thanks /Jörg ___ 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] tinyclos and the repl
(also, if you (declare (uses eval)) , theres a (repl) procedure that will handle most all of this for you, along with hooks if you want to do your own modifications... read eval.scm in the chicken source for more details. :) im not familiar with srfi-49, but the behaviour that i think you were describing contradicts the (read) procedure as described in r5rs: read should return the next scheme object available on the port, updating the port's location to exactly one char after the character ending the object. (ie, the next char, not the beginning of the next object, unless the next char is also the next object.) what exactly are you trying to do, if i may ask? -elf On Thu, 24 Jul 2008, Jörg F. Wittenberger wrote: Am Donnerstag, den 24.07.2008, 07:19 -0700 schrieb Elf: are you using the eval unit and using the repl function contained therein, or did you roll your own repl? also, you should be able to require the chicken-more-macros via (require 'chicken-more-macros) at the top. Thanks a lot, the additional (require 'chicken-more-macros) right after the (declare ...) did the trick. (I'm using load as it is, so probably from eval.) BTW: I noticed, that the SRFI-49 reference implementation (no matter how bad that may feel on it's own - though I have a lot of single, simple expressions embedded in XML attributes - there's it is a win for the lazy programmer) - yeah, that implementation does not play nice with chicken. It assumes that it can call read on a port when peek-char returns #\( and assumes that, once read read the expression, can continue to read from the port right after the corresponding #\) . Unfortunately chicken's read has already read from the port until the next #\( - so the SRFI-49 code gets confused. Does anybody have a nice Scheme reader in pure Scheme or Chicken-Scheme at hand? best regards /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] tinyclos and the repl
what do you mean by a 'pure scheme reader'? -elf On Thu, 24 Jul 2008, Jörg F. Wittenberger wrote: Am Donnerstag, den 24.07.2008, 16:53 +0200 schrieb Jörg F. Wittenberger: Unfortunately chicken's read has already read from the port until the next #\( - so the SRFI-49 code gets confused. Does anybody have a nice Scheme reader in pure Scheme or Chicken-Scheme at hand? Sorry, I blamed the wrong end. It was actually me, who made the mistake. Nevertheless: if someone has a pure Scheme reader (without any chicken- or whatesoever-specific read extensions at hand: I'd appreciate a copy. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
chicken already supports most of srfi-34 natively and the rest is supported via an egg. have you looked at all at the manual or at the egg libs yet? -elf On Thu, 24 Jul 2008, Jörg F. Wittenberger wrote: Hi all, I have some lines of Scheme, which rely on SRF-34 and I don't really want to change that code. I can hardly imagine, that I can't replace chickens exception handler. But I can't. What I tried was to overwrite ##sys#error and friends (see appended source - which does not really get the job done). [The next step is going to be funny formating and routing of those exceptions. So I *really* need to get them under control. So how would I plug my exception handler in place of the standard exception handler? Thanks a lot ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] poached, scrambled, boiled, sunny-side-up, omelette...
here is a file. this file was created by me going through all 11400 or so commits in the log by hand. we really need the autoscripts to log when new eggs become active. this is the best i could do, as 'hidden' attribute changing isnt listed anywhere that i could see. anyway! if someone wants to wikify this, it would be appreciated. the format for the qualified eggs is: SEQUENCENUM: EGG_NAME [AUTHOR_NAME*] [MMDD] [EXTRA]? the [] braces are literal. the date is when the directory was first committed into svn, unless i was personally aware of when the egg became usable. AUTHOR_NAME is the name(s) of the author(s), optionally followed by , Chicken port by MAINTAINER_NAMES. EXTRA, if it exists, is a note about the egg. the only note given is UNSUPPORTED, when the egg is listed in the redundant/unsupported section of Eggs Unlimited. eggs that have undergone renaming etc are only listed once, under the current name. at the bottom is a list of eggs NOT included in the list, along with the reason. who is going to run the (random-seed) (random 50) script? -elf On Mon, 21 Jul 2008, felix winkelmann wrote: On Sun, Jul 20, 2008 at 3:45 PM, Elf [EMAIL PROTECTED] wrote: or any other way you'd like, i think we're reached 400 eggs, with Ivan's WebDAV egg and a SOAP egg contributed by someone who wishes to remain anonymous and added by myself. yay!!! Whoa! Applause!!! We need to roll the dice. Elf, would you like to take that in your hands (updating the list at http://chicken.wiki.br/the-chicken-lottery and selecting the winner) ? cheers, felix : In the beginning, there was the Chicken. [Felix Winkelmann] 0001: ajax [Felix Winkelmann] [20051024] 0002: aquaterm [Thomas Chust] [20051024] 0003: args [Zbigniew Szadkowski] [20051024] 0004: asxt [Neil van Dyke] [20051024] 0005: autoload [Alex Shinn] [20051024] 0006: awk [Olin Shivers, Chicken port by Felix Winkelmann] [20051024] 0007: base64 [James Bailey] [20051024] 0008: bb [Felix Winkelmann] [20051024] 0009: binary-parse [Oleg Kiselyov] [20051024] 0010: blas [Felix Winkelmann] [20051024] 0011: c3 [Alex Shinn] [20051024] 0012: charconv [Alex Shinn] [20051024] 0013: complex [Thomas Chust] [20051024] 0014: crypt [Thomas Chust] [20051024] 0015: crypt3 [Thomas Chust and Kon Lovett] [20051024] 0016: csv [Neil van Dyke] [20051024] 0017: datatype [Felix Winkelmann] [20051024] 0018: defstruct [Dorai Sitaram] [20051024] 0019: dissector [Taylor Campbell] [20051024] 0020: doctype [Zbigniew Szadkowski] [20051024] 0021: eggdoc [Zbigniew Szadkowski] [20051024] 0022: environments [Felix Winkelmann] [20051024] 0023: epeg [Peter Bex] [20051024] 0024: expat [Felix Winkelmann] [20051024] 0025: ezxdisp [n-sibata and Morihiko Tamai] [20051024] 0026: format [Dirk Lutzebeck] [20051024] [UNSUPPORTED] 0027: format-modular [Alejandro Forero Cuervo, Alex Shinn and Kon Lovett] [20051024] 0028: ftp [Felix Winkelmann] [20051024] 0029: g2 [Felix Winkelmann] [20051024] 0030: gdbm [Alex Shinn] [20051024] 0031: generalised-case [Peter Bex] [20051024] 0032: generator [Kon Lovett] [20051024] 0033: gmp [Peter Keller] [20051024] 0034: hostinfo [Zbigniew Szadkowski] [20051024] 0035: html-stream [Alejandro Forero Cuervo] [20051024] 0036: htmlprag [Neil van Dyke] [20051024] 0037: http [Felix Winkelmann] [20051024] 0038: iconv [Alejandro Forero Cuervo] [20051024] 0039: imlib2 [Peter Bex] [20051024] 0040: inline [Felix Winkelmann] [20051024] 0041: irc [Felix Winkelmann] [20051024] 0042: iset [Alex Shinn] [20051024] 0043: japi [Felix Winkelmann] [20051024] 0044: lalr [Dominique Boucher] [20051024] 0045: lazy-ffi [Felix Winkelmann] [20051024] 0046: levenshtein [Kon Lovett] [20051024] 0047: lightning [Felix Winkelmann] [20051024] 0048: loop [Heinrich Taube] [20051024] 0049: magic [Peter Busser] [20051024] 0050: mailbox [Felix Winkelmann and Kon Lovett] [20051024] 0051: make [PLT, Chicken port by Felix Winkelmann] [20051024] 0052: man [Mario Goulart] [20051024] 0053: mapm [Peter Wang] [20051024] 0054: matcher [Andre van Tonder, Chicken port by Dale Jordan] [20051024] [UNSUPPORTED] 0055: md5 [Chistophe Devine, Chicken port by Felix Winkelmann] [20051024] 0056: meroon [Christian Queinnec, Chicken port by Felix Winkelmann] [20051024] 0057: metakit [Sergey Khorev] [20051024] 0058: miscmacros [Felix Winkelmann] [20051024] 0059: mole [Kirill Lisovsky] [20051024] 0060: mysql [Toby Butzon] [20051024] 0061: ncurses [Felix Winkelmann] [20051024] 0062: numbers [Felix Winkelmann] [20051024] 0063: oblist [Felix Winkelmann] [20051024] [UNSUPPORTED] 0064: opengl [Felix Winkelmann] [20051024] 0065: openssl [Thomas Chust] [20051024] 0066: pcap [Category 5] [20051024] 0067: phoghorn [Peter Bex] [20051024] 0068: pmatch [Mayer Goldberg] [20051024] 0069: pop3 [Felix Winkelmann] [20051024] 0070: postgresql [Johannes Groedem] [20051024] 0071: ppi [Michal
Re: [Chicken-users] Re: getopt, getopt_long?
On Mon, 21 Jul 2008, Shawn Rutledge wrote: On Fri, Jul 11, 2008 at 12:24 AM, Peter Bex [EMAIL PROTECTED] wrote: I agree completely. Actually, I tend to view things in the opposite way: WTF would anyone waste time trying to keep all those packages up-to-date, if you can just install it using chicken-setup? Because building them takes time. This has been my motivation for exploring cross-compilation: on my phone it takes several hours to compile chicken, and several more hours to compile the eggs I'm using. So when I'm short on time I spend more of it upgrading than actual development. I'm hoping that when OpenMoko is auto-generating new packages, and all I have to do to make that happen is visit the recipe(s) to increment the version number(s), the packages will indeed be fairly up-to-date, and it will only take a few minutes to install them. But on a real computer maybe it's a wash. An alternative idea: chicken-setup on the target could access a cache of pre-compiled eggs, on a server somewhere. If the server doesn't have it in the cache, then either the server can cross-compile it on behalf of the target machine, or the target could compile and upload it. (that depends on whether the server has the cross-toolchain or not) If the server always compiles, then once again the target does not need to have gcc, binutils, include files, dev libs etc. installed (which takes up more space than I have flash on the phone... which is why I have to run with an SD card to hold all the extra stuff) a cache of precompiled eggs is entirely impractical. the number of platforms supported alone makes this impossible, not even allowing for variations in the installed libraries (and library locations, on some systems) within a single system. however, since you already do have a cross-toolchain, what is to prevent you from doing such a thing locally? you know your own system (i hope!) and can instruct a crosscompiler to build correctly. you wouldn't even need chicken-setup (on the phone, that is)... all you'd need is a real machine accessible from the phone. when cross-compiling each egg, start with an empty egg dir. at the end of the compilation, bundle (zip, targz, whatever) the entire egg dir: viola, you have all the dependencies. :) its a little worse in terms of bandwidth in the worst cases, but youre more-or-less guaranteed to not run into problems due to dependencies or compilation that way. if you want to take it a few steps further, write a script that sends the current versions of all your installed eggs to your server, and use something like meta-setup to check (from the server) if anything needs upgrading, and if so, crosscompile it and send it back to the phone. (as the entire repo catalog is only around 30k, this is probably a win over packing all deps with every egg.) another simpler possibility is to not do anything from your phone directly. set up an environment acting like your phone on the main box and only install etc from there. then it should only be a matter of copying that environment to the actual phone. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] poached, scrambled, boiled, sunny-side-up, omelette...
On Mon, 21 Jul 2008, felix winkelmann wrote: On Sun, Jul 20, 2008 at 3:45 PM, Elf [EMAIL PROTECTED] wrote: or any other way you'd like, i think we're reached 400 eggs, with Ivan's WebDAV egg and a SOAP egg contributed by someone who wishes to remain anonymous and added by myself. yay!!! Whoa! Applause!!! We need to roll the dice. Elf, would you like to take that in your hands (updating the list at http://chicken.wiki.br/the-chicken-lottery and selecting the winner) ? actually... according to the count i just did, we're actually at 423 eggs, not counting the unsupported/redundant. (this is counting eggs which may not appear on the list, however). i can't run the lottery, i'm on the potential winners list! :) id be happy to update the list though, so the selection can be made. (as a sidenote, perhaps it would be a good thing to have the maintenance scripts autoupdate the submitted eggs list (assign a number or whatnot) whenever an egg first becomes public?) -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] poached, scrambled, boiled, sunny-side-up, omelette...
or any other way you'd like, i think we're reached 400 eggs, with Ivan's WebDAV egg and a SOAP egg contributed by someone who wishes to remain anonymous and added by myself. yay!!! -elf who is looking forward to the next 400 eggs ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup
pkgconfig is not standard across all supported operating systems. its development is sporatic, its ability to find its own files is not always the best, it cannot support multiple versions of products (with rare and generally REALLY broken exceptions), it breaks or partially breaks compatibility with itself all the time, and trying to integrate it nicely into any 'secondary' tools (ie, non-make) is aggravating in the extreme. i generally find it lower in utility and quality than even autotools. the pkg-config script itself does not support even a 'help' command, nor filtering, and trying to add directories without borking other things in such a way that any installed version of pkgconfig (opposed to ONLY 0.18 or 0.19 or 0.23 or whatever theyre on for this five months) will use it correctly is damn near impossible. -elf On Wed, 16 Jul 2008, Peter Bex wrote: On Tue, Jul 15, 2008 at 12:48:56PM -0700, Shawn Rutledge wrote: On Tue, Jul 15, 2008 at 12:11 AM, Peter Bex [EMAIL PROTECTED] wrote: I don't think this can be solved automatically (unless we want to recreate Autotools or CMake) so what is needed is a way to override or add to existing search paths by passing switches to chicken-setup, which it then can pass on to the compiler. Example: chicken-setup foo.egg -I /opt/foo/include -L /opt/foo/lib That could be a last-ditch way to solve problems but I would hope most users wouldn't need to do that for most eggs. Is there anything wrong with putting extra -I's and -L's in the meta file, with some possible guesses the egg developer can think of, where a particular library or include might be located? And chicken-setup could append the usual suspects automatically, like /usr/include, /usr/local/include etc. That simply won't do. Here's why: On OS X, you have Fink and Darwinports. Fink installs to /sw and darwinports to /opt/local. On NetBSD and many other systems you have pkgsrc, which installs to /usr/pkg. On FreeBSD you have ports, which installs to /usr/local by default, but on systems where people don't have root access they'll install somewhere under their homedirs, in which case all bets are off regarding the location. I have no idea how stuff works on native Windows, but you can bet there's very little standardization there. And then we haven't even touched on all the freaky places some Linux distros put things. (or /lib /lib64 differences for amd64) It's a reasonable assumption, however, to include Chicken's PREFIX in the search paths, since if people install Chicken using their package manager, very often it will get the same PREFIX as other packages that chicken eggs might want to wrap. As Min Thu suggested, using pkgconfig for programs which have that is a good idea, since that will ~always work properly. (perhaps provide a switch to disable usage of pkgconfig in case it isn't installed?) Cheers, Peter ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
oops, sorry about that. my 2c. chicken-setup is indeed overcomplex. i would propose a change not only to the chicken-setup and metadata files, but to the repo as well. as shawn said, there is a lot of duplication of data that should not be necessary. however, much of the actual compilation is *not* duplication, as extra bits like linked libraries need to be specified. i can draft a proposal for how to fix things based on my own experiences both with the repo and with chicken-setup, if people are interested. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
you can run chicken-setup in a way to compile an egg in-place in the current directory while you are developing it, right? rather than having to completely package it first, and without having to install it in its final location? I've been writing Makefiles for that, but figured there must be another way. chicken-setup -n (will run chicken-setup against any .setup files it sees in the local directory but will not install them. if you want them to be installed, it should be just 'chicken-setup') -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] thread makes csi eats lots of cpu
You're running readline in csi, yes? That blocks the threads. -elf On Fri, 11 Jul 2008, William Xu wrote: Run the following program in csi: (use posix srfi-18) (thread-start! (let ((max 5) (i 0)) (letrec ((thunk (lambda () (when ( i max) (print i) (thread-sleep! 1) (set! i (+ i 1))) (thunk thunk))) I'm expecting it to print 0-5. But the result is the following: , | #;2 #thread: thread0 | #;3 0 | | what? | Error: unbound variable: what? | #;3 1 | 2 | 3 | 4 ` It prints the first number 0, which is called before thread-sleep!. After that, it'll wait for me to input something random(here, what?), then it'll continute running the thread. The other problem is that after running this thread, and even after it's finished, csi starts to takes up to around 97% cpu usage!! on my dual core macbook. Then I have to restart csi. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: thread makes csi eats lots of cpu
oke, so youre on osx and its blocking from stdin... i was not aware of this. thank you. :) -elf On Fri, 11 Jul 2008, William Xu wrote: Elf [EMAIL PROTECTED] writes: You're running readline in csi, yes? That blocks the threads. I didn't install this egg. , | #;1 (use readline) | Error: (require) can not load extension: readline | | Call history: | | syntax (use readline) | syntax (##core#require-extension (quote readline)) | syntax (begin (##sys#require (quote readline)) (##core#undefined)) | syntax (##sys#require (quote readline)) | syntax (quote readline) | syntax (##core#undefined) | eval(##sys#require (quote readline))-- ` ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Profiling large programs
How large is the generated C file when profiling is not enabled? -elf On Wed, 9 Jul 2008 [EMAIL PROTECTED] wrote: Hi all. Compile times of chicken increase considerably when adding -profile. For example, 17 hours on a recent 2.4GHz processor instead of just some minutes without -profile. Furthermore, the resulting C file is 1.3GB so that it cannot be compiled by gcc. Here is the start of the resulting C file: /* Generated from nallch.scm by the CHICKEN compiler http://www.call-with-current-continuation.org 2008-07-08 18:46 Version 3.3.1 - linux-unix-gnu-x86 [ manyargs dload ] SVN rev. 10820 compiled 2008-05-14 on ki220 (Linux) command line: nallch.scm -debug-level 0 -optimize-level 1 -profile -output-file nallch3.c used units: library eval data_structures ports extras srfi_69 profiler posix srfi_1 */ ... Does anybody have any hints how to profile a large program? (Separate compilation is not an option for me, currently.) Ciao Sven ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Profiling large programs
Oh, and can you provide a link to the scheme source from which this happened? Thanks. -elf On Wed, 9 Jul 2008 [EMAIL PROTECTED] wrote: Hi all. Compile times of chicken increase considerably when adding -profile. For example, 17 hours on a recent 2.4GHz processor instead of just some minutes without -profile. Furthermore, the resulting C file is 1.3GB so that it cannot be compiled by gcc. Here is the start of the resulting C file: /* Generated from nallch.scm by the CHICKEN compiler http://www.call-with-current-continuation.org 2008-07-08 18:46 Version 3.3.1 - linux-unix-gnu-x86 [ manyargs dload ] SVN rev. 10820 compiled 2008-05-14 on ki220 (Linux) command line: nallch.scm -debug-level 0 -optimize-level 1 -profile -output-file nallch3.c used units: library eval data_structures ports extras srfi_69 profiler posix srfi_1 */ ... Does anybody have any hints how to profile a large program? (Separate compilation is not an option for me, currently.) Ciao Sven ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Profiling large programs
are you inlining anything in the scheme source? -elf On Wed, 9 Jul 2008 [EMAIL PROTECTED] wrote: Wed, 9 Jul 2008 10:55:07 -0700 (PDT), elf wrote: How large is the generated C file when profiling is not enabled? Only 37MB compared to 1300MB with profiling. (I cannot provide the Scheme source, but I assume that compiling chicken itself with -profile should show a similar effect.) Sven ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Profiling large programs
also, a 35X growth is not normal for profiling, and doesnt happen in the general case, which is why i was asking to see your scheme source. -elf On Wed, 9 Jul 2008 [EMAIL PROTECTED] wrote: Wed, 9 Jul 2008 10:55:07 -0700 (PDT), elf wrote: How large is the generated C file when profiling is not enabled? Only 37MB compared to 1300MB with profiling. (I cannot provide the Scheme source, but I assume that compiling chicken itself with -profile should show a similar effect.) Sven ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] RE: char=? question
are you converting from a symbol? if so, are you in case-insensitive or case- sensitive mode? where are W1 and W2 being defined? -elf On Thu, 12 Jun 2008, William Ramsay wrote: Now I'm even more mystified. The only change I made to my code was to change (char=? wa #\R) to (char-ci=? wa #\R) and the code now works fine. Can anyone explain what's going on?The value is always a capital R or S. Bill ___ 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
