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

Re: [Pharo-project] CRC in System-Hashing?
by Marcus Denker March 2, 2012

March 2, 2012

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

6 8

[Pharo-project] file date in filesystem
by Tudor Girba March 2, 2012

March 2, 2012

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"

3 3

[Pharo-project] [Bug Tracker] Issues tagged 1.3
by Marcus Denker March 2, 2012

March 2, 2012

Hi, Just as another suggestion of something else to do to uselessly talk about what one would do if one could do... here is something that needs to be done: http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3 Someone need to looks at each issue and as questions. - can this problem be repeated in the current last version of 1.3? - is this already fixed in 1.4? if yes -- is it so grave that the fix needs to be backported? - was it already a bug for the last 10 years and it did not hurt? -- Hint, hint: likely not important for fixing in 1.3 after it has been released. (yet, it could be. And if the fix is easy and clearly not breaking anything) - is there already a bug report about this issue on the tracker? (you have no idea how many reports are duplicated entries...) - What could be the reason for the problem? What could be a possible fix? -- Marcus Denker -- http://marcusdenker.de

9 35

Re: [Pharo-project] pharo-seed and pharo
by Marcus Denker March 2, 2012

March 2, 2012

On Mar 2, 2012, at 10:06 AM, Tudor Girba wrote: > 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. Nope, 1.3 is build from the very latest 1.3Core. Build takes 42 Minutes. Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] odd bug in Squeak 4.3, also in Pharo 1.3?...
by Marcus Denker March 2, 2012

March 2, 2012

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

2 1

[Pharo-project] leaking semaphores
by Milan Mimica March 2, 2012

March 2, 2012

Hi! I am continuing my search of why does my remote headless image run out of semaphores eventually. I have found the culprit this time. It is most definitively related to RFBServer. I am using version 38 from http://source.lukas-renggli.ch/unsorted. Every time I disconnect from the image with my VNC client (I click the disconnect icon) the count of leaked semaphores increases by 3. Since there is 3 semaphores per socket, I guess this is related to sockets. Now what do I do? What do I check? I am running the a Pharo image and Cog I got from CI server yesterday. This is the script I use to count leaked semaphores: | semaphores arr res | arr := ExternalSemaphoreTable unprotectedExternalObjects. semaphores := arr reject: #isNil. res := semaphores collect: [:sema | sema pointersTo reject: [:ptr | ptr == arr or: [ptr == semaphores ] ] ]. res := res select: [ :each | each isEmpty ]. res size. -- Milan Mimica http://sparklet.sf.net

3 5

[Pharo-project] CRC in System-Hashing?
by Max Leske March 2, 2012

March 2, 2012

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). 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? Cheers, Max

2 1

[Pharo-project] Nautilus version 4.0.4
by Benjamin March 2, 2012

March 2, 2012

Hi guys, I really want to thank you all for your feedbacks which give me the will to always add cool features to Nautilus. Thanks to that, let me introduce the new stable version with some new features: - better groups (now the granularity is method and no longer class) - better algorithm for coloring protocols and methods - more menu entries and shortcuts - Monticello integration - OCompletion integration - a lot of new icons :) (and some cleans in the code but ^^) Thanks every one for your good energy :) Ben

8 20

[Pharo-project] Give it five minutes - (37signals)
by Sven Van Caekenberghe March 2, 2012

March 2, 2012

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. Sven

2 1

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3
by Marcus Denker March 2, 2012

March 2, 2012

> > 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. And yet > there's no interest in fixing problems in 1.3. There is. But we need to be reasonable... we can not back-port everything. Even fixing bugs changes the system so that it leads to incompatibility and new problems. > > 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&… > > where I > a) submitted a bug report > b) included a video demonstrating the bug > c) included a patch fixing the bug > Yes, and I only understood the problem last week. Because I use a mouse, and it works with a mouse with right-click... it even works when your track-pad is configured with right click. It only does not work if not. > responses were > - "not a showstopper -> move it to 1.4" > - "for me the bug entry is not really relevant" > Then complain! There are 450 open reports in the database... we closed nearly 5000 issues. There will be mistakes. The thing is that we could have not released 1.3 until we fixed all bugs.... then we would never have released it. So we go through all reports and decide: what needs to be really really fixed? Yes, we make mistakes. I do not know how to not do mistakes, sorry. > seven months later it finally made its way in. > Because *I* pushed. Ben is using a mouse, so he just did not see the problem. In general, there are just not enough people to look at bugs... if nobody helps, it takes a looong time. > I can see saying, "move it to 1.4" if 1.4 is right around the corner. We could have blocked the release of 1.3 and then we would have not released 1.3 until now. (keep in mind there are 450 other open issues besides the one you are talking about). > > 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." 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. 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. Sometimes I think we should just stop and do something else. This is clearly not working. Marcus -- Marcus Denker -- http://marcusdenker.de

3 2