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

[Pharo-project] About etoy removal

by StÃ©phane Ducasse

Hi gary do you have some changesets for us :) Stef

July 29, 2008

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

by Michael Rueger

Keith Hodges wrote: > The ultimate aim here, is to be able to hand a rio as a parameter into a > tool, and that tool should be able to read and write to the file > represented by the rio, irrespective of whether that rio represents a > remote file, a gziped file or a file within a zip file. Its basically > polymorphism in action, and I would like to think that that is good design. Unfortunately that is going to come back and bite you big time in an real application as we learned in Sophie. You need to know that you are working with an archive or remote server, as there specific conditions and failures that can't be hidden. For instance you don't want to recompress images etc when storing files in an archive. And working with a remote directory is so frigging complicated in real life that you hardly ever want to do that. Michael

July 29, 2008

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

by David Mitchell

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 >

July 29, 2008

Re: [Pharo-project] Hello all

by Alexandre Bergel

Welcome!!! http://code.google.com/p/pharo/ is probably the best starting block! Alexandre On 29 Jul 2008, at 18:45, Brian Brown 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 29, 2008

[Pharo-project] Hello all

by Brian Brown

I just joined the list and wanted to say hello :) I'm looking forward to what this project promises to create! - Brian

July 29, 2008

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

by StÃ©phane Ducasse

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? 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? 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. ??? 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 === ifAbsent I found strange that ifAbsent ^ self exists not ifTrue: [ self ] ifFalse: [ Null default ] => ifAbsent ^ self exists ifFalse: [ Null default ] ifTrue: [ self ] === I was thinking that it would be nice to have a group of pharoer going over rio and - giving feedback - formatting the code - writing the tests (I could not find them) 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 Stef

July 29, 2008

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

by Keith Hodges

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

July 29, 2008

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

by Keith Hodges

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 The basic way that RioKernel works is layered upon the VM primitives. The guts of the implementation is built upon one method... #select: selectBlock which calls #startAt: rioOrString recursively: beRecursive select: selectBlock into: results I was quite pleased with the way this worked out being quite elegant, and so if you want to add this to URI's it would be better to implement URIs on top of Rio or RioKernel, than FileDirectory. The zip stuff in rio is not "convenience" methods, it aims to transparently implement an alternate file system, a zip file. I havent got around to doing remote ftp file systems, but that should be achievable using the same approach. The gzip mode implements an alternate file type, piping to and from compressed streams, again transparently. The ultimate aim here, is to be able to hand a rio as a parameter into a tool, and that tool should be able to read and write to the file represented by the rio, irrespective of whether that rio represents a remote file, a gziped file or a file within a zip file. Its basically polymorphism in action, and I would like to think that that is good design. Keith

July 29, 2008

Re: [Pharo-project] Last release & ScriptLoader

by Alexandre Bergel

No problem. This was not a big deal anyway. Cheers, Alexandre On 29 Jul 2008, at 13:30, Adrian Lienhard wrote: > > On Jul 29, 2008, at 13:07 , 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. > > ok, I see. The reason is that I did the update a couple of days > earlier and Stef later released the image. Your ScriptLoader > versions must have been committed in the the meantime. > > Cheers, > Adrian > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 29, 2008

Re: [Pharo-project] Last release & ScriptLoader

by Adrian Lienhard

On Jul 29, 2008, at 13:07 , 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. ok, I see. The reason is that I did the update a couple of days earlier and Stef later released the image. Your ScriptLoader versions must have been committed in the the meantime. Cheers, Adrian

July 29, 2008