July 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Hello all

by Damien Cassou

Welcome ! Do not hesitate to write emails on this mailing list. On Tue, Jul 29, 2008 at 6:45 PM, Brian Brown <brian(a)ablelinktech.com> wrote: > I just joined the list and wanted to say hello :) > > I'm looking forward to what this project promises to create! > > - Brian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

July 30, 2008

Re: [Pharo-project] About file.... (argh)

by Keith Hodges

Brian Brown wrote: > URI is uniform resource identifier - http://, file://, etc... > > > so using those are platform independent from a filename perspective: > > file:///C/temp/foo.bar (window: C:\temp\foo.bar) > > file:///Users/brian/foo.bar (unix: /Users/brian/foo.bar) > > > - Brian Rio does that too in theory... just hasn't been implemented yet... The class Rio handles the Path element, I was considering renaming it to Path but Path is taken in Graphics. Each rio has an executor which on windows represents the volume. The plan is to have executors for other protocols, parsing from a URI string should be part of standard parsing, a "full" absolute path may print as a URI. Keith time is extremely short for me at the moment

July 30, 2008

Re: [Pharo-project] About file.... (argh)

by Brian Brown

URI is uniform resource identifier - http://, file://, etc... so using those are platform independent from a filename perspective: file:///C/temp/foo.bar (window: C:\temp\foo.bar) file:///Users/brian/foo.bar (unix: /Users/brian/foo.bar) - Brian On Jul 29, 2008, at 2:58 PM, Keith Hodges wrote: >> === Do you think that URI could be introduced in Rio? > I have no idea what URI is. >> And I have some questions >

July 29, 2008

Re: [Pharo-project] About file.... (argh)

by Keith Hodges

StÃ©phane Ducasse wrote: > Hello keith > > I read the NullPattern and I read the code of Rio. I saw that you use > NullPattern and not nil eating > I agree with you that killing FileDirectory is a goal in itself. :) > > I read the wiki page on rio, browse the code and read the fileman/rio > comparison. > I like rio (I was already convinced). I like the select: > > === > I like the idea that we could have an internal representation for the > file and platform > related code would map that to the given OS. > While I was discussing with mike, he told me that in Sophie they used > consistently URI > and got really platform independent code. > > === Do you think that URI could be introduced in Rio? I have no idea what URI is. > And I have some questions > > === I like that we can have a sequential or cascading mode > now I do not really see the point of this setModeToRenaming... > is it in the Rio version? Yes. > Then I do not understand why setModeToRenaming: true > leads to changing file to disc: this seems to me obscure. > " > Introducing Modes - 'Renaming' Mode > When a Rio is #setModeToRenaming, all of the above fileName and path > manipulations are simultaneously actualized on disk. > > ??? It was a feature of the ruby version of rio, that renaming a rio renamed the file on disk. Once in renaming mode the filename can be changed using any of the specialist accessors, e.g #ext: #version: > When a mode is set using 'cascading' style, (e.g. #setModeToRenaming) > the mode flag is set on the given instance as you would expect. In > contrast, when a mode is set in sequential style, a new instance is > created, making the mode setting temporary for the remainer of that > 'sequential sentence'. This convention applies to all modes. e.g. > > * cascading: (myFile setModeToRenaming; yourself) base:'temp'. â > the renamng mode flag of myFile is set. > * sequential: myFile rename base: 'temp'. â myFile itself is > untouched, the renaming mode flag is set in the myFile copy that > performs #base: > " > === > + do you think that , would not be better than + for path > concatenation? > It would fit better the concatenation in Smalltalk Rio currently uses #/ and #+ for path concatenation. #+ is specifically intended for adding a suffix/extension to a pathname. We have already got #, defined as "string concatenation", this is one of the methods which allows Rios to be used in the same place as a string would be used. > === > ifAbsent > I found strange that > > ifAbsent > ^ self exists not ifTrue: [ self ] ifFalse: [ Null default ] > => > ifAbsent > ^ self exists ifFalse: [ Null default ] ifTrue: [ self ] So did I! Fixed in latest. > === > I was thinking that it would be nice to have a group of pharoer > going over rio and > - giving feedback sure > - formatting the code If you have time write a decent code formatter, ST/X has two, unfortunately this is why I am lazy. > - writing the tests (I could not find them) Tests are in squeaksource/Rio The more the merrier. > Then in a second iteration integrating rio in the system and > deprecating FileDirectory and others. > > > > === > I was wondering > why we could not have > 'myFile.dat' asRio gzip compress > => > 'myFile.dat' asGzipCompress > I saw that you have adaptor now with class extensions we could > have new methods > added for new adaptors. Especially since you have toyr > setModeToXXX methods > I think that's the plan. > > Stef > _______________ Keith

July 29, 2008

Re: [Pharo-project] About file.... (argh)

by StÃ©phane Ducasse

Lukas do you have some example of GNU because the interface of rio is looking good. After we can discuss implementation points. Stef On Jul 29, 2008, at 11:49 AM, Lukas Renggli wrote: > I like the file-library of GST very much. It is a really cool and > extensible library. Also the one of Ambrai is (or was) quite nice. > > Cheers, > Lukas > > On 7/29/08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Jul 29, 2008, at 10:10 AM, Damien Cassou wrote: >> >>> On Mon, Jul 28, 2008 at 9:26 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk >>>> wrote: >>>>> I was thinking that we could check a bit rio interface to see if >>>>> we could >>>>> use it as a scaffold >>>>> and slowly rewrite it so that at the end it is a not a wrapper >>>>> anymore on >>>>> that shit. >>>> >>>> Rio is not a wrapper and never has been, it is independant of >>>> FileDirectory >>>> always was and always will be >>> >>> Rio is a *must* have for Pharo. >> >> Ok can you check the NullPattern. >> Because I have a voice iside that tells me that I do not want it to >> creep in the image. >> So we could fork rio and provide an implementation that is not based >> on the null pattern >> >> Stef >> >>> >>> >>> >>> -- >>> Damien Cassou >>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2008

Re: [Pharo-project] About file.... (argh)

by StÃ©phane Ducasse

Yes I have the impression. Stef On Jul 29, 2008, at 7:44 PM, David Mitchell wrote: > I like message eating nulls in some situations. It would be nice if > each framework didn't have to provide their own. > > I wouldn't go so far as to switch nil to act like null, but making > null available as a design choice as part of the base system is a good > idea. > > On Tue, Jul 29, 2008 at 8:32 AM, Keith Hodges <keith_hodges(a)yahoo.co.uk > > wrote: >> StÃ©phane Ducasse wrote: >>> >>> On Jul 29, 2008, at 10:10 AM, Damien Cassou wrote: >>> >>>> On Mon, Jul 28, 2008 at 9:26 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk >>>> > >>>> wrote: >>>>>> >>>>>> I was thinking that we could check a bit rio interface to see >>>>>> if we >>>>>> could >>>>>> use it as a scaffold >>>>>> and slowly rewrite it so that at the end it is a not a wrapper >>>>>> anymore >>>>>> on >>>>>> that shit. >>>>> >>>>> Rio is not a wrapper and never has been, it is independant of >>>>> FileDirectory >>>>> always was and always will be >>>> >>>> Rio is a *must* have for Pharo. >>> >>> Ok can you check the NullPattern. >>> Because I have a voice iside that tells me that I do not want it >>> to creep >>> in the image. >> >> I think you are just being chicken. ;-) >> >> The Null pattern is very useful in certain situations, particularly >> as a >> null Logger in the Logging framework, and in higher level domain >> modelling. >> >> Now that we are entering an era in which we are attempting to >> remove chunks >> of the base image, null comes into its own. As mentioned above it >> makes a >> great Null logger for a minimal image when even the Logging >> interface itself >> has been removed. >> >> It should be part of the base image because it needs to be >> supported well >> within a particular Smalltalk implementation because it has the >> potential to >> make the image unstable if implemented badly. Every Smalltalk I >> have used it >> in so far has needed me to stoop to the lower level coding to write >> and >> rewrite Null extensively so that it works properly. This should not >> be >> necessary for higher level domain modelling work. I think that it >> should be >> supported well out of the box. >> >> There is nothing wrong with null, it is a legitimate part of the >> tool bag we >> have as smalltalk developers. Not putting it in the base image >> serves to >> provide a psychological block to using it in situations where it >> would be >> appropriate, and as I have pointed out there are some. >> >> For example in Rio it performs a very small role, but this makes >> code much >> more readable, and handles errors gracefully. The power to weight >> ratio of >> null is high, another reason it should be available as a resource for >> tidying up the kernel. >> >> Another item that is needed for domain modelling and I think should >> be in >> the base image is a dependency mechanism, SmalltalkAgents had a >> fairly good >> one. Announcements has some good ideas but is fundamentally flawed... >>> >>> So we could fork rio and provide an implementation that is not >>> based on >>> the null pattern >>> >> Its not based upon the null pattern, the null provides one idiom. >> That of >> returning "null" if it fails to obtain a valid read or writeStream. >> This >> enables readable code for writing to files without having to error >> check all >> over the place. It can tidy up a fair bit of code. >> >> As an alternative you could return nil, and implement >> UndefinedObject>>#use: >> aBlock ^self >> This should catch most of the places where null's behaviour is >> used, i.e. >> #writer: #reader: and #<< >> >> best regards >> >> Keith >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2008

Re: [Pharo-project] About file.... (argh)

by StÃ©phane Ducasse

> > > The Null pattern is very useful in certain situations, particularly > as a null Logger in the Logging framework, and in higher level > domain modelling. > > Now that we are entering an era in which we are attempting to remove > chunks of the base image, null comes into its own. As mentioned > above it makes a great Null logger for a minimal image when even the > Logging interface itself has been removed. > > It should be part of the base image because it needs to be supported > well within a particular Smalltalk implementation because it has the > potential to make the image unstable if implemented badly. Every > Smalltalk I have used it in so far has needed me to stoop to the > lower level coding to write and rewrite Null extensively so that it > works properly. This should not be necessary for higher level domain > modelling work. I think that it should be supported well out of the > box. > > There is nothing wrong with null, it is a legitimate part of the > tool bag we have as smalltalk developers. Not putting it in the base > image serves to provide a psychological block to using it in > situations where it would be appropriate, and as I have pointed out > there are some. > > For example in Rio it performs a very small role, but this makes > code much more readable, and handles errors gracefully. The power to > weight ratio of null is high, another reason it should be available > as a resource for tidying up the kernel. I understand > Another item that is needed for domain modelling and I think should > be in the base image is a dependency mechanism, SmalltalkAgents had > a fairly good one. Announcements has some good ideas but is > fundamentally flawed... Can you elaborate on that one? Because indeed having a good dependency mechanism is really important. >> So we could fork rio and provide an implementation that is not >> based on the null pattern >> > Its not based upon the null pattern, the null provides one idiom. > That of returning "null" if it fails to obtain a valid read or > writeStream. This enables readable code for writing to files without > having to error check all over the place. It can tidy up a fair bit > of code. > > As an alternative you could return nil, and implement > UndefinedObject>>#use: aBlock ^self > This should catch most of the places where null's behaviour is used, > i.e. #writer: #reader: and #<< > > best regards > > Keith > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2008

Re: [Pharo-project] About file.... (argh)

by StÃ©phane Ducasse

Mike do you refer to setModeToGzip? and others? Stef On Jul 29, 2008, at 10:50 AM, Michael Rueger wrote: > Damien Cassou wrote: > >> Rio is a *must* have for Pharo. > > I politely disagree. > > There isn't anything in Rio that isn't already or could easily be > added to URIs. > I'm also not a big fan (to say the least) of adding "convenience" > methods (like the zip stuff in Rio). > IMHO convenience is the death of good design. > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2008

Re: [Pharo-project] Hello all

by StÃ©phane Ducasse

Welcome Brian This project will deliver what we will do :) There are plenty of space if you want to help at any level: - test writing - fixing - writing new code.... - just using it and reporting problem. Stef > I just joined the list and wanted to say hello :) > > I'm looking forward to what this project promises to create! > > - Brian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2008

Re: [Pharo-project] Last release & ScriptLoader

by StÃ©phane Ducasse

The point is that the person doing the update should always check in the repository to see if there is not a more recent version of the scriptloader because we may work on it to improve it also. Then you can have a more recent version in the repository because we can be working on the class while an update is pending. So alex this is normal that the 10050 does not get the latest version of scriptloader. We will not do update of scriptloader just for little enh. We just wait to make an update. It would be also nice that from time to time we recreate the image from the beginning just as a sanity check. Stef On Jul 29, 2008, at 1:07 PM, Alexandre Bergel wrote: >> Yes you are right, each update should come with the latest version >> of ScriptLoader. Usually this is how we do it. In update 10050 the >> version loaded is ScriptLoader-al.468. The newer versions that are >> in the Pharo repository were probably committed after we did the >> update (?) > > The last version of ScriptLoader is ScriptLoader-AlexandreBergel. > 471.mcz, and the last Pharo image is Pharo0.1-10050-2008-07-19. > But at the time the image was released, the version ScriptLoader- > AlexandreBergel.470 was available. > >> Talking about the *released image* that we provide for download, I >> think this one should be identical to the one that you can produce >> from going through all updates of the stream. So, I would not >> manually load newer versions of ScriptLoader afterwards. This is to >> make sure that everybody has the exact same code. > > Exact, > Alexandre > >> >> >> On Jul 29, 2008, at 11:12 , Alexandre Bergel wrote: >> >>> The last release does not have the last version of ScriptLoader >>> loaded. >>> I think it is good to have always the last version of >>> "infrastructural" packages in the image, like ScriptLoader. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 29, 2008