Hello all,
I am open to suggestions, but I do not see a non-breaking way to get stream behavior that is consistent with other dialects. In particular, to get #next to signal an error on exhaustion. Squeak's #next: acts like what others call #nextAvailable:. IM(NS)HO, the others have it right. If a protocol calls for 41 characters to remain in a stream, I want to be able to read 41, and would like to be warned if there are fewer remaining. If I do not care, #nextAvailable: allows me to "authorize truncation." Truncating silently can lead to the same kinds of problems that (rightly) doomed "defensive programming." Exceptions offer the solution. Attached is a beginning of an alternate stream heirarchy; it adds classes vs. replacing them. There are no file streams as yet. One of my design goals will be to get the user interaction out of the latter. My recommendation for working out of #next's Squeaky behavior is to add #nextIfNone: that takes a block, and #nextOrNil. It would then be a relatively simple task to clean up many of the nil-checking sends of #next. Please take a look and let me know what you think. Suggestions for tests would be greatly appreciated. If you can see a way to integrate something like this into Squeak w/o pain, please let me know. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui EndOfStreamTests.1.cs (17K) Download Attachment |
On Nov 26, 2007, at 18:42 , Bill Schwab wrote:
> Please take a look and let me know what you think. I did not take a look, but I am positive the UI list is the wrong place to discuss this. - Bert - _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
In reply to this post by Schwab,Wilhelm K
I respectfully disagree. AFAICT, the I/O group is dormant, and the main
list has made its feelings clear. However, there might be an argument for those interested to take this to the I/O list. Any takers? Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 >>> [hidden email] 11/26/07 12:47 PM >>> On Nov 26, 2007, at 18:42 , Bill Schwab wrote: > Please take a look and let me know what you think. I did not take a look, but I am positive the UI list is the wrong place to discuss this. - Bert - _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
On Mon, Nov 26, 2007 at 01:00:31PM -0500, Bill Schwab wrote:
> I respectfully disagree. AFAICT, the I/O group is dormant, and the main > list has made its feelings clear. > > However, there might be an argument for those interested to take this to > the I/O list. Any takers? I subscribed to the io list the IO list may be appropriate, but the Flow list is probably better. Note that there are currently two alternative stream libraries in squeak (alternative meaning not in squeak.org) 1. Flow, which requires a plugin and supports many kinds of external streams, like USB streams and MIDI streams, in addition to collection streams and file streams. It is a major component of Spoon, and is not compatable with squeak's default stream library. See http://netjam.org/flow and http://netjam.org/spoon 2. Nile is a refactoring of the squeak stream library. It provides It does collection streams and file streams in two API's. The new API is much simpler than the squeak library, and is incompatable with it. The old API is compatable with squeak stream library. Nile uses traits to share code between the two API's. It does not provide any capabilities beyond the squeak libraries, as far as I can tell. See http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-November/122481.html -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
2007/11/27, Matthew Fulmer <[hidden email]>:
> On Mon, Nov 26, 2007 at 01:00:31PM -0500, Bill Schwab wrote: > > I respectfully disagree. AFAICT, the I/O group is dormant, and the main > > list has made its feelings clear. > > > > However, there might be an argument for those interested to take this to > > the I/O list. Any takers? > > I subscribed to the io list > > the IO list may be appropriate, but the Flow list is probably > better. Note that there are currently two alternative stream > libraries in squeak (alternative meaning not in squeak.org) > > 1. Flow, which requires a plugin and supports many kinds of > external streams, like USB streams and MIDI streams, in > addition to collection streams and file streams. It is a > major component of Spoon, and is not compatable with squeak's > default stream library. See http://netjam.org/flow and > http://netjam.org/spoon > 2. Nile is a refactoring of the squeak stream library. It > provides It does collection streams and file streams in two > API's. The new API is much simpler than the squeak library, > and is incompatable with it. The old API is compatable with > squeak stream library. Nile uses traits to share code between > the two API's. It does not provide any capabilities beyond > the squeak libraries, as far as I can tell. See > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-November/122481.html Moreover, Nile is maintained by someone who gives the code to the community and let it play with it and commit directly to the main repository. Nile has a lot of unit tests too. If you want to play with it, feel free. You can ask me any question. Bye -- Damien Cassou _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
In reply to this post by Schwab,Wilhelm K
Damien,
I have been aware of Flow for some time, but have reasons to avoid it, at least for now. When I tried it some time ago, Nile did not raise any type of exception on reading off the end of a stream (and AFAIK, I was using its streams vs. Squeak's). I have since seen that is supposed to work, so I will take another look. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 >>> [hidden email] 11/27/2007 2:04 AM >>> 2007/11/27, Matthew Fulmer <[hidden email]>: > On Mon, Nov 26, 2007 at 01:00:31PM -0500, Bill Schwab wrote: > > I respectfully disagree. AFAICT, the I/O group is dormant, and the main > > list has made its feelings clear. > > > > However, there might be an argument for those interested to take this to > > the I/O list. Any takers? > > I subscribed to the io list > > the IO list may be appropriate, but the Flow list is probably > better. Note that there are currently two alternative stream > libraries in squeak (alternative meaning not in squeak.org) > > 1. Flow, which requires a plugin and supports many kinds of > external streams, like USB streams and MIDI streams, in > addition to collection streams and file streams. It is a > major component of Spoon, and is not compatable with squeak's > default stream library. See http://netjam.org/flow and > http://netjam.org/spoon > 2. Nile is a refactoring of the squeak stream library. It > provides It does collection streams and file streams in two > API's. The new API is much simpler than the squeak library, > and is incompatable with it. The old API is compatable with > squeak stream library. Nile uses traits to share code between > the two API's. It does not provide any capabilities beyond > the squeak libraries, as far as I can tell. See > Moreover, Nile is maintained by someone who gives the code to the community and let it play with it and commit directly to the main repository. Nile has a lot of unit tests too. If you want to play with it, feel free. You can ask me any question. Bye -- Damien Cassou _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
2007/11/27, Bill Schwab <[hidden email]>:
> I have been aware of Flow for some time, but have reasons to avoid it, > at least for now. When I tried it some time ago, Nile did not raise any > type of exception on reading off the end of a stream (and AFAIK, I was > using its streams vs. Squeak's). I have since seen that is supposed to > work, so I will take another look. It still does not raise any exception because this is what ANSI says IIRC. But I don't really care about ANSI anymore so if you want to change the behavior of Nile please do and commit to the main repository. Nile is designed to be easily changeable and extendable. -- Damien Cassou _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
In reply to this post by Schwab,Wilhelm K
Damien,
I am far more interested in compatibility with VW and Dolphin (which tends to follow VW in such areas) than with strict ANSI compatibility. In the case of exhaustion, it sure seemed to me that ANSI did not specify an error - I am convinced that Dolphin and VW have it right. I will take a long look at Nile. Thanks! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 >>> [hidden email] 11/27/2007 9:38 AM >>> 2007/11/27, Bill Schwab <[hidden email]>: > I have been aware of Flow for some time, but have reasons to avoid it, > at least for now. When I tried it some time ago, Nile did not raise any > type of exception on reading off the end of a stream (and AFAIK, I was > using its streams vs. Squeak's). I have since seen that is supposed to > work, so I will take another look. It still does not raise any exception because this is what ANSI says IIRC. But I don't really care about ANSI anymore so if you want to change the behavior of Nile please do and commit to the main repository. Nile is designed to be easily changeable and extendable. -- Damien Cassou _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
2007/11/27, Bill Schwab <[hidden email]>:
> Damien, > > I am far more interested in compatibility with VW and Dolphin (which > tends to follow VW in such areas) than with strict ANSI compatibility. > In the case of exhaustion, it sure seemed to me that ANSI did not > specify an error - I am convinced that Dolphin and VW have it right. > > I will take a long look at Nile. Thanks! Nile uses Traits and Traits are not available under other Smalltalk dialects. -- Damien Cassou _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
In reply to this post by Schwab,Wilhelm K
Damien,
Understood, but the API can always be reproduced in terms of their existing classes. Is there a preferred forum for discussing Nile? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 >>> [hidden email] 11/28/07 6:25 AM >>> 2007/11/27, Bill Schwab <[hidden email]>: > Damien, > > I am far more interested in compatibility with VW and Dolphin (which > tends to follow VW in such areas) than with strict ANSI compatibility. > In the case of exhaustion, it sure seemed to me that ANSI did not > specify an error - I am convinced that Dolphin and VW have it right. > > I will take a long look at Nile. Thanks! Nile uses Traits and Traits are not available under other Smalltalk dialects. -- Damien Cassou _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
2007/11/28, Bill Schwab <[hidden email]>:
> Damien, > > Understood, but the API can always be reproduced in terms of their > existing classes. Yes, and you can flatten the traits inside the classes. > Is there a preferred forum for discussing Nile? squeak-dev is ok I think. Since, I'm the only developper and there is no user at all, we can also talk by mail :-). -- Damien Cassou _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
In reply to this post by Schwab,Wilhelm K
Damien,
Fair enough. Email will probably be easiest; Squeak-dev is busy enough to swamp us. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 >>> [hidden email] 11/28/07 9:49 AM >>> 2007/11/28, Bill Schwab <[hidden email]>: > Damien, > > Understood, but the API can always be reproduced in terms of their > existing classes. Yes, and you can flatten the traits inside the classes. > Is there a preferred forum for discussing Nile? squeak-dev is ok I think. Since, I'm the only developper and there is no user at all, we can also talk by mail :-). -- Damien Cassou _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
On Wed, Nov 28, 2007 at 10:17:03AM -0500, Bill Schwab wrote:
> Damien, > > Fair enough. Email will probably be easiest; Squeak-dev is busy enough > to swamp us. I kindly request that you discuss this in public on squeak-dev. It is pretty easy to just read mails on some threads and not others, if you don't want to keep up with all squeak-dev traffic. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
Hi,
MF> On Wed, Nov 28, 2007 at 10:17:03AM -0500, Bill Schwab wrote: >> >> Fair enough. Email will probably be easiest; Squeak-dev is busy enough >> to swamp us. MF> I kindly request that you discuss this in public on squeak-dev. MF> It is pretty easy to just read mails on some threads and not MF> others, if you don't want to keep up with all squeak-dev MF> traffic. same with me and to Damien: publich discussion might even create users :-)) Herbert mailto:[hidden email] _______________________________________________ UI mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/ui |
Free forum by Nabble | Edit this page |