- Pharo-dev - lists.pharo.org

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

by Henrik Johansen

On Mar 2, 2012, at 9:05 AM, Marcus Denker wrote: > > 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. Decomposing != Bloating. As long as you refactor the current users (which currently use the implementation in ZipWriteStream) to use the new CRC class, it should be fine. I would suggest deprecating the class method in ZipWriteStream rather than removing it though, based on the users in image, it is a likely method to be in use by external packages doing CRC calculations. It also seems the primitive for updating CRC is not reliant on the CrcTable class var, so should be safe to use in new class' method as well. > >> 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. IIRC, it was initially included as SecureHashAlgorithm, being renamed when imported from the Cryptography package. To allow existing packages relying on Crypto to load cleanly, SHA1 was later also included. As there are already other name clashes with the Crypto package (MD5 for instance) I would vote for deprecating SecureHashAlgorithm. (SHA1 is arguably a more descriptive name anyways) Not sure if it's worth including hashMessage: in SHA1, it's just a utility method. Cheers, Henry

March 2, 2012

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

by StÃ©phane Ducasse

> > I think this attitude is what will continue to hold Pharo back from wider > adoption. I've found 1.4 to be unusable for daily development. Why? We use it daily and not for toys application. All the Moose people are working using 1.4. Have you precise problems? > And yet there's no interest in fixing problems in 1.3. This is not that there is no interest. We do not have the time and there is too much. > As long as 1.4 is totally > experimental and not actually a productive environment, people who need to > get stuff done won't contribute to it. For the records, we are setting up a company around moose so we are not doing experimental things with 1.4 Our experimental things are not public. > That means that for the time being, > it's the five of you who know what you're doing that will make Pharo better. > It's all good to say, "complain less, patch more" (and I totally agree with > it), but often times the person "complaining" is trying to figure out how to > get going so they can solve their own problem! sure > And lest you think I don't want to contribute, I'll point you to > > http://code.google.com/p/pharo/issues/detail?id=4549&can=1&q=test%20runner&… Thanks > > where I > a) submitted a bug report > b) included a video demonstrating the bug > c) included a patch fixing the bug > > responses were > - "not a showstopper -> move it to 1.4" > - "for me the bug entry is not really relevant" > > seven months later it finally made its way in. > > I can see saying, "move it to 1.4" if 1.4 is right around the corner. But > it's seven months later and there's no 1.4 release and I'm personally still > very confused as to what versions of stuff people actually use. some people use 1.3 some 1.4 (for example I guess that pinesoft is in 1.4) we are in closing 1.4 but there are concerns that forced us to consider to delay a bit 1.4 Now I want that we go beta. > Presumably some people use 1.4 else it wouldn't be under "active development," but for > actually getting stuff done, are people on 1.3? Or do people use 1.4 to get > stuff done? Both. > Feel free to write me off, but I'm telling you this as someone who loves > smalltalk and pharo and really wants to see it win and receive wider > adoption. And I imagine that you guys do too, especially since more people > using pharo = more people contributing to pharo. > But right now the pharo ecosystem is so fragmented, what let you say that? > and I feel like the development process is > totally opaque, what are your questions? so that we reply :) > and exclusive to the few people who get together in lille > for the sprints or whatever. Not really. This is simple. There is a bug we fix it and we harvest it after some can pass under our radar. > I mean really, someone says they *can't run > tests*, *submits a patch*, and gets a "fuck you" response? Did we say fuck you? I do not think so. Now when we are in crunch release time we stop integrating simple fixes. > No wonder there's > so little contribution from outside the core group of developers. This is not true. We never meet vanbecman, pavel, you and a lot more this is just that you do not see our lives here. Because Pharo is not our job :) only the one of igor but he is rather busy with graphics and VM and other stuff. > As long as 1.3 is the prime time release - i.e. the release suitable for > active development - you have to support it and care about the people using > it. This is not some backward compatibility thing. It's a daily usability > thing. You can't tell people, "yeah that is fixed, but only in 1.4, but 1.4 > isn't really ready for you to use yet." Yes. Now if you patch works well for you you can also load it and you can also gently remind us that this fix is easy to integrate and that we forgot. Pat if one day you can make it for ESUG or for a visit at Paris you are invented to visit us. For example this week I'm traveling 4 days and I have 6 Phds students to work with and a lot lot lot more things that I must do. > And if I submit a patch for 1.3, > then accept the damn patch for 1.3. Don't tell me "it'll go into 1.4" when I > can't even use 1.4 myself. That's how you alienate users and keep the > community tiny. Don't take it like that. Give us a 5 min chance and consider the other side of the fence. We are working on improving our commit process so that we have less boring work to do. But to do that it means quite some work behind the scene to load, run, report, save, publishâ¦ and handle code that does not load load but crashâ¦. Stef > > Pat > > -- > View this message in context: http://forum.world.st/Bug-Tracker-Issues-tagged-1-3-tp4416469p4436606.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 2, 2012

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