January 2017 - Pharo-dev - lists.pharo.org

Regression in Nautilus in 60362

by stepharong

Hi Pharo 6.0 Latest update: #60362 I get several DNU - when selecting a protocol from the list - when pressing the execute icon of an example instance https://pharo.fogbugz.com/f/cases/19622/runExamplarMethod-DNU I do not know what's happened. May be a wrong fix. -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 29, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Torsten Bergmann

Pharo "Revaluator" which is an artificial word: - "Re" for Remote - "eval" like evaluation of expressions for (remote) work/debugging - "Revalution" means improvement, increase in value So far this name is not very much in use according to Google hits. Thx T.

Jan. 29, 2017

Re: [Pharo-dev] athens dead code?

by stepharong

On Sun, 29 Jan 2017 17:21:44 +0100, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 29 January 2017 at 16:16, stepharong <stepharong(a)free.fr> wrote: >> >> >>>> On 27 January 2017 at 00:06, stepharong <stepharong(a)free.fr> wrote: >>> >> Yes because it if keep dead code around we will have a broken house >> window syndrome and I do not like it. > > You don't have to advocate that to me. I am fully on your side with this > :) excellent! Can you propose a slice so that we fix the code? > > > > --Best regards, > Igor Stasenko. -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 29, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Brad

RemoPharo. Short for remote Pharo. Brad Selfridge 913-269-2385 > On Jan 29, 2017, at 11:26 AM, Graham McLeod <graham(a)inspired.org> wrote: > > OR better: TeleCode > > Graham > > Graham McLeod wrote: >> How about PharoAfar >> >> g >> >> stepharong wrote: >>> Hi guys >>> >>> Since we will push the remote tools (videos/web...) I would like to get some ideas for a cool name. >>> Any ideas? >>> >>> Because Pharmide (looks like medicine or chemical product). >>> Since I vaguely remember some german Pharmide made me think about Fern(sehen) but this is not a good name. >>> >>> Stef >>> >>> >>> -- >>> >>> >> > > <graham.vcf>

Jan. 29, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Graham McLeod

OR better: TeleCode Graham Graham McLeod wrote: > How about PharoAfar > > g > > stepharong wrote: >> Hi guys >> >> Since we will push the remote tools (videos/web...) I would like to >> get some ideas for a cool name. >> Any ideas? >> >> Because Pharmide (looks like medicine or chemical product). >> Since I vaguely remember some german Pharmide made me think about >> Fern(sehen) but this is not a good name. >> >> Stef >> >> >> -- >> >> >

Jan. 29, 2017

Re: [Pharo-dev] athens dead code?

by Igor Stasenko

On 29 January 2017 at 16:16, stepharong <stepharong(a)free.fr> wrote: > > > On 27 January 2017 at 00:06, stepharong <stepharong(a)free.fr> wrote: > >> >> Yes because it if keep dead code around we will have a broken house > window syndrome and I do not like it. > You don't have to advocate that to me. I am fully on your side with this :) -- Best regards, Igor Stasenko.

Jan. 29, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by stepharong

On Sun, 29 Jan 2017 16:40:07 +0100, Volkert <volkert(a)nivoba.de> wrote: > PharoConnect? It would convey the mean to connect ? > > > On 29.01.2017 15:14, stepharong wrote: >> Hi guys >> >> Since we will push the remote tools (videos/web...) I would like to >> get some ideas for a cool name. >> Any ideas? >> >> Because Pharmide (looks like medicine or chemical product). >> Since I vaguely remember some german Pharmide made me think about >> Fern(sehen) but this is not a good name. >> >> Stef >> >> >> -- >> > > -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 29, 2017

Re: [Pharo-dev] athens dead code?

by Igor Stasenko

Ah, yeah.. one important note: #sendCommandsTo: is used to convert backend-neutral path data to backend-specific paths. That means , that commands that implementor should use , should conform with AthensPathBuilder protocol, so that you can later do: backendSpecificPath := canvas createPath: [:builder | myBackendNeutralPathData sendCommandsTo: builder]. On 29 January 2017 at 17:41, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 29 January 2017 at 16:16, stepharong <stepharong(a)free.fr> wrote: > >> >> >> On 27 January 2017 at 00:06, stepharong <stepharong(a)free.fr> wrote: >> >>> >>> accept: aVisitor >>> ^ aVisitor lineSegment: self >>> accept: aVisitor >>> ^ aVisitor closeSegment: self >>> accept: aVisitor >>> ^ aVisitor moveSegment: self >>> >>> seems to invoke methods that do not exit >>> I check AthensLIneSegment is used so I do not understand why the methods >>> are broken. >>> >>> this is a part of visitor api for path segments. >> >> >>> I know but where is the visitor? >>> >>> if you remove it, then users cannot use it >>> for iterating trough path segments for converting them etc etc.. >>> of course, it may be nit used by Athens itself.. but it doesn't means it >>> is useless. >>> >>> >>> Where is the visitor? Why accept: are not packaged with it? Does it use >>> DNU trick? >>> In my imagine there is no implementor of moveSegment: closeSegment: >>> >>> >>> why there should be any, if nobody using this feature, yet? so you don't >> have a single visitor. >> you could add a test case for coverage, so it won't bother you that >> there's no implementors of >> given selector in image :) >> >> >> Yes because it if keep dead code around we will have a broken house >> window syndrome and I do not like it. >> >> iirc, i used it for path transformation(s) code.. which then get removed. >> >> >> Was it removed because it was not good, ? no useful? or just a mistake? >> >> >> well, i think there's some kind of duplication. > if you look at base class - AthensPathSegment > there's two methods for visitor pattern: > #accept: > and > #sendCommandsTo: > > > the main difference between the above two is that > #accept: should double-dispatch with appropriate message passing single > argument - the receiver, > while > > > #sendCommandTo: is used by a convenience protocol #sendCommandsTo: > that sends direct _series_ of commands to visitor in a fashion like: > visitor lineTo: aPoint; > curveVia: aPoint to: endPoint > etc. > > Mainly, sendCommandsTo: is for convenience, that does not requires the > user to implement a loop in own code, > and to allow user to deal directly with data instead of subinstances of > AthensPathSegment. > > Also, as i looking into code, there are some leftovers - the > #convertWith:, and #visitWith: . These should be removed and users of > #visitWith: should be > refactored to #accept: protocol. To not confuse users what exactly > protocol should be used. > > > > >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Jan. 29, 2017

Re: [Pharo-dev] athens dead code?

by Igor Stasenko

On 29 January 2017 at 16:16, stepharong <stepharong(a)free.fr> wrote: > > > On 27 January 2017 at 00:06, stepharong <stepharong(a)free.fr> wrote: > >> >> accept: aVisitor >> ^ aVisitor lineSegment: self >> accept: aVisitor >> ^ aVisitor closeSegment: self >> accept: aVisitor >> ^ aVisitor moveSegment: self >> >> seems to invoke methods that do not exit >> I check AthensLIneSegment is used so I do not understand why the methods >> are broken. >> >> this is a part of visitor api for path segments. > > >> I know but where is the visitor? >> >> if you remove it, then users cannot use it >> for iterating trough path segments for converting them etc etc.. >> of course, it may be nit used by Athens itself.. but it doesn't means it >> is useless. >> >> >> Where is the visitor? Why accept: are not packaged with it? Does it use >> DNU trick? >> In my imagine there is no implementor of moveSegment: closeSegment: >> >> >> why there should be any, if nobody using this feature, yet? so you don't > have a single visitor. > you could add a test case for coverage, so it won't bother you that > there's no implementors of > given selector in image :) > > > Yes because it if keep dead code around we will have a broken house window > syndrome and I do not like it. > > iirc, i used it for path transformation(s) code.. which then get removed. > > > Was it removed because it was not good, ? no useful? or just a mistake? > > > well, i think there's some kind of duplication. if you look at base class - AthensPathSegment there's two methods for visitor pattern: #accept: and #sendCommandsTo: the main difference between the above two is that #accept: should double-dispatch with appropriate message passing single argument - the receiver, while #sendCommandTo: is used by a convenience protocol #sendCommandsTo: that sends direct _series_ of commands to visitor in a fashion like: visitor lineTo: aPoint; curveVia: aPoint to: endPoint etc. Mainly, sendCommandsTo: is for convenience, that does not requires the user to implement a loop in own code, and to allow user to deal directly with data instead of subinstances of AthensPathSegment. Also, as i looking into code, there are some leftovers - the #convertWith:, and #visitWith: . These should be removed and users of #visitWith: should be refactored to #accept: protocol. To not confuse users what exactly protocol should be used. > -- > Best regards, > Igor Stasenko. > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > -- Best regards, Igor Stasenko.

Jan. 29, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Volkert

PharoConnect? On 29.01.2017 15:14, stepharong wrote: > Hi guys > > Since we will push the remote tools (videos/web...) I would like to > get some ideas for a cool name. > Any ideas? > > Because Pharmide (looks like medicine or chemical product). > Since I vaguely remember some german Pharmide made me think about > Fern(sehen) but this is not a good name. > > Stef > > > -- >

Jan. 29, 2017