[Pharo-project] About file.... (argh)
Hi all Is it a well-known bug that the creation time is incorrectly reported on Mac? Time dateAndTimeFromSeconds: (FileDirectory default directoryEntryFor: 'ESUG2008.txt') creationTime It seems to be confused and return the last opened or last modified date. I was browsing again the code of file support and nearly fainted. I still could not do a simple rename xxx into creationdatexxx simply Then is there a way to modify the creationTime and other characteristic of a file? So this is really something that we should do in pharo fixing that terrible part of squeak. Mike do you think that we can "harvest" sophie solution? Does sophie fix the file library or just use URI as file location description? 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. Stef
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.
Stef
Rio is not a wrapper and never has been, it is independant of FileDirectory always was and always will be Keith
On Mon, Jul 28, 2008 at 9:26 PM, Keith Hodges <keith_hodges@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. -- 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)
Thanks for the correction! Ok even better. I added that to my todo list. Now I want to investigate the dependency to the NullPattern because - I want to discuss it inside the pharo community I think that this is not a good idea to have different idiom inside the system - I would like to see if we can get a "rio" solution or other but not based on the NullPattern I will reread the wiki page first http://wiki.squeak.org/squeak/5962 Stef
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.
Stef
Rio is not a wrapper and never has been, it is independant of FileDirectory always was and always will be
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On Jul 29, 2008, at 10:10 AM, Damien Cassou wrote:
On Mon, Jul 28, 2008 at 9:26 PM, Keith Hodges <keith_hodges@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
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
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@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
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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
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
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
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
do you have some example of GNU because the interface of rio is looking good. After we can discuss implementation points.
Paolos implementation is one of the best file-directory libraries I've ever seen. It is fully extensible, and for example zip files can be transparently navigated and edited like directories. As far as I know this is similar to Rio. Unfortunately I didn't find any documentation. Have a look at the implementation (File.st, FilePath.st, VFS.st, VFSZip.st) at <http://tinyurl.com/6sb6fo>. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
because the interface of rio is looking good.
I agree, and I think it Rio goes in the right direction. I have some things to consider before including RIo in Pharo though: - I read everything mentioned about the Null pattern and checked its use in Rio. This looks nice and probably makes sense in the context. I don't believe however that something like that should be part of a standard image. People won't understand it, beginners will be confused and it is highly incompatible with any other Smalltalk dialect. - Rio prominently uses #doesNotUnderstand: for delegation (not only for the Null implementation). In my opinion this is a big no-go for any core-library. This looks like a design smell. It makes debugging and code understanding unnecessarily hard. - Internally Rio uses string concatenation everywhere. For example to get the parent directory the path is split into two parts and a new object is created. What about paths that contain $/ as part of a file-name? - Rio mixes meta-levels. For example the inst-vars 'recursive', 'rename' and 'binary' (temporary navigation settings) are on a completely different level than 'value' and 'stat' (the actual model object). - Rio uses a string as the internal representation of the path (Why not a chain of parent directories?). When opening a Smalltalk image on a different platform a conversion is supposed to happen, however this is not implemented as far as I can see. I think a correct implementation will be complicated because for n platforms n^2 conversion methods have to be provided. - Rio does not support relative paths. If you get the directory relative to the default path it simply stores the full absolute path. If I move the Smalltalk image around, Rio points to the wrong location. - Rio uses several non-standard extensions that I don't know where they are coming from. I run across: Stream>>#<< and Stream>>#, - Why copy the name of a Ruby framework? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
- Rio does not support relative paths. If you get the directory relative to the default path it simply stores the full absolute path. If I move the Smalltalk image around, Rio points to the wrong location.
It should do... 'test/myFile' asRio should be a relative directory. 'test/myFile' asRio full should be an absolute directory. Keith
On Wed, Jul 30, 2008 at 8:29 PM, Lukas Renggli <renggli@gmail.com> wrote:
- Internally Rio uses string concatenation everywhere. For example to get the parent directory the path is split into two parts and a new object is created. What about paths that contain $/ as part of a file-name?
In Unix systems, $/ is the only character which can't be part of a file name. -- 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)
Thanks. this is why I propose a group to work on a new file library may be starting from GNU + rio interface + URI. This can be a good item for pharo milestone 2. I will start to collect information (such as this email, GNU library, ....) Stef On Jul 30, 2008, at 8:29 PM, Lukas Renggli wrote:
because the interface of rio is looking good.
I agree, and I think it Rio goes in the right direction. I have some things to consider before including RIo in Pharo though:
- I read everything mentioned about the Null pattern and checked its use in Rio. This looks nice and probably makes sense in the context. I don't believe however that something like that should be part of a standard image. People won't understand it, beginners will be confused and it is highly incompatible with any other Smalltalk dialect.
- Rio prominently uses #doesNotUnderstand: for delegation (not only for the Null implementation). In my opinion this is a big no-go for any core-library. This looks like a design smell. It makes debugging and code understanding unnecessarily hard.
- Internally Rio uses string concatenation everywhere. For example to get the parent directory the path is split into two parts and a new object is created. What about paths that contain $/ as part of a file-name?
- Rio mixes meta-levels. For example the inst-vars 'recursive', 'rename' and 'binary' (temporary navigation settings) are on a completely different level than 'value' and 'stat' (the actual model object).
- Rio uses a string as the internal representation of the path (Why not a chain of parent directories?). When opening a Smalltalk image on a different platform a conversion is supposed to happen, however this is not implemented as far as I can see. I think a correct implementation will be complicated because for n platforms n^2 conversion methods have to be provided.
- Rio does not support relative paths. If you get the directory relative to the default path it simply stores the full absolute path. If I move the Smalltalk image around, Rio points to the wrong location.
- Rio uses several non-standard extensions that I don't know where they are coming from. I run across: Stream>>#<< and Stream>>#,
- Why copy the name of a Ruby framework?
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok I will. Stef On Jul 30, 2008, at 7:28 PM, Lukas Renggli wrote:
do you have some example of GNU because the interface of rio is looking good. After we can discuss implementation points.
Paolos implementation is one of the best file-directory libraries I've ever seen. It is fully extensible, and for example zip files can be transparently navigated and edited like directories. As far as I know this is similar to Rio.
Unfortunately I didn't find any documentation. Have a look at the implementation (File.st, FilePath.st, VFS.st, VFSZip.st) at <http://tinyurl.com/6sb6fo>.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
this is why I propose a group to work on a new file library may be starting from GNU + rio interface + URI.
Well, looking at GST is probably not a good idea when working on such a project, because it is LGPL licensed. I am just saying that I like the design and implementation of this particular library (which could already mean derivate work). Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Hi Lukas,
Well, looking at GST is probably not a good idea when working on such a project, because it is LGPL licensed. I am just saying that I like the design and implementation of this particular library (which could already mean derivate work).
Why being LGPL licensed may be an issue? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Well, looking at GST is probably not a good idea when working on such a project, because it is LGPL licensed. I am just saying that I like the design and implementation of this particular library (which could already mean derivate work).
Why being LGPL licensed may be an issue?
Taking an idea from (L)GPL code forces you to use (L)GPL for your code as well. See the recent discussions (mess) in the Squeak and Swazoo mailing-lists. The exact meaning of "taking an idea" depends on the interpretation. Some people argue that only reading (L)GPL code makes your code (L)GPL. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli wrote:
Taking an idea from (L)GPL code forces you to use (L)GPL for your code as well. See the recent discussions (mess) in the Squeak and Swazoo mailing-lists. The exact meaning of "taking an idea" depends on the interpretation. Some people argue that only reading (L)GPL code makes your code (L)GPL.
Which just demonstrates the whole mindset behind (L)GPL licenses. They actually take away freedom... (Almost) worse than the patent craziness... Michael
On Fri, Aug 1, 2008 at 9:40 AM, Lukas Renggli <renggli@gmail.com> wrote:
Well, looking at GST is probably not a good idea when working on such a project, because it is LGPL licensed. I am just saying that I like the design and implementation of this particular library (which could already mean derivate work).
Why being LGPL licensed may be an issue?
Taking an idea from (L)GPL code forces you to use (L)GPL for your code as well. See the recent discussions (mess) in the Squeak and Swazoo mailing-lists. The exact meaning of "taking an idea" depends on the interpretation. Some people argue that only reading (L)GPL code makes your code (L)GPL.
A library under LGPL can be used in any kind of software open-source or not. This is the difference between LGPL and GPL. The problem here, is that we don't just want to use the library but make a derivative work (I guess). http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License Would it be possible for Gnu Smalltalk to release this library under LGPL and MIT? -- 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)
Really I am not sure at all LGPL go to this level to force you to reuse the same LGPL license if you only took idea but no code. This is meanly trap from the microsoft world with their open code stuff. At the very last the only reference to look at is the LGPL text itself http://www.fsf.org/licensing/licenses/lgpl.html I have not time now to check it... Hilaire 2008/8/1 Lukas Renggli <renggli@gmail.com>:
Well, looking at GST is probably not a good idea when working on such a project, because it is LGPL licensed. I am just saying that I like the design and implementation of this particular library (which could already mean derivate work).
Why being LGPL licensed may be an issue?
Taking an idea from (L)GPL code forces you to use (L)GPL for your code as well. See the recent discussions (mess) in the Squeak and Swazoo mailing-lists. The exact meaning of "taking an idea" depends on the interpretation. Some people argue that only reading (L)GPL code makes your code (L)GPL.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (9)
-
Alexandre Bergel -
Brian Brown -
Damien Cassou -
David Mitchell -
Hilaire Fernandes -
Keith Hodges -
Lukas Renggli -
Michael Rueger -
Stéphane Ducasse