April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Build process of Pharo image

by Pharo4Stef

On 06 Apr 2014, at 11:43, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > For me this should the responsibilities of the component developers. It > is more efficient as s/he knows the component and what may break at > installation time. Except that it requires a better infrastructure and who is in charge about - RB - RBenvironment - Smart Suggestions - â¦. Stef > > Le 06/04/2014 10:44, Pharo4Stef a Ã©crit : >> You take unReloader you run the scripts and you load the configurations. >> when they fail you fix them and restart. I have been doing that a lot and we will continue but this is booooooring. > > -- > Dr. Geo http://drgeo.eu > >

April 6, 2014

MC diffs are seriously broken in Pharo2.0

by Nicolas Cellier

I'm trying to fix some Pharo VM issues (11330), but have awfully bad experience with Pharo2.0 tools. The autocompletion stuff is a joke, it moves the input cursor randomly and spoils my input. That's the first thing I disable. The pharo's PolyMorphDiffTool is good looking but awfully sloooow It clearly does not scale (10 minutes or so to diff Eliot's branch) so I reverted to the old diff tool. But of course, someone broke MCMethodDefinition>>summary (gratuitously?) and I had to revert this method to have class names displayed again. But worse than all, there are insane caches operating in MCVersion that drove me crazy. Here is the scenario: 1) I diff working copy against package.branchA-version.mcz 2) I cherry pick and install a few methods 3) I diff against package.branchA-version.mcz again to check if I missed smthing 4) Huh? it looks like my cherry pick have not been installed??? Yes they were installed, but the completePackageSnapshot has been cached in MCVersion!!! What a mistake! The working copy is going to evolve, caching a snapshot of it is a DUMB thing.It means that methods that I further change in the working copy will NEVER be taken into account next time I'll do a diff. So I had to change MCVersion>>changes ^ self completeSnapshot patchRelativeToBase: self loadCompletePackageSnapshot This is so broken that I have to report here. Note that I did not check if symptoms are still in Pharo 3.0, but the working copy scnapshot cache still is for sure! Guys, it makes me wonder, who is eating the dog food? Did anyone progress into developing VM in Pharo 3.0, because if I must eat it, I'd prefer the freshest ;) Or if I fix some more bug, I'd like my efforts to not apply to an obsolete version.

April 6, 2014

Re: [Pharo-dev] Build process of Pharo image

by Pharo4Stef

> > I can give you all the Monticello package list, but is it relevant? I > hardly know 10% of them. Some should probably belong to core other not. > >> do you want an image by default without any tools? I do but we need time. > > I don't understand: with times new important tools were developed, like > Nautilus and other I don't know I guess. Was it decided these tools > should be carved in the image or be loaded? No they should be loaded. Now we should not deliver an image that is not the one we use so we will put in place a building process from the smaller images, loading the tools we need. Now we rewrote slowly the tools and we are removing the ones that have been fully rewritten. But there is no magic: time and resources. So give me 1 engineer full time to have the process I dream and it will be there. Now igor is focusing on texteditor (beside fonts and NB) and esteban the rest :) > Was not removing old tools > and using new loadable ones the way to build step by step this core image? This is what we did: new finder, new message, new changesorter, new browserâ¦. > I confess I very likely don't see the subtle details. > >> so you are right we are concious about it but no resources. > > Is it really a resource problem? Yes. > With my scarce resources and knowledge I can build automatically drgeo > with a bash script and a .st file since 1.x for several platform. I > agree it is more complex with Pharo butâ¦ It is. And Drgeo is just managed by you and not by the community/independant projects. I asked already one year ago an engineer to build this but he was refused. We resubmitted the project and we are waiting. > > Hilaire > > > -- > Dr. Geo http://drgeo.eu

April 6, 2014

Re: [Pharo-dev] Build process of Pharo image

by Hilaire Fernandes

Le 06/04/2014 10:44, Pharo4Stef a Ã©crit : > > On 05 Apr 2014, at 21:48, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > >> Still, I do not get why the newer packages are not loadable with >> configurations instead of been carved in the image. Why can't packages >> developers provide such configurations? > > sure give us a list? > - RB > - Nautilus > - spec > - Keychain > - key mapping > - smart suggestions > - â¦.. > - and many more I can give you all the Monticello package list, but is it relevant? I hardly know 10% of them. Some should probably belong to core other not. > do you want an image by default without any tools? I do but we need time. I don't understand: with times new important tools were developed, like Nautilus and other I don't know I guess. Was it decided these tools should be carved in the image or be loaded? Was not removing old tools and using new loadable ones the way to build step by step this core image? I confess I very likely don't see the subtle details. > so you are right we are concious about it but no resources. Is it really a resource problem? With my scarce resources and knowledge I can build automatically drgeo with a bash script and a .st file since 1.x for several platform. I agree it is more complex with Pharo but... Hilaire -- Dr. Geo http://drgeo.eu

April 6, 2014

Re: [Pharo-dev] Build process of Pharo image

by Hilaire Fernandes

For me this should the responsibilities of the component developers. It is more efficient as s/he knows the component and what may break at installation time. Le 06/04/2014 10:44, Pharo4Stef a Ã©crit : > You take unReloader you run the scripts and you load the configurations. > when they fail you fix them and restart. I have been doing that a lot and we will continue but this is booooooring. -- Dr. Geo http://drgeo.eu

April 6, 2014

Re: [Pharo-dev] Hierarchy view in Nautilus

by Nicolai Hess

2014-04-06 10:46 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 06 Apr 2014, at 02:39, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > Hi! > > > > Selecting a class in a hierarchy view in Nautilus switches back to the > Flat new. > > Is this really something we want? > > No, seems like a serious recent regression ! > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > Its already reported 13171 <https://pharo.fogbugz.com/default.asp?13171> When browsing a hierarchy, Nautilus changes the view unexpectedly and this is the cause of this regression: 13099 <https://pharo.fogbugz.com/default.asp?13099> nautilus is not refreshing package tree panel on certain operations nicolai

April 6, 2014

Re: [Pharo-dev] Problem with Finder

by Pharo4Stef

On 06 Apr 2014, at 08:20, jannik laval <jannik.laval(a)gmail.com> wrote: > Hi guys, > > When I use the Finder, on a specific package, it does not take into account the class extensions. > > Is this bug already reported ? No and this is probably a bug because you may be the first one to use this feature :) > > -- > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://car.mines-douai.fr/ >

April 6, 2014

Re: [Pharo-dev] 12178 Extended-class-shown-twice-in-Browser

by Pharo4Stef

thanks! On 06 Apr 2014, at 04:11, Ben Coman <btc(a)openInWorld.com> wrote: > This one is ready to go. Been review by Martin, Nicolai and myself. > https://pharo.fogbugz.com/f/cases/12178/Extended-class-shown-twice-in-Brows… >

April 6, 2014

Re: [Pharo-dev] Hierarchy view in Nautilus

by Sven Van Caekenberghe

On 06 Apr 2014, at 02:39, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Selecting a class in a hierarchy view in Nautilus switches back to the Flat new. > Is this really something we want? No, seems like a serious recent regression ! > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

April 6, 2014

Re: [Pharo-dev] Build process of Pharo image

by Pharo4Stef

On 05 Apr 2014, at 21:48, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Still, I do not get why the newer packages are not loadable with > configurations instead of been carved in the image. Why can't packages > developers provide such configurations? sure give us a list? - RB - Nautilus - spec - Keychain - key mapping - smart suggestions - â¦.. - and many more do you want an image by default without any tools? I do but we need time. So what we want to do is - to have a core mage that the one people use is based on the core + the loading of the components and now we are arriving to this situation because before we did not have command-line jenkins - for Pharo 4.0 we will get there. Now since it is not easy to unload tools, and Iâm busy with other aspects of work we could not do it the way you describe it but this is what we want. => why did we fail ok you have a core and some nice configurations then a guy report a bug and a fixe from this core and configuration we should create a new core AND correctly loading configurations and this is not fully automated yet. have a look at Pharo/SystemConfigurations You take unReloader you run the scripts and you load the configurations. when they fail you fix them and restart. I have been doing that a lot and we will continue but this is booooooring. So we should build tools and so far I do not see many people **Helping** beside pavel on this task so you are right we are concious about it but no resources. > Why don't we have an image > without those packages? Then public images built with. Is it not what > Jenkins is supposed to do? > I am afraid the situation looks like Etoys carved in Squeak. We are fighting against it. > > Hilaire > > Le 05/04/2014 18:32, Marcus Denker a Ã©crit : >> Yes, we need to look into a more modular build in Pharo4â¦ to not just load updates >> on the server but instead build from a small core (and possibly even from a bootstrap). > > -- > Dr. Geo http://drgeo.eu > >

April 6, 2014