[Chicken-users] [ANN] Chicken Installer for Windows 4.8.0.1
Hi, I just updated the chicken installer to version 4.8.0.1. You can get it at https://bitbucket.org/roti/chicken-installer/downloads. Enjoy, Răzvan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] Chicken Installer for Windows 4.8.0.1
Mulțumesc! It's very nice to have an easy-to-use installer for Windows. Hi, I just updated the chicken installer to version 4.8.0.1. You can get it at https://bitbucket.org/roti/chicken-installer/downloads. Enjoy, Răzvan -- Best regards, Dmitry Kushnariov ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Wed, Feb 20, 2013 at 1:24 PM, Dan Leslie d...@ironoxide.ca wrote: Nice work, contributions are greatly appreciated. :) Since you're asking for constructive feedback, two things come to mind: It's a matter of taste, but IMHO it's schemier that *descriptive-variable*is preferable to *desc-var*, so in your case *s-foo* could easily be *string-foo*. However, I would drop the prefix altogether, as Chicken supports renaming on import. So *string-foo* would become *foo* and any prefixing is left up to the user of your library. I'm not certain what you intended by 'official', but if you meant that you'd like to see it packaged with Chicken then perhaps you should consider switching the license to Chicken's license. Mind you, GPL3 eggs are happily accepted, but note that many folks won't touch them for various reasons. However, if this is a port of an elisp library then likely re-licensing is not an option. I would love to package this under the BSD license, but as far as my limited knowledge is concerned, it seems that I must keep the GPL3 license of the original elisp package. If someone is aware of an alternative solution, please speak up and I'll change things accordingly. Anyhow, thanks for the hard work and the contribution! And welcome to Chicken-land, come join us on IRC if you get a chance. Thanks! It's been a joy working with the chicken community so far :) - Nick ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] documenting eggs
Hi people, some questions regarding egg docs: 1) I understand that the egg doc should be added to the wiki, but I suppose that it should respect a particular format to be compatible with chickadee, I'm right? where I can found it? 2) Is there any tools for this? I found the cock egg, but I don't find any documentation about it, so I don't know neighter how it's works or if it's helpfull in this case. Thanks, Hugo ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documenting eggs
Hi Hugo, On Thu, 21 Feb 2013 15:52:24 -0300 Hugo Arregui hugo.arre...@gmail.com wrote: some questions regarding egg docs: 1) I understand that the egg doc should be added to the wiki, but I suppose that it should respect a particular format to be compatible with chickadee, I'm right? where I can found it? Indeed. The format is the Chicken Wiki syntax. Here's the documentation for it: http://wiki.call-cc.org/edit-help You can also get the wiki content from svn[1] to see practical examples. [1] svn co https://code.call-cc.org/svn/wiki/eggref/4 (user = anonymous, empty password) 2) Is there any tools for this? I found the cock egg, but I don't find any documentation about it, so I don't know neighter how it's works or if it's helpfull in this case. There is also https://github.com/mario-goulart/quickdoc to generate an initial documentation out of source code and https://github.com/mario-goulart/el-chicken-wiki which provides some [hopefully] useful commands for emacs. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Feb 20 2013, Mario Domenech Goulart wrote: join-strings, and string-match or match-string. Another is to keep the s- prefix, which is a natural grouping. Or you could require the user to prefix on import, but if that's always needed due to conflicts, why make them go through the extra step? I'd disagree. I feel that using the (personally *much* appreciated) rename feature chicken provides to disambiguate at the users choice would be the best way to deal with this kind of matter. Adding this simple statement doesn't make much of a difference to your source code. However *not* having the feature at hand and have to rename all identifiers manually when you want to exchange one implementation for another is a real burden. I've been in this situation often enough. My boiler-plate solution is to create yet another module which imports all of the prefixed (in this case this would be the s- prefixed stuff), bind them to the names sans prefix and export again. Then ipon import rename as god intended. This makes a yet another file to maintain as trade off for a single s-expression containing three symbols… add1 (except if there is an `exchange' procedure in the API). :-) Mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Jörg F. Wittenberger scripsit: I've been in this situation often enough. My boiler-plate solution is to create yet another module which imports all of the prefixed (in this case this would be the s- prefixed stuff), bind them to the names sans prefix and export again. Then ipon import rename as god intended. I've proposed a new type of import specifier to go with prefix, namely drop-prefix. Rather than prefixing all names, this removes the prefix from any names that have it. This would be a Good Thing to add to Chicken; Chibi already has it, and it is part of a proposal for R7RS-large. -- Why are well-meaning Westerners so concerned that John Cowan the opening of a Colonel Sanders in Beijing means co...@ccil.org the end of Chinese culture? [...] We have had http://www.ccil.org/~cowan Chinese restaurants in America for over a century, and it hasn't made us Chinese. On the contrary, we obliged the Chinese to invent chop suey.--Marshall Sahlins ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
I've proposed a new type of import specifier to go with prefix, namely drop-prefix. Rather than prefixing all names, this removes the prefix from any names that have it. This would be a Good Thing to add to Chicken; Chibi already has it, and it is part of a proposal for R7RS-large. That would be incredibly handy. -Dan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Feb 21, 2013, at 1:50 PM, Jörg F. Wittenberger wrote: On Feb 20 2013, Mario Domenech Goulart [well, actually, I, Jim] wrote: join-strings, and string-match or match-string. Another is to keep the s- prefix, which is a natural grouping. Or you could require the user to prefix on import, but if that's always needed due to conflicts, why make them go through the extra step? I'd disagree. I feel that using the (personally *much* appreciated) rename feature chicken provides to disambiguate at the users choice would be the best way to deal with this kind of matter. You're totally free to do so, it seems there is no one right answer, and my opinion has changed even between eggs. Adding this simple statement doesn't make much of a difference to your source code. However *not* having the feature at hand and have to rename all identifiers manually when you want to exchange one implementation for another is a real burden. In this case the implementation is essentially of the s.el API, not a generic strings library, and so an alternate implementation of the API could just as easily be prefixed s-* to indicate the s.el API with different underlying code. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Feb 21, 2013, at 2:04 PM, John Cowan wrote: I've proposed a new type of import specifier to go with prefix, namely drop-prefix. Rather than prefixing all names, this removes the prefix from any names that have it. This would be a Good Thing to add to Chicken; Chibi already has it, and it is part of a proposal for R7RS-large. I think regex rename would be more general. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On Feb 21 2013, Mario Domenech Goulart wrote: On 21 Feb 2013 20:50:16 +0100 Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: On Feb 20 2013, Mario Domenech Goulart wrote: join-strings, and string-match or match-string. Another is to keep the s- prefix, which is a natural grouping. Or you could require the user to prefix on import, but if that's always needed due to conflicts, why make them go through the extra step? I'd disagree. Notice that what you quoted was not written by me. Sorry. Dunno how that happend. Currently I'm typing half-blind. Awaiting cataract surgery in a few weeks. Best wishes. Mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Jim Ursetto scripsit: I've proposed a new type of import specifier to go with prefix, namely drop-prefix. Rather than prefixing all names, this removes the prefix from any names that have it. This would be a Good Thing to add to Chicken; Chibi already has it, and it is part of a proposal for R7RS-large. I think regex rename would be more general. Of course it would, and the Perl substitute command would be more general still. For that matter, you could allow an arbitrary Scheme procedure to be provided. But drop-prefix is dead simple, has precedent, and is easy to understand and use. -- John Cowan http://www.ccil.org/~cowan co...@ccil.org The native charset of SMS messages supports English, French, mainland Scandinavian languages, German, Italian, Spanish with no accents, and GREEK SHOUTING. Everything else has to be Unicode, which means you get only 70 16-bit characters in a text instead of 160 7-bit characters. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Dan Leslie scripsit: Of course it would, and the Perl substitute command would be more general still. For that matter, you could allow an arbitrary Scheme procedure to be provided. But drop-prefix is dead simple, has precedent, and is easy to understand and use. Why not have both? Okay, let's do it backwards. No precedent. Harder to implement. Harder to document. Harder to use. Ticket #988 filed for drop-prefix. Feel free to file your own ticket or prepare your own patch. -- We are lost, lost. No name, no business, no Precious, nothing. Only empty. Only hungry: yes, we are hungry. A few little fishes, nassty bony little fishes, for a poor creature, and they say death. So wise they are; so just, so very just. --Gollumco...@ccil.org http://ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Of course it would, and the Perl substitute command would be more general still. For that matter, you could allow an arbitrary Scheme procedure to be provided. But drop-prefix is dead simple, has precedent, and is easy to understand and use. Why not have both? -Dan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] using types
Somehow I can't verify that my type declarations are actually
effective.
So far I noticed that when I make usage-error wrt. types I
- within a single file that is -
get an error in tje compilation step.. Which is what I like.
Now that I've got a .types file for each module, I tried to
enforce this situation by violating the declared procedures
signature. But it did *not* give me the expected error.
Maybe I'm doing something wrong?
So far I'm relying on these lines from manual/Types:
If library code is used with {{require-extension}} or {{(declare (unit
...))}} and a {{.types}} file of the same name exists in the
extension repository path, then it is automatically consulted. This
allows code using these libraries to take advantage of type-information
for library definitions.
I have a file foo.types, which declares
(: bar (fixnum) - . *)
in foobar.scm I have
(declare
(unit foobar)
(uses foo)
...)
but the attempt to provoke an error by calling
(bar some-fixnum-which-is-from-working-code-anyway 27)
-- which clearly violates the given signature above giving
the additional parameter 27
(while the signature in turn was verified to be correct in foo.types)
I did *not* result in any warning, let alone the stop-compile-on-error
I hoped to receive.
I'd like to add that prior to this experiment I went without
the (declare ... (uses foo) ...) having only an import statement
(import foo) in my foobar.scm - while this would be an analogous
use to the declare-variant it would be undocumented AFAI can see.
Now I dunno how I can make (sure) use of my type declarations
short of manually adding a -types foo.types entry for each an
every import in the scheme source to my Makefile.
Any help much apprecuated.
/Jörg
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On 2/21/13 9:55 AM, Nicholas Van Horn wrote: On Wed, Feb 20, 2013 at 1:24 PM, Dan Leslie d...@ironoxide.ca mailto:d...@ironoxide.ca wrote: I'm not certain what you intended by 'official', but if you meant that you'd like to see it packaged with Chicken then perhaps you should consider switching the license to Chicken's license. Mind you, GPL3 eggs are happily accepted, but note that many folks won't touch them for various reasons. However, if this is a port of an elisp library then likely re-licensing is not an option. I would love to package this under the BSD license, but as far as my limited knowledge is concerned, it seems that I must keep the GPL3 license of the original elisp package. If someone is aware of an alternative solution, please speak up and I'll change things accordingly. I am not a lawyer, what follows is not legal advice, etc. ... It's possible to change the license by clean room reverse engineering the library, since the new code would (from a legal standpoint) not be a copy or derivative of the original code. To do that: someone who has not seen any of the contaminated source code (i.e. the original library or your port) reimplements the library from scratch based only on a general description of the original library's API and behavior, (e.g. your README file). Then, they can attach any license they wish to the new code. This approach is typically used to reverse engineer proprietary software, for example to create an open source clone. But there's no reason it couldn't be used to create a clone of another open source library with a different license. The downside is that it might be considered rude or disrespectful by some people in the open source community, especially if you use the exact same library name and function names as the original. On the other hand, this library is so simple and obvious that I think it would be very silly for anyone to be offended by it being cloned. - John ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documenting eggs
Thanks Mario, Dan. Very useful information as usual!. Regards, Hugo ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
