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

Re: [Pharo-project] Pharo 1.4 beta?

by Norbert Hartl

Am 02.03.2012 um 09:48 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > I would like to see Pharo 1.4 going beta = > focus on bugs, less changes. > > Does it make sense? Of course. And you know this. Release early, release often is also valid for pharo. And is not done, you just tell everyone else to do it like this ;) Norbert > > What are the key problems we should focus on? > > Stef > > >

March 2, 2012

[Pharo-project] file date in filesystem

by Tudor Girba

Hi, Is there a way to obtain the creation or modification date of a file from Filesystem? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

March 2, 2012

[Pharo-project] pharo-seed and pharo

by Tudor Girba

Hi, I believe everyone agrees that one important goal in Pharo is to get to a small code/kernel/seed. During the Pharo Sprint at Bern we saw that the only reason for now having a unified image is just a temporary convenience that stems from two things: 1. Until Pharo 1.3, the core team worked in the core image, and this was frustrating because they were missing proper tools 2. After 1.3, building a pharo image out of a seed image was perceived as being too long and not fitting for the process of integration It's clear that the core team needs development tools. However, we think that 2 can be actually quite cheap if the build starts from the latest seed, and not from the original seed of 1.4 as it currently seem to happen. If this would be fast, we could go back to having one seed image (I call it seed just to avoid confusion and wrong feelings, but you can call it anyway you want) out of which the Pharo distribution (like the current image is) is built. The core team would work on this distribution, and Jenkins would do the rest. By switching the distribution build to work with the latest seed, we can probably reduce the amount of build time to a couple of minutes (at least this is what we saw during a couple of quick tests). Regarding the flow of the integrator, we saw that actually, when multiple changes need to be integrated, you can base the second change on the image that already exists locally, without needing to wait until Jenkins finishes. I would be interested in providing help. So, what do you say? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

March 2, 2012

Re: [Pharo-project] Pharo 1.4 beta?

by Sven Van Caekenberghe

On 02 Mar 2012, at 09:48, StÃ©phane Ducasse wrote: > Hi guys > > I would like to see Pharo 1.4 going beta = > focus on bugs, less changes. > > Does it make sense? > > What are the key problems we should focus on? > > Stef Yes, please, I has been pretty long already. I have been using 1.4 for some months now and I am beginning to switch certain production stuff. Like Marcus said: with the current CI things are (should be) ready all the time. Going beta, RC, release is just a label and some change in strategy (no risky stuff, more polishing). Let us all work a couple of weeks to stablelize everything. Problems will come up by themselves when we all start testing ;-) Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 2, 2012

Re: [Pharo-project] Pharo 1.4 beta?

by Tudor Girba

Playing with Moose on Pharo 1.4 over the past couple of weeks, I did not notice any major problems. Cheers, Doru On Fri, Mar 2, 2012 at 9:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I would like to see Pharo 1.4 going beta = > Â Â Â Â focus on bugs, less changes. > > Does it make sense? > > What are the key problems we should focus on? > > Stef > > > -- www.tudorgirba.com "Every thing has its own flow"

March 2, 2012

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

by StÃ©phane Ducasse

Marcus Do you play the role of yellers :) Let them do and we should move on. So max if you have solution for a better world we are all ears open :) Stef >> 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] leaking semaphores

by Henrik Johansen

On Mar 1, 2012, at 7:28 PM, Igor Stasenko wrote: > On 1 March 2012 18:20, Milan Mimica <milan.mimica(a)gmail.com> wrote: >> On 1 March 2012 02:11, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> >>> Modify RFBSocket class >> #acceptFrom: to read: >>> ^RFBSocketInstances add: (super acceptFrom: aSocket) >> >> >> Congratulations! You have just turned Pharo from so-so to awesome. >> > With one line of code? No, you must be joking! :) Not an entire line of code, -1 word :) Cheers, Henry

March 2, 2012

[Pharo-project] Pharo 1.4 beta?

by StÃ©phane Ducasse

Hi guys I would like to see Pharo 1.4 going beta = focus on bugs, less changes. Does it make sense? What are the key problems we should focus on? Stef

March 2, 2012

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