- Pharo-users - lists.pharo.org

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

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

by Tudor Girba

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 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? Cheers, Doru > cheers -ben -- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."

May 16, 2016

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

by Ben Coman

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 cheers -ben

May 15, 2016

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

by Alistair Grant

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. Cheers, Alistair

May 15, 2016

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

by Andrei Chis

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. Cheers, Andrei On Sun, May 15, 2016 at 11:58 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi All, > > I'm currently porting my personal documentation system from Python / > Django to Pharo and am trying to display formatted text in a new pane in > the inspector. If I execute something like: > > | text | > > text := 'Hello World' asText. > text addAttribute: TextColor green from: 1 to: 6. > text > > in a playground using "Do it and go", the text is displayed correctly > (with formatting). > > If I add a method in the object I want to inspect: > > gtInspectIn: composite > <gtInspectorPresentationOrder: 30> > > ^ composite text > title: 'Meme'; > display: [self asText]. > > the formatting disappears. > > I'm able to "fix" the problem by changing: > > GLMFormatedPresentation>>format > ^ format ifNil: [ format := #asString ] > > to: > > GLMFormatedPresentation>>format > ^ format ifNil: [ format := #asText ] > > Is someone more knowledgable about Glamour able to confirm that this is > really a bug? If so, I'll submit a formal bug report on fogbugz. (If > there's a better solution, that would be great too). > > Thanks! > Alistair > >

May 15, 2016