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

Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Jan Vrany

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. 4, 2014

GT first impressions

by HernÃ¡n Morales Durand

Sorry if following issues were reported. I have seen so many mails about GT that I wanted to try it. These are my first notes and personal tastes, don't take them as negative just want to provide some feedback: - First weird thing: The Workspace doesn't open a Workspace anymore, it opens a Playground window. - When I select code, right click gives no "Copy, Cut, Delete" commands. - Selecting an instance variable from the "State" tab, completely shift the code view and scrolls to a new Inspector. Is not that I would love to scroll back everytime to get a view on my code. - I cannot find how to close new Inspector tabs. - "Print it" seems broken. It seems to print evaluation result but suddenly dissapears. - Debugger buttons Into, Through, etc. -- They are too small and close themselves for the importance they have. -- They have no caption, so you have to mouse over to know what they do (until you get used to) -- They are like "too distant" from the code view. Cheers, HernÃ¡n

Oct. 4, 2014

Re: [Pharo-dev] Seconds set of additions to GT-Inspector

by Tudor Girba

Great! Just a note: just in case you are not already doing it, you should try extending the inspector from within the Meta tab of the inspector. It's quite nice to see the preview live (given that self is bound). Cheers, Doru On Sat, Oct 4, 2014 at 8:48 PM, stepharo <stepharo(a)free.fr> wrote: > Neat > > Stef > > > On 4/10/14 20:41, Sven Van Caekenberghe wrote: > >> In Moose/GToolkit: >> >> === >> Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.58 >> Author: SvenVanCaekenberghe >> Time: 4 October 2014, 8:39:58.350356 pm >> UUID: 2d078975-c2ac-4fcf-af82-4dd3fc709016 >> Ancestors: GT-InspectorExtensions-Core-TudorGirba.57 >> >> Customized GT-Inspector for Time, Date, DateAndTime and Duration by >> adding a Details tab listing various chronology aspects >> === >> >> Sven >> >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 4, 2014

Re: [Pharo-dev] Presetting variables to Spec's TextModel.

by Nicolai Hess

This opens a text field where all "self ..." calls are evaluated for the morph object: |t| t:=TextModel new. t title:'evaluates for a morph'. t doItReceiver:(Morph new). t openWithSpec for example self openInWorld self color:Color red. will show the object and change the color. But yes, you can not set any variable binding. The workspace handles this on its own, there is no support for this in TextModel/TextAdapter 2014-10-04 21:20 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > I was looking at the Inspector and I saw the doItContext/doItReceiver but > it spans over several objects and I wasn't able to figure out how it > actually works / how to use it. (OpalCompiler was calling various methods > on the objects, so it was expecting some kind of structure). > > Could you give me an example? > > On Sat, Oct 4, 2014 at 9:15 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> Am 04.10.2014 17:09 schrieb "Peter UhnÃ¡k" <i.uhnak(a)gmail.com>: >> >> > >> > Hi, >> > >> > I'm trying to preset variables to TextModel but I'm not sure if/how can >> such thing be achieved. >> > >> > With Workspace (in pre-GT Pharo) I could do >> > >> > ws := Workspace openContents: 'a'. >> > b := Dictionary new. >> > b add: (WorkspaceVariable key: #a value: 42). >> > ws setBindings: b. >> > >> > Unfortunately Workspace isn't Spec's ComposableModel so I can't just >> reuse it. >> > Is something similar possible with TextModel? Perhaps somehow changing >> model to Workspace (without actually opening the workspace) or something? >> > >> > Inspector seems to do something like that but my investigation ended up >> in OpalCompiler which is way over my head. :( >> > >> > Thanks, >> > Peter >> >> I don't know how this works for variable binding, >> but you can set the doItReceiver: >> >> (that's how the inspector works) >> >> >> >

Oct. 4, 2014

Re: [Pharo-dev] Presetting variables to Spec's TextModel.

by Peter UhnÃ¡k

I was looking at the Inspector and I saw the doItContext/doItReceiver but it spans over several objects and I wasn't able to figure out how it actually works / how to use it. (OpalCompiler was calling various methods on the objects, so it was expecting some kind of structure). Could you give me an example? On Sat, Oct 4, 2014 at 9:15 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Am 04.10.2014 17:09 schrieb "Peter UhnÃ¡k" <i.uhnak(a)gmail.com>: > > > > > Hi, > > > > I'm trying to preset variables to TextModel but I'm not sure if/how can > such thing be achieved. > > > > With Workspace (in pre-GT Pharo) I could do > > > > ws := Workspace openContents: 'a'. > > b := Dictionary new. > > b add: (WorkspaceVariable key: #a value: 42). > > ws setBindings: b. > > > > Unfortunately Workspace isn't Spec's ComposableModel so I can't just > reuse it. > > Is something similar possible with TextModel? Perhaps somehow changing > model to Workspace (without actually opening the workspace) or something? > > > > Inspector seems to do something like that but my investigation ended up > in OpalCompiler which is way over my head. :( > > > > Thanks, > > Peter > > I don't know how this works for variable binding, > but you can set the doItReceiver: > > (that's how the inspector works) > > >

Oct. 4, 2014

Re: [Pharo-dev] Presetting variables to Spec's TextModel.

by Nicolai Hess

Am 04.10.2014 17:09 schrieb "Peter UhnÃ¡k" <i.uhnak(a)gmail.com>: > > Hi, > > I'm trying to preset variables to TextModel but I'm not sure if/how can such thing be achieved. > > With Workspace (in pre-GT Pharo) I could do > > ws := Workspace openContents: 'a'. > b := Dictionary new. > b add: (WorkspaceVariable key: #a value: 42). > ws setBindings: b. > > Unfortunately Workspace isn't Spec's ComposableModel so I can't just reuse it. > Is something similar possible with TextModel? Perhaps somehow changing model to Workspace (without actually opening the workspace) or something? > > Inspector seems to do something like that but my investigation ended up in OpalCompiler which is way over my head. :( > > Thanks, > Peter I don't know how this works for variable binding, but you can set the doItReceiver: (that's how the inspector works)

Oct. 4, 2014

Re: [Pharo-dev] Seconds set of additions to GT-Inspector

by stepharo

Neat Stef On 4/10/14 20:41, Sven Van Caekenberghe wrote: > In Moose/GToolkit: > > === > Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.58 > Author: SvenVanCaekenberghe > Time: 4 October 2014, 8:39:58.350356 pm > UUID: 2d078975-c2ac-4fcf-af82-4dd3fc709016 > Ancestors: GT-InspectorExtensions-Core-TudorGirba.57 > > Customized GT-Inspector for Time, Date, DateAndTime and Duration by adding a Details tab listing various chronology aspects > === > > Sven > > >

Oct. 4, 2014

Re: [Pharo-dev] Presetting variables to Spec's TextModel.

by stepharo

May be this is the occasion to create a WorkspaceModel and support this behavior. Stef On 4/10/14 17:09, Peter UhnÃ¡k wrote: > Hi, > > I'm trying to preset variables to TextModel but I'm not sure if/how > can such thing be achieved. > > With Workspace (in pre-GT Pharo) I could do > > ws := Workspace openContents: 'a'. > b := Dictionary new. > b add: (WorkspaceVariable key: #a value: 42). > ws setBindings: b. > > Unfortunately Workspace isn't Spec's ComposableModel so I can't just > reuse it. > Is something similar possible with TextModel? Perhaps somehow changing > model to Workspace (without actually opening the workspace) or something? > > Inspector seems to do something like that but my investigation ended > up in OpalCompiler which is way over my head. :( > > Thanks, > Peter

Oct. 4, 2014

Seconds set of additions to GT-Inspector

by Sven Van Caekenberghe

In Moose/GToolkit: === Name: GT-InspectorExtensions-Core-SvenVanCaekenberghe.58 Author: SvenVanCaekenberghe Time: 4 October 2014, 8:39:58.350356 pm UUID: 2d078975-c2ac-4fcf-af82-4dd3fc709016 Ancestors: GT-InspectorExtensions-Core-TudorGirba.57 Customized GT-Inspector for Time, Date, DateAndTime and Duration by adding a Details tab listing various chronology aspects === Sven

Oct. 4, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Thierry Goubier

Le 04/10/2014 12:07, stepharo a Ã©crit : > >> NativeBoost is not unstable for me, but why libcgit is on a bleeding >> edge NativeBoost version then? > > I do not get what you want to say. May be restating will help me > understand. Last time I checked, libcgit was tied to an experimental NativeBoost version (or bleeding edge version). The changes needed by libcgit should have been integrated in Pharo instead. >> Athens is stable for me, but I believe that TxText requires a bleeding >> edge Athens. > > Igor improve Athens each time it is needed and it does not make athens > unstable. But basically TxText is on a fork of mainline Athens. It's the "Windows undocumented" approach: I'm on TxText, I need something from Athens, I just add the stuff to Athens; anyway, I'm not on the main Athens, I can get my own customized version. Now, when merging TxText, you'll have to merge a new Athens as well, and I hope that you won't find by then that this new Athens breaks Roassal. I can understand why you may want to work like that. From the outside, I'm not impressed by the process. >> Libcgit is like that: its Pharo 4 + Bleeding edge native boost not yet >> in Pharo 4 + libcgit (and from ESUG, I get that it will require an >> entire refactoring of Monticello and a complete new on disk format). >> It's really shaping up like a long, long term target. > So for you it would be better that we move faster :) > Not slowler. Not really. If you had a few million â¬ to burn, I'd say "perfect". With the amount of resources we have, I'm saying: this is really risky. And hard to contribute to, so I can't help. > You see if there is a bug in a cache on the system somehwere what can we > do. Igot told to alex to use another font and it solved the problem. > TxText will be pushed soon in Pharo 40. I tried to work on that cache issue because my demos with Roassal had the issue, but I couldn't find Igor's description in the archives. I know it's there... Igor, if you are listening, can you tell us again? Thierry

Oct. 4, 2014