[Ann] Nile 0.8.0 available
Locked
12
12
 
|
On May 14, 2007, at 12:06 PM, Bert Freudenberg wrote: > > 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 - In Sophie we use the URI package thruout, nothing is a string, all URI objects. Then we just ask the URI object for a UTF8 or binary stream, it looks after the messy details, is that a file, a ftp, or http address, and we've even a URI sophieStream: that lets us denote a memory mapped storage system where we read/write temporary items for specialized cases. -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
|
In reply to this post by K. K. Subramaniam
You don't have to use this method set* mean it's require by the trait
but should not appear for the client. Traits don't have this possibility so we use "set" and "get" for methods that should not be called by the clients only by methods defined in the traits. If you want to open a file you use the same technic as before: NSReadFileTextStream fileNamed: 'woo.txt' cheers Mth On May 14, 2007, at 9:02 PM, subbukk wrote: > 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 : |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by Damien Cassou-3
Damien,
I had to read that a few times, but I think I follow. *If* I do, then the answer is that for your gettable stream, you would not consider hitting the end to be an error. An analog in Dolphin would be 'hello' readStream nextWord which evaluates to 'hello'. The stream is left at its end, and a subsequent #nextWord evauates to nil (which I find questionable). Don't take my word for it. Try asking #next: to read off the end of a stream in Dolphin and VW - you will find the both environments complain about it, and I submit they are correct to do so. #nextAvailable: will silently truncate if it hits the end of a stream, which is sometimes the correct behavior. IMHO, the problem at present is that Squeak assumes all is well in situations that call for an error; the result is that additional error checks are required, and history teaches us that they will not always be included. Bill 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. 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. 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
>
> 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. > Rio supports the idea of stream adaptors, so (when implemented) you would write. This would invoke an adaptor which specializes the stream methods. You could have a far greater range of adaptors with Nile' piping etc. '/home/readme.txt' asRio nile readStream cheers Keith |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by danil osipchuk
Your question is double:
- is it worth to do a big bang swapping now or can we do it slowly - are traits worth To the first one I would say: - let us build on top of nile something really cool - then we can see - the nile library shows that traits are cool (even with not enough tool supports). Stef On 14 mai 07, at 20:24, danil osipchuk wrote: > > 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. > > > |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by Damien Cassou-3
On 14 mai 07, at 21:07, Damien Cassou wrote: > 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. but we do not need it now :) We need a really cool stream library with a cool core and composable abstractions. And Nile is that > If people want to help making Nile better, > feel free to join. Indeed we need more clients of Nile to improve it. > 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. This would be a really experience. because we could get a small core and all kind of possibilities. > > 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 timrowledge
message received.
>> 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. we should look at URI instead of a morbid look at FileStream :) |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by Schwab,Wilhelm K
Bill
I cannot reply exactly but I can tell you that some of the choices of VW to trhow an error when at the end of a stream deep down in the library hurt us (roel and me long time ago and this is really bad). Now I will let damien take into account your feedback Stef On 14 mai 07, at 23:28, Bill Schwab wrote: > Damien, > > I had to read that a few times, but I think I follow. *If* I do, then > the answer is that for your gettable stream, you would not consider > hitting the end to be an error. An analog in Dolphin would be > > 'hello' readStream nextWord > > which evaluates to 'hello'. The stream is left at its end, and a > subsequent #nextWord evauates to nil (which I find questionable). > > Don't take my word for it. Try asking #next: to read off the end of a > stream in Dolphin and VW - you will find the both environments > complain > about it, and I submit they are correct to do so. #nextAvailable: > will > silently truncate if it hits the end of a stream, which is > sometimes the > correct behavior. IMHO, the problem at present is that Squeak assumes > all is well in situations that call for an error; the result is that > additional error checks are required, and history teaches us that they > will not always be included. > > Bill > > > 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. > > 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. > > > > > 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 > > > |
Re: [Ann] Nile 0.8.0 available
|
|
Hi stephane
Then it is once again a discussion about Exception. If exception is implemented and you don't want it, then you catch it and resume with appropriate value. Easy. If exception is not implemented and you want one, then you have to protect each next with either a pre atEnd test, or post ifNil: test. Easy too. (Heavy, too I would say to my personnal taste). Just a question of style... Also think of Damien's argument (Array new: 10) readStream would answer nil to next. Not easy to discriminate atEnd with a single ifNil: test. We should not be hurted by either solution, except when porting an application to a different dialect not implementing same rules. If this is what you mean by hurted, then this is an argument to adopt most common behaviour, that is not the squeak one. Unless I misunderstood something? Nicolas stephane ducasse a écrit : > Bill > > I cannot reply exactly but I can tell you that some of the choices of VW > to trhow an error > when at the end of a stream deep down in the library hurt us (roel and > me long time ago and this is really bad). > > Now I will let damien take into account your feedback > > Stef > On 14 mai 07, at 23:28, Bill Schwab wrote: > >> Damien, >> >> I had to read that a few times, but I think I follow. *If* I do, then >> the answer is that for your gettable stream, you would not consider >> hitting the end to be an error. An analog in Dolphin would be >> >> 'hello' readStream nextWord >> >> which evaluates to 'hello'. The stream is left at its end, and a >> subsequent #nextWord evauates to nil (which I find questionable). >> >> Don't take my word for it. Try asking #next: to read off the end of a >> stream in Dolphin and VW - you will find the both environments complain >> about it, and I submit they are correct to do so. #nextAvailable: will >> silently truncate if it hits the end of a stream, which is sometimes the >> correct behavior. IMHO, the problem at present is that Squeak assumes >> all is well in situations that call for an error; the result is that >> additional error checks are required, and history teaches us that they >> will not always be included. >> >> Bill >> >> >> 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. >> >> 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. >> >> >> >> >> 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 >> >> >> > > > |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by stephane ducasse
Aha, I see.
Thank you both. Do you mean a library with a new api by complete reimplementation of the collection hierarchy? I'm asking because I don't understand a difference between a refactoring (using traits) and a complete rewrite if library protocol and user classes stay the same. Nathanael changed pretty everything exept of public api - no? Regards, Danil
|
Re: [Ann] Nile 0.8.0 available
|
|
The refactoring of Nathanael keeps the implementation of methods.
Methods are just moved from a class to a trait. This brings reusable traits, but the result could have been better. What we are doing with Nile is more like a complete reimplementation trying to keep the same API when it makes sense. Method implementations are completely different. Our traits have been made to be reusable and to have their own meaning. They are not built to factorize existing classes. Is it clearer? 2007/5/16, danil osipchuk <[hidden email]>: > > Aha, I see. > Thank you both. > Do you mean a library with a new api by complete reimplementation of the > collection hierarchy? I'm asking because I don't understand a difference > between a refactoring (using traits) and a complete rewrite if library > protocol and user classes stay the same. Nathanael changed pretty everything > exept of public api - no? > > Regards, > Danil > > stephane ducasse wrote: > > > > > > On 14 mai 07, at 21:07, Damien Cassou wrote: > > > >> 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. > > > > but we do not need it now :) > > We need a really cool stream library with a cool core and composable > > abstractions. > > And Nile is that > >> If people want to help making Nile better, > >> feel free to join. > > > > Indeed we need more clients of Nile to improve it. > > > >> 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. > > > > This would be a really experience. because we could get a small core > > and all kind of possibilities. > >> > >> Does this answer all your questions ? > >> > >> 2007/5/14, danil osipchuk <[hidden email]>: > >>> > > > > > > -- > View this message in context: http://www.nabble.com/-Ann--Nile-0.8.0-available-tf3726678.html#a10637141 > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > > -- Damien Cassou |
Re: [Ann] Nile 0.8.0 available
|
|
Yes, it is clear now, thank you regards, Danil |
Re: [Ann] Nile 0.8.0 available
|
|
In reply to this post by Damien Cassou-3
Stef,
Hurt you in what type of work? I am far more concerned about silent truncation failing to raise an (in-context) alarm than I am about having to test my code to ensure that it works in all relevant cases. In my view, there are ways (#nextOrNil, #nextAvailable:) to allow truncation, it is simply never done w/o consent from the programmer. Would that have worked for you? Regards, Bill ========= stephane ducasse wrote: Bill I cannot reply exactly but I can tell you that some of the choices of VW to trhow an error when at the end of a stream deep down in the library hurt us (roel and me long time ago and this is really bad). Now I will let damien take into account your feedback 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
>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: Wed, 16 May 2007 11:07:45 +0200 > >What we are doing with Nile is more like a complete reimplementation >trying to keep the same API when it makes sense. I hope you are planning to completely implement the ANSI standard, any extra methods that Smalltalkers expect to find with streams. Otherwise it can't ever replace the base implementation, which should be the long term goal imo. _________________________________________________________________ More photos, more messages, more storageget 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
|
|
2007/5/18, J J <[hidden email]>:
> >What we are doing with Nile is more like a complete reimplementation > >trying to keep the same API when it makes sense. > > I hope you are planning to completely implement the ANSI standard, any extra > methods that Smalltalkers expect to find with streams. Otherwise it can't > ever replace the base implementation, which should be the long term goal > imo. ANSI is already implemented. Everything is ready to implement all squeak methods. I've already started. If you want to help, the repository is open, documentation is present, everything is tested. Feel free :-) Bye -- Damien Cassou |
|
|
>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: Fri, 18 May 2007 14:09:49 +0200 > >2007/5/18, J J <[hidden email]>: >> >What we are doing with Nile is more like a complete reimplementation >> >trying to keep the same API when it makes sense. >> >>I hope you are planning to completely implement the ANSI standard, any >>extra >>methods that Smalltalkers expect to find with streams. Otherwise it can't >>ever replace the base implementation, which should be the long term goal >>imo. > >ANSI is already implemented. Everything is ready to implement all >squeak methods. I've already started. If you want to help, the >repository is open, documentation is present, everything is tested. >Feel free :-) > >Bye > >-- >Damien Cassou Ok, if I get a chance I may. :) The "that make sense" made me wonder if that meant a big part of the API wouldn't be included, so I just wanted to make sure. :) I haven't had a chance to check out your work yet, but I think it's great that you're doing it. Type classes in Haskell (the closest thing I have experience with that is like Squeak's traits :) are awesome, and I have hopes that Squeak traits can be shown to be just as useful/powerful at filling a big gap. _________________________________________________________________ Make every IM count. Download Messenger and join the im Initiative now. Its free. http://im.live.com/messenger/im/home/?source=TAGHM_MAY07 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |