- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Halt

by Sean P. DeNigris

Okay, I'm mostly through the refactoring. It is sooo much cleaner out of object. Many deprecated methods!! Here are a few points and questions... * Under protest :) I'm keeping the Object API, which forwards to Halt. * I was slightly liberated to find that halt behavior is not part of the ANSI standard * Halt onCount: - this is a weird one - It's currently global. Should it be per call, possibly with a (resumable?) error if called elsewhere? In other words, if I put in a Halt countOn: 3, and there is another #countOn: in the image that gets called and decrements the global count, it seems that this will give me confusing and hard to track down results. I guess maybe we can't pinpoint it to the exact call, but at least to the calling context. - The name is misleading. I thought of a few (Halt onPassNumber: 3, Halt onIterationNumber: 3, Halt onCallNumber: 3). Any suggestions while we're breaking compatibility, lol? - is there a lint check that says haltOnCount: and maybe haltOnce? - per object/method/process/exact call? * 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 Sean -- View this message in context: http://forum.world.st/Halt-tp3774723p3776539.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] Headless image hanging

by Bernat Romagosa

Yeah, I also do have several images that have been running for months without crashing, that's what's bugging me :) This is an Iliad app, I'll check both how I overrode the session class and the VNC connection to see if I can get closer to where the problem comes from. Thanks! Bernat. 2011/8/29 Sven Van Caekenberghe <sven(a)beta9.be> > > On 23 Aug 2011, at 23:44, Bernat Romagosa wrote: > > > Any ideas? > > Many people, including myself, have various images running for many weeks > and even months, so it is possible. I am guessing that you are running some > Seaside (maybe Pier) with one of the standard HTTP servers ? Those should > not leave connections hanging open. Maybe the VNC stuff is the culprit ? > > I never use VNC, but the Seaside tools (Status | Config | Inspector | > Browser | Dispatcher | VersionUploader) to manage and debug running servers. > Just make sure you set them up with at least a password. Then you could try > to find out what is happening. > > Sven > > > -- Bernat Romagosa.

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by StÃ©phane Ducasse

+ 1000 now who has time. So nautilus is our attempt to make sure that we can still have a browser and remove string holder out of the image. Now the only person I see being real and making progress on the IDE front is doru with glamour. Now Nautilus is not in competition with OB or Glamour. It is the browser I want to use when I code in core. Stef > +1 > > On Mon, Aug 29, 2011 at 3:26 PM, Max Leske <maxleske(a)gmail.com> wrote: >> +1 >> >> On 29.08.2011, at 14:51, Torsten Bergmann wrote: >> >> Yes, there were times when other IDE's got their ideas from >> Smalltalk and I think now we should look at some ideas from >> mainstream IDE's. >> > > > > -- > Jorge Ressia > www.jorgeressia.com >

Aug. 29, 2011