Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
I did not consider the stream-ext library in the design of SRFI-41. In general, as explained in the SRFI, I designed SRFI-41 according to the advice of Antoine de Saint-Exupéry: *Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher*. (“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”) And I think I got a couple of things wrong -- if I was to rewrite SRFI-41 today, I would take away even more. Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, due to the underlying promises that require numerous type conversions, so streams should be used only when the sequence of elements is truly infinite (such as mathematical series) or when there is some clear advantage of laziness (such as reducing the number of passes through a large data set). Writing a library that duplicates SRFI-1 for streams seems to me to be folly. I looked briefly at your list of suggested extensions. A few may be useful for a modest extension library, if you have in mind a particular set of uses -- some of the examples in the SRFI, such as stream-partition, fall into this category. Some certainly don't belong in a general-purpose library -- if you need symbol-stream to convert the name of a symbol into a stream of characters, you can write it as part of your program. Many -- such as stream-butlast -- make sense only for lists (which are materialized in their entirety) and not for streams (which may never be materialized). I find it amusing that you consider stream-vector and vector-stream, since the pure FP people have such trouble with mutable arrays. And even the design is poor -- stream-butlast-n should almost certainly be merged into stream-butlast with an optional argument, but stream-reverse shouldn't also optionally append a list (or is it a stream?). You say that it is so obvious that all these functions should be included that you won't waste your time justifying it, but to me it is anything but obvious -- in fact, it is obvious to me that some of the functions you mentioned should never exist in the context of streams implemented for Scheme, much less be included in a standard library. On the other hand, in the context of streams implemented for Haskell, it may make sense to include some of the list-oriented functions, since Haskell has no finite-list type and uses streams in its place. Remember: streams are not lists. You are of course free to use SRFI-41 as the basis for an extended library of stream functions. I ask only that you do not call it streams, or streams-primitive, or streams-derived, so as not to cause confusion with the SRFI. I also recommend that you switch over as soon as possible from the deprecated SRFI-40 to SRFI-41. By the way, you should have mentioned as you critiqued SRFI-41 that you are the author of stream-ext. Phil On Tue, May 5, 2009 at 9:16 PM, Alejandro Forero Cuervo a...@freaks-unidos.net wrote: SRFI-40 is deprecated due to a memory leak. Please port SRFI-41 instead, and adapt any code that uses SRFI-40 to the new interface. Did you, during the design of srfi-41, consider the existance of the stream-ext library, which implements a lot of stream functions on top of srfi-40? http://chicken.wiki.br/eggref/3/stream-ext It's first version was released a long time before srfi-41 and only small changes have been made since then. The naming conventions and the semantics match those of srfi-1 as close as possible, to make things as consistent as possible. I've used the stream-ext library in many applications that represent strings as streams of characters throughout. The largest of these is probably Svnwiki. I'm worried about the incompatibilities I see between stream-ext and srfi-41. My concerns are the following: 1. srfi-41 provides a very small subset of the functionality that I think that any program that uses streams significantly will need. As such, I think it fails significantly at providing syntax derived from those primitives that permits convenient expression of stream operations. Most of the functions I list below can be implemented in a portable manner, as stream-ext does. To be fair, srfi-41 does seem to provide some functions that stream-ext does not. 2. More importantly (the previous concern can be solved with an additional library), a small portion of the interface exported by srfi-41 differs from that in the stream-ext library. I provide some cases below and explain why I believe the semantics from stream-ext are slightly preferable, mostly because of consistency with the srfi-1 list-based counterparts. I quite like the interface of srfi-1 and I find that, by providing inconsistent counterparts, srfi-41 is making it slightly harder to use streams than stream-ext. I may be the person who has written the most Scheme code using srfi-40
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
Hi, Phil Bewig pbe...@gmail.com writes: Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, due to the underlying promises that require numerous type conversions, so streams should be used only when the sequence of elements is truly infinite (such as mathematical series) or when there is some clear advantage of laziness (such as reducing the number of passes through a large data set). I also find that any data structure in general which is built on I/O works well as a stream. For the current NLP app I'm working on, I need to build a parse graph from a port. Slurping up the whole input at once could require too much memory, and also would prevent the parser acting as a proper (buffered) Unix filter. On the other hand, since the algorithm for determining how much text I need to work with is dynamic, I can't just read chunks at a time (the basic unit I want to work on is a sentence, but I don't know what a sentence is until the parse is finished). So I build the graph as a lazy stream of nodes, and the algorithm transparently expands only as much input as needed. From what I've seen Alejandro also uses streams primarily with I/O - it's a very natural combination. Writing a library that duplicates SRFI-1 for streams seems to me to be folly. Well, if you have streams at all, even if they are only suited to a special class of algorithms, it makes sense to provide a complete library of basic operations. Otherwise people will continuously reinvent the same utilities, and sometimes get them wrong. In fact, it is specifically desirable to provide an exact match of the SRFI-1 API for easy conversions and comparisons. In any module system with import prefixing (including Chicken 4), you can write everything with a stream- prefix and swap the backend from streams to lists with: (import srfi-41) (import (prefix stream-) srfi-1) Going the other direction (writing for SRFI-1 but then switching to streams) is only a little more verbose, requiring renaming of the individual identifiers you use. Some certainly don't belong in a general-purpose library -- if you need symbol-stream to convert the name of a symbol into a stream of characters, you can write it as part of your program. Sure: (define (symbol-stream sym) (string-stream (symbol-string sym))) That's just trivial and probably borderline enough that it isn't needed in the library. string-stream or equivalent functionality should be included, though, because the most efficient implementation of this may vary wildly depending on the Scheme implementation. However, the name may be unintuitive if you're not coming from a streams as I/O perspective. It may be both simpler to specify and easier to understand if you replace most of the foo-stream procedures with: (write-to-character-stream object) (display-to-character-stream object) Many -- such as stream-butlast -- make sense only for lists (which are materialized in their entirety) and not for streams (which may never be materialized). I think it's a little unfair to pick on stream-butlast when SRFI-41 includes stream-length, stream-list, stream-reverse, etc. As you yourself say, not all streams are infinite, and for finite streams these can be useful. Otherwise you'll repeatedly find people who when working entirely with streams (for type signature compatibility, and because all of their utilities are designed for streams, not lists), write things like (list-stream (butlast (stream-list stream))) when they really do need all but the last element of a stream they know to be finite. [I would argue the name and API should be changed to stream-drop-right to match SRFI-1, though.] Now, if you want to argue that the SRFI-1 API is too large, that's another story :) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, due to the underlying promises that require numerous type conversions, so streams should be used only when the sequence of elements is truly infinite (such as mathematical series) or when there is some clear advantage of laziness (such as reducing the number of passes through a large data set). I also find that any data structure in general which is built on I/O works well as a stream. For the current NLP app I'm working on, I need to build a parse graph from a port. Slurping up the whole input at once could require too much memory, and also would prevent the parser acting as a proper (buffered) Unix filter. On the other hand, since the algorithm for determining how much text I need to work with is dynamic, I can't just read chunks at a time (the basic unit I want to work on is a sentence, but I don't know what a sentence is until the parse is finished). So I build the graph as a lazy stream of nodes, and the algorithm transparently expands only as much input as needed. From what I've seen Alejandro also uses streams primarily with I/O - it's a very natural combination. Just thought I'd mention another example where I do this, which I feel is relevant to this discussion: http://wiki.freaks-unidos.net/xc, my command-line calculator. The whole lexing/parsing is done using streams: the input is received by the lexer as a stream of characters and turned into a stream of tokens (by procedure 'lexer'); the parser itself receives this stream of tokens and returns a stream with the numbers that should be printed (by procedure 'parse-input'). The whole evaluation of the input is thus simply (and here I'm quoting verbatim): (stream-for-each (lambda (obj) (if (number? obj) (output-num obj) (format #t ~S~% obj))) (parse-input (lexer (port-stream Very clean, isn't it? All is evaluated lazily, allowing things such as output-num to be redefined during the evaluation, to output numbers in a different formats. Given the primitives provided by stream-ext and stream-parser, xc does not have to add complexity of its own to handle streams but can deal exclusively with the problem it attacks, of evaluating arithmetic expressions and such. And, obviously, the sequence of elements in these streams is finite and, even if the tricks such as redefining output-num didn't matter, using streams instead of lists still has the advantage that Alex Shinn mentions of loading elements from the input lazily. Perhaps more importantly, it also produces the output as soon as it is available (so that one can actually use the calculator interactively and see the result of an expression immediately after entering it). Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
On Wed, May 6, 2009 at 4:56 PM, Alex Shinn alexsh...@gmail.com wrote: Hi, Phil Bewig pbe...@gmail.com writes: Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, due to the underlying promises that require numerous type conversions, so streams should be used only when the sequence of elements is truly infinite (such as mathematical series) or when there is some clear advantage of laziness (such as reducing the number of passes through a large data set). I also find that any data structure in general which is built on I/O works well as a stream. For the current NLP app I'm working on, I need to build a parse graph from a port. Slurping up the whole input at once could require too much memory, and also would prevent the parser acting as a proper (buffered) Unix filter. On the other hand, since the algorithm for determining how much text I need to work with is dynamic, I can't just read chunks at a time (the basic unit I want to work on is a sentence, but I don't know what a sentence is until the parse is finished). So I build the graph as a lazy stream of nodes, and the algorithm transparently expands only as much input as needed. From what I've seen Alejandro also uses streams primarily with I/O - it's a very natural combination. You are correct that streams and parsing go well together. One of the examples I wrote for SRFI-41 was a parsing library based on the calculator Wadler wrote for his 'list of successes' paper, but I dropped it because it was too long, and illustrated the list of successes technique with the eight-queens problem. Parsing also works well without streams, as decades of lex/yacc users can attest. Writing a library that duplicates SRFI-1 for streams seems to me to be folly. Well, if you have streams at all, even if they are only suited to a special class of algorithms, it makes sense to provide a complete library of basic operations. Otherwise people will continuously reinvent the same utilities, and sometimes get them wrong. In fact, it is specifically desirable to provide an exact match of the SRFI-1 API for easy conversions and comparisons. In any module system with import prefixing (including Chicken 4), you can write everything with a stream- prefix and swap the backend from streams to lists with: (import srfi-41) (import (prefix stream-) srfi-1) Going the other direction (writing for SRFI-1 but then switching to streams) is only a little more verbose, requiring renaming of the individual identifiers you use. I disagree. Streams and lists are not substitutable. Haskell conflates the two because everything in Haskell is lazy, so there is no difference. But that isn't true in Scheme. Some certainly don't belong in a general-purpose library -- if you need symbol-stream to convert the name of a symbol into a stream of characters, you can write it as part of your program. Sure: (define (symbol-stream sym) (string-stream (symbol-string sym))) That's just trivial and probably borderline enough that it isn't needed in the library. string-stream or equivalent functionality should be included, though, because the most efficient implementation of this may vary wildly depending on the Scheme implementation. However, the name may be unintuitive if you're not coming from a streams as I/O perspective. It may be both simpler to specify and easier to understand if you replace most of the foo-stream procedures with: (write-to-character-stream object) (display-to-character-stream object) When would it make sense to convert the name of a symbol to a stream of characters? Many -- such as stream-butlast -- make sense only for lists (which are materialized in their entirety) and not for streams (which may never be materialized). I think it's a little unfair to pick on stream-butlast when SRFI-41 includes stream-length, stream-list, stream-reverse, etc. As you yourself say, not all streams are infinite, and for finite streams these can be useful. Otherwise you'll repeatedly find people who when working entirely with streams (for type signature compatibility, and because all of their utilities are designed for streams, not lists), write things like (list-stream (butlast (stream-list stream))) when they really do need all but the last element of a stream they know to be finite. [I would argue the name and API should be changed to stream-drop-right to match SRFI-1, though.] Stream-length and stream-reverse are certainly candidates to be dropped from a stream library. I'm not entirely sure how I feel about them. You and Alejandro seem to be suggesting that you would use streams in preference to lists in a variety of programs. Take as given that streams will be much slower than lists, at least in current Scheme implementations. I can't imagine using streams for much more than toy programs or academic
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
On Wed, May 6, 2009 at 10:32 AM, Phil Bewig pbe...@gmail.com wrote: Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, ... To the extent that this is true, it should be fixed, not perpetuated. Indeed, one of Scheme's greatest weaknesses is that the core functions of the language are not generic enough, and different representations of the same things are unduly difficult to intermix. Let us move towards perfection by removing an arbitrary distinction between two sequential data structures whose only real difference is that one is restricted to being finite. ~Alexey Radul P.S. On the technicalities of how to achieve this, I find the design of Clojure inspiring (http://clojure.org). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
SRFI-40 is deprecated due to a memory leak. Please port SRFI-41 instead, and adapt any code that uses SRFI-40 to the new interface. Did you, during the design of srfi-41, consider the existance of the stream-ext library, which implements a lot of stream functions on top of srfi-40? http://chicken.wiki.br/eggref/3/stream-ext It's first version was released a long time before srfi-41 and only small changes have been made since then. The naming conventions and the semantics match those of srfi-1 as close as possible, to make things as consistent as possible. I've used the stream-ext library in many applications that represent strings as streams of characters throughout. The largest of these is probably Svnwiki. I'm worried about the incompatibilities I see between stream-ext and srfi-41. My concerns are the following: 1. srfi-41 provides a very small subset of the functionality that I think that any program that uses streams significantly will need. As such, I think it fails significantly at providing syntax derived from those primitives that permits convenient expression of stream operations. Most of the functions I list below can be implemented in a portable manner, as stream-ext does. To be fair, srfi-41 does seem to provide some functions that stream-ext does not. 2. More importantly (the previous concern can be solved with an additional library), a small portion of the interface exported by srfi-41 differs from that in the stream-ext library. I provide some cases below and explain why I believe the semantics from stream-ext are slightly preferable, mostly because of consistency with the srfi-1 list-based counterparts. I quite like the interface of srfi-1 and I find that, by providing inconsistent counterparts, srfi-41 is making it slightly harder to use streams than stream-ext. I may be the person who has written the most Scheme code using srfi-40 streams. I've put special care into the design of the interface of the stream-ext library. This interest I have in using streams in Scheme makes the fact that srfi-41 offers an inferior interface rather frustrating for me. Now onto the differences and similarities: The following is a list of symbols provided by stream-ext and srfi-41 with apparently the exact same semantics: list-stream stream-ref stream-length stream-append stream-take-while stream-drop-while The following is a list of symbols available in stream-ext but not in srfi-41, which I believe most software using streams would benefit from: stream-xcons stream-cons* stream-tabulate stream-iota make-infinite-stream I think these should be included as counterparts to the srfi-1 versions for lists. The make-infinite-stream should probably be added (see stream-ext's make-stream, discussed bellow). stream-string string-stream stream-downcase, stream-upcase stream-lines stream-unlines I think these should be included: if one does include port-stream, encouraging the use of streams of characters to represent ports/streams, why not go the extra mile of simplifying conversion to and from strings and handling of streams of characters? stream-vector vector-stream number-stream stream-number stream-symbol symbol-stream And if we include the stream-string and string-stream symbols, encouraging the programmer to use streams throughout his program to represent strings, these should probably also be included, specially the vector ones. I don't think we should force all programs that use streams to define this compositions directly. iterator-stream This is a fundamental block for turning iterators into streams. I've found it extremely useful in my programs that use streams. For example, list-stream can be trivially implemented as: (define (list-stream l) (iterator-stream (lambda (return stop) (for-each return l Among *many* other things, this makes it trivial to do things like 'with-output-to-stream', given the right support from the implementation (for creating special ports). Also, iterator-stream does not depend on anything non-portable, simply on call/cc. write-stream The counter-part to port-stream. Most of my programs have a lot of functions that generate streams (see for example my html-stream library). A lot of these will be wrapped in a simple call to write-stream, to output these to the right port. I think it should be included in a general purpose streams library. stream= stream-prefix= stream, stream stream-caar ... stream-cr stream-first ... stream-tenth stream-intersperse stream-split stream-last stream-last-n stream-butlast stream-butlast-n stream-length= stream-count stream-partition stream-remove stream-sort stream-find stream-find-tail stream-any stream-every I'm using all these quite often. I feel all of them deserve
[Chicken-users] Which eggs to migrate from Chicken 3 first?
The following is a list, derived from the dependency graphs, for Chicken 3 eggs on which more than one other Chicken 3 egg depends. Eggs high up on this list should probably be migrated soon. I have excluded all eggs shown in the current Chicken 4 egg list, as well as syntax-case. 312 misc-extn 121 lookup-table 89 srfi-40 77 locale 74 srfi-29 71 format-modular 63 coerce 53 srfi-37 52 eggdoc 42 stream-ext 39 srfi-42 36 uri 24 url 23 args 20 rlimit 19 openssl 17 message-digest 17 http 16 stream-parser 10 tinyclos 7 array-lib 6 sendfile 6 iconv 6 html-stream 5 utf8 5 syntactic-closures 5 srfi-4-comprehensions 5 blas 4 tcp-server 4 stream-sections 4 ssax 4 srfi-95 4 s11n 4 job-worker 3 sxml-tools 3 srfi-66 3 rfc822 3 md5 3 format 3 dyn-vector 3 crc 3 codewalk 3 args-doc 2 z3 2 tool 2 stream-wiki 2 sha1 2 runcmd 2 pipeline 2 mime 2 graph-scc -- John Cowan http://www.ccil.org/~cowanco...@ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
SRFI-40 is deprecated due to a memory leak. Please port SRFI-41 instead, and adapt any code that uses SRFI-40 to the new interface. On Wed, Apr 22, 2009 at 11:11 AM, John Cowan co...@ccil.org wrote: The following is a list, derived from the dependency graphs, for Chicken 3 eggs on which more than one other Chicken 3 egg depends. Eggs high up on this list should probably be migrated soon. I have excluded all eggs shown in the current Chicken 4 egg list, as well as syntax-case. 312 misc-extn 121 lookup-table 89 srfi-40 77 locale 74 srfi-29 71 format-modular 63 coerce 53 srfi-37 52 eggdoc 42 stream-ext 39 srfi-42 36 uri 24 url 23 args 20 rlimit 19 openssl 17 message-digest 17 http 16 stream-parser 10 tinyclos 7 array-lib 6 sendfile 6 iconv 6 html-stream 5 utf8 5 syntactic-closures 5 srfi-4-comprehensions 5 blas 4 tcp-server 4 stream-sections 4 ssax 4 srfi-95 4 s11n 4 job-worker 3 sxml-tools 3 srfi-66 3 rfc822 3 md5 3 format 3 dyn-vector 3 crc 3 codewalk 3 args-doc 2 z3 2 tool 2 stream-wiki 2 sha1 2 runcmd 2 pipeline 2 mime 2 graph-scc -- John Cowan http://www.ccil.org/~cowanhttp://www.ccil.org/%7Ecowan co...@ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
John Cowan co...@ccil.org writes: 52 eggdoc 19 openssl 6 iconv 5 utf8 4 tcp-server 3 format 6 sendfile 2 graph-scc These have already been ported. 17 http Should be deprecated in favor of intarweb? 5 syntactic-closures Deprecated in favor of the new native macro system. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
Alex Shinn scripsit: 52 eggdoc 19 openssl 6 iconv 5 utf8 4 tcp-server 3 format 6 sendfile 2 graph-scc These have already been ported. They aren't in http://chicken.wiki.br/chicken-projects/egg-index-4.html, and don't have html files in the http://chicken.wiki.br/eggref/4/ directory, though, so only insiders know about them. Someone needs to fix that. -- Where the wombat has walked,John Cowan co...@ccil.org it will inevitably walk again. http://www.ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
2009/4/22 John Cowan co...@ccil.org: only insiders know about them. You only get told about these things if you're part of the Dark Cabal©. Now that you've heard about it, I'll have to kill you ... Leo ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
John Cowan scripsit: The following is a list, derived from the dependency graphs, for Chicken 3 eggs on which more than one other Chicken 3 egg depends. Eggs high up on this list should probably be migrated soon. It's wrong, though. It turns out that the .dot files I was using as raw data often mention dependent eggs multiple times. I'm going to add Alex's list of Chicken 4 eggs, modify my analysis code, and re-run it. -- John Cowanco...@ccil.org At times of peril or dubitation, http://www.ccil.org/~cowan Perform swift circular ambulation, With loud and high-pitched ululation. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
Phil Bewig scripsit: SRFI-40 is deprecated due to a memory leak. Please port SRFI-41 instead, and adapt any code that uses SRFI-40 to the new interface. The following eggs depend directly on the srfi-40 egg: egg-post-commit html-plots html-stream irnc-base mat5-lib ode scheme-dissect stream-base64 stream-cgi stream-ext stream-flash stream-htpasswd stream-httplog stream-ldif stream-parser stream-sections stream-wiki -- John Cowanco...@ccil.orghttp://ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
On Wed, Apr 22, 2009 at 12:11:12PM -0400, John Cowan wrote: I have excluded all eggs shown in the current Chicken 4 egg list, as well as syntax-case. [..eggs about which I have absolutely no say omitted..] 52 eggdoc I believe this was ported yesterday. 36 uri This could be deprecated in favor of uri-common/uri-generic. I don't see a big problem with them existing together, but if possible please use these. They have a much bigger testsuite and are probably much more compliant to the RFC. 24 url This egg was already marked 'Unsupported or redundant' in Eggs Unlimited 3. We should take this opportunity to put it down for good. 17 http Should be deprecated in favor of intarweb. 6 sendfile This was already ported... 5 utf8 This was already ported... 4 tcp-server 3 sxml-tools Already ported, as the sxpath egg. Other parts of the sxml-tools that should be made available for Chicken should be put in other eggs, since sxml-tools is many things all rolled into one. It's better to separate the bloat a bit. Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth pgpthvVWNGILm.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
On Wed, Apr 22, 2009 at 11:28 AM, John Cowan co...@ccil.org wrote: Alex Shinn scripsit: 52 eggdoc 19 openssl 6 iconv 5 utf8 4 tcp-server 3 format 6 sendfile 2 graph-scc These have already been ported. They aren't in http://chicken.wiki.br/chicken-projects/egg-index-4.html, Yes, they are. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
Jim Ursetto scripsit: These have already been ported. They aren't in http://chicken.wiki.br/chicken-projects/egg-index-4.html, Yes, they are. Okay. I must have botched the list somehow. -- John Cowanhttp://www.ccil.org/~cowan co...@ccil.org Please leave your valuesCheck your assumptions. In fact, at the front desk. check your assumptions at the door. --sign in Paris hotel --Cordelia Vorkosigan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
I propose that the following eggs be made obsolete: srfi-40 (superseded by srfi-41) uri + url (superseded by uri-generic) syntactic-closures (superseded by Chicken 4 macros) I started porting all graph eggs last night, so dyn-vector, digraph and everything graph-* is ported or in the process of being ported to Chicken 4. Also, since most of those eggs use eggdoc for documentation, I will scavenge some code from egg-post-commit and update the make-egg-index script to account for eggdoc-based documentation, instead of assuming all egg documentation resides in eggref. -Ivan John Cowan co...@ccil.org writes: The following is a list, derived from the dependency graphs, for Chicken 3 eggs on which more than one other Chicken 3 egg depends. Eggs high up on this list should probably be migrated soon. I have excluded all eggs shown in the current Chicken 4 egg list, as well as syntax-case. 312 misc-extn 121 lookup-table 89 srfi-40 77 locale 74 srfi-29 71 format-modular 63 coerce 53 srfi-37 52 eggdoc 42 stream-ext 39 srfi-42 36 uri 24 url 23 args 20 rlimit 19 openssl 17 message-digest 17 http 16 stream-parser 10 tinyclos 7 array-lib 6 sendfile 6 iconv 6 html-stream 5 utf8 5 syntactic-closures 5 srfi-4-comprehensions 5 blas 4 tcp-server 4 stream-sections 4 ssax 4 srfi-95 4 s11n 4 job-worker 3 sxml-tools 3 srfi-66 3 rfc822 3 md5 3 format 3 dyn-vector 3 crc 3 codewalk 3 args-doc 2 z3 2 tool 2 stream-wiki 2 sha1 2 runcmd 2 pipeline 2 mime 2 graph-scc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
On Apr 22, 2009, at 9:16 AM, Phil Bewig wrote: SRFI-40 is deprecated due to a memory leak. Please port SRFI-41 instead, and adapt any code that uses SRFI-40 to the new interface. The srfi-41 extension is available for Chicken 4. ,snip ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
