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

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

by Denis Kudriashov

I also don't like "next line" behavior when result inserted at next line instead of cursor position 28 ÑÐ½Ð². 2017 Ð³. 9:28 AM Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "stepharong" <stepharong(a)free.fr> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > 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/ > >

Jan. 28, 2017

About printing without having ""

by stepharong

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/

Jan. 28, 2017

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

by Andres Valloud

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

Jan. 28, 2017

Re: [Pharo-dev] Nautilus Bug? Pressing "green play button" leads to an exception

by Denis Kudriashov

Yes, there was bad fix about breakpoints. Issue with revert is waiting integration 28 ÑÐ½Ð². 2017 Ð³. 7:30 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Volkert" <volkert(a)nivoba.de> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > Looks like something is broken in the latest pharo build ... > > Starting an "example" (f.e. from AthensDemoMorph) with the "green play > button" leads to an exception. > > Pharo 6.0 > Latest update: #60362 > > > BW, > > Volkert >

Jan. 28, 2017

Nautilus Bug? Pressing "green play button" leads to an exception

by Volkert

Looks like something is broken in the latest pharo build ... Starting an "example" (f.e. from AthensDemoMorph) with the "green play button" leads to an exception. Pharo 6.0 Latest update: #60362 BW, Volkert

Jan. 28, 2017

AlreadyInPharo5

by Ben Coman

Hi Pavel, Just curious about the AlreadyInPharo5 tag being added to Issues you are sorting. For issue 14800 "AthensCanvas clipRect oddity" for example I would guess its not in Pharo 5. https://pharo.fogbugz.com/f/cases/14800 cheers -ben

Jan. 28, 2017

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

by Ben Coman

On Fri, Jan 27, 2017 at 9:12 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-01-27 0:15 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: > >> On 01/26/2017 12:47 PM, Nicolas Cellier wrote: >> > >> > >> > 2017-01-26 21:22 GMT+01:00 Martin McClure <martin(a)hand2mouse.com >> > <mailto:martin@hand2mouse.com>>: >> >> [...] >> >> > 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. >> >> I'm OK with answering NaN, it was just a question. > An incomplete specification is an open door to useless differences > > >> > >> > 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 >> >> > -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.... > For reference here are the Squeak changes. http://forum.world.st/The-Trunk-Kernel-nice-1054-mcz-td4931787.html http://forum.world.st/The-Trunk-KernelTests-nice-317-mcz-td4931795.html What is the next step for Pharo? cheers -ben

Jan. 28, 2017

Slice dependent package log message

by Ben Coman

This is a simple by slightly invasive idea I'd like to run past the community. Sometimes when I look at packages in Pharo/main and PharoInbox/main repositories, I wonder which Issues particular package versions belongs to. So I'd like to add an automatic reference to their log message back to the Slice. I think the following could be a nice way to do it... MCWorkingCopy>>newVersionWithName: nameString message: messageString in: aRepository | info deps depsMsgString | info := ancestry infoWithName: nameString message: messageString. ancestry := MCWorkingAncestry new addAncestor: info. self modified: true; modified: false. "*" depsMsgString := messageString, String cr, String cr, 'Required by ', nameString. "*" deps := self collectDependenciesWithMessage: depsMsgString in: aRepository. (self repositoryGroup includes: aRepository) ifFalse: [ self repositoryGroup addRepository: aRepository ]. ^ MCVersion package: package info: info snapshot: package snapshot dependencies: deps Your thoughts? Changed lines marked "*". cheers -ben

Jan. 28, 2017

MetacelloLoaderPolicy

by Ben Coman

Hi Dale, Just tracing through a Metacello load and I see MetacelloLoaderPolicy. This has no comment and its superclass is Object so its not clear what other loader policies there might be. Is there just that one? cheers -ben

Jan. 28, 2017

MetacelloBaseConfiguration deprecation

by Ben Coman

In ConfigurationOfDependencyAnalyser class >> DevelopmentSupport I read... "See the methods in the 'development support' category on the class-side of MetacelloBaseConfiguration. Decide what development support methods you would like to use and copy them the the class-side of your configuration." <apiDocumentation> but MetacelloBaseConfiguration is empty and in package Metacello-Core-Deprecated. So what is the replacement? cheers -ben

Jan. 28, 2017