Re: [Chicken-users] MSVC makefile and patches
On Thu, Feb 21, 2008 at 11:44 PM, Ashley [EMAIL PROTECTED] wrote: The build runs on msys with no problems. Tomorrow I plan to add a setup for cmd.exe, so a user only needs to have gnu make installed to build chicken for visual c. That seems like a pretty low barrier for windows users. Very good, Ashley. I'll integrate your stuff into the trunk ASAP. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: [Chicken-hackers] Re: repository branching
On Thu, Feb 21, 2008 at 9:13 PM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: Umm, what's the motivation for this? To keep egg sources for released but old versions, with the option of maintaining them. It's quite frustrating (as all of us know), that if I reinstall some eggs (say on a new machine), and those eggs use features that are only supported in newer chickens. I think it's a bad idea not only because it makes the size of a checkout of the repository grow greatly with each major release but, more importantly, because it adds complexity which, AFAICS, is not justified. The repository is already too big to checkout completely (unless you really want or have to). The complexity is IMHO acceptable. There will be some simplification once I have moved the toplevel eggs into a release/2 branch. If I now say stream-ext v1.8, no one knows if I'm refering to the code in 3/stream-ext/tags/1.8 or to the code in stream-ext/tags/1.8. Now I have to say stream-ext v1.8 for release 3. If the goal is to allow us to use different code in our eggs for each Chicken release, it should force us to use different version numbers (so that at least stream-ext v1.8 always refers to the same particular code, even if it has to live in multiple locations, which maintainers will need to manually keep in sync). If I have egg-version 1.7 for Chicken 2 and egg-version 1.8 for release 3 and then I need to make a release of my egg that will only work for Chicken 2, what version number should I use? Should I use 1.8, making egg-foo v1.8 refer to two different chunks of codes or should I use 1.9, making people running v1.8 feel that they need to update? The old tags for older releases are indeed unneccessary (but can be kept for reference). To release an egg for an older version, merge your changes into the appropriate release branch. Old eggs should only be modified for critical bugs (probably on request). The current official chicken version designates the branch you should be working on. - Trying to standarize on version numbers beginning with the number of the release (eg. stream-ext/tags/3.1.8 vs stream-ext/tags/2.1.8). For eggs that need them, branches for older releases would be kept in branches, as in stream-ext/branches/2/. We already have differing versioning schemes and we should not start changing everything. - Embedding the number of major release in the name of the egg, to end up with stream-ext-2 and stream-ext-3. This is probably the simplest solution. No. - Extending the .meta files to specify which releases are supported by each version of an egg would probably have been even better (so in the meta files you specify the releases supported and the post-commit code figures out which is the latest supported egg release for each Chicken release). What percentage of the eggs do we really expect to require different code for each Chicken release? I would imagine that the percentage is very small, but I don't really know... As a maintainer of eggs, I find the idea of having to keep separate directories for each egg for each release that I want to support unbearable. If I maintain 15 eggs, I will have to maintain 45 different directories the next time a major release comes along. To make a release of a new version of my code, I now have to sync the two dirs and make two releases, separatelly. And worse, since I have 2 (and eventually more) trunks, chances are that they will diverge and I'll end up having to waste time merging them and figuring out what changed in one but failed to make it to the other. You should not release for multiple chicken major versions. Release for the current. Only to fix critical bugs should eggs for older releases be modified. This change is not only inconsistent with the way most svn repositories tend to be used and redundant with the standard practices of /tags and /branches, but it puts a burden on the maintainers, when I think we ought to be striving for the opposite goal. Maintainers are short on time; we shouldn't waste it by forcing them to spend some of this sync'ing multiple directories and increasing the complexity associated with their eggs. Sorry, I may sound somewhat stubborn on this, but the whole machinery to automatically upload eggs on changes is already quite complicated and in place and working and I'm not going to change it (only extend). While I admit that the current layout is a bit confusing, I don't think the complexity is overwhelming: just don't worry about older releases. But we still have the possibility to maintain eggs for old releases in a relatively simple manner, and this is crucial. Repo checkout size shouldn't be a showstopper. Just checkout what you need or use svn externals. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org
Re: [Chicken-users] MSVC makefile and patches
On 2008 Feb 22, at 01:08, felix winkelmann wrote: On Thu, Feb 21, 2008 at 11:44 PM, Ashley [EMAIL PROTECTED] games.com wrote: The build runs on msys with no problems. Tomorrow I plan to add a setup for cmd.exe, so a user only needs to have gnu make installed to build chicken for visual c. That seems like a pretty low barrier for windows users. Very good, Ashley. I'll integrate your stuff into the trunk ASAP Would it be possible to put together a package of GnuWin32 programs so as to make Chicken building and egg installation reliable on Windows? I guess that would include make, gzip, tar, maybe cp, rm, mv, and I don't know what else. That would make it easy for a naive Windows user to set up and use Chicken. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
On 2008 Feb 21, at 23:57, Alejandro Forero Cuervo wrote: As such, I will need more convincing before implementing support for indexentry. I don't see what it adds that we can't already do. Ok, I see that it would allow arbitrary pages to declare sub-topics of a given topic, but I don't think that should be supported. I fully agree that much of the indexing can be done automatically, but a good index also includes entries that can't be generated automatically. Again, taking my append example, we might be documenting SRFI-1, in which case we might want concatenate to have an index entry for append. Truthfully, the indexing facility is going to be more useful for the Chicken manual itself, but I do think that a complicated egg might also benefit from it. As for bold-facing entries, sometimes that can be done from section headings, but sometimes that isn't practical. Consider documenting the tinyclos egg, where you might find that the main index entry for `method resolution order' may or may not be in a section with that name. These entries would just be written to a file, and external code would then process them to produce index pages or whatever. I think an index of the entire wiki would be way too big to be useful. If there's interest in this, I could generate it. Keep in mind that the wiki currently has 300+ files. Ulp. That requires more thought on my part. Again, I was mostly thinking in terms of an index database for the manual, or for a small locally- developed set of eggs. Perhaps Alejandro's database of `where symbols in the wiki are documented' could also be added to this external file? I like this idea. I'll probably do it. :-) Thanks for the suggestions, Vincent. My pleasure! -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: [Chicken-hackers] Re: repository branching
On 21 Feb 2008, at 8:13 pm, Alejandro Forero Cuervo wrote: What percentage of the eggs do we really expect to require different code for each Chicken release? I would imagine that the percentage is very small, but I don't really know... I'd hope it to be few, and would want to handle it with a suitable macro around the afflicted bits of code, rather than duplicating the whole source file... ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Stupid backquote/unquote question
On 21 Feb 2008, at 3:39 pm, Hans Nowak wrote: (Which leads me to wonder, *are* there Lisps/Schemes that have first-class macros? Where you can, for example, pass a macro as an argument to map, the way you can do with a function?) There can be, in principle, but they wouldn't be very compilation- friendly. Take the metacircular evaluator out of SICP, and modify the semantics of function such that, if the function is a function, evaluate all its arguments and apply it to the result. If it's a macro, then do not evaluate the arguments; just pass them directly to the underlying function of the macro, then recursively evaluate the result in the same environment... However, doing this in a compiler would be a pain, since you cannot in general tell if (a b c) is a function call or a macro reference. So for every application you'd need to output code that, if it was a macro, applied it to (b c), then called (eval ...) on the result, in a specially constructed environment. Eg, you'd end up evaluation anything that was made with macros anyway, unless you got really clever with metacompiling macros, eg making them produce compiled code rather than Scheme expressions. Which might be possible in some situations. However, you can make macros into second class values, a term I use to describe things which do behave much like first class objects, *except* that they must be fully decidable at compile time. Eg, we could allow: (defmacro (foo ...) ...) (defmacro (bar ...) ...) (define baz (if #t foo bar)) (baz ...) Or: (define (wibble macro) (macro 1 2 3)) (wibble foo) Since in both cases, we can tell that it's foo we're using, at compile time, with a little bit of partial evaluation. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: [Chicken-hackers] Re: repository branching
On Fri, 22 Feb 2008 12:34:36 +0100 Peter Bex [EMAIL PROTECTED] wrote: On Fri, Feb 22, 2008 at 02:38:25AM -0800, Alejandro Forero Cuervo wrote: So what about the idea of adding a (supported-releases 2.3 3.0.0) tag to the meta file, where particular versions of an egg that needs to do so specify which is the range of Chicken releases it supports? Actually, this is a much better idea as it also provides better granularity than the current system. I have a practical problem *right now* with my soon-to-be-released wmiirc egg. It _requires_ chicken 3.0.1 (because of a change in the way printf works on ports), but I can't currently express this in the meta file/repos tree, afaik. So it's located in the release/3 but it won't actually work with the 3.0.0 release. In this case I think you should create a custom procedure to replace printf (maybe using printf's code from 3.0.1?). When the next repo branch takes place, you can switch back to the stock printf. It'd be a temporary kludgy hack, but it should work (and it'd work much better than requiring a chicken version which does not exist :-)). Best wishes, Mario ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: [Chicken-hackers] Re: repository branching
On 22 Feb 2008, at 10:56 am, Alejandro Forero Cuervo wrote: I'd hope it to be few, and would want to handle it with a suitable macro around the afflicted bits of code, rather than duplicating the whole source file... Yes, that'd seem a more reasonable approach, I'd have to say... Alejo, ducking to avoid the rotten oranges that Felix will throw at him! :-) I'd expect that currently written eggs would be written for whatever version of Chicken the egg author had installed when they started, and that they'd tag it with this information somehow in the .meta file or whatever (or, if they're feeling like the effort, actually looking up what features they use and when they came in, and working out the minimum version they actually require). THEN when they upgrade to a new release, and use a snazzy new feature, they can do either: (require chicken-2-9) ...where all subsequent versions of chicken that remain backwards compatible to 2.9 will still accept that, or: or... what's it called... that thing that works like C's #ifdef. Something-case. Can't find it in the manual. Use that to select between different implementations for different versions, so they can use snazzy features that provide more speed or features, while falling back to old code if it's not available. I think I see Felix's point - *if* you consider the version-specific copies of the eggs as tags of the egg repository at that point in time, when they all worked with that version of chicken, and only ever modify them if a critical bug is found therein. However, this means that, as a blanket definition, old releases of chicken can't use newer eggs at all, unless the egg maintainer goes to special efforts to make them available by backporting them. In which case, I'd take the eggs in / to be current, and just tag them off for a release of chicken *before* releasing the new chicken. Eg, when 3.0 is released, the current set of eggs become the 2.9 'basket', and are tagged for prosperity somewhere. Then 3.0 comes out and people rewrite all their eggs to use the amazing new call-with- free-biscuit macro... *browse* Hmmm, I always find fun things when I start looking in the Chicken manual. case-lambda. Must remember that one. It'd be cool if it let you put constants and stuff in the cases, destructuring bindings always make functions that recurse over data structures particularly lovely. Ah, match-lambda* exists! Drool... ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] understanding eval
Hi, This might be a stupid question, but would someone help me understand the following eval example? I was expecting to get 1. Daishi 8--8--8--8--8--8--8--8-- CHICKEN Version 2.732 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook cross ] (c)2000-2007 Felix L. Winkelmanncompiled 2007-12-04 on spirits (Linux) #;1 (define a 'car) #;2 (define b '(1 2 3)) #;3 (eval (list a b)) Error: call of non-procedure: 1 Call history: syntax(eval (list a b)) syntax(list a b) eval (eval (list a b)) eval (list a b) syntax(car (1 2 3)) syntax(1 2 3) eval (car (1 2 3)) eval (1 2 3) -- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] understanding eval
On Fri, Feb 22, 2008 at 09:22:36PM +0900, Daishi Kato wrote: Hi, This might be a stupid question, but would someone help me understand the following eval example? I was expecting to get 1. You're evaluating (car (1 2 3)) You want to be evaluating (car (list 1 2 3)) or (car (quote (1 2 3))) 8--8--8--8--8--8--8--8-- CHICKEN Version 2.732 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook cross ] (c)2000-2007 Felix L. Winkelmanncompiled 2007-12-04 on spirits (Linux) #;1 (define a 'car) #;2 (define b '(1 2 3)) #;3 (eval (list a b)) Error: call of non-procedure: 1 Call history: syntax(eval (list a b)) syntax(list a b) eval (eval (list a b)) eval (list a b) syntax(car (1 2 3)) syntax(1 2 3) eval (car (1 2 3)) eval (1 2 3) -- Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth pgpMInQgMbwFF.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] understanding eval
OK, so that was stupid. How about this? (define a 'values) (define b '((1 2 3) #(4 5 6)) I'd like to evaluate (values '(1 2 3) '#(4 5 6)) using eval, a and b. --daishi At Fri, 22 Feb 2008 13:29:55 +0100, Peter Bex wrote: On Fri, Feb 22, 2008 at 09:22:36PM +0900, Daishi Kato wrote: Hi, This might be a stupid question, but would someone help me understand the following eval example? I was expecting to get 1. You're evaluating (car (1 2 3)) You want to be evaluating (car (list 1 2 3)) or (car (quote (1 2 3))) 8--8--8--8--8--8--8--8-- CHICKEN Version 2.732 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook cross ] (c)2000-2007 Felix L. Winkelmanncompiled 2007-12-04 on spirits (Linux) #;1 (define a 'car) #;2 (define b '(1 2 3)) #;3 (eval (list a b)) Error: call of non-procedure: 1 Call history: syntax(eval (list a b)) syntax(list a b) eval (eval (list a b)) eval (list a b) syntax(car (1 2 3)) syntax(1 2 3) eval (car (1 2 3)) eval (1 2 3) -- Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] understanding eval
On Fri, Feb 22, 2008 at 09:57:42PM +0900, Daishi Kato wrote: OK, so that was stupid. How about this? (define a 'values) (define b '((1 2 3) #(4 5 6)) I'd like to evaluate (values '(1 2 3) '#(4 5 6)) using eval, a and b. More of the same: (eval (cons a (map (cut list 'quote ) b))) HTH, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth pgpJtM9M93QLR.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] aliases in the wiki
On Sun, Feb 17, 2008 at 7:11 PM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: I have tweaked a bit the code in Svnwiki a bit to support defining aliases for functions in the wiki. My thinking is that (1) for all procedures f, http://chicken.wiki.br/f should return something useful, regardless of where f is defined and (2) we shouldn't have to duplicate information in the wiki. Here is how I do it: $ ln -s 'stream-ext#stream-xcons' stream-xcons $ svn add stream-xcons $ svn ci -m Creating link for procedure stream-xcons This causes accesses to http://chicken.wiki.br/stream-xcons to be redirected to http://chicken.wiki.br/stream-ext#stream-xcons. Go ahead and try it. As such, we don't have to split the eggs' documentation wiki files (or documents in the manual) and we can still allow people to play with URL hacking. Feel free to create links such as those. To make it even easier, you can send me mails with the subject 'chicken wiki links' containing lines of the form 'source-for-link destination#url' and I will define those links. If Mario or some other hackers can programatically extract a list of such functions and their location in the wiki, that'd be neat. :-) Could we please remove this? It makes a grep over the working copy impossible. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] aliases in the wiki
Could we please remove this? It makes a grep over the working copy impossible. Hi Felix. What about: find -P . -print0 | xargs -0 grep TEXT Regards, N.- -- http://arhuaco.org ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] aliases in the wiki
On Fri, Feb 22, 2008 at 5:55 PM, Nelson Castillo [EMAIL PROTECTED] wrote: Could we please remove this? It makes a grep over the working copy impossible. Hi Felix. What about: find -P . -print0 | xargs -0 grep TEXT Sorry. It is: find . -type f -print0 | xargs -0 grep TEXT N.- -- http://arhuaco.org ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] aliases in the wiki
From: Nelson Castillo [EMAIL PROTECTED] Subject: Re: [Chicken-users] aliases in the wiki Date: Fri, 22 Feb 2008 18:04:34 -0500 On Fri, Feb 22, 2008 at 5:55 PM, Nelson Castillo [EMAIL PROTECTED] wrote: Could we please remove this? It makes a grep over the working copy impossible. Hi Felix. What about: find -P . -print0 | xargs -0 grep TEXT Sorry. It is: find . -type f -print0 | xargs -0 grep TEXT Ugh. IIRC, azul suggested a different (database based) way of handling this. Creating thousands of dangling links doesn't look right to me. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
