- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Enterprise Pharo Book updates

by Damien Cassou

Gabriel Cotelli <g.cotelli(a)gmail.com> writes: > Are the book versions available at books.pharo.org automatically > updated? It seems that are missing the last updates. no. Things are manual. Automated updated are on the continuous integration servers. https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/ https://ci.inria.fr/pharo-contribution/view/Books/job/DeepIntoPharo/ https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

March 22, 2016

Re: [Pharo-dev] Discussing FileSystem >> #workingDirectory and VM process getcwd(3)

by Damien Cassou

Damien Pollet <damien.pollet(a)gmail.com> writes: > On 22 March 2016 at 12:56, Damien Cassou <damien.cassou(a)inria.fr> wrote: > >> typical applications ran with double-click are bound to the HOME >> directory. Why do you want to do it differently? >> > > Only on Linux. On OS X it's / so, why do you want to make it the image directory? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

March 22, 2016

Re: [Pharo-dev] Discussing FileSystem >> #workingDirectory and VM process getcwd(3)

by Damien Pollet

On 22 March 2016 at 12:56, Damien Cassou <damien.cassou(a)inria.fr> wrote: > typical applications ran with double-click are bound to the HOME > directory. Why do you want to do it differently? > Only on Linux. On OS X it's / -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

March 22, 2016

Re: [Pharo-dev] Discussing FileSystem >> #workingDirectory and VM process getcwd(3)

by Damien Cassou

Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > 1) *If Pharo was launched from double click* then we do not care about its > location and I think it's correct to default to image location: > > 1.1) FileSystem >> #workingDirectory refers to the directory containing > the .image file > 1.2) The VM process getcmd() is the default one of the particular OS ($HOME > in my OSX). > > So...there is a mismatch between #workingDirectory and VM's process cmd. > > *I think (as Damien said), that we should do a chdir() for the VM process > to match the .image location. * typical applications ran with double-click are bound to the HOME directory. Why do you want to do it differently? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

March 22, 2016

Enterprise Pharo Book updates

by Gabriel Cotelli

Are the book versions available at books.pharo.org automatically updated? It seems that are missing the last updates.

March 21, 2016

Re: [Pharo-dev] How to set styler for RubEditingArea?

by Nicolai Hess

2016-03-21 21:45 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > You made my day. Thank you. Now I have a minimal working example to > experiment with. > > Uko > And if you want to have an editor with styling for method definitions, you need to set the behavior (classOrMetaclass) area := RubEditingArea new. area backgroundColor: Color lightGray; textColor: Color white; beNotWrapped; beForSmalltalkCode; width: 400; withDecoratorNamed: #shoutStyler. area shoutStyler styler: RubSHTextStylerST80 new. area shoutStyler classOrMetaClass: UndefinedObject. area updateTextWith: 'method: sth ^ 1'. area openInWorld > > On 21 Mar 2016, at 20:46, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > '| area | area := RubEditingArea new. > > >

March 21, 2016

Re: [Pharo-dev] How to set styler for RubEditingArea?

by Yuriy Tymchuk

You made my day. Thank you. Now I have a minimal working example to experiment with. Uko > On 21 Mar 2016, at 20:46, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > '| area | area := RubEditingArea new.

March 21, 2016

Re: [Pharo-dev] How to set styler for RubEditingArea?

by Henrik Nergaard

The TextModel? is not set to a specific class, so it does not understand that it is a method you are declaring. The same code is red in the Playground as well. Switch 'method: sth ^ 1' to for example: '| area | area := RubEditingArea new.' Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Yuriy Tymchuk Sent: Monday, March 21, 2016 8:36 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] How to set styler for RubEditingArea? Ok, Iâm continuing my journey of styling code. And at the beginning I want to at least recreate the original coding area. Iâve did this and everything is redâ¦ area := RubEditingArea new. area backgroundColor: Color lightGray; updateTextWith: 'method: sth ^ 1'; textColor: Color white; beNotWrapped; beForSmalltalkCode; width: 400; withDecoratorNamed: #shoutStyler. area shoutStyler styler: RubSHTextStylerST80 new. area openInWorld any idea what could possibly go wrong? Uko > On 20 Mar 2016, at 02:56, monty <monty2(a)programmer.net> wrote: > > There are actually two, a highlighting parser used when you inspect files from spotter, and a highlighting writer used to implement the "Tree" and "Source" tabs when inspecting an already-parsed DOM tree. > > > Sent: Saturday, March 19, 2016 at 7:24 AM > From: "Nicolai Hess" <nicolaihess(a)gmail.com> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] How to set styler for RubEditingArea? > Isn't there a xml.-Styler in Moose? How is that implemented? > > Am 19.03.2016 11:28 vorm. schrieb "Stephan Eggermont" <stephan(a)stack.nl>:On 19-03-16 10:59, Henrik Nergaard wrote:There is no way of doing that, RubParagraphDecorator lacks a method to set its style variable. > > If you add that, then you can do something like: > Self is a RubEditingArea > > (self decoratorNamed: #shoutStyler) style: yourStyleclass new. > > I'm strongly in favor of adding this. There are other languages I want to style than smalltalk. > > Stephan > > >

March 21, 2016

Re: [Pharo-dev] How to set styler for RubEditingArea?

by Yuriy Tymchuk

Ok, Iâm continuing my journey of styling code. And at the beginning I want to at least recreate the original coding area. Iâve did this and everything is redâ¦ area := RubEditingArea new. area backgroundColor: Color lightGray; updateTextWith: 'method: sth ^ 1'; textColor: Color white; beNotWrapped; beForSmalltalkCode; width: 400; withDecoratorNamed: #shoutStyler. area shoutStyler styler: RubSHTextStylerST80 new. area openInWorld any idea what could possibly go wrong? Uko > On 20 Mar 2016, at 02:56, monty <monty2(a)programmer.net> wrote: > > There are actually two, a highlighting parser used when you inspect files from spotter, and a highlighting writer used to implement the "Tree" and "Source" tabs when inspecting an already-parsed DOM tree. > > > Sent: Saturday, March 19, 2016 at 7:24 AM > From: "Nicolai Hess" <nicolaihess(a)gmail.com> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] How to set styler for RubEditingArea? > Isn't there a xml.-Styler in Moose? How is that implemented? > > Am 19.03.2016 11:28 vorm. schrieb "Stephan Eggermont" <stephan(a)stack.nl>:On 19-03-16 10:59, Henrik Nergaard wrote:There is no way of doing that, RubParagraphDecorator lacks a method to set its style variable. > > If you add that, then you can do something like: > Self is a RubEditingArea > > (self decoratorNamed: #shoutStyler) style: yourStyleclass new. > > I'm strongly in favor of adding this. There are other languages I want to style than smalltalk. > > Stephan > > >

March 21, 2016

Re: [Pharo-dev] Discussing FileSystem >> #workingDirectory and VM process getcwd(3)

by Damien Pollet

+1 FileSystem workingDirectory should never ever diverge from getcwd(); 2.1 is definitely a bug. On 21 March 2016 at 19:39, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > this pinged my memory about OSX ... the funkiness is that you had to > arrange for PWD to be set "correctly" when double clicking an application > ... when running from the command line PWD was set "correctly" ... > > This was affecting GemStone because I was using the PWD of the client in > certain circumstances (and years ago) ... > > Sounds like this quirk probably doesn't apply, but I still think it is > something to be aware of ... > > Dale > > > On 3/21/16 11:13 AM, Mariano Martinez Peck wrote: > > Hi guys, > > In a couple of recent threads, there were discussions about FileSystem >> > #workingDirectory VS VM process getcwd(3) and the fact that they do not > match. > > The current state is as follows: > > 1) *If Pharo was launched from double click* then we do not care about > its location and I think it's correct to default to image location: > > 1.1) FileSystem >> #workingDirectory refers to the directory containing > the .image file > 1.2) The VM process getcmd() is the default one of the particular OS > ($HOME in my OSX). > > So...there is a mismatch between #workingDirectory and VM's process cmd. > > *I think (as Damien said), that we should do a chdir() for the VM process > to match the .image location. * > > 2) *If Pharo was launched from command line* then we likely are > interested in the current CMD from where we launched the VM > process (imagine using Pharo for scripting). The current status is: > > 2.1) FileSystem >> #workingDirectory still refers to the directory > containing the .image file which I think it is incorrect. > 2.2) The CMD of the VM process is correct. But again, there is a mismatch > with #workingDirectory. > > *For this case, I think we should set FileSystem >> #workingDirectory to > CMD. * > > Before start discussing how to implement this, do you agree with the idea? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

March 21, 2016