May 2016 - Pharo-users - lists.pharo.org

Retina support in Pharo

by markm

Hi Is it possible to get Pharo (4 or 5) to run with retina support on OS X? I have tried searching for some answers, but alas could only find a handful of posts from a few years back. Any help much appreciated! Mark -- View this message in context: http://forum.world.st/Retina-support-in-Pharo-tp4895245.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 17, 2016

On Class and Method comments

by Dimitris Chloupis

I really like to start writing some class and method comments to make Pharo image more beginner friendly. Are there any guidelines when and how to comment classes and methods ? What about inline comments ?

May 16, 2016

Re: [Pharo-users] TextAction bugs

by stepharo

Hi all :) > Hi All, > > TextAction appears to have a couple of issues: > > > TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor > "sent when a user clicks on a piece of text to which I am applied in an editor" > > "may be self is included in the event or an Object. " > ^ actOnClickBlock cull: self cull: anEvent cull: anObject cull: paragraph cull: editor To me this use of cull: is plain plain plain bad. cull: is a plague. People use is far too often. It indicates a lack of - design - object because with one object the block would get it and select what is needed. - then I do not get why we need to pass the paragraph and the editor > #cull:cull:cull:cull:cull: doesn't exist, so should be something like: > > > TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor > "sent when a user clicks on a piece of text to which I am applied in an editor" > > "may be self is included in the event or an Object. " > ^ actOnClickBlock valueWithEnoughArguments: (Array with: self with: anEvent with: anObject with: paragraph with: editor) it looks already better. > > > It is also missing the Rubric version: > > > TextAction>>rubActOnClick: anEvent for: anObject in: paragraph editor: editor > "sent when a user clicks on a piece of text to which I am applied in an editor" > > "may be self is included in the event or an Object. " > ^ actOnClickBlock valueWithEnoughArguments: (Array with: self with: anEvent with: anObject with: paragraph with: editor) > > > I've followed the convention in the other implementations of > #rubActOnClick:for:in:editor: and reimplemented the code, but it could > just as easily call #actOnClick:for:in:editor:. > > Any reason not to submit this as a formal bug report? > > Should it be submitted as two separate bug reports since they are in > separate packages? > > Thanks! > Alistair > >

May 16, 2016

Re: [Pharo-users] TextAction bugs

by Alistair Grant

On Mon, May 16, 2016 at 01:42:16PM +0200, Nicolai Hess wrote: > 2016-05-16 8:29 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > Hi All, > > TextAction appears to have a couple of issues: > > > TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor > Â Â Â Â "sent when a user clicks on a piece of text to which I am applied > in an editor" > > Â Â Â Â "may be self is included in the event or an Object. " > Â Â Â Â ^ actOnClickBlock cull: self cull: anEvent cull: anObject cull: > paragraph cull: editor > > > #cull:cull:cull:cull:cull: doesn't exist, so should be something like: > > > TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor > Â Â Â Â "sent when a user clicks on a piece of text to which I am applied > in an editor" > > Â Â Â Â "may be self is included in the event or an Object. " > Â Â Â Â ^ actOnClickBlock valueWithEnoughArguments: (Array with: self with: > anEvent with: anObject with: paragraph with: editor) > > > It is also missing the Rubric version: > > > TextAction>>rubActOnClick: anEvent for: anObject in: paragraph editor: > editor > Â Â Â Â "sent when a user clicks on a piece of text to which I am applied > in an editor" > > Â Â Â Â "may be self is included in the event or an Object. " > Â Â Â Â ^ actOnClickBlock valueWithEnoughArguments: (Array with: self with: > anEvent with: anObject with: paragraph with: editor) > > > I've followed the convention in the other implementations of > #rubActOnClick:for:in:editor: and reimplemented the code, but it could > just as easily call #actOnClick:for:in:editor:. > > Any reason not to submit this as a formal bug report? > > Should it be submitted as two separate bug reports since they are in > separate packages? > > > There is already a bug report for the first issue you described: > 18200 > TextAction calls unimplemented method #cull:cull:cull:cull:cull: Sigh, guilty (and embarrassed) about not checking the bug tracker first. It looks like there isn't a fix proposed (I couldn't see it in the bug report or in Pharo60Inbox), so if you don't have any objection I'll add my proposed fix. I also couldn't find any reference to the second issue, so will raise a new issue and submit the proposed fix. Thanks for pointing this out, Alistair

May 16, 2016

OSSubprocess for Windows discussion [WAS] Re: OSProcess in Pharo 5?

by Mariano Martinez Peck

On Mon, May 16, 2016 at 9:25 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, May 15, 2016 at 11:19 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> On Sat, May 14, 2016 at 8:06 AM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >> > If you are only interested in Unix / Linux / OSX, >> >> What is the plan for Windows support? >> > > I am not planning to add that. What I have found, is that tools that try > to provide the same API for all platforms do not end up doing well or they > limit the specific benefits of each custom platform. I > > Sorry...shortcut sent email before I finished it. I am not planning to add that. What I have found, is that tools that try to provide the same API for all platforms do not end up doing well or they limit the specific benefits of each custom platform. I very much prefer the approach used by GitFileTree and others. That is... AT YOUR APPLICATION level, you check wether you are on windows or not. If you are under Linux/OSX, then you may want to use OSProcess / OSSubprocess. And if you are in windows, then you may want to use ProcessWrapper. A simple IF or a strategy or whatever that calls the right API. That way you can customize the code for each platform better. Finally, again, if someone wants a unified API, then I don't think it should be at OSProcess / OSSubprocess level. I would write an API that internally calls either ProcessWrapper or OS(Sub)Process. But I wouldn't use that API as mentioned above. Cheers, > cheers -ben >> >> > then you may want to try >> > OSSubprocess (it does work correctly in Pharo 5.0) >> > >> > https://github.com/marianopeck/OSSubprocess >> > >> > Cheers, >> > >> > >> > >> > On Fri, May 13, 2016 at 8:03 PM, PAUL DEBRUICKER <pdebruic(a)gmail.com> >> wrote: >> >> >> >> Hi - >> >> >> >> >> >> Is OSProcess the thing to use in Pharo 5 if you want to run a bash >> command >> >> and then bring the result into a running image? >> >> >> >> >> >> It seems to be locking up an image I've got with code that previously >> >> worked in Pharo 4. >> >> >> >> >> >> Thanks >> >> >> >> >> >> Paul >> > >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

May 16, 2016

Re: [Pharo-users] OSProcess in Pharo 5?

by Mariano Martinez Peck

On Sun, May 15, 2016 at 11:19 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Sat, May 14, 2016 at 8:06 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > If you are only interested in Unix / Linux / OSX, > > What is the plan for Windows support? > I am not planning to add that. What I have found, is that tools that try to provide the same API for all platforms do not end up doing well or they limit the specific benefits of each custom platform. I > cheers -ben > > > then you may want to try > > OSSubprocess (it does work correctly in Pharo 5.0) > > > > https://github.com/marianopeck/OSSubprocess > > > > Cheers, > > > > > > > > On Fri, May 13, 2016 at 8:03 PM, PAUL DEBRUICKER <pdebruic(a)gmail.com> > wrote: > >> > >> Hi - > >> > >> > >> Is OSProcess the thing to use in Pharo 5 if you want to run a bash > command > >> and then bring the result into a running image? > >> > >> > >> It seems to be locking up an image I've got with code that previously > >> worked in Pharo 4. > >> > >> > >> Thanks > >> > >> > >> Paul > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

May 16, 2016

Re: [Pharo-users] TextAction bugs

by Nicolai Hess

2016-05-16 8:29 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi All, > > TextAction appears to have a couple of issues: > > > TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor > "sent when a user clicks on a piece of text to which I am applied > in an editor" > > "may be self is included in the event or an Object. " > ^ actOnClickBlock cull: self cull: anEvent cull: anObject cull: > paragraph cull: editor > > > #cull:cull:cull:cull:cull: doesn't exist, so should be something like: > > > TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor > "sent when a user clicks on a piece of text to which I am applied > in an editor" > > "may be self is included in the event or an Object. " > ^ actOnClickBlock valueWithEnoughArguments: (Array with: self > with: anEvent with: anObject with: paragraph with: editor) > > > It is also missing the Rubric version: > > > TextAction>>rubActOnClick: anEvent for: anObject in: paragraph editor: > editor > "sent when a user clicks on a piece of text to which I am applied > in an editor" > > "may be self is included in the event or an Object. " > ^ actOnClickBlock valueWithEnoughArguments: (Array with: self > with: anEvent with: anObject with: paragraph with: editor) > > > I've followed the convention in the other implementations of > #rubActOnClick:for:in:editor: and reimplemented the code, but it could > just as easily call #actOnClick:for:in:editor:. > > Any reason not to submit this as a formal bug report? > > Should it be submitted as two separate bug reports since they are in > separate packages? > There is already a bug report for the first issue you described: 18200 <https://pharo.fogbugz.com/f/cases/18200/TextAction-calls-unimplemented-meth…> TextAction calls unimplemented method #cull:cull:cull:cull:cull: > > Thanks! > Alistair > >

May 16, 2016

Re: [Pharo-users] blue ink - format on accept?

by Esteban Lorenzano

> On 15 May 2016, at 15:08, stepharo <stepharo(a)free.fr> wrote: > > > > Le 14/5/16 Ã 15:11, Esteban Lorenzano a Ã©crit : >> >>> On 14 May 2016, at 15:01, stepharo < <mailto:stepharo@free.fr>stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> Please >>> >>> we did not add it because we were afraid that people do not want :) >>> >> people do not want (I donât) :) >> >>> But indeed I would like to have another button so that we can do format on accept. >>> >> yes, a setting is how it should be. > > Why we cannot have a button just besides the other one. Heh, I meant something that people can choose, not necessarily the settings frameworkâ¦ Esteban > > Stef >> >> Esteban >> >>> Stef >>> >>> Le 13/5/16 Ã 23:29, Peter UhnÃ¡k a Ã©crit : >>>> Only "format as you read" is available at the moment. (Which formats the methods without changing the source code, good for reading.) >>>> >>>> But it shouldn't be that hard to implementâ¦ in AbstractTool>>compileANewMethodInClass:categorized:from:notifyng: or NautilusUI>>compileAMethodFromCategory:withSource:notifying: >>>> >>>> Maybe we should add this for 6â¦ >>>> >>>> Peter >>>> >>>> On Fri, May 13, 2016 at 6:52 PM, PAUL DEBRUICKER < <mailto:pdebruic@gmail.com>pdebruic(a)gmail.com <mailto:pdebruic@gmail.com>> wrote: >>>> Hi - >>>> >>>> Is there a way in Pharo 5 to turn on format on accept? >>>> >>>> >>>> Thanks >>>> >>>> >>>> Paul >>>> >>>> >>> >> >

May 16, 2016

TextAction bugs

by Alistair Grant

Hi All, TextAction appears to have a couple of issues: TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor "sent when a user clicks on a piece of text to which I am applied in an editor" "may be self is included in the event or an Object. " ^ actOnClickBlock cull: self cull: anEvent cull: anObject cull: paragraph cull: editor #cull:cull:cull:cull:cull: doesn't exist, so should be something like: TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor "sent when a user clicks on a piece of text to which I am applied in an editor" "may be self is included in the event or an Object. " ^ actOnClickBlock valueWithEnoughArguments: (Array with: self with: anEvent with: anObject with: paragraph with: editor) It is also missing the Rubric version: TextAction>>rubActOnClick: anEvent for: anObject in: paragraph editor: editor "sent when a user clicks on a piece of text to which I am applied in an editor" "may be self is included in the event or an Object. " ^ actOnClickBlock valueWithEnoughArguments: (Array with: self with: anEvent with: anObject with: paragraph with: editor) I've followed the convention in the other implementations of #rubActOnClick:for:in:editor: and reimplemented the code, but it could just as easily call #actOnClick:for:in:editor:. Any reason not to submit this as a formal bug report? Should it be submitted as two separate bug reports since they are in separate packages? Thanks! Alistair

May 16, 2016

Re: [Pharo-users] GLMFormatedPresentation>>format bug?

by Alistair Grant

On Mon, May 16, 2016 at 05:42:54AM +0200, Tudor Girba wrote: > Hi, > > > On May 16, 2016, at 1:00 AM, Ben Coman <btc(a)openInWorld.com> wrote: > > On Mon, May 16, 2016 at 6:28 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > Hi Andrei, > > On Mon, May 16, 2016 at 12:08:01AM +0200, Andrei Chis wrote: > > Hi Alistair, > > Try something like this. Now 100% sure it will work. > > gtInspectIn: composite > <gtInspectorPresentationOrder: 30> > > ^ composite text > title: 'Meme'; > format: [self asText]. > > The display block should return the object to be displayed, which > is this case > is self. > > > Yep, that fixes the problem! Thanks for your reply. > > > Just curious if this also works... > > ^ composite text > title: 'Meme'; > format: #asText This also works, and looking at the definition of #format I'm guessing that this is closer to the original intended usage (see below)? > It works because the format block takes an optional argument with the input > entity. However, the semantics are not going to be quite the same. In > isolation, the behavior will be identical. However, the difference comes when > you try to reuse a presentation. > > Letâs look at an example. This is how an AST node displays the source: > > RBProgramNode>>gtInspectorSourceCodeIn: composite > <gtInspectorPresentationOrder: 30> > ^ composite pharoMethod > title: 'Source codeâ; > display: [ self source ]; > ... > > Like this, the block closure can simply delegate to the corresponding ast node > to display the source: > > BlockClosure>>gtInspectorSourceCodeIn: composite > <gtInspectorPresentationOrder: 40> > self sourceNode gtInspectorSourceCodeIn: composite > > And a keymap object which holds a block in an action instance variable, can > simply delegate to the block closure object to display the source: > > KMKeymap>>gtInspectorSourceCodeIn: composite > <gtInspectorPresentationOrder: 30> > ^ self action gtInspectorSourceCodeIn: composite > > > If the ProgramNode definition would have been implemented like: > display: [ :each | each source ] > > then when inspecting the block object, we would have gotten the block object as > each, and not the AST node. > > Does this explanation make sense? So using this code is going to be more flexible than ^ composite text title: 'Meme'; format: [self asText] since the format object isn't supplied the optional arguments. Thanks, Alistair

May 16, 2016