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

Re: [Pharo-project] Omnibrowser in 1.4

by Lukas Renggli

>> I do not know. I will continue to use OB. > > Lukas, if you get a version working in 1.4, will you let me know/release it? It took several man-weeks to get everything running in Pharo 1.3 and there are still quite a few of issues left. Next on my list is to stabilize everything and to get some productive/fun things done. There is no plan in moving things (RB, OB, eCompletion, ...) to Pharo 1.4 in the foreseeable future: All the groundbreaking changes to the system (RPackage, System Announcements, Ring, Opal, RB, ...) will require a lot of work and will likely also introduce new issues (@stef: this is not a complaint, I just don't have the time to keep up with it). Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Alexandre Bergel

Since there is ob, I personally use Nautilus. It provides interesting functionalities such as grouping packages and the hierarchies view (such as in vw). Importing things are missing however, including refactorings. Alexandre Le 29 aoÃ»t 2011 Ã 07:28, "Sean P. DeNigris" <sean(a)clipperadams.com> a Ã©crit : > > Lukas Renggli wrote: >> >> I do not know. I will continue to use OB. >> > > Lukas, if you get a version working in 1.4, will you let me know/release it? > > Sean > > -- > View this message in context: http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3775979.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Sean P. DeNigris

Lukas Renggli wrote: > > I do not know. I will continue to use OB. > Lukas, if you get a version working in 1.4, will you let me know/release it? Sean -- View this message in context: http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3775979.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] [squeak-dev] Re: Halt

by Bert Freudenberg

On 29.08.2011, at 18:14, DeNigris Sean wrote: > 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... It's useful for testing an intermediate result, without having to declare another temp. E.g.: ^ foo bar + fum becomes ^ (foo bar haltIf: [:x | x > 42]) + fum - Bert -

Aug. 29, 2011

Re: [Pharo-project] Halt

by StÃ©phane Ducasse

On Aug 29, 2011, at 1:19 PM, Sean P. DeNigris wrote: > > StÃ©phane Ducasse wrote: >> >> and we could keep all the Object method in a extension of the halt >> packages and just some of them as forward to Halt. >> > > Why don't we just remove all halt methods from Object? What does it buy you > to say "self halt" instead of "Halt now", but we gain less code and tests to > maintain. do not afraid users :) > > Sean > > -- > View this message in context: http://forum.world.st/Halt-tp3774723p3775964.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 29, 2011

Re: [Pharo-project] Halt

by StÃ©phane Ducasse

On Aug 29, 2011, at 12:56 PM, Lukas Renggli wrote: > On 29 August 2011 09:29, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> and we could keep all the Object method in a extension of the halt packages and just some of them as forward to Halt. >> >> I know that there was an attempt on the inbox to do that. But I was worried that people will complain. >> Now cleaning Object would be nice. > > Backward compatibility is good, but in this very case I would argue > against it. Code that has "self halt*" in it (and that is quite a > bit), is broken by definition. > >> why not >> Halt ifTrue: [a = 2]. > > The condition is in the argument, not the receiver. What you suggest > would be very confusing change to Boolean>>ifTrue: aBlock, I suspect > :-) Yes I was getting out my bed and still sleeping. :) > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 29, 2011

Re: [Pharo-project] Halt

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > and we could keep all the Object method in a extension of the halt > packages and just some of them as forward to Halt. > Why don't we just remove all halt methods from Object? What does it buy you to say "self halt" instead of "Halt now", but we gain less code and tests to maintain. Sean -- View this message in context: http://forum.world.st/Halt-tp3774723p3775964.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Lukas Renggli

>> 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. > > What are the advantages compared to OB? I do not know. I will continue to use OB. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 29, 2011

Re: [Pharo-project] Halt

by Lukas Renggli

On 29 August 2011 09:29, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > and we could keep all the Object method in a extension of the halt packages and just some of them as forward to Halt. > > I know that there was an attempt on the inbox to do that. But I was worried that people will complain. > Now cleaning Object would be nice. Backward compatibility is good, but in this very case I would argue against it. Code that has "self halt*" in it (and that is quite a bit), is broken by definition. > why not > Halt ifTrue: [a = 2]. The condition is in the argument, not the receiver. What you suggest would be very confusing change to Boolean>>ifTrue: aBlock, I suspect :-) Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 29, 2011

Re: [Pharo-project] [ANN] glamorous inspector

by Tudor Girba

Hi, I forgot to mention that a CompiledMethod offers a view with the bytecode. Just to give you an idea of what it takes to extend the inspector, here is the implementation needed for adding the bytecode view to a CompiledMethod object: CompiledMethod>>gtInspectorBytecodeIn: composite <gtInspectorPresentationOrder: 40> composite text title: 'Bytecode'; display: [:anObject | anObject symbolic ] Cheers, Doru On 29 Aug 2011, at 09:19, StÃ©phane Ducasse wrote: > getting really sexy. > > On Aug 29, 2011, at 12:06 AM, Tudor Girba wrote: > >> Hi, >> >> There are a couple of improvements related to the GT Inspector: >> >> - A morph has a dedicated submorphs tab with which we can inspect the tree of morphs (see attached picture) >> - A parse tree has a dedicated view that provides a tree of RB nodes and previews the information as a selection on the method source code (see the attached picture) >> - On the top right there is a refresh button to update the inspector (it does not happen automatically) >> - Damien Cassou fixed the "do it" support in the evaluator so now you can use the default keys as in the workspace >> - Some more relevant menu items for manipulation >> >> Cheers, >> Doru >> >> >> <gti13.png> >> <gti14.png> >> >> >> On 24 Aug 2011, at 11:12, Tudor Girba wrote: >> >>> The GT Inspector is now available by default in the Moose image (CMD+Shift+i). >>> >>> It seems to work quite well. >>> >>> Cheers, >>> Doru >>> >>> >>> On 22 Aug 2011, at 22:59, StÃ©phane Ducasse wrote: >>> >>>> Thanks doru :) >>>> >>>> Stef >>>> >>>> On Aug 22, 2011, at 7:59 PM, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> I am happy to announce the first release of the Glamorous Inspector, a new browser for inspecting objects based on Glamour. >>>>> >>>>> More information, including a demo and screenshots, can be found here: >>>>> http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk >>>>> >>>>> To download it follow the instructions from: >>>>> http://www.moosetechnology.org/tools/glamoroustoolkit >>>>> >>>>> You can use it by: >>>>> 1. "GTInspector openOn: someObject", or >>>>> 2. "GTInspector registerToolsOn: Smalltalk tools" and then use CMD+I (explore) >>>>> >>>>> Please let your opinion be heard :) >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> p.s. Have fun at ESUG :) >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every successful trip needs a suitable vehicle." >>>>> >>>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "In a world where everything is moving ever faster, >>> one might have better chances to win by moving slower." >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Some battles are better lost than fought." >> >> >> > > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Aug. 29, 2011