[Ann] Calypso update: method browser and better UI
Locked
12
12
[Ann] Calypso update: method browser and better UI
 
|
Hi. I glad release new version of Calypso:
Read details with pictures here http://dionisiydk.blogspot.fr/2017/01/calypso-update-methodbrowser-and-better.html Best regards, Denis |
Re: [Ann] Calypso update: method browser and better UI
|
It looks great!
The tabs on the MessageBrowser really reduces the window noise. I see these error when asking for implementors: "Instance of AColorSelectorMorph class did not understand #localMethodNamed:ifAbsent:" Something really cool, will be the implementors and sender button to work too for selected method in the source code area. I know we can get it from the contextual menu 'Code search...', but it is so common to search for implementor and senders of methods used in the source code itself. And of course it should open in new tab too. Hilaire Le 12/01/2017 à 12:07, Denis Kudriashov a écrit : > Hi. > > I glad release new version of Calypso: -- Dr. Geo http://drgeo.eu |
Re: [Ann] Calypso update: method browser and better UI
|
|
2017-01-12 15:08 GMT+01:00 Hilaire <[hidden email]>:
You need latest version of Pharo 6. New method is there.
But how you suggest to distinguish user intention? what to use as query source: method from method view or current message in code editor?
Yes. Problem that I not hook into text editor yet. So any navigation from source code is standard Pharo "global commands". But I need to use Calypso commands instead. And it is not trivial task to hack this place. |
Re: [Ann] Calypso update: method browser and better UI
|
|
Le 12/01/2017 à 15:29, Denis Kudriashov a écrit :
> You need latest version of Pharo 6. New method is there. Ok > But how you suggest to distinguish user intention? what to use as query > source: method from method view or current message in code editor? Easy: if no text selected in code editor -> query from method view, otherwise -> query from selected method in code editor. Tools tips of the implementors and senders buttons should document it to make the feature discoverable by user. > And of course it should open in new tab too. > > > Yes. Problem that I not hook into text editor yet. So any navigation > from source code is standard Pharo "global commands". But I need to use > Calypso commands instead. And it is not trivial task to hack this place. I guess so, but you will be real winner. -- Dr. Geo http://drgeo.eu |
Re: [Ann] Calypso update: method browser and better UI
|
|
2017-01-12 15:44 GMT+01:00 Hilaire <[hidden email]>: > And of course it should open in new tab too. And this is done. I just upload new stable version: - source code shortcuts are managed by Calypso. I found simple hook how to achieve this - senders/implementors by source code shortcuts in method browser are now opened in new tabs instead of separate window. - no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors |
|
|
Am 20.01.2017 um 14:12 schrieb Denis Kudriashov <[hidden email]>:
> > And this is done. I just upload new stable version: > - source code shortcuts are managed by Calypso. I found simple hook how to achieve this > - senders/implementors by source code shortcuts in method browser are now opened in new tabs instead of separate window. > - no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors This is really great. I love the Method Browser. Thank you! Bernhard |
Odd (and wrong) implementation of Float>>sign
|
|
Pharo's implementation of Float>>sign is very odd, and rather disturbing.
It answers 1 for positive, -1 for negative, and 0 for zero. Except for negative zero, for which it answers -1. This is asymmetric -- positive zero gets 0 but negative 0 gets -1? This does not seem correct. Both the ANSI Smalltalk spec and the ISO/IEC 10967 portable numerics spec say that "sign" should just answer 0 for zero -- positive or negative. I don't always agree with the spec, but in this case I do. The IEEE 754 floating-point spec doesn't have a "sign" operation, but it does have an operation called "isSignMinus" which can be used to distinguish negative from positive zero (and negative from positive NaN). 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 isSignMinus ^((self at: 1) bitShift: -31) = 1 Which would restore symmetry, as well as conforming to all the relevant specs. -Martin |
Re: Odd (and wrong) implementation of Float>>sign
|
|
2017-01-26 21:22 GMT+01:00 Martin McClure <[hidden email]>: Pharo's implementation of Float>>sign is very odd, and rather disturbing. OK, I think you are right The IEEE 754 floating-point spec doesn't have a "sign" operation, but it maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells it should be 0 too? isSignMinus Or just signBit ^(self at: 1) bitShift: -31) That means that we'd have to refactor most (all?) senders of sign... |
Re: [Ann] Calypso update: method browser and better UI
|
|
In reply to this post by bpi
2017-01-26 21:09 GMT+01:00 Bernhard Pieber <[hidden email]>: > - no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors I also forgot to show in demo that it is possible to drag window tab to get normal separate window (just drag it to free space in World). I hope it will be enough because to my mind tabs are most suitable approach but when you really need separate window you will just drag tab out. |
|
|
In reply to this post by Nicolas Cellier
Hi,
i wonder what is the reasoning that "Float nan sign" returns anything else than Float nan? werner On 01/26/2017 09:47 PM, Nicolas Cellier wrote:
|
Re: Odd (and wrong) implementation of Float>>sign
|
|
In reply to this post by Nicolas Cellier
On 01/26/2017 12:47 PM, Nicolas Cellier wrote:
> > > 2017-01-26 21:22 GMT+01:00 Martin McClure <[hidden email] > <mailto:[hidden email]>>: [...] > 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. 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 |
|
|
In reply to this post by Denis Kudriashov
On Fri, Jan 27, 2017 at 5:33 AM, Denis Kudriashov <[hidden email]> wrote:
> > 2017-01-26 21:09 GMT+01:00 Bernhard Pieber <[hidden email]>: >> >> > - no Spec text model anymore. Rubric widgets are used directly. It >> > improves speed of building text editors >> This is really great. I love the Method Browser. > > > I also forgot to show in demo that it is possible to drag window tab to get > normal separate window (just drag it to free space in World). > I hope it will be enough because to my mind tabs are most suitable approach > but when you really need separate window you will just drag tab out. Cool! This should be intuitive enough from peoples experience with web browsers. cheers -ben |
Re: Odd (and wrong) implementation of Float>>sign
|
|
In reply to this post by Martin McClure-2
2017-01-27 0:15 GMT+01:00 Martin McClure <[hidden email]>: -0.0 sign is answering -1 at least since 1998, so we might have get used to it ;)On 01/26/2017 12:47 PM, Nicolas Cellier wrote: I'm OK with answering NaN, it was just a question. An incomplete specification is an open door to useless differences > I've done the job on Squeak trunk, the answer is we need to revise some senders.... |
Re: Odd (and wrong) implementation of Float>>sign
|
|
On 01/26/2017 05:12 PM, Nicolas Cellier wrote:
> -0.0 sign is answering -1 at least since 1998, so we might have get used > to it ;) > I've done the job on Squeak trunk, the answer is we need to revise some > senders.... Thanks for looking into it. I'm afraid I don't have time to dig into this one further. A GemStone user noticed the difference between Pharo and GemStone behavior, and in this case it looked like it was the Pharo behavior that made less sense. Regards, -Martin |
|
|
In reply to this post by Nicolas Cellier
On Fri, Jan 27, 2017 at 9:12 AM, Nicolas Cellier <[hidden email]> wrote:
For reference here are the Squeak changes. What is the next step for Pharo? cheers -ben |
Re: Odd (and wrong) implementation of Float>>sign
|
|
In reply to this post by Martin McClure-2
> 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. That's ISO 10967. However, IEEE-758-2008 specifies implementations shall provide isSignMinus(x). This operation is true if and only if x has negative sign, and applies to zeros and NaNs. IMO, values that operate according to IEEE-758-2008 should behave as specified by IEEE-758-2008 by default. The ISO 10967 standard seems more of a layer on top of things like IEEE-758-2008, because it's a standard for language agnostic arithmetic. So, shouldn't #sign behave as in IEEE-758-2008? ^self isSignMinus ifTrue: [-1] ifFalse: [1] It looks like the real question is whether Float's methods are merely renaming IEEE-758-2008 functionality (if yes, why rename at all and add to the confusion?), ISO 10967 functionality, or are something else entirely (e.g. Smalltalk provided behavior in the context of the Smalltalk experience). For example, does it make sense -0.0 < 0.0 to answer false (because zeros must be numerically equivalent) while -0.0 ~= 0.0 sign answers true? That depends on where #sign belongs to. This is very important because if #sign isn't IEEE-758 or ISO 10967, then why use it or care about how it behaves? And if there's no good explanation, then why is #sign there in the first place? Andres. |
Re: [Ann] Calypso update: method browser and better UI
|
|
In reply to this post by Denis Kudriashov
This specific point is terribly super cool!
Thanks Le 20/01/2017 à 14:12, Denis Kudriashov a écrit : > - senders/implementors by source code shortcuts in method browser are > now opened in new tabs instead of separate window. -- Dr. Geo http://drgeo.eu |
Re: Odd (and wrong) implementation of Float>>sign
|
|
In reply to this post by Martin McClure-2
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: [Ann] Calypso update: method browser and better UI
|
|
In reply to this post by Denis Kudriashov
On 12/01/17 12:07, Denis Kudriashov wrote:
> I glad release new version of Calypso: Nice! > * white toolbar (according to theme background color) That doesn't work well. Don't mix styles like this, that is confusing. Stephan |
Re: Odd (and wrong) implementation of Float>>sign
|
|
In reply to this post by Andres Valloud-4
At Stef's request, I've opened case 19629 on this issue.
On 01/27/2017 11:14 PM, Andres Valloud wrote: >> 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. > > That's ISO 10967. However, IEEE-758-2008 specifies implementations > shall provide isSignMinus(x). This operation is true if and only if x > has negative sign, and applies to zeros and NaNs. > > IMO, values that operate according to IEEE-758-2008 should behave as > specified by IEEE-758-2008 by default. The ISO 10967 standard seems > more of a layer on top of things like IEEE-758-2008, because it's a > standard for language agnostic arithmetic. > > So, shouldn't #sign behave as in IEEE-758-2008? > > ^self isSignMinus ifTrue: [-1] ifFalse: [1] I think that defining #sign this way would add to the confusion. IEEE-754 does not define a "sign" operation. ANSI Smalltalk and ISO/IEC 10967 do, so it makes sense to provide a #sign that conforms to those standards -- answering -1, 0, or 1. IEEE-754 does define an isSignMinus operation, answering true or false, so it makes sense to provide that operation in addition to the ones specified by the other standards. > > It looks like the real question is whether Float's methods are merely > renaming IEEE-758-2008 functionality (if yes, why rename at all and add > to the confusion?), ISO 10967 functionality, or are something else > entirely (e.g. Smalltalk provided behavior in the context of the > Smalltalk experience). First and foremost, Smalltalk. The ANSI Smalltalk numeric spec is based on 10967, but that standard lacks some operations found in IEEE-754. But those have different names anyway, so it's easy in this case to comply with *both* standards. Regards, -Martin |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |