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

Re: [Pharo-project] Monticello Version Info

by Sven Van Caekenberghe

On 02 Mar 2012, at 01:52, Chris Cunningham wrote: > The issue is that Monticello is setup for distributed processing, and > allowing for multiple repositories, some of which may not be available > to all of the users for a project. For instance, a project might be > developed internally (or on the developers hard-drive) until they feel > comfortable distributing the code later. So, publicly, you get > version 12, 17, 34, and 37. There is no access to the intermediate > ones (unless you happen to be the one that created them and didn't > release them). The 'whole ancestry' let's you do diffs off of a > version derived from 37 against one derived from 34 - the ancestry can > determine that version 34 if 'common', and work from there. [Note > that just numbers aren't enough - the original developer, say, cbc > could have version cbc.34, while you could have, say, CamilloBruni.34, > but yours is based off of 17 (since you picked up that verison and > started working there). So, merging cbc.37 with CamilloBruni.34 would > need to pull down cbc.17 for a good merge to work.] > > At least, that's my understanding from long ago discussions. This makes sense, but how is this handled with git ? Sven

March 2, 2012

Re: [Pharo-project] CRC in System-Hashing?

by StÃ©phane Ducasse

On Mar 2, 2012, at 8:18 AM, Max Leske wrote: > I need to calculate CRC for Git and couldn't find it in the system packages (I guess I'd find it in Cryptography). Since Pharo has a system package called "System-Hashing" I was wondering if anyone sees a reason why CRC should not be part of that package. That would also allow the Zip implementation to use the system CRC function (at the moment Zip implements its own CRC check). No idea but your suggestion makes sense :) > > Another thing: going through Sytem-Hashing I noticed that there are two implementations for SHA1: "SHA1" and "SecureHashAlgorithm". They both have the exact same class comment but vary slightly in the messages they implement (although most of them are present in both classes). Can we remove one? May be ask ron teitelbaum since I guess that ron worked on it. > > Cheers, > Max

March 2, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by StÃ©phane Ducasse

> > Please :). It would be nice to have one strong mechanism for providing notifications. +1

March 2, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by StÃ©phane Ducasse

On Mar 2, 2012, at 1:42 AM, Benjamin wrote: > I made some improvements in it, and I will use it :) Cool! I think that we should load it in 1.4 > But here, the Growl morph is really text oriented when in my version, you can add whatever you want :) merge it :) > Maybe I will do a refactor in Growl to have this abstraction I don't know :) > > But for sure, you did a cool job with Doru, and I will use it n Nautilus :) > tx I do not remember what I did :) Stef

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by StÃ©phane Ducasse

> well, you usually cache the mcz in your local directory cache (at least that's the default). > and extracting the meta-data out of a local mcz is rather cheap since zip allows you to directly extract certain files. > > maybe we could add another entry to the mcz with just the stripped down version info in it. this way older monticello versions would still be able to load it the slow way, whereas an updated version could benefit from incremental loading? may be I do not know enough of it. Stef > On 2012-03-01, at 23:11, Nicolas Cellier wrote: > >> I think the main reason is that you cannot load just the metadata, but >> the whole mcz when you need to dig into the history... >> That ain't cheap, and that happens when you merge more or less distant branches. >> >> Also, it's not unusual to upload directly version N+5 without the >> whole N+1 to: N+4 ancestry... >> In this case MC can still find a common ancestor. >> >> Nicolas >> >> Le 1 mars 2012 23:07, Dale Henrichs <dhenrich(a)vmware.com> a Ã©crit : >>> For the majority of use cases I think that the immediate ancestor is the only one needed ... so you might be onto something here... >>> >>> Dale >>> >>> ----- Original Message ----- >>> | From: "Camillo Bruni" <camillobruni(a)gmail.com> >>> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>> | Sent: Thursday, March 1, 2012 1:53:48 PM >>> | Subject: [Pharo-project] Monticello Version Info >>> | >>> | I am still having a look at the Monticello implementation. >>> | Now coming from the git world, this seems very weird: >>> | >>> | Why does each Monticello version store the complete ancestor history? >>> | >>> | ------------------------------------------------------------------------ >>> | >>> | Wouldn't it simply be enough to keep pointers to the immediate >>> | ancestors, and then lazily load and cache them? >>> | >>> | Where is the complete ancestry needed, besides diffing/merging? >>> | >>> | ------------------------------------------------------------------------ >>> | >>> | The current setup implies that something like >>> | >>> | MCCacheRepository default loadVersionFromFileNamed: >>> | 'SLICE-Issue-5416--Improve-MC-version-loading-CamilloBruni.1.mcz' >>> | >>> | takes around 1.5 seconds to complete, whereas this could be done in a >>> | fragment of a second for most cases... >>> | >>> >> > >

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by StÃ©phane Ducasse

+1 I would like that we respect a bit MC. Because so far this is the only thing that we have that is working well. Ranting about it does not make it any better (Camillo this is not about you in particular but in general). Stef On Mar 1, 2012, at 11:11 PM, Nicolas Cellier wrote: > I think the main reason is that you cannot load just the metadata, but > the whole mcz when you need to dig into the history... > That ain't cheap, and that happens when you merge more or less distant branches. > > Also, it's not unusual to upload directly version N+5 without the > whole N+1 to: N+4 ancestry... > In this case MC can still find a common ancestor. > > Nicolas > > Le 1 mars 2012 23:07, Dale Henrichs <dhenrich(a)vmware.com> a Ã©crit : >> For the majority of use cases I think that the immediate ancestor is the only one needed ... so you might be onto something here... >> >> Dale >> >> ----- Original Message ----- >> | From: "Camillo Bruni" <camillobruni(a)gmail.com> >> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> | Sent: Thursday, March 1, 2012 1:53:48 PM >> | Subject: [Pharo-project] Monticello Version Info >> | >> | I am still having a look at the Monticello implementation. >> | Now coming from the git world, this seems very weird: >> | >> | Why does each Monticello version store the complete ancestor history? >> | >> | ------------------------------------------------------------------------ >> | >> | Wouldn't it simply be enough to keep pointers to the immediate >> | ancestors, and then lazily load and cache them? >> | >> | Where is the complete ancestry needed, besides diffing/merging? >> | >> | ------------------------------------------------------------------------ >> | >> | The current setup implies that something like >> | >> | MCCacheRepository default loadVersionFromFileNamed: >> | 'SLICE-Issue-5416--Improve-MC-version-loading-CamilloBruni.1.mcz' >> | >> | takes around 1.5 seconds to complete, whereas this could be done in a >> | fragment of a second for most cases... >> | >> >

March 2, 2012

Re: [Pharo-project] Give it five minutes - (37signals)

by StÃ©phane Ducasse

On Mar 1, 2012, at 11:52 PM, Sven Van Caekenberghe wrote: > Coming from someone who is often accused of having a big ego: > > http://37signals.com/svn/posts/3124-give-it-five-minutes > > Well written. > > I am equally guilty sometimes. He is right :) Listening is important else you cannot change and improve yourself I will even learn git so â¦ amazing isn't :) Stef

March 2, 2012

Re: [Pharo-project] CRC in System-Hashing?

by Marcus Denker

On Mar 2, 2012, at 8:19 AM, Max Leske wrote: > I need to calculate CRC for Git and couldn't find it in the system packages (I guess I'd find it in Cryptography). Since Pharo has a system package called "System-Hashing" I was wondering if anyone sees a reason why CRC should not be part of that package. That would also allow the Zip implementation to use the system CRC function (at the moment Zip implements its own CRC check). > Yes, that would be nice. But people will yell at you for making Pharo bloated and going in the completely wrong direction and that you should and never ever add any code. > Another thing: going through Sytem-Hashing I noticed that there are two implementations for SHA1: "SHA1" and "SecureHashAlgorithm". They both have the exact same class comment but vary slightly in the messages they implement (although most of them are present in both classes). Can we remove one? Yes. But for sure someone will yell at you if you remove it, because the system should be stable and not force people to change their code. Marcus -- Marcus Denker -- http://marcusdenker.de

March 2, 2012

Re: [Pharo-project] odd bug in Squeak 4.3, also in Pharo 1.3?...

by Marcus Denker

On Mar 2, 2012, at 4:25 AM, Lawson English wrote: > I was creating a new video tutorial to show how to find all comments in all classes but I'm getting errors in both Squeak 4.3 and Pharo 1.3. > > In Squeak 4.3, the error is: Key not found: Comment > > In Pharo 1.3, the error is: Improper store into indexable object. commentsIn: returns a collection, not a string. Marcus -- Marcus Denker -- http://marcusdenker.de

March 2, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by Sven Van Caekenberghe

Marcus, On 01 Mar 2012, at 23:35, Marcus Denker wrote: > We can not backport everything... especially as the amount of people looking > at stuff is very small. yes, we should release more often... > > E.g. since I asked for help on 1.3 issues: > > http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3 > > There was *no reaction at all*. Nothing. Zero. We are all guilty, me too. I know. I try to keep my main contributions (Zinc HTTP Components & Zodiac) compatible with both 1.3 and 1.4 and so far that works. But of course, some deeper issues are only resolved on 1.4, perfectly normal. The work that you do, including the backporting to 1.3 is much appreciated: it is _you_ who makes that happen. > Sometimes I think we should just stop and do something else. This is clearly not working. The current strategy is good, IMHO, given the resources available. The current stable version, 1.3, is a very good version: it was developed by a whole community for a long time, and we all worked and lived with it for a long time, a lot still do. Today, 1.4 is moving fast and is very promising, for many of us, it is our daily workhorse. Maybe one of the tasks of the consortium could be to dedicate some extra effort to maintaining the current stable version. Sven

March 2, 2012