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
Re: [Chicken-hackers] [patch] utils: qs not escaping pipes
Peter Bex scripsit: > > 2) removed the charater '%'. I don't see a good reason to escape it. Am I > > wrong? Percent must be escaped in .BAT and .CMD files because %FOO% is how you say $FOO. -- John Cowan co...@ccil.orghttp://ccil.org/~cowan No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friends or of thine own were: any man's death diminishes me, because I am involved in mankind, and therefore never send to know for whom the bell tolls; it tolls for thee. --John Donne ___ 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 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 (/tags/), 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
Re: [Chicken-hackers] Taming the egg versioning wilderness
Hi Mario, Mario Domenech Goulart writes: > I don't know exactly how to simplify this situation, so I'll comment on > how detect those errors. > > [... lots of useful advice ...] thanks for that, this will definitely help to make maintenance less of a pain in the meantime unless one forgets to do the salmonella dance :-) It would be better if we wouldn't have to worry about these problems to begin with, though, or would you disagree? Thanks again! 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
On Mon, 25 Feb 2013 20:04:53 +0100 Moritz Heidkamp wrote: > Mario Domenech Goulart writes: >> I don't know exactly how to simplify this situation, so I'll comment on >> how detect those errors. >> >> [... lots of useful advice ...] > > thanks for that, this will definitely help to make maintenance less of a > pain in the meantime unless one forgets to do the salmonella dance :-) > It would be better if we wouldn't have to worry about these problems to > begin with, though, or would you disagree? I totally agree. I just don't know a simple way to do that, keeping things backward-compatible and so on. 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:
(define-type NAME TYPE)
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] Whishlist entry: macro expansion for type declarations.
Thanks!
On Feb 25 2013, megane wrote:
Hi,
have you tried define-type:
(define-type NAME TYPE)
No, I did not - so far.
(I thought this would be a part of the FFI stuff.)
Looks as if it just did the job. Thus I should be able to
have an extra file of type aliases like this to be included
all over the place.
That's a solution to the problem at hand.
/Jerry
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] [Chicken-users] using types
Will try ASAP.
On Feb 24 2013, megane wrote:
Jörg F. Wittenberger writes:
On Feb 21 2013, Jörg F. Wittenberger wrote:
Somehow I can't verify that my type declarations are actually
effective.
I've been able to verify that my .types files are not ever consulted.
Using strace I found that the "foo.types" file is searched for in
stat("/usr/lib/chicken/6/foo.types", 0x7fffc1895400) = -1 ENOENT (No
such file or directory)
But since that's not an extension but just a simple module, which is
part of a larger program, there is no good reason to ever install
the .types file in the repository.
To deal with the issue I tried to use -setup-mode. No effect at all.
Further it seem to be the case that CHICKEN_REPOSITORY must be s imple
directory and may not be some colon-separated path.
At this moment I don't see any solution how to make chicken read
the .types files it produced *within* a single directory.
How would I do that?
Thanks a lot!
Could you try if this [1] patch is of help. It essentially makes the
compiler to search for .types files from each path supplied with
-include-path.
Footnotes:
[1] http://bugs.call-cc.org/ticket/9
___
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 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
