[Pharo-project] To try out FileSystem in 2.0 -- which download?
Hello I would like to try out the newly integrated FileSystem The Pharo 2.0 unstable page http://www.pharo-project.org/pharo-download/unstable-2-0 has two options: 1) a link to https://ci.lille.inria.fr/pharo/ (all builds) and 2) a One-click distribution http://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/lastSuccessful... Is the One-click distribution on par with the latest builds or lagging behind? Thank you in advance Hannes
On Oct 3, 2012, at 10:13 AM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello
I would like to try out the newly integrated FileSystem
The Pharo 2.0 unstable page http://www.pharo-project.org/pharo-download/unstable-2-0
has two options:
1) a link to https://ci.lille.inria.fr/pharo/ (all builds)
and
2) a One-click distribution http://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/lastSuccessful...
Is the One-click distribution on par with the latest builds or lagging behind?
It is pointing to the last successfull build. So it is on the same level as the image. It even contains a recent VM, this one from 25th of September: Smalltalk vm version 'CoInterpreter VMMaker-oscog-EstebanLorenzano.164 uuid: d77dee73-00f5-4d00-847b-00646b08329d Sep 25 2012 StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.164 uuid: d77dee73-00f5-4d00-847b-00646b08329d Sep 25 2012 https://git.gitorious.org/cogvm/blessed.git Commit: bfc9fe2c4abcd2972c8bd9eac1c77f9baaf23e8a Date: 2012-09-25 13:34:47 +0200 By: Esteban Lorenzano <estebanlm@gmail.com> ' This is the nice thing about a continous build server... it really changes the game. Marcus -- Marcus Denker -- http://marcusdenker.de
Thank you Marcus, I assume for exploring the code I start with package 'FileSystem-Core-Public' ? --Hannes On 10/3/12, Marcus Denker <marcus.denker@inria.fr> wrote:
On Oct 3, 2012, at 10:13 AM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello
I would like to try out the newly integrated FileSystem
The Pharo 2.0 unstable page http://www.pharo-project.org/pharo-download/unstable-2-0
has two options:
1) a link to https://ci.lille.inria.fr/pharo/ (all builds)
and
2) a One-click distribution
http://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/lastSuccessful...
Is the One-click distribution on par with the latest builds or lagging behind?
It is pointing to the last successfull build. So it is on the same level as the image.
It even contains a recent VM, this one from 25th of September:
Smalltalk vm version
'CoInterpreter VMMaker-oscog-EstebanLorenzano.164 uuid: d77dee73-00f5-4d00-847b-00646b08329d Sep 25 2012 StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.164 uuid: d77dee73-00f5-4d00-847b-00646b08329d Sep 25 2012 https://git.gitorious.org/cogvm/blessed.git Commit: bfc9fe2c4abcd2972c8bd9eac1c77f9baaf23e8a Date: 2012-09-25 13:34:47 +0200 By: Esteban Lorenzano <estebanlm@gmail.com> '
This is the nice thing about a continous build server... it really changes the game.
Marcus
-- Marcus Denker -- http://marcusdenker.de
On Oct 4, 2012, at 4:41 AM, "H. Hirzel" <hannes.hirzel@gmail.com> wrote:
Thank you Marcus,
I assume for exploring the code I start with package 'FileSystem-Core-Public' ?
I would start with the book chapter: http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/FileSystem.pd... Then another nice thing is that the whole image already was refactored to use FileSystem. (the old API is right now even not there, it will come back in form of a compatibility layer, though). The idea here is the following: Libraries are in the end theories. They model something, e.g. Filesystem access. There was an old theory, and it turned out it was not really good. So Colin made a new Theory: FileSystem. Now there are two philosophies 1) we load the new in addition. It even is compatible to many different versions of the System, and everyone uses it in new code. But the sytem can not use it, as the developer of course wants to load the latest version of this independendly develpopped library. Some people requested that for FileSystem, and we renamed all classes so that they can continue to load the code themselves. 2) We replace the old. Why? - to prove the theory. It is amazing, but in all cases, the new needs to be either sligthly adapted / improved or bug fixed when you *really* replace the old. It's the ultimate test. - to only have to maintain one code base. - to have a better used and therefore more bug free code base (see e.g. the FilePlugin fixes that had to be done) and, actually not last but very important: Have examples in the image that show how the library is used. In the end, the system is it's own best documentation. There should only be code in there that shows the beginner how he is suppossed to write new code. So after reading the chapter, you can just browse the users and should get *a lot* of examples. Isn't that amazing? Marcus -- Marcus Denker -- http://marcusdenker.de
On Oct 4, 2012, at 8:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Now there are two philosophies
1) we load the new in addition. It even is compatible to many different versions of the System, and everyone uses it in new code. But the sytem can not use it, as the developer of course wants to load the latest version of this independendly develpopped library. Some people requested that for FileSystem, and we renamed all classes so that they can continue to load the code themselves.
This actually is interesting, these two philosophies... 1) The Addition View Smalltalk is perfect and finished. Everything we do we do "on top". If we implement Morphic, we keep MVC. Things like FileSystem code is there as an additonal library. When doing research, the picture you have is not that of a System that you improve to make a new System that makes the next research easier. No. You do something *on top*, and throw it away after. 2) The System View I think some people's brain kind of got a hickup when they looked at instances of Class and saw that they just use standard libraries. MethodDictionay is a Dictionary... there is no special "I wrote everyhting again because I am clever!" code even deep in the system. That is one of the things that makes Smalltalk powerful! The main reason is that it created a feedback loop: We improve something for an application. But then, instead of throwing it away, we *apply* that improvement to the *whole* system. The system gets better (faster, smaller). And its expressiveness is improved: the next developer can just *use* the improvement and put the time into something else. Especially in Research, this is quite important: You can't publish things that have already been done. Time is limited (just 3-4 years to do a PhD...). So if the guy has to constantly start from scratch, this gets very hard after just some interations. Yet, when the System itself improves... the picture here is that of a mountain: We can always climb up from the valley deep down, or we can build base camps. Who will do better? I think we are starting to (slowly) see this with Pharo. E.g. the on-demand loading of the .sources. It uses Zinc and FileSystem, it's just a couple of lines of code. Yes, you could have done it before. But would anyone do it? Of course not. (just a very trivial example). Marcus -- Marcus Denker -- http://marcusdenker.de
Thanks for the explanation and pointers, Marcus. Well written, well said, as usual ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 04 Oct 2012, at 08:26, Marcus Denker <marcus.denker@inria.fr> wrote:
On Oct 4, 2012, at 8:02 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Now there are two philosophies
1) we load the new in addition. It even is compatible to many different versions of the System, and everyone uses it in new code. But the sytem can not use it, as the developer of course wants to load the latest version of this independendly develpopped library. Some people requested that for FileSystem, and we renamed all classes so that they can continue to load the code themselves.
This actually is interesting, these two philosophies...
1) The Addition View
Smalltalk is perfect and finished. Everything we do we do "on top". If we implement Morphic, we keep MVC. Things like FileSystem code is there as an additonal library. When doing research, the picture you have is not that of a System that you improve to make a new System that makes the next research easier. No. You do something *on top*, and throw it away after.
2) The System View
I think some people's brain kind of got a hickup when they looked at instances of Class and saw that they just use standard libraries. MethodDictionay is a Dictionary... there is no special "I wrote everyhting again because I am clever!" code even deep in the system. That is one of the things that makes Smalltalk powerful!
The main reason is that it created a feedback loop: We improve something for an application. But then, instead of throwing it away, we *apply* that improvement to the *whole* system. The system gets better (faster, smaller). And its expressiveness is improved: the next developer can just *use* the improvement and put the time into something else.
Especially in Research, this is quite important: You can't publish things that have already been done. Time is limited (just 3-4 years to do a PhD...). So if the guy has to constantly start from scratch, this gets very hard after just some interations. Yet, when the System itself improves... the picture here is that of a mountain: We can always climb up from the valley deep down, or we can build base camps. Who will do better?
I think we are starting to (slowly) see this with Pharo. E.g. the on-demand loading of the .sources. It uses Zinc and FileSystem, it's just a couple of lines of code. Yes, you could have done it before. But would anyone do it? Of course not. (just a very trivial example).
Marcus
-- Marcus Denker -- http://marcusdenker.de
On 04 Oct 2012, at 08:02, Marcus Denker <marcus.denker@inria.fr> wrote:
I would start with the book chapter:
http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/FileSystem.pd...
To those who helped writing this chapter and bringing FileSystem to Pharo and writing FileSystem in the first place: thanks ! One thing though: the public API as described in the high-level documentation should be used to write method comments - this is a contribution that anyone can do ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On Oct 5, 2012, at 10:57 AM, Sven Van Caekenberghe wrote:
On 04 Oct 2012, at 08:02, Marcus Denker <marcus.denker@inria.fr> wrote:
I would start with the book chapter:
http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/FileSystem.pd...
To those who helped writing this chapter and bringing FileSystem to Pharo and writing FileSystem in the first place: thanks !
One thing though: the public API as described in the high-level documentation should be used to write method comments - this is a contribution that anyone can do ;-)
yes with camillo we added method comments too :). Stef
participants (4)
-
H. Hirzel -
Marcus Denker -
Stéphane Ducasse -
Sven Van Caekenberghe