March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo Command Line

by Camillo Bruni

On 2013-03-08, at 22:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Because in Pharo we are doing more than talking and we value documentation â¦â¦ > Yes guys you can twitt that one! thanks stef. though something to nag about... :P why is code not in a fixed-width font in the pdf? :D It breaks all the formatting for the help comments.

March 8, 2013

Re: [Pharo-project] building traits programmatically

by Ciprian Teodorov

On Fri, Mar 8, 2013 at 10:32 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > > On Mar 8, 2013, at 7:57 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > wrote: > > Hi guys, > > Can anyone give me some pointers on how to create traits dynamically? > > > you mean with the refactoring engine? > Yes something like it, I am little confused with all ring, rb stuff. But I know that I can build classes, add methods, and see changes (and apply them) using RBNamespace api... it does not seem to work with traits. Some time ago I have spend some time patching the RB thingy to accept trait also... but then I have run into other problems (i don't remember exactly what)... Moreover, it was just hacks to make it work... so I've lost them over time... and I don't like patching every new image that I download with my changes to make It work... So maybe, I don't use them right... or there are things that should be done... I'm willing to contribute, if it helps. I know that one argentinian student added support for traits in RB but I > never got the time to have a look and integrate it. > cool, maybe we should have a look... Then again, it is not clear in my head what is the politics of traits and pharo... I know that there were some discussions about them being bad because their methods are copied to classes, not being well integrated.... how exactly do they fit in the big picture (next pharo versions). Can we use them as they are now, or the implementation is likely to change in the near future? -- stateful traits, or something else? cheers, ciprian > > > I have tried something like: > > model := RBNamespace new. > > model defineClass: ('Trait named: #TMyTrait > uses: {} > category: ''My-Tests'''). > > and I get a DNU: RBAddTraitChange>>superclassName > > Cheers, > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

March 8, 2013

Re: [Pharo-project] VM Crashes

by Igor Stasenko

On 8 March 2013 22:23, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > We will have to address this! > We are getting there :) > Unstable VM is not a big tragedy. If you remember we released 1.4 with unstable VM as well.. Of course, it would be nice if we could have some stability.. but getting there could delay release for weeks if not months :( -- Best regards, Igor Stasenko.

March 8, 2013

Re: [Pharo-project] building traits programmatically

by stephane ducasse

On Mar 8, 2013, at 7:57 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi guys, > > Can anyone give me some pointers on how to create traits dynamically? you mean with the refactoring engine? I know that one argentinian student added support for traits in RB but I never got the time to have a look and integrate it. > I have tried something like: > > model := RBNamespace new. > > model defineClass: ('Trait named: #TMyTrait > uses: {} > category: ''My-Tests'''). > > and I get a DNU: RBAddTraitChange>>superclassName > > Cheers, > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro

March 8, 2013

Re: [Pharo-project] VM Crashes

by stephane ducasse

> List, > > I hope you realize I'm motivated to investigate VM crashes. > Esteban reports that the VM is now more stable w.r.t. becomeForward: > after I debugged load cases a couple of week ago. But I could do with > some help. It really helps to be provided with an image that > reproduces the bug in start-up. e.g. evaluating a doit that saves and > then invokes crashing code: > > Smalltalk saveAs: 'crash'. > Gofer it > url: 'http://www.squeaksource.com/MetacelloRepository'; > package: 'ConfigurationOfFFI'; > load. > (Smalltalk at: #ConfigurationOfFFI) project stableVersion load. > > This saves me a lot of time. I have a day job that does not pay me to > investigate Cog crashes. Your help is most appreciated. Your too. Yes getting reproducible cases is a key aspect. Esteban and Igor spent some days checking for this and other problems (that nicolas experienced on his servers). Stef

March 8, 2013

Re: [Pharo-project] Pharo consultants

by Tudor Girba

Yes, I completely agree. I think it is important to start exchanging Pharo-related business experiences. This is why the second day of PharoConf and part of the MooseDay will feature several talks about doing business around Pharo. I think we should collect and spread such stories. Cheers, Doru On Mar 8, 2013, at 10:05 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I just got a nice chat with a cool Pharo expert (Mariano) that is doing consulting and development around Pharo and this is a cool feeling to know that smart guys in our community can find nice jobs that keeps them busy in Pharo. > I think that we should market the community much more, because I think that this is important for other companies > to know that they can find help with really talented people in our community. > May be we should make more noise around: > Pharo: a community with smart developers for cool business > > Stef > > > > > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

March 8, 2013

Re: [Pharo-project] VM Crashes

by stephane ducasse

On Mar 8, 2013, at 5:03 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Camillo Bruni-3 wrote >> If it's too old, what do you do? you go and fetch a newer VM ;). >> So I would say the implied actions are ok, especially for newcomers, >> but there should be more details indeed. > > Since Zinc is now included could the warning instead be a choice dialog that > lets the user download either an appropriate VM for the image or an > altogether more-up-to-date image+vm combo rather than just leaving the user > to figure out how and where to find an appropriate VM? Paul we will provide one VM :) after the message could be a bit more explicit. and one image + vm combo will be offered. This is just that we ran after this become: bug since a couple of months and we are getting to the situation were we could reproduce it. Stef

March 8, 2013

Re: [Pharo-project] Cleanup of the Zerconf scripts

by Tudor Girba

+1 Doru On Mar 8, 2013, at 10:09 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Mar 8, 2013, at 1:23 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> With the release of 2.0 imminent we are going to cleanup the zeroconf scripts a bit: >> >> - the only valid VM scripts are PharoVM, StackVM and RizelVM >> - NBCogVM and CogVM scripts are going to be removed! > > Superb! > >> so if you used ciPharo20NBCogVM.sh, use ciPharo20PharoVM.sh from now on! >> >> I will deprecate the scripts in a first step, and fully remove them within next week. > > Superb! > Cleaning cleaning cleaning is the only way :) > >> I hope this won't cause too many problems, otherwise let me know. > > -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

March 8, 2013

Re: [Pharo-project] VM Crashes

by stephane ducasse

We will have to address this! We are getting there :) Stef >>>> But I have said this before: the wall clock time of loading a lot of code is actually close to unacceptable - I don't think it is the download or the compilation, but more all the dynamic stuff that happens after that. There should be a way to not do all those updates for each method and move the updates to one big batch update after the load - if that is possible. >>> >>> To continue my rant (sorry ;-) about the problem with slow code loading. >>> >>> These are some benchmarks on the same machine: >>> >>> $ ./vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' >>> 106532 >>> >>> $ ./stack/vm.sh experimental.image eval '[Smalltalk allClassesAndTraits do: #compileAll] timeToRun' >>> 221708 >>> >>> So it takes like 3 minutes to recompile every method in the system. >>> >>> How in the hell can it take 40 minutes to load some code (with all packages already present in the package-cache (but then again the package-cache is only 3.5 Mb, which could be downloaded in seconds)) ? >> >> I with you on this one! :D I always wondered what Metacello and Compiler do there! :D > > Well, open the Time Profiler and load your favourite Config. You'll have a hard time finding the actual time slice of the compiler. As far as I could see in my run it was less than 1% ! All the rest MC, Gofer, RPackage and SystemAnnouncement stuff, even completion stuff. > > Quite a challenge to optimize if you ask me. > > Sven

March 8, 2013

Re: [Pharo-project] VM Crashes

by stephane ducasse

> > I was trying to suggest a more meaningful message for the use case of a user > running Pharo on a non-Pharo VM. The message says to get a newer VM, which > is wrong in that case. Ah that of course :) > Yes I understand that I am not part of the target market. I am a person who > is trying to maintain external packages for Squeak and Pharo. Sometimes I need > to use another VM in order to do that, so I think it's a legitimate use case. > > Dave

March 8, 2013