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

Re: [Pharo-project] Omnibrowser in 1.4

by Jan van de Sandt

I think Lukas means Nautilus. [1] http://www.squeaksource.com/Nautilus.html On Sun, Aug 28, 2011 at 8:46 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > 2011/8/28 Lukas Renggli <renggli(a)gmail.com>: > > There are currently no plans to make OB work in upcoming Pharo > > versions; Pharo 1.4 is supposed to have its own much better browser > > framework. > > > > Which framework? > >

Aug. 28, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by HernÃ¡n Morales Durand

2011/8/28 Lukas Renggli <renggli(a)gmail.com>: > There are currently no plans to make OB work in upcoming Pharo > versions; Pharo 1.4 is supposed to have its own much better browser > framework. > Which framework?

Aug. 28, 2011

Re: [Pharo-project] Halt

by Marcus Denker

On Aug 28, 2011, at 8:10 PM, Lukas Renggli wrote: > We have a class Halt and the class-side is empty. This seems to be the > right place to hold all the code in the protocols #debugging and > #debuggin-haltonce of Object. With a few renames we could get a really > nice DSL: > > Halt now. > Halt if: a = 2. > Halt once. > Nice! I want that. This would even allow for making the #haltIf: less overloaded and provide a explicit control flow based halt with something like this: Halt selector: #DoIt. or maybe better: Halt ifCalledFrom: #testMyWonderfulBuggyTest Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 28, 2011

Re: [Pharo-project] Halt

by Lukas Renggli

We have a class Halt and the class-side is empty. This seems to be the right place to hold all the code in the protocols #debugging and #debuggin-haltonce of Object. With a few renames we could get a really nice DSL: Halt now. Halt if: a = 2. Halt once. Lukas On 28 August 2011 19:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 28, 2011, at 7:24 PM, Sean P. DeNigris wrote: > >> >> 2. Using Object to halt causes bloat, and doesn't buy much (except that's >> how we've always done it). > > > Back in the days, we were virtually crucified for introducing the Beeper class along the > same reasoning... > > The Beeper actually got very depressed due to having his very existance being > questioned. > > "I am just the result of a random refactoring" he was complaining "maybe I should just > just delete myself and everyone will be happy". > > (you know, reflection *is* dangerous! There has been a lot of talk to make reflection more > secure... for a reason!). > > To cheer him up, I gave him the lead role in a real, peer reviewed Paper: > > Â Â Â Â http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf > > The Beeper thus was the first Class to be really "Meta" in the history of > Objects. What a thrill. In an interview, the Beeper said: "You know, being meta is hard > to decribe... Classes claim to be Meta all the time. But I doubt they ever really are Meta. Being > Meta is special. The whole System looks different when meta!" > > ;-) > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 28, 2011

Re: [Pharo-project] What does FixedWaitingToBePharoed mean?

by StÃ©phane Ducasse

This is a fix proposed for squeak and we should have a look because it should be probably adapted to pharo. On Aug 28, 2011, at 5:15 PM, Sean P. DeNigris wrote: > > > -- > View this message in context: http://forum.world.st/What-does-FixedWaitingToBePharoed-mean-tp3774520p3774… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 28, 2011

Re: [Pharo-project] PharoInbox broken?

by StÃ©phane Ducasse

Tx we will fix that :) Stef On Aug 28, 2011, at 5:09 PM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote: >> >> Fix in *new* inbox - Monticello-SeanDeNigris.532 :) >> > > The fix I uploaded is a start, but does not fix the problem i.e. the old > inbox still shows in the MC Browser > > -- > View this message in context: http://forum.world.st/PharoInbox-broken-tp3774478p3774508.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 28, 2011

Re: [Pharo-project] Halt

by Marcus Denker

On Aug 28, 2011, at 7:24 PM, Sean P. DeNigris wrote: > > 2. Using Object to halt causes bloat, and doesn't buy much (except that's > how we've always done it). Back in the days, we were virtually crucified for introducing the Beeper class along the same reasoning... The Beeper actually got very depressed due to having his very existance being questioned. "I am just the result of a random refactoring" he was complaining "maybe I should just just delete myself and everyone will be happy". (you know, reflection *is* dangerous! There has been a lot of talk to make reflection more secure... for a reason!). To cheer him up, I gave him the lead role in a real, peer reviewed Paper: http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf The Beeper thus was the first Class to be really "Meta" in the history of Objects. What a thrill. In an interview, the Beeper said: "You know, being meta is hard to decribe... Classes claim to be Meta all the time. But I doubt they ever really are Meta. Being Meta is special. The whole System looks different when meta!" ;-) -- Marcus Denker -- http://marcusdenker.de

Aug. 28, 2011

[Pharo-project] Halt

by Sean P. DeNigris

The halt code is a mess. There are several open issues and should be several more. Here's what I found today... 1. Object>>setHaltOnce and friends are misleading See http://code.google.com/p/pharo/issues/detail?id=2621 All the accessors for the global HaltOnce are on the instance side of Object, making it unclear whether haltOnce and especially haltOnCount: are per-object or global. I suggest they be moved to some object representing the system (like SmalltalkImage or a delegate - I know we're trying to clean SmalltalkImage). #haltOnce Smalltalk haltOnceEnabled "used to be self haltOnceEnabled" ifTrue: [Smalltalk clearHaltOnce. "used to be self clearHaltOnce" ^ self halt]. makes it obvious that this is a global property, not per-instance. The first requires a comment (as indicated by the pending issue), the second is documented by the code. 2. Using Object to halt causes bloat, and doesn't buy much (except that's how we've always done it). See http://code.google.com/p/pharo/issues/detail?id=2394 for a proposal to change from "self haltOnce" to Halt once. 3. Is anyone using the versions that take a string message (e.g. #haltOnce:). A halt brings you into a debugger, so is the extra info worth the added complexity? p.s. right now, the versions are cut-and-pastes of each other I've already started to clean all this up and write tests, but wanted to be clear what the right direction is. Cheers, Sean -- View this message in context: http://forum.world.st/Halt-tp3774723p3774723.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 28, 2011

[Pharo-project] What does FixedWaitingToBePharoed mean?

by Sean P. DeNigris

-- View this message in context: http://forum.world.st/What-does-FixedWaitingToBePharoed-mean-tp3774520p3774… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 28, 2011

Re: [Pharo-project] PharoInbox broken?

by Sean P. DeNigris

Sean P. DeNigris wrote: > > Fix in *new* inbox - Monticello-SeanDeNigris.532 :) > The fix I uploaded is a start, but does not fix the problem i.e. the old inbox still shows in the MC Browser -- View this message in context: http://forum.world.st/PharoInbox-broken-tp3774478p3774508.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 28, 2011