- Pharo-dev - lists.pharo.org

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

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

Jan. 29, 2017

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

by 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 <stepharong(a)free.fr> 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] Any idea for a cool name for the remote tool suite?

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

Jan. 29, 2017

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

by 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/

Jan. 29, 2017

Re: [Pharo-dev] athens dead code?

by stepharong

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? > >--Best regards, > Igor Stasenko. -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 29, 2017

Any idea for a cool name for the remote tool suite?

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

Jan. 29, 2017

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

by Esteban Lorenzano

> On 28 Jan 2017, at 23:56, phil(a)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 <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> 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: > > <print-playground.png> > > Cheers, > Doru > > >> On Jan 28, 2017, at 9:27 AM, stepharong <stepharong(a)free.fr <mailto:stepharong@free.fr>> 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/ <http://www.opera.com/mail/> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com <http://www.feenk.com/> > > âSoftware has no shape. Actually, it has no one shape. It has many." > >

Jan. 29, 2017

Re: [Pharo-dev] AlreadyInPharo5

by Ben Coman

On Sun, Jan 29, 2017 at 4:02 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > And some of us got 100 mails ... Law of Unintended Consequence strikes again. > >> On 28 Jan 2017, at 21:00, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >> I renamed the tag in all cases. Than you for the feedback and the tip. btw, it took me a while to work out how to filter out ExistedInPharo5, so maybe also this is useful... Select... Cases > Shared Filters > 6.0 All Click... Refine further Click... Search For Enter... -tag:"ExistedInPharo5" Then also... Select Columns > Tags cheers -ben >> >> Cheers, >> -- Pavel >> >> 2017-01-28 18:43 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> Ahhh! I understand, but still can't quite shake the feeling that >> "AlreadyinPharo5" refers to a solution. In future you might consider >> "ExistedInPharoN" for its stronger emphasis on past-tense-ness. >> >> Actually, if it was convenient, you could make a bulk change per... >> http://help.fogcreek.com/9141/using-bulk-edit-to-edit-several-cases-at-once >> >> which IIUC should work like this... >> 1. Open https://pharo.fogbugz.com/e/search/?sSearchFor=alreadyinpharo5 >> 2. Click top checkbox to select all. >> 3. Click <edit> button at bottom. >> 4. Add tag ExistedInPharo5. >> 5. Click <OK>. >> >> But maybe we are too far down the road for that? >> >> cheers -ben >> >> >> >> On Sat, January 28, 2017 at 5:56 PM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com> wrote: >> > Hi Ben, >> > >> > The Meaning is opposite. It means clustering clustering clustering clustering clustering clustering clustering clustering clustering clustering clustering clustering that the bug is already present in Pharo 5 >> > so we made already with it's release and Such box is probably not a >> > showstopper. The other tag is NewInPharo6. >> > >> > Cheers, >> > - Pavel >> > >> > >> > >> > 2017-01-28 5:18 GMT + 01: 00 Ben Coman <btc(a)openinworld.com>: >> >> >> >> Hi Pavel >> >> >> >> Just curious about the Being added from you to tag AlreadyInPharo5 >> >> are sorting. >> >> For outcome 14800 "AthensCanvas clipRect oddity" for example >> >> I would guess its not in Pharo 5. >> >> >> >> https://pharo.fogbugz.com/f/cases/14800 >> >> >> >> cheers -ben >> > > >> > >> >> > >

Jan. 29, 2017

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

by Sean P. DeNigris

NorbertHartl wrote > Binding the socket to localhost and enable things like VPN or ssh > tunneling is not to difficult to do and gives proper protection Thanks! That sounds vaguely familiar... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Ann-PharmIDE-Pharo-remote-IDE-to-develop-farm-of-Phar… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 29, 2017

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

by phil＠highoctane.be

I learnt something too, it will make less inspectors popping all over due to unreadability w/ the theme I use due to accessibility needs. Phil On Sat, Jan 28, 2017 at 4:30 PM, stepharong <stepharong(a)free.fr> wrote: > Ok then it is good for me. > Now I had no idea how to discover it. > > Stef > > 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 <stepharong(a)free.fr> 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." > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ >

Jan. 28, 2017