- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Font & Theming of GT 'composite rubricText' is weird

by Sven Van Caekenberghe

Great, even before I had a chance to make it into an issue - thanks ! On 06 Oct 2014, at 21:41, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Fixed in the latest Moose version. > > > Cheers, > Andrei > > On Mon, Oct 6, 2014 at 4:42 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Indeed. This looks like a bug. Could you open an issue? > > Doru > > On Mon, Oct 6, 2014 at 4:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > The font and theme rendering of GT 'composite rubricText' (like when inspecting Strings) is a bit off, IMHO: > > <Screen Shot 2014-10-06 at 16.30.35.png> > > The font is different, does not appear in the settings and is not influenced by the theme. > > Sven > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 6, 2014

Re: [Pharo-dev] Font & Theming of GT 'composite rubricText' is weird

by Andrei Chis

Fixed in the latest Moose version. Cheers, Andrei On Mon, Oct 6, 2014 at 4:42 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Indeed. This looks like a bug. Could you open an issue? > > Doru > > On Mon, Oct 6, 2014 at 4:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> The font and theme rendering of GT 'composite rubricText' (like when >> inspecting Strings) is a bit off, IMHO: >> >> >> The font is different, does not appear in the settings and is not >> influenced by the theme. >> >> Sven >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 6, 2014

Re: [Pharo-dev] [ANN] flow: a living full-stack #âframework for the web

by Alain Rastoul

This development stack sounds really nice! A really great idea. Some thoughts (more or less en vrac, apologizes): As it is aimed at people who want a working app/demo solution out of the box, and if you intent is to push this stack further, perhaps it should have a more dedicated site than github with links to: - the setup part (more or less your github pages?) - a zipped tarball with everything working out of the box with up to date versions of mongo, nginx, the Pharo image , and all parts needed : a tarball for windows, one for linux, one for mac - a sample application and the tutorial how to build it (Sven's is right) I have no clue about angularjs? - I know I have to learn javascript, made some trials but don't like it much - does it replace or complete seaside (don't think so , but not sure) ? , how does it play with jquery and others ? - a part about mongo. I like mongo, even if I work with relational systems every day. I don't like orms and Mapless sounds great (but as I discovered it this morning on your site I have to spend some time on it). Really great idea indeed - I will make a try. Regards, Alain Le 05/10/2014 23:04, Sebastian Sastre a Ã©crit : > Hi guys, > > Iâm sharing slides of my presentation at CampSmalltalkVI2014 > http://www.slideshare.net/sebastianconcept/flow-39897704 > > > From flowâs readme at github <https://github.com/flow-stack/flow>: > > Flow's mission is to provide /consultants/, /startups/ and /software > houses/ with *a competitive Smalltalk full-stack framework* that allows > them to quickly deliver a demo with all the modern html5 features the > market expects today (2014). The idea is that they can tactically use > this framework to keep momentum up among their prospects and clients and > scale things to full successful projects delivered by kickass productive > teams or individuals. > > sebastian <https://about.me/sebastianconcept> > > o/ > > blog: http://sebastianconcept.com <http://sebastianconcept.com/> > LinkedIn: http://www.linkedin.com/in/sebastiansastre > github: https://github.com/sebastianconcept > > > > >

Oct. 6, 2014