February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why a package management system

by StÃ©phane Ducasse

On Feb 23, 2010, at 12:49 PM, GÃ¶ran Krampe wrote: > Hi! > > StÃ©phane Ducasse wrote: >> You are probably right. I should not read squeak-dev anymore I spent my time trying to show >> that there is NO contradiction between innovation/fun and good and clean system. >> But I'm not fun enough or smart enough. >> >> Stef (a etoy haters that was so stupid that he translated the book of etoy in french, >> an idiot that wrote most of the squeak books available right now, one of the four amigos that created the squeak foundation, >> a guy that did this stupid squeak 3.9 - you know stef this guy without any vision that just wants a >> "commercial smalltalk" puck! No innovation just plain engineering ....) > > First you write "You are probably right" and then you write the above, > you just can't stop can you? :) Is it insulting for you when I say that I felt insulted and immensely sad? Stef

Feb. 23, 2010

Re: [Pharo-project] Why a package management system

by StÃ©phane Ducasse

> > When I read the first article about Metacello don't figured out is power until I invested some > time to learn it and developed some "ConfigurationOf..." and currently I think is an > invaluable tool that help to put Pharo/Squeak at the "next level" :) Thanks. I'm really happy that dale started to push that (even if keith was doing the same with Sake) because since the first day we worked with MC and used MC to manage 3.9 we were aware that we need such mechanism. Expressing package dependency is key to system deployment scale.

Feb. 23, 2010

Re: [Pharo-project] Why a package management system

by StÃ©phane Ducasse

> > > "I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." Exactly this is exactly my experience. :)

Feb. 23, 2010

Re: [Pharo-project] Diff tools

by StÃ©phane Ducasse

Gary sometimes I know (since for example I already checked all the conflicts but the system crashes for another reason) that I want to take all the incoming versions or the working copy ones. Right now I have to go over the list each time (even if I know what I'm doing). in the old merge there was such buttons. Stef On Feb 23, 2010, at 4:40 PM, Gary Chambers wrote: > If you can describe exactly what you wish I'm sure it can be done ;-) ... > Remember, conflicts are conflicts and *should* be checked on a one-by-one > basis when merging. > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, February 11, 2010 7:57 AM > Subject: Re: [Pharo-project] Diff tools > > >> gary >> do we have resolved all conflict by taking the incoming? >> and the inverse because in the old diff tools we could and this is handy. >> >> On Feb 9, 2010, at 4:24 PM, GARY CHAMBERS wrote: >> >>> New version on SqueakSource Polymorph-Tools-Diff-gvc.20. >>> >>> Descriptions added and small bug fix for merge tool (selecting next >>> conflict now ignores "resolved" conflicts). >>> >>> Merge and select incoming for each conflict to load.. >>> >>> Regards, Gary >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by StÃ©phane Ducasse

On Feb 23, 2010, at 2:25 PM, Torsten Bergmann wrote: >> make sure that we can get metacello configuration working in 3/5 years from now. > > We should also think about > > - mirroring. Currently in Metacello you give the repo hard coded in the baseline. > Maybe it would be better to have an alias there and define the repo > elsewhere (for instance in #versionXXX method). > - offline work where on is working offline, behind a closed proxy. There are also > companies that want to have an internal server. They do not want to rely > on a public server even when it is 24*7. > > Did I already ask if we have the infrastructure/resources to run an own > server (PharoSource, ...)? I requested inria to get a server with the correct webdav configuration but so far they were busy... > > Bye > T. > > c > -- > NEU: Mit GMX DSL Ã¼ber 1000,- Â¿ sparen! > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by StÃ©phane Ducasse

neat! > >> El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribiÃ³: >> I was thinking about this problem yesterday in the light of the packages >> moved by Lukas. >> We have a problem with the packages referenced by a ConfigurationOfXXX. >> The can disappear anytime. The repository can disappear anytime. >> >> So I thought that we need a dedicated hosting server where: >> >> - We have all the ConfigurationOfXXX (in the MetacelloRepository repo, >> just as now) >> - We copy there *all* the packages that conform a giver >> ConfigurationOfXXX>>versionXX: from the original repo to this dedicated >> repo. >> - There is *no way* to delete anything. This is a *write only, read >> always, delete never* repository. > > Sidenote: SqueakMap actually caches all URLs used for versions and if > the original URL fails an SHA check it falls back on the cached file on > the SqueakMap server. > > In that way it was meant to handle original URLs going stale or > disappearing. > > regards, GÃ¶ran > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2010

Re: [Pharo-project] Pharo by Example is back on Lulu

by StÃ©phane Ducasse

We need to get some cool reviews now. :) Stef On Feb 23, 2010, at 1:46 PM, Oscar Nierstrasz wrote: > > Hi Folks, > > After much pain, PBE is back on Lulu: > > http://www.lulu.com/content/paperback-book/pharo-by-example/7522128 > > The problem seems to have been caused by embedded PDF figures, which messed up the fonts on several pages. By turning all th efigures into embedded PNGs, the problem finally went away. > > Cheers, > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2010

Re: [Pharo-project] Trying to build alien plugin in linux

by StÃ©phane Ducasse

I hope that we will get an engineer paid by inria but this will not be before september 2010. we should get some news in a couple of weeks. Stef On Feb 23, 2010, at 10:51 AM, Torsten Bergmann wrote: > Havent followed this thread and currently lacking some time. > The VMMaker config is changeable, so go ahead. > > Take care that it also works in latest Squeak trunk. > Since most VM maintainers use Squeak to build the VM this is > essential to follow their progress. > > Would also be a great move if Alien would be available on Windows - > this would open the door to interfacing with Win technologies like > COM or .NET (and therefore wake more commercial interest in Pharo). > Having Alien on major OS platforms would also allow to use Smalltalk<-> > Java bridging technologies like JavaConnect/JNIPort, > > Bye > T. > > -------- Original-Nachricht -------- >> Datum: Tue, 23 Feb 2010 10:08:55 +0100 >> Von: Mariano Martinez Peck <marianopeck(a)gmail.com> >> An: Pharo-project(a)lists.gforge.inria.fr >> CC: Arnaud Jean-Baptiste <jbaptiste.arnaud(a)gmail.com>, Torsten Bergmann <astares(a)gmx.de> >> Betreff: Re: [Pharo-project] Trying to build alien plugin in linux > >> Torsten and JB: it would be cool to create a new metacello configuration >> version with this new version of VMMaker, puting the fix about the >> baseHeaderSize and integrating JB fixes to VMMaker. >> >> Cheers >> >> Mariano >> >> On Tue, Feb 23, 2010 at 7:55 AM, Fernando olivero >> <oliverof(a)lu.unisi.ch>wrote: >> >>> >>> On Feb 23, 2010, at 4:19 AM, John M McIntosh wrote: >>> >>>> >>>> On 2010-02-22, at 6:48 PM, Javier PimÃ¡s wrote: >>>> >>>>> >>>> >>>>> Lastly, as I said when I loaded Alien Core the first time, I got this >>> error while loading it: >>>>> >>>>> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". >>>>> >>>>> What should I do about that? ignore it? >>>> >>>> Well it seems to be related to >>>> >>>> ((Smalltalk includesKey: #ObjectMemory) >>>> and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien >>> ifAbsent: []) ~~ (index - 1)]) ifTrue: >>>> [self error: 'index probably wrong']. >>>> >>>> Usually people don't have ObjectMemory loaded in their image, and I"m >> not >>> sure what it is check for. >>>> Why don't you try it in a regular Pharo image versus your VMMaker >> image. >>> >>> Great work Jorge! Nice to know you won the battle against VMMaker! >>> >>> The ensure in special objects array error, has to do with some missing >>> classes as John pointed out. >>> >>> The smalltalk special objects array has hardcoded indexes for some >> relevant >>> classes ( Globals) in the system. >>> In the alien configuration i've just ensured that the size should be 53, >>> before loading Alien, because the Alien code installs itself in that >> array >>> at positions 54 and 55. >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > > -- > NEU: Mit GMX DSL Ã¼ber 1000,- Â¿ sparen! > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2010

Re: [Pharo-project] how to remove World?

by StÃ©phane Ducasse

Yes this is a good idea. May be the DummyUIManager should be by default in the system. Can you open a ticket? Stef > I think that maybe it is a good idea to use the DummyUIManager and the MorphicUIManager from Pavel MinimalImage. > > We can put those classes in a repository called PharoMinimal or something similar. Then, you will be able to load both classes, run your image headless and before, evaluate something to set those classes as the current. > > Just an idea... > > On Tue, Feb 23, 2010 at 10:18 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > this is a really good experiment > please continue > and let us know the results. > Stef > On Feb 22, 2010, at 8:21 PM, Esteban Lorenzano wrote: > > > I tried by starting pharo with a script: > > > > Project uiProcess suspend. > > Smalltalk > > snapshot: true > > andQuit: true. > > > > ...and the processing stop working after the #suspend (no > > snapshot:andQuit: happens :( ) > > > > On 2010-02-22 13:43:05 -0300, Lukas Renggli > > <renggli(a)gmail.com> said: > > > >>> Is that also necessary for a headless Pharo/Squeak? > >> > >> No, it is not necessary. It saves a few CPU cycles because the event > >> polling stops, the #step methods on the visible morphs are not called > >> anymore, and the display is not updated any longer. > >> > >> Programmatically you can still do everything (headless or > >> non-headless). For example you can open morphs and move them around, > >> you just won't see a change on the screen. Code that have some > >> interaction with the GUI thread (like the debugger) might deadlock (or > >> hang) the system. > >> > >> Lukas > > > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2010

Re: [Pharo-project] Why a package management system

by laurent laffont

> > > Metacello is nothing new for sure, but contrary to other systems, it > seems to have reached wide acceptance in Pharo. > IMHO that's a key point. We don't need to have the best package management system, we need to have only ONE. Major Linux distributions are great for that. Ruby too (though there has been a lot of problems when github came in, you had to choose which fork of the gem you wanted to use, everybody fork..... gemcutter has resolved this). When there will be needs to switch to another package management system, trash the old, only use the new one. So we can keep one way to load packages. Metacello is great :) Laurent Laffont.

Feb. 23, 2010