October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GT-Inspectors need live updating

by Tudor Girba

Hi, I want that, too. But, the problem is that having it generically for any presentation is not working safely. Some presentations can be heavy on computations, and having them refresh on the #step can be way too heavy. One solution would be to refresh presentations selectively, but that is not so nice. Or we have to find a smarter way. Doru On Mon, Oct 6, 2014 at 11:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I meant *without* an extra process, of course. > > It seems to be in EyeInspector>>#step -> EyeInspector>>#refresh. > > BTW, it ***really, really*** is needed for live object demos, no way > around it. > > On 06 Oct 2014, at 23:18, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > Indeed. Not having live update by default was a conscious decision > because we did not find a solution that scales properly both for several > inspectors and for heavy computations of presentations. It would be great > if someone could propose a way to go. > > > > Cheers, > > Doru > > > > > > > > On Mon, Oct 6, 2014 at 11:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > It seems that currently there is no automatic live updating for > GT-Inspectors. > > > > That has to be fixed since we had that in both the old and in the eye > inspectors. > > > > I remember Stef did something to do this with an extra process. > > > > Sven > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by Sven Van Caekenberghe

I meant *without* an extra process, of course. It seems to be in EyeInspector>>#step -> EyeInspector>>#refresh. BTW, it ***really, really*** is needed for live object demos, no way around it. On 06 Oct 2014, at 23:18, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Indeed. Not having live update by default was a conscious decision because we did not find a solution that scales properly both for several inspectors and for heavy computations of presentations. It would be great if someone could propose a way to go. > > Cheers, > Doru > > > > On Mon, Oct 6, 2014 at 11:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > It seems that currently there is no automatic live updating for GT-Inspectors. > > That has to be fixed since we had that in both the old and in the eye inspectors. > > I remember Stef did something to do this with an extra process. > > Sven > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by Tudor Girba

Hi, Indeed. Not having live update by default was a conscious decision because we did not find a solution that scales properly both for several inspectors and for heavy computations of presentations. It would be great if someone could propose a way to go. Cheers, Doru On Mon, Oct 6, 2014 at 11:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > It seems that currently there is no automatic live updating for > GT-Inspectors. > > That has to be fixed since we had that in both the old and in the eye > inspectors. > > I remember Stef did something to do this with an extra process. > > Sven > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by Sven Van Caekenberghe

On 06 Oct 2014, at 23:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > It seems that currently there is no automatic live updating for GT-Inspectors. > > That has to be fixed since we had that in both the old and in the eye inspectors. > > I remember Stef did something to do this with an extra process. > > Sven I meant to say *without* an extra process ;-)

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspector presentations for Core Zn objects

by Tudor Girba

Hi, On Mon, Oct 6, 2014 at 11:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 06 Oct 2014, at 20:21, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > It seems you got the hang of it :). > > Yeah, I also see that much more is possible, but my UI skills are limited. > > > Still my question: are you developing these extension from within the > inspector? > > I can see going to the Meta tab and modifying a gtInspector method in > place, but how/where would I then see a live preview ? I guess I miss > something ... > If you save, the presentations get updated in place. Ideally, we should have a faster feedback, but that is what is available at the moment. > That being said, developing all these presentations was quite fun with > several playgrounds open. > :) Doru > > > Cheers, > > Doru > > > > On Mon, Oct 6, 2014 at 4:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.65 > > Author: SvenVanCaekenberghe > > Time: 6 October 2014, 4:20:04.98872 pm > > UUID: 3f4e93c1-eed7-4769-81c1-9c2ac6c48702 > > Ancestors: GT-InspectorExtensions-Core-SvenVanCaekenberghe.64 > > > > Added multiple presentations for all Core Zinc HTTP Components objects > > > > Sven > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 6, 2014

GT-Inspectors need live updating

by Sven Van Caekenberghe

It seems that currently there is no automatic live updating for GT-Inspectors. That has to be fixed since we had that in both the old and in the eye inspectors. I remember Stef did something to do this with an extra process. Sven

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspector presentations for Core Zn objects

by Sven Van Caekenberghe

On 06 Oct 2014, at 20:21, Tudor Girba <tudor(a)tudorgirba.com> wrote: > It seems you got the hang of it :). Yeah, I also see that much more is possible, but my UI skills are limited. > Still my question: are you developing these extension from within the inspector? I can see going to the Meta tab and modifying a gtInspector method in place, but how/where would I then see a live preview ? I guess I miss something ... That being said, developing all these presentations was quite fun with several playgrounds open. > Cheers, > Doru > > On Mon, Oct 6, 2014 at 4:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.65 > Author: SvenVanCaekenberghe > Time: 6 October 2014, 4:20:04.98872 pm > UUID: 3f4e93c1-eed7-4769-81c1-9c2ac6c48702 > Ancestors: GT-InspectorExtensions-Core-SvenVanCaekenberghe.64 > > Added multiple presentations for all Core Zinc HTTP Components objects > > Sven > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] Patch GTInspector>>#printObjectAsAnItem:

by Sven Van Caekenberghe

Well, writing code is the only way to make something happen, right ;-) On 06 Oct 2014, at 20:20, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Nice. You beat me to it :) > > Doru > > On Mon, Oct 6, 2014 at 4:28 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > === > Name: GT-Inspector-SvenVanCaekenberghe.243 > Author: SvenVanCaekenberghe > Time: 6 October 2014, 4:26:27.106938 pm > UUID: c415dc4f-5808-4b0f-99ab-bef45287e5c8 > Ancestors: GT-Inspector-AndreiChis.242 > > Patch GTInspector>>#printObjectAsAnItem: to no longer add a class name when it is already present > === > > I don't think this can be done in Object>>#gtDisplayOn: because of the stream involved. > > In any case, things look *way* better now ;-) > > Sven > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Jan Vrany

OK. I think enough has been said. No need to waste more time on it. I closed the issue. Thanks Nicolai for making the slice for me! Best, Jan On Sat, 2014-10-04 at 21:14 +0100, Jan Vrany wrote: > Hi guys, > > I've just opened: > > https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-met… > > Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to > SmalltalkImage to ease multi-dialect development. > > RATIONALE: > > Commonly used approach to solve differences among dialect is to use a > sort of platform object and dispatch there for troublesome operations > that has to be specialized. This platform object is usually in platform > specific package. > Other option is to load some library like Grease or Sport. > > The problem of the first approach is that brings to much (unnecessary) > burden when used for two, three things. The amount of of the code and > management is way to bigger then the amount of the code that has to be > specialized. Loading Grease/Sport on the other hand introduces a > dependency on an external package - not worth of for two or three > things. > > The proposed dialect testing messages would allow for simple, > #ifdef-like idiom like: > > | stream | > ... > ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk > isSomeCoolDialect]) ifTrue:[ > stream := CharacterWriteStream on: (String new: 10) > ] ifFalse:[ > stream := WriteStream on: (String new: 10) > ] > > The #respondsTo: check, while not nice, is required as at the moment not > all dialects could be trusted to have these testing messages. > > Putting these methods may not stick with Pharo standard (whatever it > is), but Smalltalk global is probably one of the > very few that are present in pretty much every Smalltalk implementation. > Other option would be to place them to the class side of an Object > (which is amost certainly present everywhere), however > > Smalltalk isPharo > > reads better than > > Object isPharo. > > Best, Jan > >

Oct. 6, 2014

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Jan Vrany

On Sun, 2014-10-05 at 19:08 -0700, Paul DeBruicker wrote: > Would using Metacello's knowledge of the platform work for you? e.g. > > > (MetacelloPlatform current defaultPlatformAttributes includes: '#squeak') > ifTrue:[ ... ] > (MetacelloPlatform current defaultPlatformAttributes includes: '#pharo1.2') > ..... > (MetacelloPlatform current defaultPlatformAttributes includes: > '#gemstone2.4') ..... Actually not. Dependency on Metacello is not what I want. Metacello is is not maintained on GST or VAST, after all. > > Or are you trying to get very very cross platform (e.g. GST, VAST, etc...) ? Yes. Just to make myself clear, I did not proposed this to solve some problem I'm facing now. It's just that this very simple idiom has proved itself over years, and almost certainly cannot break anything, so I decided to contribute. Jan > > > > Jan Vrany wrote > > On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote: > >> Itâs true that when you do a lot of cross-dialect development, such a > >> method is often what you desire. > >> However, I think itâs better to do feature detection instead of dialect > >> detection. So, something like: > >> > >> ((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ > >> stream := CharacterWriteStream on: (String new: 10) > >> ] ifFalse:[ > >> stream := WriteStream on: (String new: 10) > >> ] > >> > > > > Right, in this example it could eventually work. Another concrete > > example I bumped just yesterday. The "feature testing" code would look > > like > > > > ((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval]) > > ifTrue:[ > > ... > > ] ifFalse:[ > > ... > > ]. > > > > (true, in this very case you may be able to get around using different > > method, but you get the point, no?) > > > > Some time ago Hilaire posted a very nice, 15 lines long code that does > > reliable "feature detection" whether the system is Pharo 2.0 or 3.0 > > (or similar, I don't remember exactly). > > > > Is the interval testing code above more robust? Perhaps. Is it more > > readable, more intention revelaling? I doubt it. > > > > While I can agree that feature testing is is better, however, in my > > experience it is very tricky if the code does not provide support for > > such tests. > > > >> And yes: use Grease where applicable. We try to maintain Grease across > >> Pharo, Squeak and Gemstone. I also think itâs actively ported to VA. > >> > > That's great. But having such dependency is exactly what I, and not only > > me, don't want if it would be for only one or two methods. The aim is to > > provide a simple solution for simple cases, not a silver bullet. > > > > Jan > > > > > >> cheers > >> Johan > >> > >> On 05 Oct 2014, at 09:00, stepharo < > > > stepharo@ > > > > wrote: > >> > >> > Hi jan > >> > > >> > Thanks for the proposal. > >> > I thought about it and I'm against because it goes again the idea of > >> dispatch. > >> > I prefer to have a class and some dispatch. Seaside with Grease is the > >> way to go from my perspective. > >> > Finally I do not want such methods in the systems because I spent my > >> time removing isXXXX because of bad design. > >> > Let us see what other people think. > >> > > >> > Stef > >> > > >> > On 4/10/14 22:14, Jan Vrany wrote: > >> >> Hi guys, > >> >> > >> >> I've just opened: > >> >> > >> >> > >> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-met… > >> >> > >> >> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods > >> to > >> >> SmalltalkImage to ease multi-dialect development. > >> >> > >> >> RATIONALE: > >> >> > >> >> Commonly used approach to solve differences among dialect is to use a > >> >> sort of platform object and dispatch there for troublesome operations > >> >> that has to be specialized. This platform object is usually in > >> platform > >> >> specific package. > >> >> Other option is to load some library like Grease or Sport. > >> >> > >> >> The problem of the first approach is that brings to much (unnecessary) > >> >> burden when used for two, three things. The amount of of the code and > >> >> management is way to bigger then the amount of the code that has to be > >> >> specialized. Loading Grease/Sport on the other hand introduces a > >> >> dependency on an external package - not worth of for two or three > >> >> things. > >> >> > >> >> The proposed dialect testing messages would allow for simple, > >> >> #ifdef-like idiom like: > >> >> > >> >> | stream | > >> >> ... > >> >> ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk > >> >> isSomeCoolDialect]) ifTrue:[ > >> >> stream := CharacterWriteStream on: (String new: 10) > >> >> ] ifFalse:[ > >> >> stream := WriteStream on: (String new: 10) > >> >> ] > >> >> > >> >> The #respondsTo: check, while not nice, is required as at the moment > >> not > >> >> all dialects could be trusted to have these testing messages. > >> >> > >> >> Putting these methods may not stick with Pharo standard (whatever it > >> >> is), but Smalltalk global is probably one of the > >> >> very few that are present in pretty much every Smalltalk > >> implementation. > >> >> Other option would be to place them to the class side of an Object > >> >> (which is amost certainly present everywhere), however > >> >> > >> >> Smalltalk isPharo > >> >> > >> >> reads better than > >> >> > >> >> Object isPharo. > >> >> > >> >> Best, Jan > >> >> > >> >> > >> >> > >> > > >> > > >> > >> > >> > > > > > > -- > View this message in context: http://forum.world.st/Issue-14160-Introduce-isXXX-dialect-testing-methods-t… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Oct. 6, 2014