March 2016 - Pharo-dev - lists.pharo.org

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

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

by Dale Henrichs

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

March 21, 2016

Discussing FileSystem >> #workingDirectory and VM process getcwd(3)

by Mariano Martinez Peck

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

March 21, 2016

Re: [Pharo-dev] feedback from yet another student presentation

by Dale Henrichs

Tobias Pape has been improving SS3 over the years and the latest versions are in continual use at HPI ... I can find out if there is serious interest ... Dale On 3/10/16 11:15 PM, Serge Stinckwich wrote: > On Fri, Mar 11, 2016 at 8:08 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Le 10/3/16 22:14, Alexandre Bergel a Ã©crit : >>>> - it was reallllly hard to register a project on smalltalkhub just after >>>> we created an account. >>>> This already happened to me during the open-devs. >>>> So this is a really big show stopper for the mooc. Because people will >>>> gave up just after the first lecture :( >>> The situation will be much easier I hope once git is well supportedâ¦ >> >> But will we have to answer 100 of problems during the mooc? >> And if people drop after just because they cannot save their code as we say >> it :( > Yes this is real annoying problem ... Maybe you can ask Gemstone to > support the MOOC > with a dedicated ss3 instance (or use ss3). >

March 21, 2016