[Ann] Nile 0.8.0 available
Locked
12
12
 
|
I've just released a new version of Nile, a completely new stream
implementation. It's available on Universe (category 'Model Extension'), SqueakMap and SqueakSouce (loads Nile-All from http://www.squeaksource.com/Nile). Nile already allowed you to stream over readable collections and writeable collections. This part has been enhanced with more tests and more functionalities. A diagram can be seen at: http://damien.cassou.free.fr/documents/internship_2007/nile/complete_hierarchy.pdf. But now, Nile is able to read from and write to files too (thanks to Mathieu Suen for the implementation). A diagram is available at: http://damien.cassou.free.fr/documents/internship_2007/nile/fileStreams.pdf. You can also use Nile in a pipe-like way: you can chain different streams to obtain a bigger, more interesting stream. For example: | stream | stream := ReadableCollectionStream on: '123 12 142 25'. stream := NumberReader inputStream: stream. stream := SelectStream selectBlock: [:each | each even] inputStream: stream. stream peek. ==> 12 stream next. ==> 12 stream atEnd. ==> false stream next. ==> 142 stream atEnd. ==> true This code uses three stream: - NSReadableCollectionStream is equivalent to ReadStream. - NSNumberReader is waiting for characters on its input and converts them to numbers. Spaces separate numbers. - NSSelectStream reads its input and only returns elements matching the selectBlock (http://wiki.cs.uiuc.edu/PatternStories/SelectStream) Each pipe is really easy to implement: subclass a particular class and implement a method and a constructor. What is your opinion about this work? -- Damien Cassou |
Re: [Ann] Nile 0.8.0 available
|
|
Damien,
The pipe/composition features are interesting. I would strongly urge you to have something like | in | in := NSReadableCollectionStream on:'hello'. in next:20. signal an error. #nextAvailable:20 would answer a truncated string w/o error. Since you are creating new stream classes, IMHO, it makes sense to match their behavior to the other major dialects. 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 |
|
|
In reply to this post by Damien Cassou-3
oops the link seem to be broken
Mth On May 11, 2007, at 12:35 PM, Damien Cassou wrote: > - NSSelectStream reads its input and only returns elements matching > the selectBlock (http://wiki.cs.uiuc.edu/PatternStories/SelectStream) |
Re: [Ann] Nile 0.8.0 available
|
|
2007/5/12, Mathieu Suen <[hidden email]>:
> oops the link seem to be broken > Mth I hope this is only a temporary failure. > On May 11, 2007, at 12:35 PM, Damien Cassou wrote: > > - NSSelectStream reads its input and only returns elements matching > > the selectBlock (http://wiki.cs.uiuc.edu/PatternStories/SelectStream) -- Damien Cassou |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by Schwab,Wilhelm K
Hi Bill,
2007/5/12, Bill Schwab <[hidden email]>: > The pipe/composition features are interesting. I would strongly urge > you to have something like > > | in | > in := NSReadableCollectionStream on:'hello'. > in next:20. > > signal an error. #nextAvailable:20 would answer a truncated string w/o > error. Since you are creating new stream classes, IMHO, it makes sense > to match their behavior to the other major dialects. I already asked a few month ago what would be the best solution to handle errors. Nobody agreed. So I decided to follow the ANSI standard: problems like this are unspecified. Even the standard guys were unable to make any decision :-( Now, if people start to agree on a specific behavior, I would really like that. What do other people think? -- Damien Cassou |
|
|
If the standard doesn't agree then I would go with what everyone else does
so at least we are compatible. >From: "Damien Cassou" <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: "The general-purpose Squeak developers >list"<[hidden email]> >Subject: Re: [Ann] Nile 0.8.0 available >Date: Sat, 12 May 2007 09:06:37 +0200 > >Hi Bill, > >2007/5/12, Bill Schwab <[hidden email]>: >>The pipe/composition features are interesting. I would strongly urge >>you to have something like >> >> | in | >> in := NSReadableCollectionStream on:'hello'. >> in next:20. >> >>signal an error. #nextAvailable:20 would answer a truncated string w/o >>error. Since you are creating new stream classes, IMHO, it makes sense >>to match their behavior to the other major dialects. > >I already asked a few month ago what would be the best solution to >handle errors. Nobody agreed. So I decided to follow the ANSI >standard: problems like this are unspecified. Even the standard guys >were unable to make any decision :-( > >Now, if people start to agree on a specific behavior, I would really like >that. > >What do other people think? > >-- >Damien Cassou > _________________________________________________________________ Make every IM count. Download Messenger and join the iÂ’m Initiative now. ItÂ’s free. http://im.live.com/messenger/im/home/?source=TAGHM_MAY07 |
Re: [Ann] Nile 0.8.0 available
|
|
But is there a common behavior which is found in many other Smalltalk dialect?
2007/5/12, J J <[hidden email]>: > If the standard doesn't agree then I would go with what everyone else does > so at least we are compatible. > > > >From: "Damien Cassou" <[hidden email]> > >Reply-To: The general-purpose Squeak developers > >list<[hidden email]> > >To: "The general-purpose Squeak developers > >list"<[hidden email]> > >Subject: Re: [Ann] Nile 0.8.0 available > >Date: Sat, 12 May 2007 09:06:37 +0200 > > > >Hi Bill, > > > >2007/5/12, Bill Schwab <[hidden email]>: > >>The pipe/composition features are interesting. I would strongly urge > >>you to have something like > >> > >> | in | > >> in := NSReadableCollectionStream on:'hello'. > >> in next:20. > >> > >>signal an error. #nextAvailable:20 would answer a truncated string w/o > >>error. Since you are creating new stream classes, IMHO, it makes sense > >>to match their behavior to the other major dialects. > > > >I already asked a few month ago what would be the best solution to > >handle errors. Nobody agreed. So I decided to follow the ANSI > >standard: problems like this are unspecified. Even the standard guys > >were unable to make any decision :-( > > > >Now, if people start to agree on a specific behavior, I would really like > >that. > > > >What do other people think? > > > >-- > >Damien Cassou > > > > _________________________________________________________________ > Make every IM count. Download Messenger and join the i'm Initiative now. > It's free. http://im.live.com/messenger/im/home/?source=TAGHM_MAY07 > > > -- Damien Cassou |
|
|
Bill Schwab seemed to indicate, below, that their was.
>From: "Damien Cassou" <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: "The general-purpose Squeak developers >list"<[hidden email]> >Subject: Re: [Ann] Nile 0.8.0 available >Date: Sat, 12 May 2007 09:56:48 +0200 > >But is there a common behavior which is found in many other Smalltalk >dialect? > >2007/5/12, J J <[hidden email]>: >>If the standard doesn't agree then I would go with what everyone else does >>so at least we are compatible. >> >> >> >From: "Damien Cassou" <[hidden email]> >> >Reply-To: The general-purpose Squeak developers >> >list<[hidden email]> >> >To: "The general-purpose Squeak developers >> >list"<[hidden email]> >> >Subject: Re: [Ann] Nile 0.8.0 available >> >Date: Sat, 12 May 2007 09:06:37 +0200 >> > >> >Hi Bill, >> > >> >2007/5/12, Bill Schwab <[hidden email]>: >> >>The pipe/composition features are interesting. I would strongly urge >> >>you to have something like >> >> >> >> | in | >> >> in := NSReadableCollectionStream on:'hello'. >> >> in next:20. >> >> >> >>signal an error. #nextAvailable:20 would answer a truncated string w/o >> >>error. Since you are creating new stream classes, IMHO, it makes sense >> >>to match their behavior to the other major dialects. >> > >> >I already asked a few month ago what would be the best solution to >> >handle errors. Nobody agreed. So I decided to follow the ANSI >> >standard: problems like this are unspecified. Even the standard guys >> >were unable to make any decision :-( >> > >> >Now, if people start to agree on a specific behavior, I would really >>like >> >that. >> > >> >What do other people think? >> > >> >-- >> >Damien Cassou >> > >> >>_________________________________________________________________ >>Make every IM count. Download Messenger and join the i'm Initiative now. >>It's free. http://im.live.com/messenger/im/home/?source=TAGHM_MAY07 >> >> >> > > >-- >Damien Cassou > _________________________________________________________________ More photos, more messages, more storage—get 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by Damien Cassou-3
Hi Damien!
Good work! Although I am not expert in this, a good way to assess the quality of your code is to incrementally replace some streams by yours. The class TextStream has some test (i.e., TextAndTextStreamTest). Since streams are vital, this will not be an easy task. By the way, did you point out some anomalies in the implementation (or design) of the Stream hierarchy ? Just a question... Alexandre On 11 May 2007, at 12:35, Damien Cassou wrote: > I've just released a new version of Nile, a completely new stream > implementation. > > It's available on Universe (category 'Model Extension'), SqueakMap and > SqueakSouce (loads Nile-All from http://www.squeaksource.com/Nile). > > Nile already allowed you to stream over readable collections and > writeable collections. This part has been enhanced with more tests and > more functionalities. A diagram can be seen at: > http://damien.cassou.free.fr/documents/internship_2007/nile/ > complete_hierarchy.pdf. > > But now, Nile is able to read from and write to files too (thanks to > Mathieu Suen for the implementation). A diagram is available at: > http://damien.cassou.free.fr/documents/internship_2007/nile/ > fileStreams.pdf. > > You can also use Nile in a pipe-like way: you can chain different > streams to obtain a bigger, more interesting stream. For example: > > | stream | > stream := ReadableCollectionStream on: '123 12 142 25'. > stream := NumberReader inputStream: stream. > stream := SelectStream selectBlock: [:each | each even] > inputStream: stream. > > stream peek. ==> 12 > stream next. ==> 12 > stream atEnd. ==> false > stream next. ==> 142 > stream atEnd. ==> true > > This code uses three stream: > - NSReadableCollectionStream is equivalent to ReadStream. > - NSNumberReader is waiting for characters on its input and converts > them to numbers. Spaces separate numbers. > - NSSelectStream reads its input and only returns elements matching > the selectBlock (http://wiki.cs.uiuc.edu/PatternStories/SelectStream) > > > Each pipe is really easy to implement: subclass a particular class and > implement a method and a constructor. > > What is your opinion about this work? > > -- > Damien Cassou > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.software-artist.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: [Ann] Nile 0.8.0 available
|
|
Hi Alexandre,
2007/5/12, Bergel, Alexandre <[hidden email]>: > Good work! Although I am not expert in this, a good way to assess the > quality of your code is to incrementally replace some streams by > yours. The class TextStream has some test (i.e., TextAndTextStreamTest). > Since streams are vital, this will not be an easy task. In fact, I've written a lot of tests which run for both hierarchies (traits are cool to do that too :-)). > By the way, did you point out some anomalies in the implementation > (or design) of the Stream hierarchy ? Just a question... Too much to discuss here. -- Damien Cassou |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by Damien Cassou-3
>From what I have seen in Squeak:
- return nil - return false - return -1 - return self - #become: some other kind of Stream - silently ignore in some other way - throw an Error (not some subclass that you can meaningfully handle) Personally I would like a specific exception with a helpful message to be thrown. This way you'd know that there was a problem and you can fix it. You could even handle it if you wanted. But that's what Java does so it must be wrong. Cheers Philippe 2007/5/12, Damien Cassou <[hidden email]>: > But is there a common behavior which is found in many other Smalltalk dialect? > > 2007/5/12, J J <[hidden email]>: > > If the standard doesn't agree then I would go with what everyone else does > > so at least we are compatible. > > > > > > >From: "Damien Cassou" <[hidden email]> > > >Reply-To: The general-purpose Squeak developers > > >list<[hidden email]> > > >To: "The general-purpose Squeak developers > > >list"<[hidden email]> > > >Subject: Re: [Ann] Nile 0.8.0 available > > >Date: Sat, 12 May 2007 09:06:37 +0200 > > > > > >Hi Bill, > > > > > >2007/5/12, Bill Schwab <[hidden email]>: > > >>The pipe/composition features are interesting. I would strongly urge > > >>you to have something like > > >> > > >> | in | > > >> in := NSReadableCollectionStream on:'hello'. > > >> in next:20. > > >> > > >>signal an error. #nextAvailable:20 would answer a truncated string w/o > > >>error. Since you are creating new stream classes, IMHO, it makes sense > > >>to match their behavior to the other major dialects. > > > > > >I already asked a few month ago what would be the best solution to > > >handle errors. Nobody agreed. So I decided to follow the ANSI > > >standard: problems like this are unspecified. Even the standard guys > > >were unable to make any decision :-( > > > > > >Now, if people start to agree on a specific behavior, I would really like > > >that. > > > > > >What do other people think? > > > > > >-- > > >Damien Cassou > > > > > > > _________________________________________________________________ > > Make every IM count. Download Messenger and join the i'm Initiative now. > > It's free. http://im.live.com/messenger/im/home/?source=TAGHM_MAY07 > > > > > > > > > -- > Damien Cassou > > |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by Schwab,Wilhelm K
2007/5/12, Bill Schwab <[hidden email]>:
> Damien, > > The pipe/composition features are interesting. I would strongly urge > you to have something like > > | in | > in := NSReadableCollectionStream on:'hello'. > in next:20. > > signal an error. #nextAvailable:20 would answer a truncated string w/o > error. Since you are creating new stream classes, IMHO, it makes sense > to match their behavior to the other major dialects. I thought about it however there is a problem. When you have a gettable stream, you don't always know how much elements remain in the stream. You are then obliged to read all elements before you know if there was enough or not. This is a problem because once read, the elements may not be available anymore. So, if the method signal an error, all elements that have been read are lost. -- Damien Cassou |
Re: [Ann] Nile 0.8.0 available
|
|
On Monday 14 May 2007 6:38 pm, Damien Cassou wrote:
> I thought about it however there is a problem. When you have a > gettable stream, you don't always know how much elements remain in the > stream. You are then obliged to read all elements before you know if > there was enough or not. The string example is not a good illustration for a Stream since its length is already known. A Stream represents a open-ended sequence. When there are no more elements to be read, we cannot be sure that the stream has ended. Perhaps, more elements may come in at a later time (e.g. reading from stdin on Unix). The atEnd test is required to distinguish between the two cases. For closed sequences, a separate class, Buffer, could be introduced. It would be like an Array except that it would have a cursor and would be accessed sequentially. Since the sequence is closed, its size is known. Remaining elements would be (size - position). Nile is very nicely done. I hope it replaces the current File/Directory classes which are too closely tied to the underlying platform. One area where it could improve is in handling pathnames. Pathnames should be distinct class instead of aString. We could represent Path by a sequence of aString, then we could abstract out pathname separator characters. This deserves a separate discussion thread. Regards .. Subbu |
Re: [Ann] Nile 0.8.0 available
|
|
2007/5/14, subbukk <[hidden email]>:
> On Monday 14 May 2007 6:38 pm, Damien Cassou wrote: > Nile is very nicely done. I hope it replaces the current File/Directory > classes which are too closely tied to the underlying platform. > One area where it could improve is in handling pathnames. Pathnames should be > distinct class instead of aString. We could represent Path by a sequence of > aString, then we could abstract out pathname separator characters. This > deserves a separate discussion thread. Nile has nothing to do with File/Directory classes. It's only for streaming. Yes, you can stream over a file, but our implementation relies on FileDirectory. What Nile aims to replace is ReadStream, WriteStream, StandardFileStream, SocketStream, ZipReadStream... -- Damien Cassou |
Re: [Ann] Nile 0.8.0 available
|
|
Damien,
this is probably a naive question, but anyway: what do you think - is it possible to replace both collection and stream hierarchies with their traitified counterparts and to get a still working image? How much effort will it cost (not as a proposal for mainline but as an experiment) Danil
|
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by Damien Cassou-3
On Monday 14 May 2007 10:44 pm, Damien Cassou wrote:
> Nile has nothing to do with File/Directory classes. It's only for > streaming. Yes, you can stream over a file, but our implementation > relies on FileDirectory. What Nile aims to replace is ReadStream, > WriteStream, StandardFileStream, SocketStream, ZipReadStream... Nile passes the argument it receives via its NSAbstractFileStream>>setFileName: method to file primitives for opening a file, thereby assuming it is a string. This would force callers (see TTFFontDescription>>setDefault) to use paths like : setFileName: "C:\WINDOWS\Fonts\msgothic.ttf" to open a stream on a file. This would affect portability. I believe the issue is traceable to FileDirectory failing to hide platform-specific aspects in pathnames. I could be wrong, though. Subbu |
Re: [Ann] Nile 0.8.0 available
|
|
On May 14, 2007, at 21:02 , subbukk wrote: > On Monday 14 May 2007 10:44 pm, Damien Cassou wrote: >> Nile has nothing to do with File/Directory classes. It's only for >> streaming. Yes, you can stream over a file, but our implementation >> relies on FileDirectory. What Nile aims to replace is ReadStream, >> WriteStream, StandardFileStream, SocketStream, ZipReadStream... > Nile passes the argument it receives via its > NSAbstractFileStream>>setFileName: method to file primitives for > opening a > file, thereby assuming it is a string. This would force callers (see > TTFFontDescription>>setDefault) to use paths like : > > setFileName: "C:\WINDOWS\Fonts\msgothic.ttf" > > to open a stream on a file. This would affect portability. I > believe the > issue is traceable to FileDirectory failing to hide platform- > specific aspects > in pathnames. I could be wrong, though. If you are concerned with portability - we have had good experience with Michael's URI package. This lets you use URIs throughout and not worry about platform paths. - Bert - |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by danil osipchuk
Hi Daniel,
I secretly dream of replacing the Stream hierarchy by Nile. But Nile is far away from a possible replacement. This is because Nile does not implement most of the methods that can be found in the Stream hierarchy. Moreover, replacing the current hierarchy requires a reimplementation of all subclasses of the class Stream. However, I think the task is doable. If people want to help making Nile better, feel free to join. About the collection hierarchy, I think the replacement is not worth it. This is because Nathanael refactored the hierarchy using traits instead of completely reimplementing it. This was the right thing to do at this time but I would prefer a completely new version, rewritten from scratch as I did with Nile. Does this answer all your questions ? 2007/5/14, danil osipchuk <[hidden email]>: > > Damien, > this is probably a naive question, but anyway: what do you think - is it > possible to replace both collection and stream hierarchies with their > traitified counterparts and to get a still working image? How much effort > will it cost (not as a proposal for mainline but as an experiment) > > Danil > > > Damien Cassou-3 wrote: > > > > > > > > Nile has nothing to do with File/Directory classes. It's only for > > streaming. Yes, you can stream over a file, but our implementation > > relies on FileDirectory. What Nile aims to replace is ReadStream, > > WriteStream, StandardFileStream, SocketStream, ZipReadStream... > > > > > > > > -- > View this message in context: http://www.nabble.com/-Ann--Nile-0.8.0-available-tf3726678.html#a10609518 > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > > -- Damien Cassou |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by K. K. Subramaniam
2007/5/14, subbukk <[hidden email]>:
> On Monday 14 May 2007 10:44 pm, Damien Cassou wrote: > > Nile has nothing to do with File/Directory classes. It's only for > > streaming. Yes, you can stream over a file, but our implementation > > relies on FileDirectory. What Nile aims to replace is ReadStream, > > WriteStream, StandardFileStream, SocketStream, ZipReadStream... > Nile passes the argument it receives via its > NSAbstractFileStream>>setFileName: method to file primitives for opening a > file, thereby assuming it is a string. This would force callers (see > TTFFontDescription>>setDefault) to use paths like : > > setFileName: "C:\WINDOWS\Fonts\msgothic.ttf" > > to open a stream on a file. This would affect portability. I believe the > issue is traceable to FileDirectory failing to hide platform-specific aspects > in pathnames. I could be wrong, though. You are right :-) Having a path instead of a string would be better. Rio or URI might be of help here. If you want to experiment, feel free to do so. The repository is open. Thank you for your interest in Nile. -- Damien Cassou |
|
|
In reply to this post by K. K. Subramaniam
On 14-May-07, at 12:02 PM, subbukk wrote: > > setFileName: "C:\WINDOWS\Fonts\msgothic.ttf" Unless you are using something like a URI filenaming system you should never, ever, ever, ever. Ever,ever. Evereverever. *Ever* use strings like that to make filenames/paths. Build paths a step at a time with #directoryNamed: and fileNamed:. Allowing #fileNamed: to attempt to parse mangled platform related strings was a serious error. Platform fiddle-faddle for filenames is just horrific. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Don't sweat petty things....or pet sweaty things. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |