October 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] To try out FileSystem in 2.0 -- which download?

by Sven Van Caekenberghe

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(a)inria.fr> wrote: > > On Oct 4, 2012, at 8:02 AM, Marcus Denker <marcus.denker(a)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 > >

Oct. 4, 2012

Re: [Pharo-project] To try out FileSystem in 2.0 -- which download?

by Marcus Denker

On Oct 4, 2012, at 8:02 AM, Marcus Denker <marcus.denker(a)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

Oct. 4, 2012

Re: [Pharo-project] To try out FileSystem in 2.0 -- which download?

by Marcus Denker

On Oct 4, 2012, at 4:41 AM, "H. Hirzel" <hannes.hirzel(a)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.p… 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

Oct. 4, 2012

Re: [Pharo-project] presenting is storytelling at esug 2008

by Geert Claes

For great presentations make sure you check out the likes of Garr Reynolds, Nancy Duarte andÂ Guy Kawasaki! -- View this message in context: http://forum.world.st/presenting-is-storytelling-at-esug-2008-tp4649977p465… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 4, 2012

Re: [Pharo-project] To try out FileSystem in 2.0 -- which download?

by H. Hirzel

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(a)inria.fr> wrote: > > On Oct 3, 2012, at 10:13 AM, H. Hirzel <hannes.hirzel(a)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/lastSuccessfu… >> >> 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(a)gmail.com> > ' > > This is the nice thing about a continous build server... it really changes > the game. > > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > >

Oct. 4, 2012

Re: [Pharo-project] NB cant locate a module

by Igor Stasenko

On 3 October 2012 16:49, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Ok, so the plot thickens! thanks for the info Igor > > I will follow your guideliness, and try to make Pango work > as you did with Cairo. > good luck with that, right now i working making it work on Windows . > Fernando > pd: I also HATE all this non-smalltalk crap! So thanks for the blog and effort. > > On Wed, Oct 3, 2012 at 2:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 3 October 2012 13:54, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>> Hi Igor, >>> >>> following your example on using CairoLibraryLoader, i did the same for >>> the PangoCairo library part of Athens. >>> >>> But there's something i don't understand, why [1] works and [2] >>> doesn't (it returns 0), if both are in the plugins folder of the vm. >>> >>> 1.NativeBoost forCurrentPlatform loadModule: 'libcairo.2.dylib' >>> 2.NativeBoost forCurrentPlatform loadModule: 'libpango-1.0.0.dylib' >>> >>> Does it depend on something else besides being in that path? >>> #loadModule: by default looks >>> at the Plugins folder? >>> >>> I've also tried passing as an argument the full path. >>> >>> I've attached the dylib, compiled with Macports universal binaries option. >>> >>> I'm using MacOS. >> >> you want to put it into bundle, isnt? >> >> now, run >> otool -l libpango-1.0.0.dylib >> >> and you will see that this library has a lot of dependencies coming >> from /out/local/lib... >> and that's why i won't load on any other mac, than yours, because of >> missing dependencies. >> >> Don't expect these libs to be installed on other Mac machine. >> So, to bundle things properly you need to also copy these libraries >> into bundle (and also fix the references).. >> >> I mention about it here: >> https://computeradventures.wordpress.com/2012/06/10/bundling-vm-with-thirdp… >> >> "The last thing about bundling (and it is Mac-specific) is to change >> the references in produced .dylib files to correct ones. I tried to >> use BundleUtils provided by cmake.. but it is prone to be buggy, so i >> had to write own. All it does is replacing an absolute paths in all >> .dylib-s (including external plugin libs) to path relative to .app >> bundle." >> >> without this, you won't be able to make a proper bundle. >> >> See, how i doing it in: >> >> MacOSConfig >> postBuildActions: >> >>> >>> Thanks, >>> Fernando >> >> >> >> -- >> Best regards, >> Igor Stasenko. -- Best regards, Igor Stasenko.

Oct. 3, 2012

Re: [Pharo-project] NB cant locate a module

by Fernando Olivero

Ok, so the plot thickens! thanks for the info Igor I will follow your guideliness, and try to make Pango work as you did with Cairo. Fernando pd: I also HATE all this non-smalltalk crap! So thanks for the blog and effort. On Wed, Oct 3, 2012 at 2:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 3 October 2012 13:54, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Hi Igor, >> >> following your example on using CairoLibraryLoader, i did the same for >> the PangoCairo library part of Athens. >> >> But there's something i don't understand, why [1] works and [2] >> doesn't (it returns 0), if both are in the plugins folder of the vm. >> >> 1.NativeBoost forCurrentPlatform loadModule: 'libcairo.2.dylib' >> 2.NativeBoost forCurrentPlatform loadModule: 'libpango-1.0.0.dylib' >> >> Does it depend on something else besides being in that path? >> #loadModule: by default looks >> at the Plugins folder? >> >> I've also tried passing as an argument the full path. >> >> I've attached the dylib, compiled with Macports universal binaries option. >> >> I'm using MacOS. > > you want to put it into bundle, isnt? > > now, run > otool -l libpango-1.0.0.dylib > > and you will see that this library has a lot of dependencies coming > from /out/local/lib... > and that's why i won't load on any other mac, than yours, because of > missing dependencies. > > Don't expect these libs to be installed on other Mac machine. > So, to bundle things properly you need to also copy these libraries > into bundle (and also fix the references).. > > I mention about it here: > https://computeradventures.wordpress.com/2012/06/10/bundling-vm-with-thirdp… > > "The last thing about bundling (and it is Mac-specific) is to change > the references in produced .dylib files to correct ones. I tried to > use BundleUtils provided by cmake.. but it is prone to be buggy, so i > had to write own. All it does is replacing an absolute paths in all > .dylib-s (including external plugin libs) to path relative to .app > bundle." > > without this, you won't be able to make a proper bundle. > > See, how i doing it in: > > MacOSConfig >> postBuildActions: > >> >> Thanks, >> Fernando > > > > -- > Best regards, > Igor Stasenko.

Oct. 3, 2012

[Pharo-project] presenting is storytelling at esug 2008

by Alexandre Bergel

Today I was working with a student in my office, guess on what, code profiling, you're right :-). A professor entered my room and asked me about the name of the presenter who gave a wonderful talk about how to give talks. I immediately though about Doru's esug presentation, but I said nothing since I cannot make a connection between this professor and Doru. I started to think about some previous professors we invited at the department or something. The student immediately said "Tudor Girba!". The professor replied with "yes!!! He is the guy!" before saying "Muy buena la presentaciÃ³n!" and immediately leaving my office. I am still stunned. For whom who did not see the presentation, have a look at: http://www.tudorgirba.com/presentations/presenting-is-storytelling It is short and goes to the point. Good job Doru! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 3, 2012

Re: [Pharo-project] Pharo Sprint Nov 2

by Marcus Denker

On Oct 3, 2012, at 2:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 03 Oct 2012, at 13:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> RMoD is organizing a Pharo Sprint >> >> - When? Fr, Nov 2nd. Starting at 9am >> - Where? INRIA Lille: http://www.inria.fr/centre/lille > > And do we get to visit your shiny new building/offices ? Yes, I think we will do it here in the meeting room / open space. Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 3, 2012

Re: [Pharo-project] NB cant locate a module

by Igor Stasenko

On 3 October 2012 13:54, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Hi Igor, > > following your example on using CairoLibraryLoader, i did the same for > the PangoCairo library part of Athens. > > But there's something i don't understand, why [1] works and [2] > doesn't (it returns 0), if both are in the plugins folder of the vm. > > 1.NativeBoost forCurrentPlatform loadModule: 'libcairo.2.dylib' > 2.NativeBoost forCurrentPlatform loadModule: 'libpango-1.0.0.dylib' > > Does it depend on something else besides being in that path? > #loadModule: by default looks > at the Plugins folder? > > I've also tried passing as an argument the full path. > > I've attached the dylib, compiled with Macports universal binaries option. > > I'm using MacOS. you want to put it into bundle, isnt? now, run otool -l libpango-1.0.0.dylib and you will see that this library has a lot of dependencies coming from /out/local/lib... and that's why i won't load on any other mac, than yours, because of missing dependencies. Don't expect these libs to be installed on other Mac machine. So, to bundle things properly you need to also copy these libraries into bundle (and also fix the references).. I mention about it here: https://computeradventures.wordpress.com/2012/06/10/bundling-vm-with-thirdp… "The last thing about bundling (and it is Mac-specific) is to change the references in produced .dylib files to correct ones. I tried to use BundleUtils provided by cmake.. but it is prone to be buggy, so i had to write own. All it does is replacing an absolute paths in all .dylib-s (including external plugin libs) to path relative to .app bundle." without this, you won't be able to make a proper bundle. See, how i doing it in: MacOSConfig >> postBuildActions: > > Thanks, > Fernando -- Best regards, Igor Stasenko.

Oct. 3, 2012