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

2017-01-29 Thread p...@highoctane.be
Codero
Proxyion
Proxemote
Evade
Reon
ProxyCode
Remoon
Reode
Phreode
Remoteon
CodeRemote
EvaCode
Remotion
Drinx
Phemote
Smuggler
BitSmuggler

Phil

On Sun, Jan 29, 2017 at 4:27 PM, stepharong  wrote:

> On Sun, 29 Jan 2017 16:24:03 +0100, Dimitris Chloupis <
> kilon.al...@gmail.com> wrote:
>
> Apostasis (Greek for distance)
> Background ( playing with words Playground and back end )
> Parallax ( distance viewed from two point [eg eyes])
> Apex ( tip of)
> Outpost (distant place)
> HyperOcean ( another Greek word for a thing that can cross oceans , oceans
> here being surfing the Internet)
> Telemachus or Telemachos ( son of Odyssey, his name means in Ancient Greek
> , the one who fights from a distance , tale means distance , telephone =
> voice from a distance , television = vision from a distance etc. )
>
>
> may telepharo :)
>
> Stef
>
>
>
> On Sun, 29 Jan 2017 at 16:15, 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/
>


Re: [Pharo-dev] athens dead code?

2017-01-29 Thread p...@highoctane.be
Why do not we have that concept of -contrib like there is in so many other
places?

Packages are release with the official party line and there is a -contrib
package, or contrib/ subfolder that contains extensions and other useful
bits that are not "core" but are still useful for people and do not require
a hunt to figure out that they do exist?

Phil

On Sun, Jan 29, 2017 at 6:16 PM, stepharong  wrote:

> On Sun, 29 Jan 2017 17:21:44 +0100, Igor Stasenko 
> wrote:
>
>
>
> On 29 January 2017 at 16:16, stepharong  wrote:
>
>>
>>
>> On 27 January 2017 at 00:06, stepharong  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/
>


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

2017-01-29 Thread Eliot Miranda
I found myself thinking of those airtight boxes with gloves used in biology 
labs and that led to

Scissorhands 
Claw (as in Toy Story)

Less frivolous:
Extensor
Pert   (Pharo Extended with Remote Tools. pert
1. 
a. High-spirited, lively, or cheerful: A pert receptionist greets each client.
b. Impudently bold; saucy: He was pert to his teacher. She gave a pert answer.
2. 
a. Attractive or stylish in appearance: a pert hat.
b. Small or firm and well-formed: a pert nose.

and hence pert means sexy)

_,,,^..^,,,_ (phone)

> On Jan 29, 2017, at 4:06 PM, Ben Coman  wrote:
> 
> 
> 
>> On Sun, Jan 29, 2017 at 10:14 PM, 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.
>> 
>> 
> 
> For a change, I'm lacking original ideas :P
> But of other suggestions, I like...
> 
> > Phresnel from Fresnel lenses [1] used in lighthouses to be visible over 
> > greater distances
> Good googability and a *great* fit for Pharo's lighthouse theme.
> There is one competing project https://github.com/lobid/Phresnel
> but it looks abandoned and ranks low in searches.
> 
> > PharoAfar 
> Except its a bit of a tongue twist and I'd shorten it to Pharofar, and maybe 
> Pharophar.
> far = at, to, or by a great distance
> 
> > Pharoscope from Pharo + Telescope 
> Related terms: borescope, oscilloscope, spectroscope.
> 
> So far Phresnel is my phavorite.
> 
> cheers -ben


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

2017-01-29 Thread Ben Coman
On Sun, Jan 29, 2017 at 10:14 PM, 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.
>
>
>
For a change, I'm lacking original ideas :P
But of other suggestions, I like...

> Phresnel from Fresnel lenses [1] used in lighthouses to be visible over
greater distances
Good googability and a *great* fit for Pharo's lighthouse theme.
There is one competing project https://github.com/lobid/Phresnel
but it looks abandoned and ranks low in searches.

> PharoAfar
Except its a bit of a tongue twist and I'd shorten it to Pharofar, and
maybe Pharophar.
far = at, to, or by a great distance

> Pharoscope from Pharo + Telescope
Related terms: borescope, oscilloscope, spectroscope.

So far Phresnel is my phavorite.

cheers -ben


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

2017-01-29 Thread Rafael Luque
My two cents...

* Pharoscope from Pharo + Telescope.
* Phresnel from Fresnel lenses [1] used in lighthouses to be visible over
greater distances.

[1] Fresnel lens: https://en.wikipedia.org/wiki/Fresnel_lens.




2017-01-29 22:16 GMT+01:00 Cyril Ferlicot D. :

> Le 29/01/2017 à 15:14, stepharong a écrit :
> > 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
> >
> >
> > --
> >
>
> RIDE? (Remote Integrated Development Environment)
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>
>


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

2017-01-29 Thread Cyril Ferlicot D.
Le 29/01/2017 à 15:14, stepharong a écrit :
> 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
> 
> 
> -- 
> 

RIDE? (Remote Integrated Development Environment)

-- 
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature


Re: [Pharo-dev] Regression in Nautilus in 60362

2017-01-29 Thread Denis Kudriashov
About last problem it was wrong fix 18232
.
Here is revert 19617 .

2017-01-29 21:48 GMT+01:00 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/ca
> ses/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/
>
>


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

2017-01-29 Thread Guillermo Polito
avatar, avatools?

Le 29 janv. 2017 20:01, "Torsten Bergmann"  a écrit :

> 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.
>
>
>


[Pharo-dev] Regression in Nautilus in 60362

2017-01-29 Thread 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/



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

2017-01-29 Thread 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. 




Re: [Pharo-dev] athens dead code?

2017-01-29 Thread stepharong
On Sun, 29 Jan 2017 17:21:44 +0100, Igor Stasenko   
wrote:





On 29 January 2017 at 16:16, stepharong  wrote:




On 27 January 2017 at 00:06, stepharong  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/

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

2017-01-29 Thread Brad
RemoPharo.  Short for remote Pharo.

Brad Selfridge
913-269-2385

> On Jan 29, 2017, at 11:26 AM, Graham McLeod  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
>>> 
>>> 
>>> -- 
>>> 
>>> 
>> 
> 
> 



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

2017-01-29 Thread 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


--






<>

Re: [Pharo-dev] athens dead code?

2017-01-29 Thread Igor Stasenko
On 29 January 2017 at 16:16, stepharong  wrote:

>
>
> On 27 January 2017 at 00:06, stepharong  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.


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

2017-01-29 Thread stepharong

On Sun, 29 Jan 2017 16:40:07 +0100, Volkert  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/



Re: [Pharo-dev] athens dead code?

2017-01-29 Thread 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  wrote:

>
>
> On 29 January 2017 at 16:16, stepharong  wrote:
>
>>
>>
>> On 27 January 2017 at 00:06, stepharong  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.


Re: [Pharo-dev] athens dead code?

2017-01-29 Thread Igor Stasenko
On 29 January 2017 at 16:16, stepharong  wrote:

>
>
> On 27 January 2017 at 00:06, stepharong  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.


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

2017-01-29 Thread 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
>
>
> -- 
>




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

2017-01-29 Thread stepharong

Hi  Graham


How about PharoAfar

g


can you explain it?



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


--






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

2017-01-29 Thread stepharong
On Sun, 29 Jan 2017 16:24:03 +0100, Dimitris Chloupis  
 wrote:



Apostasis (Greek for distance)
Background ( playing with words Playground and back end )Parallax (  
distance viewed from two point [eg eyes])Apex ( tip of)Outpost (distant  
place)HyperOcean ( another Greek word for a thing that can cross oceans  
, oceans here being surfing the Internet)Telemachus or Telemachos ( son  
of Odyssey, his name means in Ancient Greek , the one who fights from a  
distance , tale means distance , telephone = voice from a distance ,  
television = vision >from a distance etc. )


may telepharo :)

Stef




On Sun, 29 Jan 2017 at 16:15, 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/

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

2017-01-29 Thread Dimitris Chloupis
Apostasis (Greek for distance)
Background ( playing with words Playground and back end )
Parallax ( distance viewed from two point [eg eyes])
Apex ( tip of)
Outpost (distant place)
HyperOcean ( another Greek word for a thing that can cross oceans , oceans
here being surfing the Internet)
Telemachus or Telemachos ( son of Odyssey, his name means in Ancient Greek
, the one who fights from a distance , tale means distance , telephone =
voice from a distance , television = vision from a distance etc. )

On Sun, 29 Jan 2017 at 16:15, 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
>
>
> --
>
>


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

2017-01-29 Thread Graham McLeod

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


--




<>

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

2017-01-29 Thread stepharong

Hi martin

open a ticket so that we do not lose this point.
Stef


[...]


The current implementation of #sign is

self > 0 ifTrue: [^ 1].
(self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1].
^ 0

I'd propose factoring this into two simpler methods:

sign
self > 0 ifTrue: [^ 1].
self < 0 ifTrue: [^ -1].
^ 0


maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard
tells it should be 0 too?


This addition makes sense to me.

The standards help a *little* and suggest on alternative.

ANSI Smalltalk acts like NaNs don't exist (basically, it lets
implementers do what they want for those values).

ANSI Smalltalk relies on ISO/IEC 10967 of 1994 for numerics (even when
it *cannot* rely on 10967, it does, sigh). That spec only defines a
"sign" operation for floats with a definite numeric value, and says that
operations are *permitted* to accept infinities and NaNs, but does not
require this, nor say what the answer should be.

The 2007 update of 10967 is somewhat more helpful. It replaces the
"sign" operation with one called "signum" which returns 1, -1, or NaN.
It returns 1 for positive zero and positive infinity, and -1 for
negative zero and negative infinity. If given a qNaN, it returns a qNaN.
If given a signaling NaN, it returns a qNaN but notifies the application
of an "invalid" situation.


what is a qNan?



If we extend this to Smalltalk, I *think* this would have us answer qNaN
for qNaN, and for a sNaN signal a resumable exception (a Notification,
perhaps?) that if resumed would answer qNaN. This also seems to make
some sense -- NaNs are supposed to propagate, and asking the just plain
"sign" (as opposed to signBit or isSignMinus) of a NaN is more or less
nonsense. But if you prefer (-1 raisedTo: self signBit) I won't complain.



That means that we'd have to refactor most (all?) senders of sign...



Certainly should audit senders of sign, but I'd expect that most senders
don't really care about what the sign of -0.0 or NaNs are. The answer
would remain the same for all other receivers.

Regards,

-Martin




--
Using Opera's mail client: http://www.opera.com/mail/



Re: [Pharo-dev] athens dead code?

2017-01-29 Thread stepharong



On 27 January 2017 at 00:06, stepharong  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?


--Best regards,
Igor Stasenko.




--
Using Opera's mail client: http://www.opera.com/mail/

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

2017-01-29 Thread stepharong

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


--



Re: [Pharo-dev] About printing without having ""

2017-01-29 Thread Esteban Lorenzano

> On 28 Jan 2017, at 23:56, p...@highoctane.be wrote:
> 
> I mean in the Darktheme.
> 

I have no problem with it and darktheme:



Esteban

> On Sat, Jan 28, 2017 at 11:18 AM, Tudor Girba  > wrote:
> Hi,
> 
> The solution we agreed upon was integrated since quite some time now.
> 
> Try this:
> - type 42
> - press Cmd+p
> - press Cmd+p
> 
> It produces:
> 
> 
> 
> Cheers,
> Doru
> 
> 
>> On Jan 28, 2017, at 9:27 AM, stepharong > > wrote:
>> 
>> Hi
>> 
>> this is nearly more than a year that I ask if we can have a way to NOT have 
>> "" when we print a result in the tool.
>> What is the status?
>> This %#$&^$&*(&)**&^$%#$&%*^&( popup BREAKS the flow when writing tests. I'm 
>> FED UP to have to remove the " at the beginning and end of my expression 
>> result.
>> 
>> We got an long discussion and now how it is handled?
>> I have the impression that the strategy here is to make sure that people 
>> believe that they are heard but do not care.
>> 
>> Stef
>> 
>> -- 
>> Using Opera's mail client: http://www.opera.com/mail/ 
>> 
>> 
> 
> --
> www.tudorgirba.com 
> www.feenk.com 
> 
> “Software has no shape. Actually, it has no one shape. It has many."
> 
>