February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Automatic One-Click VM

by Torsten Bergmann

see also http://code.google.com/p/pharo/issues/detail?id=3484 -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

Feb. 1, 2011

Re: [Pharo-project] Issue 3645 in pharo: Update Hudson One-Click build files for 1.2

by pharo＠googlecode.com

Comment #1 on issue 3645 by Torsten....(a)astares.de: Update Hudson One-Click build files for 1.2 http://code.google.com/p/pharo/issues/detail?id=3645 see also http://code.google.com/p/pharo/issues/detail?id=3484

Feb. 1, 2011

Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo

by Igor Stasenko

On 1 February 2011 08:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 1, 2011, at 7:04 AM, StÃ©phane Ducasse wrote: > >> Nicolas >> >> We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the >> diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is >> years that we passed it. >> >>> Maybe it's because the process only have appearances of quality, but >>> doesn't really pay off. >> >> Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life. >> Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server >> is subject to missing some parts. But this is life. > > > Another aspect: Every 100% regid requirement kills a process. We tried that in Squeak in the past. E.g. at one point, people > said we should *require* tests and a code review before adding a fix. Result: complete standstill. Yes, these things are *nice* > and they should be done more often, but as soon as you require them, nothing will happen. > > The same with deprecation: Yes, we want to provide deprecation for one release for easy migration. But this in turn can not > be a law. There is so much cruft and so little structure (API vs. internal methods undefined), that one can not move if a strict > rule is adopted. > > Strict rules kills human processes. > +1 Strict rules work mostly for pedantic people.. Not many of us having this trait. And for impulsive people like me, who is "chaotic pedant" its not always good, because boring stuff drains my energy quite fast :) We are not perfect and so, we should embrace that :) > Â Â Â Â Marcus > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 1, 2011

Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo

by Igor Stasenko

On 1 February 2011 08:01, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/2/1 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>> Maybe I had some bad luck with >>> http://code.google.com/p/pharo/issues/detail?id=3468 >>> Or is there many examples of issues closed without a clue ? >> >> In a case like that, the changeset was just merged in the release. >> >> The test is failing, as you can see: >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… >> >> > > This is probably because you must > Â Â (Object recompile: #perform:withArguments:) there is no way to fix that without altering VM itself. This test actually shows that there is issue on VM side which needs to be adressed (but in Cog it works ok). > > Nicolas > >> >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 1, 2011

Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo

by Igor Stasenko

On 1 February 2011 01:47, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > The fact is that, while many patches find their way from Squeak to > Pharo, very few take the other way. > Frankly, i had the opposite impression. For instance, Sets with nil already have more than year in Squeak, but still didn't found their way into Pharo. > Why is that ? > - squeak people are sobing pharoers > - squeak people are too few to achieve this task > - there is nothing interesting happening in Pharo > No no, please don't answer, I innoculate this bullshit intentionnally > to vaccine this thread against further crap. > > What IMO is the main explanation is this: > - it's very easy to cherry pick squeak changes thanks to trunk: diff > messages, while there is nothing equivalent in Pharo. > > Just browsing Squeak/Pharo diffs, it's easy to recognize text > copy/pasted via web with tabs changed in spaces. > Also the pharo issue tracker is full of these. > This gives some clues. > > This is a very good thing that patches can be shared. But why not the > other way around ? > This is surprising because: > - 1) Pharo is very active these days. > - 2) Pharo was apparently setting a higher quality hurdle by forcing > each modification to be traced > Â Â Â ( http://code.google.com/p/pharo/issues ) > So we could have expected more fixes coming from Pharo. > > Maybe it's because the process only have appearances of quality, but > doesn't really pay off. > Maybe I had some bad luck with > http://code.google.com/p/pharo/issues/detail?id=3468 i was proposed this fix for squeak and pharo both, months before, because NativeBoost were dependent on that to work correctly, because it was heavily exploiting #perform: primitive for retrying the same method after first invocation when there was no native code generated yet, and primitive failed because of that. But i weren't able to force it to be made into both forks.. because certainly i was busy with other stuff, so instead of pushing fix to both forks, i just made a changeset and put it into NB site. In that way i made sure, that no matter if fix is integrated or not, NB works :) > Or is there many examples of issues closed without a clue ? > Imagine you can recognize the symptoms of this bug in Pharo 1.1 and > want to backport the patch... > I'm interested to hear how to proceed. > > The simple squeak trunk diff messages are not a panacea. > A database of changes in all flavours of Squeak might help better. > But it's very practicle and I wish I could see an equivalent in Pharo. > I think an upcoming Ring (yeah , to rule them all) or Torch? project will help addressing this issue. But i can't shed light details on it, because i don't know.. > On the other end, I was finally forced to filter out the automated > [Pharo-Issues] posts. > The signal/noise ratio is far too low to sustain attention, though I > for one care about patches. > > I wish my criticism could bring introspection, better and - why not - > squeak friendly :) practices. > I am one, who would certainly be happy too, to see a interchange between Pharo and Squeak to be easy. I can only say, that this is because two camps using different development process.. and not because of some intentionally political attitude. Nicolas, i encourage you (and others) to come up with initiative, to establish a process , or write down rules/guidelines, how to cherrypick the code between forks. This would help to both camps, so its worth to do. > Nicolas > > -- Best regards, Igor Stasenko AKA sig.

Feb. 1, 2011

Re: [Pharo-project] Sound package fixes

by Igor Stasenko

i hope that time which Stephane spent yesterday on merging changes from squeak will not be put in vane... On 1 February 2011 12:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Jan 31, 2011, at 6:18 23PM, StÃ©phane Ducasse wrote: > >> Hi >> >> we merged all the squeak fixes to Sound and published them in >> Â Â Â PharoNonCorePackages >> >> It will be loaded in 1.3 dev but you can load them if you want to try. >> >> Stef >> > Why? > http://www.squeaksource.com/PharoSound > > Cheers, > Henry > -- Best regards, Igor Stasenko AKA sig.

Feb. 1, 2011

[Pharo-project] Issue 3645 in pharo: Update Hudson One-Click build files for 1.2

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3645 by marcus.d...(a)gmail.com: Update Hudson One-Click build files for 1.2 http://code.google.com/p/pharo/issues/detail?id=3645 -> current VM Please list everything else...

Feb. 1, 2011

Re: [Pharo-project] Automatic One-Click VM

by Marcus Denker

On Feb 1, 2011, at 1:44 PM, Geert Claes wrote: > > Can we replace the Croquet VM exe file that is bundled in the one-click > images generated using Hudson with a with a Pharo branded one? Yes, the one-click needs a couple of iterations... 1) we need to update the VMs to the latest 2) we need to sync the one-click with the old ones. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 1, 2011

Re: [Pharo-project] react on low space

by Igor Stasenko

On 1 February 2011 14:11, Igor Stasenko <siguctua(a)gmail.com> wrote: > I think you can catch the OutOfMemory exception: > Oops. example was a bit wrong. something like that: [ | y x | y := x := Â Array new: 1000. Â 1000000 timesRepeat: [ x at: 1 put: (Array new: 10000). x := x at: 1 ] ] on: OutOfMemory do: [:ex | Â .... ] > > On 1 February 2011 12:00, Max Leske <maxleske(a)gmail.com> wrote: >> I'm bumping this message. I think it's an important question and could help >> other developers who might have the same problem one day. The low space >> watcher is cool but if you don't get the chance to actually look at the >> stack it's pretty useless. >> Max >> On 30.01.2011, at 13:10, Max Leske wrote: >> >> Hi guys >> Is there an easy way to react on low space? Something like: >> >> SmalltalkImage isSpaceLow >> ifTrue: [ <suspend my process> ] >> >> The reason I'm asking is that I have a background process running that >> causes a low space condition but I never get around to opening the debugger >> and the image crashes on me. So for debugging purposes I'd like to >> periodically check the space that is left or alternatively be notified if >> low space is signalled. >> Any ideas? >> Thanks, >> Max >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Feb. 1, 2011

Re: [Pharo-project] react on low space

by Igor Stasenko

I think you can catch the OutOfMemory exception: [ x := Array new: 1000. 1000000 timesRepeat: [ x at: 1 put: (Array new: 10000). x := x at: 1 ] ] on: OutOfMemory do: [:ex | .... ] On 1 February 2011 12:00, Max Leske <maxleske(a)gmail.com> wrote: > I'm bumping this message. I think it's an important question and could help > other developers who might have the same problem one day. The low space > watcher is cool but if you don't get the chance to actually look at the > stack it's pretty useless. > Max > On 30.01.2011, at 13:10, Max Leske wrote: > > Hi guys > Is there an easy way to react on low space? Something like: > > SmalltalkImage isSpaceLow > ifTrue: [ <suspend my process> ] > > The reason I'm asking is that I have a background process running that > causes a low space condition but I never get around to opening the debugger > and the image crashes on me. So for debugging purposes I'd like to > periodically check the space that is left or alternatively be notified if > low space is signalled. > Any ideas? > Thanks, > Max > -- Best regards, Igor Stasenko AKA sig.

Feb. 1, 2011