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

Re: [Pharo-project] Halt

by Alexandre Bergel

cool! Alexandre On 29 Aug 2011, at 14:30, Sean P. DeNigris wrote: > Thanks to Stephan Eggermont who paired with me all morning on this. > > Here are the results of the first pass in inbox > (SLICE-Issue-2394-Halt-SeanDeNigris.1): > > Object > * 16 methods deprecated > * 5 halt methods that now forward to Halt > > Globals - can remove #HaltOnce and #HaltCount (I don't know how) > > Halt class > * methods (all heavily refactored from the original Object implementation) > - 5 for halting API > - 3 to enable/disable haltOnce > - 6 private helpers > * 2 class instance variables (for haltOnce/onCount) > > World menu - updated to use Halt API > > Tests > * 6 new assertions in 2 test methods > * 4 test helpers for halt behavior > * changed other halt tests to use the helpers > > Questions remaining: > * countOn: (which I left it in for the time being) > - safety & scope (see earlier in thread) > - method name > > -- > View this message in context: http://forum.world.st/Halt-tp3774723p3776819.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 29, 2011

Re: [Pharo-project] Halt

by Sean P. DeNigris

Thanks to Stephan Eggermont who paired with me all morning on this. Here are the results of the first pass in inbox (SLICE-Issue-2394-Halt-SeanDeNigris.1): Object * 16 methods deprecated * 5 halt methods that now forward to Halt Globals - can remove #HaltOnce and #HaltCount (I don't know how) Halt class * methods (all heavily refactored from the original Object implementation) - 5 for halting API - 3 to enable/disable haltOnce - 6 private helpers * 2 class instance variables (for haltOnce/onCount) World menu - updated to use Halt API Tests * 6 new assertions in 2 test methods * 4 test helpers for halt behavior * changed other halt tests to use the helpers Questions remaining: * countOn: (which I left it in for the time being) - safety & scope (see earlier in thread) - method name -- View this message in context: http://forum.world.st/Halt-tp3774723p3776819.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] Pharo 1.4

by Alexandre Bergel

RoelTyper is probably what should be interfaced with the automatic completion. Other approaches are expensive. Alexandre On 28 Aug 2011, at 19:04, Frank Shearar wrote: > On 28 August 2011 21:18, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Damien Cassou wrote: >>> >>> >> >> Cool! That would make a big difference. Where are they/what are they called? > > I know of Roel Wuyts' RoelTyper > (http://decomp.ulb.ac.be/roelwuyts/smalltalk/roeltyper/) and Lex > Spoon's Chuck (http://www.lexspoon.org/ti/) Matt Might has also > written about k-CFA (Control Flow Analysis) for inferring types in a > dynamic language (Scheme, in particular) - > http://matt.might.net/articles/implementation-of-kcfa-and-0cfa/ - > which we might be able to apply to Smalltalk. > > frank > >> Sean >> >> -- >> View this message in context: http://forum.world.st/Pharo-1-4-tp3759684p3774973.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Marcus Denker

On Aug 29, 2011, at 6:35 PM, Lukas Renggli wrote: >>> Nautilus looks to me like yet another Smalltalk-80 browser that works >>> exactly the same as all previous Smalltalk browsers in the last 32 >>> years (including OB). IMHO fixed lists, a text field and ugly buttons >>> do not cut it anymore. Did any Smalltalker ever work with XCode, >>> Eclipse, VisualStudio, ...? >> >> Have a "basic" browser so that we can get rid of StringHolder. > > You could push down all the code of StringHolder into the subclass(es) > and remove the empty class. This can be done with RB with a few > clicks. > >> No more for me. > > Introducing more code into Pharo that depends on more parts of Pharo > (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it > easier to maintain and change Pharo. Or did I misunderstand something > about cohesion and coupling? :-) > With that philosophy, we can just declare Pharo as finished and do something else. My point of view is that I invent new abstractions *and than use them* on and for the system itself. Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Damien Cassou

On Mon, Aug 29, 2011 at 6:35 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Or did I misunderstand something > about cohesion and coupling? :-) you certainly got a bad teacher ;-) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Lukas Renggli

>> Nautilus looks to me like yet another Smalltalk-80 browser that works >> exactly the same as all previous Smalltalk browsers in the last 32 >> years (including OB). IMHO fixed lists, a text field and ugly buttons >> do not cut it anymore. Did any Smalltalker ever work with XCode, >> Eclipse, VisualStudio, ...? > > Have a "basic" browser so that we can get rid of StringHolder. You could push down all the code of StringHolder into the subclass(es) and remove the empty class. This can be done with RB with a few clicks. > No more for me. Introducing more code into Pharo that depends on more parts of Pharo (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it easier to maintain and change Pharo. Or did I misunderstand something about cohesion and coupling? :-) Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 29, 2011

Re: [Pharo-project] Halt

by Lukas Renggli

> * Halt onCount: - this is a weird one I would remove it. I have never seen anybody using it. > * Is anybody using Object>>toggleHaltOnce? I'm toying with removing it as > there are no senders in the image, and there are accessors and a testing > method That was probably there to call it from a menu. Seems to be useless, IMHO. Also make sure to remove all the global state that is added to SystemDictionary, this can easily be put into a class variable of Halt. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 29, 2011

Re: [Pharo-project] Halt

by Damien Cassou

On Mon, Aug 29, 2011 at 5:44 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > * Is anybody using Object>>toggleHaltOnce? I'm toying with removing it as > there are no senders in the image, and there are accessors and a testing > method I guess there are no senders because a developer calls this method from a workspace. As I understand it, it works that way: 1- you find an erroneous behavior 2- you put a "self halt" here and you notice that you have to close a thousand debuggers as a result 3- you change your "self halt" to "self haltOnce" to be sure only one debugger is going to pop up 4- you #toggleHaltOnce manually from a workspace and run your application 5- one debugger pops up and it automatically #toggleHaltOnce so that no other debugger will appear -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 29, 2011

Re: [Pharo-project] Halt

by DeNigris Sean

What is the purpose of #haltIf: aBlock? Right now, you can pass any of the following to Object>>haltIf: - aBlock taking an optional argument which is automatically set to the receiver of #halt - aSelector which looks up the call chain and halts if present - aBoolean So, whatever the condition is, it seems like you should be able to evaluate it in the calling context. When would you ever need to use a block? Can we eliminate the block behavior? Or, who has a great war story about blocks saving them from imminent doom... Thx. Sean

Aug. 29, 2011

Re: [Pharo-project] Halt

by Sean P. DeNigris

Sean P. DeNigris wrote: > > Here are a few points and questions... > Forgot one thing. #haltOnCount: currently depends on whether haltOnce is enabled. In my world, the purpose of haltOnce is so that you can put a halt down deep in the system where otherwise it may fire over and over (e.g. in the World loop). Since haltOnCount: is called once by definition, I want to remove the haltOnce-enabled check. Does that make sense/sound right? S -- View this message in context: http://forum.world.st/Halt-tp3774723p3776556.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011