Re: Patch for CHICKEN 6 uri-generic
Hello Peter, Thanks a lot for the patch! Overall it looks ok, but it has been quite a while since I have had to deal with UTF-8 at this level of detail, so I don't really understand all the bitwise operations and range comparisons. I am wondering if it is possible to factor out the UTF-8-specific logic into a separate module and let it be invoked by the uri-generic parsing routines. Also, I think it would be tremendously helpful to use named constants, as I don't quite know the significance of #x800 or #x1. Perhaps CHICKEN 6 already offers the definitions and routines to make this code more readable? I will try to install CHICKEN 6 and actually run the code with your patch soon. Thanks, Ivan On Thu, May 16, 2024 at 2:52 AM Peter Bex wrote: > > On Wed, May 15, 2024 at 02:44:07PM +0200, Peter Bex wrote: > > Unfortunately, it also means we must now choose to reject certain URIs > > (at least in uri-common) by raising an exception instead of allowing them > > to be decoded. These are for invalid UTF-8 encoded characters, either > > because they're a truncated byte sequence or because they encode a > > character in too many bytes. > > I realised that there was a bug in this code, since "eat-rest-chars" > would consume the percent-encoded bytes and then they'd get discarded > in case the set of characters to decode doesn't contain the decoded > character in question. > > After trying this out, I noticed that the code actually worked, to my > astonishment. Then I realised that this was because the code would > still cons the UTF-8 *leading byte* back onto the result, and then > traverse the cdr of the UTF-8 tail bytes as the rest list, which would > pass through unprocessed. > > I added test cases for both situations and changed the code to detect > UTF-8 continuation bytes without a leading byte and bail out in such > cases, or other unforeseen and unhandled cases (the "else" in the main > decoder). And of course tweaked the eat-rest-chars code and callers to > always restore all of the undecoded bytes. > > Still not super happy with using "values" here and the way we're passing > in somewhat redundant information about the first consumed byte. I realise > an alternative would be to pass the success continuation as an argument > but I don't think that makes the code much clearer. > > Cheers, > Peter
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
The csv egg in Chicken 4 has been superseded by tabular in Chicken 5, which offers a generalized interface for parsing tabular text data, including fixed-width columns. -Ivan On Sat, Sep 28, 2019 at 11:28 AM Matt Welland wrote: > > On Sat, 2019-09-28 at 19:18 +0200, Jörg F. Wittenberger wrote: > > Am Fri, 27 Sep 2019 23:27:23 +0200 > > schrieb felix.winkelm...@bevuta.com: > > > > > > Hi all, > > > > > > > > Attached is a relatively straightforward patch for SRFI-13. It > > > > changes the let-string-start+end macro (and also > > > > let-string-start+end2 but that isn't exported) so that it uses > > > > let-optionals* and the entire picking apart of the rest arg list > > > > into start/end can be completely inlined, as well as checking the > > > > values against the string length(s). > > > > > > Wonderful! Applied and tagged (0.3). > > > > Would it make sense to apply this also on Chicken 4? > > > > I see the latter living for quite a while. > > > > If nothing else than if it just was for me. :-/ > > It will be a while before I can migrate away from Chicken 4 so count me > among those who would be appreciative of any porting of > fixes/improvements from chicken 5 to 4. I'm keen on getting to Chicken > 5 as soon as possible but it is a large task and is likely to take six > months to a year. > > NOTE: Aside from the effort in porting the code there are still a few > dependencies on eggs that have not been ported. Triming dependencies > may eliminate some of these. A quick crude scan of use statements gave > me this: > > call-with-environment-variables > csv > csv-xml > dot-locking > foof-loop > hostinfo > pathname-expand > ports > regex-case > rpc > s11n > sparse-vectors > srfi-12 > srfi-19 > tcp > > > > > > ___ > > Chicken-hackers mailing list > > Chicken-hackers@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/chicken-hackers > > > ___ > Chicken-hackers mailing list > Chicken-hackers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [CR] Make keywords distinct from symbols
I think the historical precedent has been to make the big sweeping change and then frantically rush to fix all broken eggs :-) But in this case it really sounds like it is better to make all changes to keyword semantics at once, rather than piecemeal. -Ivan On Fri, May 17, 2019 at 12:44 PM Peter Bex wrote: > > On Mon, May 06, 2019 at 10:30:14PM +0200, Peter Bex wrote: > > Some of the defining forms reject keywords now, but there may be some > > we missed, and by making them completely distinct we fix these problems > > for good. For the vast majority of the code out there this is an > > unimportant change. Code which relies on symbol? returning #t for keywords > > will run into trouble (but is usually easy to fix by adding another cond > > clause for keyword?, which will happily be backwards compatible to older > > CHICKENs). There may be other obscure uses of keywords that will fail, but > > I can't really think of many. > > So far nobody has bothered to reply here or on the ticket at all. > It will be two weeks after next Monday (the 20th). > > As our process document at https://wiki.call-cc.org/change-requests > says that if two weeks pass without comments, it should be assumed nobody > cares enough or has a problem with the change. > > I've heard from Felix on IRC, he said he's worried we're changing too > much at once in 5.1. Personally, I think if we make this change in a > later version it'll be more frustrating for users, because we're already > changing how keywords behave (no plists, cannot be used as identifiers > anymore). Making keywords and symbols distinct types later means we'll > have two such changes. > > To sum up, we could: > > 1) Not make this change at all > 2) Do it anyway in 5.1 > 3) Do it in some later version (but how long do we wait?) > > What do the other hackers think? Please, speak up! > > Cheers, > Peter > ___ > Chicken-hackers mailing list > Chicken-hackers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules
Thanks for making a patch for this issue! -Ivan On Thu, Aug 30, 2018 at 4:14 AM wrote: > > > > So the basic problem is to install multiple sets of files, in separate > > > steps? I think for "scheme-include" components this should be possible, > > > but (as far as I can see) this is not currently possible for "c-include" > > > components (but could be added). > > > > It's for more than that. SPOCK for instance installs its Scheme *and* > > JS runtime into PREFIX/lib/chicken/8/spock/. The latter is neither a > > scheme-include nor a c-include. Feathers installs itself into > > PREFIX/share/chicken/feathers.tcl. I'm not sure what I'd categorize > > these as, but I suspect these eggs cannot be ported until you can > > specify a PREFIX-relative destination directory (as opposed to > > specifying the type of file to be installed). > > Feathers is part of the core system and ths spock stuff could in theory > simply be treated as data and installed/accessed from a diffent location, > so it is already possible, even if not ideal. But a patch is pending, as you > probably know, so no need to panic. > > > felix > ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules
Yes, exactly, the issue is installing multiple sets of files in
different subdirectories of PREFIX/{include,share}. It would be very
useful for "c-include" as well as "data" components.
Thanks,
-Ivan
On Tue, Aug 28, 2018 at 1:07 PM wrote:
>
> > I have a couple of eggs that generate and compile code similar to the
> > way chicken-crunch works. These eggs would install header or source
> > files that are required for the compilation process. Some of these
> > source files belong to distinct functional modules that are organized
> > in subdirectories. In CHICKEN 4, it was possible to install these
> > files to corresponding subdirectories of CHICKEN_PREFIX/share/chicken,
> > thus preserving the logical structure. In CHICKEN 5, this is currently
> > not possible, but I think it would be a very convenient feature. We
> > can of course define our own conventions and install the additional
> > files into subdirectories of $HOME, but it makes more sense to me to
> > keep them in the CHICKEN directory hierarchy. I hope this makes sense.
>
> So the basic problem is to install multiple sets of files, in separate
> steps? I think for "scheme-include" components this should be possible,
> but (as far as I can see) this is not currently possible for "c-include"
> components (but could be added).
>
>
> felix
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules
Hi Felix, I think this last question about installing include files is closely related to my question, so let me try to clarify. I have a couple of eggs that generate and compile code similar to the way chicken-crunch works. These eggs would install header or source files that are required for the compilation process. Some of these source files belong to distinct functional modules that are organized in subdirectories. In CHICKEN 4, it was possible to install these files to corresponding subdirectories of CHICKEN_PREFIX/share/chicken, thus preserving the logical structure. In CHICKEN 5, this is currently not possible, but I think it would be a very convenient feature. We can of course define our own conventions and install the additional files into subdirectories of $HOME, but it makes more sense to me to keep them in the CHICKEN directory hierarchy. I hope this makes sense. Best regards, -Ivan On Tue, Aug 28, 2018 at 11:40 AM wrote: > > > > - Is there a clean way to install C and Scheme include files somewhere else > > than the default place from an .egg file? It seems to be possible to specify > > absolute target paths, but that is pretty much useless since the prefix of > > the > > CHICKEN installation is not known at the time the .egg file is written. > > Also, > > specifying relative *source* paths for include files doesn't even work, if > > they > > have subdirectory components, because the files get installed in the top > > level > > target directories but their full relative paths get entered into the > > .egg-info > > files. An equivalent to custom build scripts doesn't seem to exist for file > > deployment either. > > Installation into system paths seems to me somewhat questionable - > files installed for CHICKEN should end in a location specific to that > CHICKEN installation. If you can give a specific example where this > is useful, I'd appreciate it. > > A final note: don't expect too much of chicken-install: it is neither a > package system, nor it is a general build system. It addresses the basic > need of installing Scheme libraries. These may use foreign code and > we will try to work on supporting the most common cases. > But not all scenarios can be convered, as you will surely understand, > the different OS- and toolchain-idiosynchrasies are already making > this a serious piece of work. If you have very specialized build- and/or > usage-cases, consider distributing the code not as an egg but as a > normal library using whatever build system you prefer. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-janitors] #1218: chicken-install may fail if TMPDIR is mounted noexec (depending on setup-file details)
Ubuntu-derived distributions now ship with /tmp mounted as noexec by default. This results in a chicken-install error that is difficult to diagnose by non-expert users. The remedy can be as simple as setting TMPDIR (but perhaps that should be prominently documented), an option that forces chicken-install to use a temporary subdir HOME as the build location, or a test that compiles a program in TMPDIR and tries to execute it. Does anyone else have opinions or suggestions about the best way to solve this? -Ivan On Sat, Apr 22, 2017 at 7:30 AM, Peter Bex <pe...@more-magic.net> wrote: > On Sat, Apr 22, 2017 at 07:17:09AM -0700, Ivan Raikov wrote: >> It considerably limits the effectiveness of distributing software >> written in Chicken, because now users who are not familiar with its >> peculiarities cannot simply run chicken-install. Could at least some >> option be added so that the user home directory is used instead of >> TMPDIR? > > I fail to see the usefulness of adding yet another option, when > overriding TMPDIR does exactly the same thing. Let's take this to > chicken-hackers; chicken-janitors isn't really intended as a > discussion mailing list. > > Cheers, > Peter ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] merging the argvector changes
I agree that the argvector patch should be merged, as it is a change that allows Real Work to be done with CHICKEN. It would be nice to have performance comparisons of course, and I would be particularly curious to benchmark CPS-style tree traversal and combinator parsing code. I think having the patch merged would make it easier to test and identify potential performance problems. -Ivan On Fri, Aug 28, 2015 at 3:32 AM, felix.winkelm...@bevuta.com wrote: Hello! Peter asked me to write a few words about the status of the argvector related changes (passing arguments to CPS-procedures in a stack-allocated vector instead of doing it directly). As I already wrote, the initial reason for this change was the new ARM64 iOS ABI, which rigorously punishes the undefined behaviour we exploit in the way CHICKEN translates Scheme to C. At bevuta, we have a large mobile App that needed to be ported to arm64 (Apple requires this now for all updates in the App Store and of course for all newly submitted apps). The changes in the argvector branch of the core repo have been used for the new (universal) 32/64-bit build and seem to work flawlessly. We are not sure about any performance differences yet - one tester say it actually got faster, but that is likely to be caused by the 64-bit environment and not by the argvector-related differences in the generated code, I guess. Mario was so kind to run Salmonella on the argvector branch and the results are actually quite good: 50 or so eggs break vs. 16 previously, and nearly all of the breakages are caused by the new signature of C_apply (was C_do_apply) and C_values, but these are very easy to fix. So we think this should be merged. Peter already has prepared patches for the numbers egg and the chicken-5 core. Opinions and comments are welcome. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal
I think these are lofty goals, but it is way too much work for a single release. Perhaps modularising the compiler and refactoring the core modules should be the goals for 5.0 release, and points 1.3-1.8 would be done as 5.x releases leading up to 6.0. As for library names, I favor fully spelled out names instead of abbreviations, i.e. chicken.fixnum, chicken.flonum, etc. Also, shouldn't it be CHICKEN.fixnum now that we are using the FORTRAN convention? ;-) -Ivan On Sun, Aug 24, 2014 at 12:35 AM, Peter Bex peter@xs4all.nl wrote: Hello hackers! I've made a start on the wiki, at what we'd like CHICKEN 5 to be about. Please, do not make this into another pony page, only add things that we really need to look at which require a rework in core which may be backwards-incompatible. http://wiki.call-cc.org/chicken-5-roadmap I already fear I may have gone a bit overboard with adding too many things I'd really like to see myself :) I'd especially appreciate feedback on the core library names and the things to kill from core. I will be expanding this page over the next few days/weeks. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
The Chicken wiki still has an index of Chicken 3 eggs, although I do think chicken-setup is no longer operational. Perhaps now would be a good time to clean the wiki of vestigial references to 2 3. I also like the idea of adopting the r7rs library names. -Ivan On Wed, Aug 20, 2014 at 1:13 AM, Peter Bex peter@xs4all.nl wrote: I didn't know we still supported CHICKEN 2 and 3. In what way is that done? AFAIK the server-side component for chicken-setup is no longer active. Is it? Works for me. I do think, however, that we should take a good look at the r7rs library names, and probably adopt them wholesale, for the parts that we implement. This would make CHICKEN easier to use for people using multiple Schemes, and for newbies coming from other Schemes. It would also ease our burden at figuring out good names: half of the stuff will suddenly *have* a good name. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
I do think it is time for an overhaul, and creating a new major version branch is the right way to go about it. Obviously it would take some time to port everything, but it seems that the changes will be simpler than during the hygienic macros transition. Ivan On Aug 19, 2014 12:09 AM, Peter Bex peter@xs4all.nl wrote: On Mon, Aug 18, 2014 at 04:53:22PM +0200, Felix Winkelmann wrote: - I don't know how this is handled with henrietta - do we need a separate CGI script running for this? It seems so, so the core-branch will need to have different download URLs in setup.defaults. Perhaps, I'm not sure about that. The release-info files don't have a way to indicate CHICKEN version either. This needs some extra attention, so that repositories can support multiple CHICKEN versions. All this is mainly to safe time - keeping up backward-compatibility hacks (wrapper-eggs, hacks in setup.defaults, etc.) just needs more work and time and we haven't much of that, considering that we are just a handful of part-time maintainers. Yeah, we're pretty thinly spread right now. I think calling this CHICKEN 5 may be a good idea. I don't know for sure though: adding backwards compatibility may actually be easier in this situation. Ripping out the SRFIs from core should be pretty simple, but it does require updating all the eggs. And of course there's shitloads of eggs that are unmaintained, which will break and never get fixed. So all in all, starting over might be easiest. I'd love to hear from some of the people using CHICKEN in their business or for other Serious Projects (Kristian? Ivan? Andy?) how painful this would be for them. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
I would think that support for Chicken 2 3 should be dropped after a Chicken 5 branch is made. If anyone desperately needs Chicken 3, would it not be better to migrate the Chicken 3 stuff to another server? I had also implicitly assumed that the modularisation changes would help bring full R7RS support to core. Is this not the case? What are the goals for a Chicken 5 release? On Tue, Aug 19, 2014 at 9:03 AM, Mario Domenech Goulart mario.goul...@gmail.com wrote: Sorry for the sudden jump to those topics. :-) In fact, as a user, I was just trying to bring some topics that are practical issues and that we could piggyback with the breaking changes to make a major release. I'm not sure reorganizing the core and making it smaller justifies a major release. I understand some changes caused by the core reorganization may break code, but I'm looking at major releases from a user standpoint. What immediate benefit do those changes bring for users? Maybe R7RS support? Are those changes worth the breakage? Please, note that I'm not against those changes. Not at all, absolutely. I'm totally for them. I just wonder if they justify a major release and and all the burden to maintain another major version. I mentioned Unicode and bignums because, in my opinion, they are quite important for practical applications, and the support CHICKEN provides for them at the moment is not very appealing. Since you mentioned a new major release, why not making them part of it? Of course the obvious, realistic and straight-to-the-point answers are lack of manpower and lack of consensus on those topics, I know. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] will we have a release this year?
Hi Andy, The environments egg will not work under Chicken 4.7.4 and later, due to changes in the internal representation (also noted in the documentation). The rewrite branch is meant to fix this issue. Ivan On Sep 23, 2012 10:09 PM, Andy Bennett andy...@ashurst.eu.org wrote: Hi, I have been testing 4.8.0rc4 quite a bit this week, and everything seems to work fine, so if there are no objections, I will make the release next Monday. Did people see my bug report on chicken-users regarding the environments egg and eval? I posted in the Re: [Chicken-users] Chicken 4.8.0 release candidate 4 now available thread on 2012/09/18. -- Another was segfaulting and continued to segfault on 'load'. I narrowed it down to this repro case in the interpreter: - #;1 (use environments) #;2 (define widget-eval-env (make-parameter (environment-copy (scheme-report-environment 5) #t))) - Using Mortiz's rewrite branch of the environments egg: https://anonymous:@code.call-cc.org/svn/chicken-eggs/release/4/environments/branches/rewrite/ ... stops the segfault. I can get a binary out but it throws an exception somewhere it didn't used to: - unbound variable ##sys#list - ...and my debugging efforts so far point to a problem with eval and an environment from the environments egg. -- Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] On Hash Collisions (28C3)
I also do not understand why using different data structures is not under consideration. There are many algorithms and data structures for handling collisions so that hash table access remains efficient even with a high rate of collisions. Why not have the option to choose the data structure for buckets -- if you don't like alists, there are balanced trees, dynamic arrays, and others. On Jan 1, 2012 11:57 PM, John Cowan co...@mercury.ccil.org wrote: Peter Bex scripsit: Agreed. Changing datastructures is not an option. Why not? It's a matter of replacing a datastructure whose worst-case cost is quadratic with one whose worst-case cost is linear. Do we even know what the break-even point is between a-lists with their higher algorithmic complexity vs. hash tables with their higher constant factors? I tried writing a little benchmark to determine this, but so far without success. The patch ensures no two hash tables use the same offset, so even if the hash value of a given table were to leak out (which the user still should take every precaution to avoid!), it won't compromise the randomization of other hash tables. What you are doing is imposing an additional cost on *all* users of hash tables so as to make them more resistant to malicious attack. The vast majority of hash tables do not need to deal with malicious data. Once I know, I'll estimate the cost to fix it to save my brain from remebering that I'm not supposed to use hash tables where appropriate because they could degenerate into an issue. Indeed. If other languages have fixed it transparently, so can we. We aren't Perl or Python, where hash tables are deeply embedded in the implementation. Using a hash table in Scheme should always be an informed choice, not a default one. Right now the information is lacking. -- John Cowan co...@ccil.orghttp://ccil.org/~cowan I am he that buries his friends alive and drowns them and draws them alive again from the water. I came from the end of a bag, but no bag went over me. I am the friend of bears and the guest of eagles. I am Ringwinner and Luckwearer; and I am Barrel-rider. --Bilbo to Smaug ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-meisters] Let's have a roadmap, just like the grown-ups
I think that setting up and maintaining a ratings site might be a bit too much overhead, and more importantly, it will take effort to convince people to vote (if the Chicken survey is any indication). How about we set up a system similar to the Debian popularity contest, where the Debian package system maintains a record of how many times a package was installed (which may be some indicator of its maturity and stability). I think it would not be too hard to modify the henrietta script to update a flat database each time a package is installed. Is anybody else interested in this, or should I look at it? -Ivan John Gabriele jmg3...@gmail.com writes: On Fri, Sep 9, 2011 at 4:41 AM, Alaric Snell-Pym ala...@snell-pym.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2011 02:58 AM, John Gabriele wrote: 4) Just plain user rankings with a little vote button Python did this with their central module repository. They added the feature, but then later removed it. The reasons, as I recall, were mostly: 1. It was hardly getting any use, and 2. There were arguments over what the ratings actually meant, their usefulness, and their validity. Perl 5 has a separate ratings site http://cpanratings.perl.org/ , which is quite valuable to the community -- not so much for the rating numbers themselves, IMO, but for the thoughtful comments people add about a given module. It's often useful to use when choosing between multiple similar modules. Interesting. A common theme here is that comments matter more than ratings. Shall we explore how that might be done? I think that a simple http://egg-ratings.call-cc.org site would be an excellent project for someone with web development skills who would like to contribute to Chicken (but not necessarily by writing core code). Once the site starts getting some content, add to each egg's doc page a link to that egg's ratings page (containing zero or more ratings/comments) at the ratings site. (BTW, having comments right in a wiki page such as http://wiki.call-cc.org/eggref/4/egg-name/comments might be quite convenient, but probably futile since editing such a comments page would allow any editor to change any previous comments on the given egg.) I'd suggest adding a request for the small ratings site to http://wiki.call-cc.org/wish-list and see if anyone comes forward with a working prototype site. I bet it won't take long for someone to whip something up. Also, I'm not sure what pages link to the wish-list page, but maybe someone could add a link to it at http://wiki.call-cc.org/ ? ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] single egg documentation format
Alex Shinn has contributed some code to parse wiki content, and I have modified it to parse svnwiki syntax and placed in the Chicken SVN repository (in directory release/4/wiki-parse). Peter Bex and I will work on a suitable replacement for stream-wiki, which will most likely be an SXML-based system. Others are also welcome to help. -Ivan Ivan Raikov ivan.g.rai...@gmail.com writes: Ok, I can do some research and see if there is some existing wiki parser that can be adapted to read the svnwiki dialect and produce s-expressions. If there are some reasonable solutions out there, then I will propose an s-expression-based substitute for stream-wiki, and some way to automatically merge eggdoc in such a wiki. -Ivan felix winkelmann bunny...@gmail.com writes: On Fri, Jul 31, 2009 at 9:02 AM, Ivan Raikovivan.g.rai...@gmail.com wrote: Please do not get rid of eggdoc and seriously consider either finding someone to maintain the wiki software, or using a better source format for the manual. I doubt that someone will be willing to maintain stream-wiki - it really is rather complex and has loads of dependencies. That wiki2html is a hack is also true, but I'm quite unhappy with the current situation. Having all documentation in a wiki on the other hand is quite convenient and allows more people to help maintain it. Having multiple documentation formats is not acceptable, IMHO, and I hope you agree with that. I personally don't care what format we use, and the easier it is to manipulate in Scheme, the better. So do we need an eggdoc wiki? What are we going to do? ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] R6RS
There are many good reasons not to support R6RS. You might want to read them here: http://www.r6rs.org/ratification/results.html Thomas Bushnell BSG t...@becket.net writes: So the extraordinary compiler Stalin is sliding into obscurity, because it remains stuck at r4rs, with nobody having done anything to bring it up-to-date. Chicken Scheme can be talked into being r5rs, which is great, though it's not obvious sometimes what needs to be done. But r6rs has been out a while. I think we should create a punchlist of to-do items, with the goal being to get r6rs compliance in the not-too-distant future. With the version 4 macro system in place, this shouldn't be too far off. And yet, we have a quote from Felix Winkelmann from a couple years ago saying it will never happen, and R6RS must die. Is this still the rule? ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] R6RS
Chicken Scheme, along with its extension libraries, supports a large superset of R6RS. Given what you have written below, I do not understand why you think R6RS should be a guideline for a punchlist of features to implement in Chicken. It is not a particularly good specification, and equivalent or better functionality is already provided in Chicken anyway. -Ivan Thomas Bushnell BSG t...@becket.net writes: I'm sorry; those are reasons not to approve r6rs. There are many things, it seems to me, which don't belong in the standard, but which should be in any good Scheme system. Are you saying that if X should not be in the standard, then it is wrong for Chicken Scheme to implement X? Suppose r6rs had mandated the Chicken Scheme FFI; would you begin lobbying for its removal from Chicken Scheme? ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] single egg documentation format
Ok, I can do some research and see if there is some existing wiki parser that can be adapted to read the svnwiki dialect and produce s-expressions. If there are some reasonable solutions out there, then I will propose an s-expression-based substitute for stream-wiki, and some way to automatically merge eggdoc in such a wiki. -Ivan felix winkelmann bunny...@gmail.com writes: On Fri, Jul 31, 2009 at 9:02 AM, Ivan Raikovivan.g.rai...@gmail.com wrote: Please do not get rid of eggdoc and seriously consider either finding someone to maintain the wiki software, or using a better source format for the manual. I doubt that someone will be willing to maintain stream-wiki - it really is rather complex and has loads of dependencies. That wiki2html is a hack is also true, but I'm quite unhappy with the current situation. Having all documentation in a wiki on the other hand is quite convenient and allows more people to help maintain it. Having multiple documentation formats is not acceptable, IMHO, and I hope you agree with that. I personally don't care what format we use, and the easier it is to manipulate in Scheme, the better. So do we need an eggdoc wiki? What are we going to do? ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] Chicken 4 development snapshots
Dear all, The Chicken development snapshot script has been adapted to Chicken 4. From now on, Chicken 4 snapshots will be built and linked to on the development snapshots page: http://chicken.wiki.br/dev-snapshots/ New snapshots will be built when the Chicken version is increased in the repository. In the next few days, I will be updating the salmonella script for Chicken 4, so some breakage is possible in the salmonella-report page. -Ivan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] manual and chicken4 infrastructure
Hello, As Elf pointed out, the 3.5.0 release was botched because too many untested modifications were made to it. The current development snapshot, 3.5.5 includes bug fixes for some of those issues, although I am not convinced of the stability of srfi-18, and someone reported a segmentation fault while building Chicken 3.4+ on x86_64 architecture. So 3.4.0 should be considered the last stable release of the 3.x series, and the 3.5.x development snapshots will be used for backporting features from 4.x until enough eggs are ported so that we can retire the 3 branch altogether. As for why the 4.0.0 release was not on the releases page, the excuse is that some infrastructure has to be updated on the Chicken wiki server before 4.x tarballs can be generated automatically. The main Chicken page does have a link to the 4.0.0 release tarball. I have also added a link to it on the releases page, and I will post an announcement on Freshmeat shortly. -Ivan Shawn Rutledge shawn.t.rutle...@gmail.com writes: The main page points to http://chicken.wiki.br/releases/ 3.4.0 is there. So it gives the impression that's the newest stable version. Now I wonder if that's actually true? There are more dev releases in the 3.4.x series; which one should Linux distros be using? 4.0.0 is NOT there. Why can't the releases page actually be in sync with the releases that are available? Because it's a manual process and somebody always forgets to update it? Maybe make it more automated then? or just point to a web directory which has listings turned on and does not have an index file, so we can see what tarballs are there. On gentoo I managed to build 3.4.0 by just copying the 3.3.0 ebuild. I haven't seen a link anywhere to http://www.call-with-current-continuation.org/chicken-4.0.0.tar.gz other than Felix's email. Why isn't that in the usual releases directory instead? ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] changes in trunk
Hi Felix, Can you copy the current trunk into an old-stable branch (or maybe in the release/3 branch)? I would like to make one or two more releases of the 3.x Chicken by the end of the year. Thanks, -Ivan felix winkelmann [EMAIL PROTECTED] writes: Hi! If possible, new features should only be added to the hygienic branch. The current trunk should only receive bugfixes from now on. I'd like to move the hygienic branch into trunk in the next days. If there are any reasons to delay this, please speak up. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] install-extension: locations for docs, examples etc.
The (compile... and (install... forms are actual shell commands, while the rest is metadata. I am not saying they must be in separate files, but they are semantically different, so you can't just mash them together like that. -Ivan Shawn Rutledge [EMAIL PROTECTED] writes: On Mon, Apr 14, 2008 at 4:05 AM, felix winkelmann [EMAIL PROTECTED] wrote: If you allow me to say so: chicken-setup needs a rewrite. In that case I have a couple more ideas: Take the version number from the svn tag so I don't have to keep changing the setup file every time. Maybe the rest of the setup information can come from the meta file: ((egg dbus.egg) (compile -s -O2 -d1 -ldbus-1 -I/usr/include/dbus-1.0/ -I/usr/lib/dbus-1.0/include dbus.scm) (install (implementation dbus.so dbus.o) (exports dbus.exports) (documentation extra-doc.html yet-more-doc.html from-wiki) (examples (list-files examples/*)) ) (license MIT) (category os) (author Shawn Rutledge) (synopsis A binding for libdbus, the IPC mechanism)) Documentation from-wiki would imply installing the docs from the wiki in addition to the others in the list (in the right place), and (exports ...) would imply adding the compile flags to generate the exports. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] install-extension: locations for docs, examples etc.
You don't actually need to list the documentation files twice in the arguments to install-extension. It is only necessary to list them in the `documentation' property. This is just legacy from older versions of chicken-setup. It would be pretty easy to add an -examples-path option to chicken-setup, but I want to think about this a little bit and figure out what is the best way to specify a base path for installing documentation and examples. -Ivan Shawn Rutledge [EMAIL PROTECTED] writes: with as many files as the egg would like to install there, rather than being restricted to just the typical everything-on-one-page. (/usr/share/doc/package-version/xxx is the Gentoo convention, at least. It could be configurable in case other distros are different.) It's also inconsistent that examples only need to be mentioned in the property list, whereas documentation has to be mentioned both there and in the list of files to install. I think it should be enough to have it in the property list. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] required-extension-version (possible version-numbers issue)
Hi Mario, How do you propose this is handled? The situation below occurs because 501 6 (obviously), so chicken-setup thinks that 1.501 is newer than 1.6.x. My solution would be to remove releases and prerequisites of the form x.xxx because such a versioning scheme is idiotic. But I am open to reasonable suggestions. -Ivan Mario Domenech Goulart [EMAIL PROTECTED] writes: Hi folks, Here's what I get when trying to install http: $ /usr/local/chicken-3.1.3/bin/chicken-setup http (many messages ommited) downloading uri.egg from (www.call-with-current-continuation.org eggs/3 80) ... gzip -d -c /tmp/chicken-setup-3-mario/downloads/uri.egg | tar xf - Error: the required extension `lookup-table' is older than 1.501, which is what this extension requires - please run chicken-setup lookup-table and repeat the current installation operation. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] required-extension-version (possible version-numbers issue)
I don't understand what you mean by that. As long as a version is defined as a dotted list of integers in decimal representation, 1.501 1.6.0. If you want your release versions to be ordered correctly, then those version numbers have to be a well-ordered sequence in increasing order and consistent representation. You can't go from release 1.16 to Aleph.XVII and expect that chicken-setup would know what to do. -Ivan Leonardo Valeri Manera [EMAIL PROTECTED] writes: On 15/04/2008, Ivan Raikov [EMAIL PROTECTED] wrote: The versions egg uses the same (sane) principle of version comparison: (version? (string-version 1.501) (string-version 1.6.0)) = #t I agree that it is time to sanitize the egg versions, but 501 6 and there is nothing I can do about that. That's what I mean - version numbers have to make sense to that egg, in the sense that it ill will say (version? new old) = #t Leo ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Symbols and immutability
Hello, I have changed the symbol-string procedure to copy the string associated with its argument. There should be a new development snapshot available tomorrow, or you can check it out from SVN. -Ivan Peter Bex [EMAIL PROTECTED] writes: Hi all, According to Elf the main Chicken hackers (Felix and Kon) do not read the janitors list and few others do. I just submitted a ticket for a nasty bug, #433 http://trac.callcc.org/ticket/433 What are your thoughts on how to solve this issue? ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] required-extension-version (possible version-numbers issue)
Yes, that's exactly what I have been trying to say. If you use the same consistent versioning format, then chicken-setup will work correctly, regardless of whether the format is x.x.x or x.xxx, or whatever. But if you switch from one format to another, then you risk messing up the version order. So the moral of the story is, do use consistent versioning format. -Ivan Mario Domenech Goulart [EMAIL PROTECTED] writes: Actually I think the real problem is that lookup-table uses two different and incompatible versioning schemes. Maybe egg authors should stick to either xx.xx or xx.xx.xx forms, and should not combine them for the same egg. That would solve the problem, wouldn't it? Best wishes, Mario ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] regex speedup
I saw it was updated, and I assumed it was you, but the svn log shows otherwise. Praise withdrawn :-) -Ivan Elf [EMAIL PROTECTED] writes: i did? i didnt -elf On Tue, 11 Mar 2008, Ivan Raikov wrote: You remembered to update NEWS, also. Good developer! :-) -Ivan Elf [EMAIL PROTECTED] writes: patch applied! thanks! -elf ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] TinyCLOS 'examples' install path?
Okay, I see what you mean now. I think it might be possible to introduce separate actions or stages in chicken-setup, but I do not want to make any more changes right now, because I need to deal with the side-effects of introducing the -install-prefix option. I believe it would be easy to separate the installation of libraries and documentation. The more difficult part would have to do with eggs that use copy-file/move-file to install additional files, and eggs that run make or some other external commands as part of the compilation. One possible scheme would be to introduce the following stages in chicken-setup: 1. Compilation (via the compile macro, or make) 2. Installation of extensions 3. Installation of programs 4. Installation of scripts 5. Installation of documentation 6. Files installed with copy-file/move-file I think that it would not be very difficult to add options to chicken-setup that only execute a part of the above sequence. But some eggs do things like this: (run (csi -qbs atlas-lapack-eggdoc.scm atlas-lapack.html)) Logically, this should be part of the compilation process, but of course chicken-setup has no way of telling that. One possible solution would be to prohibit the direct use of the run macro in setup scripts, and instead use a variant of the macro that specifies the stage when it should be executed, e.g.: (post-compile (run (csi -qbs atlas-lapack-eggdoc.scm atlas-lapack.html))) post-compile here tells chicken-setup that this command should be considered part of the compilation stage, and it should be executed after all invocations of compile or make. So I think what you are proposing is feasible, it just takes a little bit of careful thought, and unfortunately it will require modifying existing setup scripts. -Ivan Leonardo Valeri Manera [EMAIL PROTECTED] writes: What I mean is that the egg build system does not support separate compilation/installation actions, or at least not consistently. With 3.0.0 chicken-setup it was (sometimes) possible to do this, with the chicken-setup in trunk (which is much better, btw) this isnt possible at all, from what I can tell. Not that we at gentoo could make a use of such a feature if it existed because: It also has no support for separate documentation installation paths. I've reworked my eclass functions around trunk. Its working very nicely, and you don't have to really bother with anything else on my account: I compile and install in a temp dir in one action, where it would normally be 2, then perform 'make install' equivalent actions to the real sandbox install tree myself since I need to move the documentation to /usr/share/doc. Of course it would be better if I could make chicken-setup do that for me, but that would probably be not worth the bother for you guys :) Leo ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] TinyCLOS 'examples' install path?
I will look at the tinyclos egg, but I think you should use -install-prefix for what you are trying to do. I have started using that for my Debian scripts and so far it seems to work well. I haven't tried anything with tinyclos yet, though. The idea is that you should _not_ have to add any workarounds: the express purpose of the -install-prefix option is for sandbox-type installation. -Ivan Leonardo Valeri Manera [EMAIL PROTECTED] writes: On 02/03/2008, Ivan Raikov [EMAIL PROTECTED] wrote: What you are referring to is the _Chicken_ install prefix, i.e. where the Chicken executables are installed. What I am referring to, is the user _install_ prefix, for situations where you would like have the eggs in a separate directory hierarchy (e.g. when building binary packages). It is a bit confusing, but take a look and the updated chicken-setup documentation and let me know what you think. I have already made the changes, but of course I can make further changes. I still have the same issue when installing tinyclos (release) with trunk chicken. I need to know whether I need to add functions to take care of eggs that do not respect -R, or what :) Cheers, Leo ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] TinyCLOS 'examples' install path?
I was wrong about that, the value of CHICKEN_REPOSITORY is accessed
through the parameter repository-path, and the -R option works as
expected. But if -destdir is specified, then the repository becomes
{destdir}/lib/chicken. -destdir always overrides the repository path,
hence the confusion. I propose eliminating -destdir, and introducing
option -install-prefix, which is prepended to the repository path and
any data files being installed with copy-file. Something along the
lines of this:
$ chicken-setup -R
/var/lib/chicken/3
$ chicken-setup tinyclos =
files installed in /var/lib/chicken/3
$ chicken-setup -R /usr/lib/chicken tinyclos =
files installed in /usr/lib/chicken/3.
$ chicken-setup -install-prefix $HOME/gentoo/tinyclos =
files installed in $HOME/gentoo/tinyclos/var/lib/chicken/3
$ chicken-setup -R /usr/lib/chicken \
-install-prefix $HOME/gentoo/tinyclos =
files installed in $HOME/gentoo/tinyclos/usr/lib/chicken/3
Right now, CHICKEN_REPOSITORY is not checked in chicken-setup,
although the man page claims otherwise. I am going to put this back,
so we are consistent with the documentation.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] call for repository/chicken-setup organization plans
You can use the svn lock command, but I suppose there isn't so much danger of modifications to the release/2 branch. -Ivan felix winkelmann [EMAIL PROTECTED] writes: I've created the link. I don't know how to lock release/2 with svn and would rather avoid that to make it possible to quickly fix bugs should the need arise. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] sudo-install
I have added checks for TMPDIR and TEMPDIR. I do have TMP set in my
environment, but it turned out this is something I have added, not
part of the standard user environment. If anyone has suggestions about
other environment variables that specify temporary directory, I can
add those, too.
If none of the T.* variables is set, then if /tmp is writeable, the
default build directory becomes
/tmp/chicken-setup-{MAJOR-VERSION}-{USER},
otherwise {HOME}/tmp/chicken-setup-{MAJOR-VERSION}-{USER}. If
{HOME}/tmp does not exist, then the current directory is used.
-Ivan
felix winkelmann [EMAIL PROTECTED] writes:
On Mon, Feb 25, 2008 at 2:48 PM, Ivan Raikov [EMAIL PROTECTED] wrote:
I have added two options to chicken-setup: -build-prefix and
-download-dir. build-prefix is where chicken-setup creates a temporary
directory, unpacks the egg and then compiles it. download-dir is the
directory where downloaded egg files are saved. build-prefix defaults
to the value of the environment variable TMP, if set, otherwise
$HOME/chicken-build. If some other behavior is desired, I can easily
make changes.
I would propose the following changes:
- also check TMPDIR and TEMPDIR (I have none of those T... variables
set in my env, BTW)
- use /tmp/chicken-setup-$USER (or similar) instead of $HOME/chicken-build
(the latter is too generic and might conflict with existing directories)
cheers,
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] sudo-install
I have added two options to chicken-setup: -build-prefix and -download-dir. build-prefix is where chicken-setup creates a temporary directory, unpacks the egg and then compiles it. download-dir is the directory where downloaded egg files are saved. build-prefix defaults to the value of the environment variable TMP, if set, otherwise $HOME/chicken-build. If some other behavior is desired, I can easily make changes. The issue with sudo is a bit more complicated than I thought, because the real user id also gets set to zero when chicken-setup is running under sudo or su. sudo sets environment variable SUDO_USER, which shows the id of the user that invoked sudo, so that might be one way to detect if chicken-setup is being run under sudo. I will look some more into this before hacking chicken-setup to change its euid. -Ivan felix winkelmann [EMAIL PROTECTED] writes: Cool! I have to warn you, though: chicken-setup.scm is a real mess! ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] procedure/etiquette for submitting changes?
Hello, If you want, post your patch to this mailing list before committing, and I can make sure it doesn't break the Unix builds. I don't have Windows or MSVC, so I cannot test the MSVC build, but at least I can make sure there are no accidental breakages of something else. -Ivan Ashley Bone [EMAIL PROTECTED] writes: What is the general process for submitting changes? I have write access to the subversion repository and I'd like to submit some minor changes to rules.make, Makefile.msvc, and a one-line change to library.scm, all to fix the MSVC build. Should I just commit the changes? I saw a previous post about submitting svn diffs via chicken-bug but I'm not sure that's for everything or just major revisions. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] trac.callcc.org
Hi all, It seems that trac.callcc.org is down most of the time I try to access it. Either I get a 500 error, or the HTTP request times out after a very long time. Is this instability inherent in Trac, or is there something peculiar about this particular installation? In either case, we need to do something about that. -Ivan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] Re: trac roadmap
Hi Felix, I don't believe I have access rights for milestones, so if anyone can grant me those, I can start working on a tentative roadmap for the next release. I have also created a wiki page for roadmap proposals and discussions: http://chicken.wiki.br/roadmap The idea is to use the wiki to hammer out proposals for new features or major changes, and create tickets that have fairly specific todo items. So I would appreciate if people start including their ideas about future modifications to Chicken on that page. -Ivan felix winkelmann [EMAIL PROTECTED] writes: Hi, Ivan! Since you asked for keeping up a more disciplined release process, have you access rights for creating milestones on trac? (I shortsightedly removed my admin permissions the other day, so perhaps mario or arto have to help out). If you would like to do some release planning and keeping a list of feature requests and such, using the trac milestone/roadmap stuff may be quite helpful. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] .egg - .deb packaging issues
I am also still interested in packaging Chicken eggs for Debian. But, to add to your list of issues, the current version of Chicken in Debian testing is 2.5. There is a wishlist item filed to upgrade Chicken to 2.7, but so far no response on part of the package maintainer. So we will either have to use unofficial Debian packages with more recent Chicken, or find a way to get in touch with the maintainer: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418747 And I have some responses to the other issues below: * package naming convention -- I actually prefer the naming convention for Common Lisp packages, which is cl-PACKAGE (in our case, chicken-PACKAGE). The libPACKAGE-LANGUAGE seems overly verbose. * more extension repository locations -- good idea, I could use CHICKEN_LIBRARY_PATH to direct Chicken to look into my home directory for extensions first. By the way, the current Debian location for Chicken extensions is /var/lib/chicken/binary-version. * default repository for chicken-setup -- perhaps an even more sensible default would be to check if the current user is root, and if so, install the extension in the system-wide /var/lib/chicken, otherwise install into $HOME/var/lib/chicken, or something along those lines. What do people think? With an APT-repository of Debian packages available, deploying a feature-rich version of Chicken-based Scheme programming environment could be made lightning-fast. I believe this will make Chicken a viable alternative to other languages (such as Perl or Python), at least in Debian-based GNU systems. Preach on, brother ;-) -Ivan Ivan Shmakov [EMAIL PROTECTED] writes: I'm still interested in packaging pre-built binary extensions for Chicken with `dpkg'. There're a few issues still unresolved, IIRC: * Debian packages for other languages' extensions usually follow libEXTENSION-LANGUAGE convention (e. g., libocamlnet-ocaml); could this convention be adopted for Chicken's extensions? * currently, Chicken seems to search for extensions in, roughly, $CHICKEN_REPOSITORY and $CHICKEN_HOME; it's not enough, since there's to be a distribution-wide repository of pre-compiled packages (/usr/lib/chicken/binary-version), a system-local one (/usr/local/...) and a user's own one (e. g., ~/lib/chicken/binary-version); a facility for selecting any number of directories to search for the packages needs to be added (perhaps, a CHICKEN_LIBRARY_PATH environment variable); * on the other hand, `chicken-setup' needs exactly one directory to install the packages into; thus, CHICKEN_REPOSITORY variable is to be preserved in its current meaning; BTW, as a convenience, a default repository for `chicken-setup' could be changed to point to a directory below $HOME; thus, `chicken-setup' will behave sensibly even for non-privileged accounts on system-wide Chicken installations; ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] RFC : How to make a Debian package for a chicken egg?
Okay, definitely let me know if there is anything I can do help with this effort. I am not able maintain a lot of packages on my own, but I am very interested in helping to get Chicken eggs packages in the official Debian distribution. -Ivan Nelson Castillo [EMAIL PROTECTED] writes: On 9/11/07, Ivan Raikov [EMAIL PROTECTED] wrote: Hello, Nelson, You can look at the Debian packaging scripts I wrote for some eggs here: http://www.irp.oist.jp/raikov/chicken-eggs-debian.tar.gz Let me know if you have any questions about those scripts. Thanks! Well, there was a request for Debian packages for Svnwiki in a list about Debian in Colombia[1]. I would like to try to create the packages (basically because nobody else seems to be willing to do it :) ). The Debian developer said he would sponsor the packages so that they can get in Debian. The packages you created will be very useful in this task. I will let you know if we make any progress. Regards, N.- ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] anybody good with cmake?
Famous last words. ;-) Peter Bex [EMAIL PROTECTED] writes: It can never be worse than autohell. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Debian package
Okay, wow, I didn't know there was so much drama involved in this :-) I assumed that Chicken used Automake/Autoconf, the way God intended, and since I have extensive experience with those, I didn't think there would be a problem adding the Debian files to the dist target. But I'll learn CMake, if you say so. Unfortunately, it's hard to deduce when the Debian scripts get broken, except for actually running the package builder. But I'll definitely keep an eye on those. -Ivan Brandon J. Van Every [EMAIL PROTECTED] writes: The only change? :-) And in one breath, you point out the problem. You see, Makefile.am is *not* the way anybody's supposed to be building distros. People are supposed to be using CMake and typing make dist. It's supposed to be the One True Way To Build Distros. But Felix had some difficulty with CMake on Linux a month or so ago, and I think he was hacking his way around it for a time. Rather than learning how to deal with CMake's bugs. Don't know what the circumstances are now, as I've been preoccupied. I do know that CMake 2.4.5 has fewer bugs, and Felix said some Linux problems went away. My point is, we all need to be on the SAME PAGE about how distros are built. I'm not pointing fingers; I've been as stressed out as anyone else, actually moreso. But under pressure, people tend to stick with what they know. That damages the reliability of the build. Code diverges, specific items stop working, and then people don't fix them because it's a PITA. So what I believe needs to happen is: - you need to be given proper Darcs access - I need to provide you with the CMake stubs to fire up make dist correctly for Debian. Sounds trivial enough. - you need to implement your Debian packaging, test it, and maintain it, i.e. take ownership. - you need to use CMake to do make dist - I need to provide whatever system deduction checks and error messages are useful for this, so that when (inevitably), someone breaks the Debian distro, we know it has happened. - Felix shouldn't have to do anything, unless there's some lurking horror about texi that we've forgotten about. Do you agree? Cheers, Brandon Van Every ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CMake vs. Autoconf
No, I never tested the library in Windows command prompt or MSVC. I like my POSIX conveniences too much. But of course, Chicken is a vastly more complex program, so I am sure yours are perfectly legitimate grievances. I was just curious to hear what problems people have encountered, since I don't use Windows, and most likely never will. -Ivan Brandon J. Van Every [EMAIL PROTECTED] writes: I ported a fairly complex distributed computing toolkit to MinGW last month, and the only GNU-related problem I saw was that libtool somehow gets confused when the source directory includes spaces (like Documents and Settings). In fact, I was pleasantly surprised how painless things were. The only? That kind of whitespace problem consumed a few months of our time, and I'm still not certain the beast is slain. Handling different pathname conventions on different shells is a nightmare. I'm curious, did your project also handle straight Windows Command Prompt? or MSVC builds? If you stay in a Unix-insulated universe where pathnames are always forward slash, your job is a helluva lot easier. I've also had problems with MSYS's support of Autoconf. At times, that has sucked as well. Enough that I dumped the standard MSYS package and went with mingw-install. http://sourceforge.net/projects/mingw-install Cheers, Brandon Van Every ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
