Re: [Chicken-hackers] [patch] utils: qs not escaping pipes
On Sun, Feb 24, 2013 at 06:00:17PM +0100, Michele La Monaca wrote: While backslash-escaping is equivalent to its corresponding quoting, the same is not true for caret-escaping. Depending on the context one is more appropriate than the other. AFAICT the general rule is to use double-quoting for pathnames and caret-escaping for textual strings. Do you have a reference where we can read up on this caret escaping? If it's context-dependent it seems like it would be impossible to decide generally which to use, and we might need an extra option to choose between both quoting forms (abusing the quoting option for this is wrong because the difference in Windows is semantical while in Unix it seems to be purely aesthetical). 1) added the characters '|' '=' '^' ',' 2) removed the charater '%'. I don't see a good reason to escape it. Am I wrong? 3) removed a non ASCII character (0xb4). Why it was there? If you see missteps or ways to improve please raise your hands. I see zero usefulness in the backwards compatibility feature. It just doubles the size of the code with no advantage except it may be more readable in a few cases. I think if this more readable version is desirable to have (which I seriously doubt), it should be put in an egg. 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] Taming the egg versioning wilderness
Fellow Chickeneers, I just had the following problem (again): I tagged a new version of the lowdown egg (0.0.6). While doing so I realized that the previous tag (0.0.5) still installed itself as 0.0.4 via the install-extension invocation in its .setup file. This lead me to think over the whole situation of how we deal with egg versioning and I found it pretty error-prone and inconvenient for both users and authors. Sticking to my example: 1) Users get confused because if they run chicken-install lowdown (or even chicken-install lowdown:0.0.5), chicken-status will afterwards tell them that 0.0.4 is installed in this case. 2) Authors have to be vigilant to always keep three places in sync: The version in the .setup file (another issue here is that each invocation of install-extension and install-program require the version to be passed -- hopefully it's always the same one), the version in the .release-info file and (if a VCS is used, which is usually the case) the version in the tag name. It may of course be that I misunderstand some intentions of the versioning system as it is (e.g. why it is possible to install multiple extensions and programs with differing versions from within an egg which itself can have yet another differing version). If that's the case I'd be happy to be enlightened about it! Otherwise I'd suggest to somehow get rid of at least the versions in the .setup file. Maybe it would be possible to make them optional and use the egg's version as a default in this case? Let me know what your thoughts are on this issue. I am happy to try to come up with a patch should we agree on how to proceed. Thanks! Moritz ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Taming the egg versioning wilderness
Hi der gute Moritz, On Mon, 25 Feb 2013 09:51:22 +0100 Moritz Heidkamp mor...@twoticketsplease.de wrote: I just had the following problem (again): I tagged a new version of the lowdown egg (0.0.6). While doing so I realized that the previous tag (0.0.5) still installed itself as 0.0.4 via the install-extension invocation in its .setup file. This lead me to think over the whole situation of how we deal with egg versioning and I found it pretty error-prone and inconvenient for both users and authors. Sticking to my example: 1) Users get confused because if they run chicken-install lowdown (or even chicken-install lowdown:0.0.5), chicken-status will afterwards tell them that 0.0.4 is installed in this case. 2) Authors have to be vigilant to always keep three places in sync: The version in the .setup file (another issue here is that each invocation of install-extension and install-program require the version to be passed -- hopefully it's always the same one), the version in the .release-info file and (if a VCS is used, which is usually the case) the version in the tag name. It may of course be that I misunderstand some intentions of the versioning system as it is (e.g. why it is possible to install multiple extensions and programs with differing versions from within an egg which itself can have yet another differing version). If that's the case I'd be happy to be enlightened about it! Otherwise I'd suggest to somehow get rid of at least the versions in the .setup file. Maybe it would be possible to make them optional and use the egg's version as a default in this case? Let me know what your thoughts are on this issue. I am happy to try to come up with a patch should we agree on how to proceed. I don't know exactly how to simplify this situation, so I'll comment on how detect those errors. Salmonella is able to detect those kind of errors if run with the --eggs-source-dir option. In that case, it uses chicken-install with the local transport. tests-call-cc.org doesn't use that mode, so it is unable to detect those errors. Even if it used the local transport, it would detect the error only after it was published. It would be slightly better than the current situation, but using the local transport would mean not testing the network part of chicken-install and the server-side part (henrietta servers) -- we caught some problems related to those parts in the past. Besides that, using --eggs-source-dir is not compatible with salmonella-epidemy, since chicken-install uses the eggs source directory to compile code, which makes it subject to race conditions when running multiple salmonella instances in parallel (that's what salmonella-epidemy does). We current don't use salmonella-epidemy on tests.call-cc.org, but as soon as we get a better machine we can use it. Salmonella in the egg-lint mode could catch the version problem before the egg is published, but setting it up to do that is a bit awkward: you'd need to fake the directory layout expected by chicken-install in the local transport mode (egg/tags/version), and you'd need to provide --eggs-source-dir. I don't think it is practical. After you do all that, you probably realized that you have a version problem. We could make salmonella check versions even in the non local transport mode: it could query henrietta for the egg versions, pick the latest and then proceed to install/test the egg. Then it could check if the version stored in .setup-info matches the latest version provided by henrietta. But, again, it would only report the problem ater it has been published. Also, since the pick-latest-version/install/check-installed-version steps are not atomic, salmonella could report some false problems. With regard to the problem of a single egg installing multiple extension versions, salmonella could detect that for newer chickens (IIRC, chickens 4.7.0 -- not sure about the exact version), since they add the the egg-name field to .setup-info files. So, salmonella could read all the .setup-info files in the local egg repository, find the ones that have egg-name corresponding to the egg under test and check if the versions are the same. Best wishes, Mario -- http://parenteses.org/mario ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] Whishlist entry: macro expansion for type declarations.
Hi all, maybe that's not a wishlist entry, but just me missing somthing? When adding type declarations to some source, which has grown for over a decade, I ran into this situation: There's are widespread use cases of some types, which are actually implemented as vectors, pairs or lists with a certain substructure. The original idea to add types to this otherwise working (and relied upon) program was to simplify the structure. Thus I don't just want to add the type as is happens to be using a long wielded construct like (or boolean (pair (struct whatever) (pair symbol maybesomthing))) which would be what I'd have to write next dozends of times. Once I'd be through this, I'd like to replace the (pair ...) stuff and selectively remove the boolean alternative. This is so error-prone that I don't dare! My great idea was, to write a handful of templates using define-syntax and then use these where appropriate. This would allow me to change these as desired and then fix all the resulting warnings ((second wishlist entry: have a compiler switch to turn these warnings into errors)) accordingly. So I wrote (define-syntax :foo-type-or-not: (syntax-rules () ((_) (or boolean (pair (struct whatever) (pair symbol maybesomthing)) and used it like this (: bar (my params - (:foo-type-or-not:))) But: chicken complains that the (:foo-type-or-not:) macro I defined would be illegal in the type annotation. I take this as sign that the macro was not expanded at all. Correct? Any way to get this done? If not, would it be feasible to add this expansion step into chicken? Thanks a lot! /Jerry ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Whishlist entry: macro expansion for type declarations.
Hi,
have you tried define-type:
syntax(define-type NAME TYPE)/syntax
Defines a type-abbreviation {{NAME}} that can be used in place of
{{TYPE}}. Type-abbreviations defined inside a module are not visible
outside of that module.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [patch] utils: qs not escaping pipes
On Mon, Feb 25, 2013 at 9:10 AM, Peter Bex peter@xs4all.nl wrote: Do you have a reference where we can read up on this caret escaping? I think you already provided one: http://technet.microsoft.com/en-us/library/cc723564.aspx If it's context-dependent it seems like it would be impossible to decide generally which to use, Right. In Windows escape/quoting rules really depends on which command is issued. The interpretation of the command-line is mostly up to the command itself. And each command has its own interpretation of the rules. An example? # cd a^ b will try to enter the a b folder, while # md a^ b will create the folders a and b. and we might need an extra option to choose between both quoting forms (abusing the quoting option for this is wrong because the difference in Windows is semantical while in Unix it seems to be purely aesthetical). Not quite true. For example backslash-escaping has this nice property: (qs (string-append s1 s2)) == (string-append (qs s1) (qs s2)) Regards, Michele ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
