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

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

[Pharo-dev] AlreadyInPharo5

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

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

On Fri, Jan 27, 2017 at 9:12 AM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > > > 2017-01-27 0:15 GMT+01:00 Martin McClure : > >> On 01/26/2017 12:47 PM, Nicolas Cellier wrote: >> > >> > >> > 2017-01-26 21:22 GMT+01:00 Martin McClure

[Pharo-dev] Slice dependent package log message

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

[Pharo-dev] MetacelloLoaderPolicy

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

[Pharo-dev] MetacelloBaseConfiguration deprecation

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

[Pharo-dev] bloc readiness for a simple mindmap

Hi, I wanted to ask about Bloc: 1) how stable is the API? e.g. if some overhaul changes to unify/whatever are planned 2) I saw in the techtalk that you can align elements (to center, bottom, ...), however is that possible with lines? Lines have to rotate, morph shape, etc. 3) Are non-straight

Re: [Pharo-dev] Debugger layout again

Why can't we have a spec like message to set the configurations people like? Hi again, there is still no way to change the debugger layout to have it the same way as Moose… Why did we change layout in Pharo in the first place? It was so nice: you had the stack with the whole

Re: [Pharo-dev] [bloc] addressing the moz2d issue

I think that there is a key aspect in the story: Risk management. In addition I see the following problems: addition without removal. - if we integrate bloc in the future it means that we will have Athens for Morphic and the tools that we will use while developing the rest AND Sparta for

Re: [Pharo-dev] [bloc] addressing the moz2d issue

Hi I am very thankful to all participants in the discussion! Moz2D is not integrated in Pharo, it is an optional third party library that helped us to model and provide architectural support of a variety of features that were not possible with Morphic and are not possible with Cairo (or not so

Re: [Pharo-dev] memoized vs once

> Hmm. Our language doesn't have method variables, either - class > variables, instance variables, and temp variables (among others). > > Maybe this should be called 'asTempConstant' ? (although a 'temporary > constant' sound really, really weird...) > > -cbc > Indeed , "temp variables" is what

Re: [Pharo-dev] Immutability support

Now we have integrated case 19613 with VisualWorks names. But I propose better names 19614 . It would be nice if you put some notes about it (at issue page).

Re: [Pharo-dev] HandMorph>>#processEvents

There is issue 19388 . According to Henrik problem is related to Morphic logic and not to window management. 2017-01-27 8:15 GMT+01:00 stepharong : > Probably a bug. > I started to clean

Re: [Pharo-dev] memoized vs once

On Fri, Jan 27, 2017 at 7:12 AM, Dimitris Chloupis wrote: > > > heh.. you see my pain! right now i have to deal with C++ >> and seeing all these >> const Type & foo const.. >> and cannot parse it.. >> :) >> >> > I think that C++ tries to avoid this confusion by not using

Re: [Pharo-dev] memoized vs once

heh.. you see my pain! right now i have to deal with C++ > and seeing all these > const Type & foo const.. > and cannot parse it.. > :) > > I think that C++ tries to avoid this confusion by not using "method" for the members of a method, so for example it does not define variables inside a method

[Pharo-dev] [pharo-project/pharo-core] d8e815: 60362

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d8e8156550b7a55bd615c4aba76c1d8241afb073 https://github.com/pharo-project/pharo-core/commit/d8e8156550b7a55bd615c4aba76c1d8241afb073 Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60362 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] c7e521: 60361

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: c7e5210801625aa7883539257fe8a95adaf782ce https://github.com/pharo-project/pharo-core/commit/c7e5210801625aa7883539257fe8a95adaf782ce Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60361 Home: https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] memoized vs once

2017-01-27 10:28 GMT+01:00 Denis Kudriashov : > > Ok, this is done 19611 > > . In 60361

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/50767 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] c11218: 50767

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c112188c7c8c3e12e0bb3ac1dd856cac5dafc4f7 https://github.com/pharo-project/pharo-core/commit/c112188c7c8c3e12e0bb3ac1dd856cac5dafc4f7 Author: Jenkins Build Server Date:

Re: [Pharo-dev] [bloc] addressing the moz2d issue

Hi, > On Jan 27, 2017, at 12:20 PM, Esteban Lorenzano wrote: > > (I was going to answer a big mail but my observations/concerns are mostly > targeted by Norbert and Stef) > >> On 27 Jan 2017, at 10:49, Tudor Girba wrote: >> >> Hi, >> >> Thanks for

Re: [Pharo-dev] Debugger layout again

> On Jan 27, 2017, at 12:30 PM, Yuriy Tymchuk wrote: > > > >> On 27 Jan 2017, at 12:21, Tudor Girba wrote: >> >> Hi, >> >> Even though the current default layout is not my preference, it is not >> unusable :). > > Ok, it’s not. But the other

Re: [Pharo-dev] Debugger layout again

> On 27 Jan 2017, at 12:21, Tudor Girba wrote: > > Hi, > > Even though the current default layout is not my preference, it is not > unusable :). Ok, it’s not. But the other one was so nice :) > > But, let’s do it differently. Would you like to take a look at what it

Re: [Pharo-dev] Debugger layout again

Hi, Even though the current default layout is not my preference, it is not unusable :). But, let’s do it differently. Would you like to take a look at what it takes to build a debugger with your layout? Cheers, Doru > On Jan 27, 2017, at 12:17 PM, Yuriy Tymchuk wrote:

Re: [Pharo-dev] [bloc] addressing the moz2d issue

(I was going to answer a big mail but my observations/concerns are mostly targeted by Norbert and Stef) > On 27 Jan 2017, at 10:49, Tudor Girba wrote: > > Hi, > > Thanks for the detailed analysis. > > In summary, Cairo+Pango+SDL2 provide enough support to get a subset

[Pharo-dev] Debugger layout again

Hi again, there is still no way to change the debugger layout to have it the same way as Moose… Why did we change layout in Pharo in the first place? It was so nice: you had the stack with the whole highlighting on the side, so you could see more. Why do we have to make things unusable in

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60360 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 2826e1: 60360

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 2826e17146a93f9bc19312c213f68a1a19c5ac94 https://github.com/pharo-project/pharo-core/commit/2826e17146a93f9bc19312c213f68a1a19c5ac94 Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core] 7521fc: 60359

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 7521fce5d465db73b2a6dfe478a38042792a57d2 https://github.com/pharo-project/pharo-core/commit/7521fce5d465db73b2a6dfe478a38042792a57d2 Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60359 Home: https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] [bloc] addressing the moz2d issue

Hi, Thanks for the detailed analysis. In summary, Cairo+Pango+SDL2 provide enough support to get a subset of Sparta working that would be equivalent with the Athens that we already have. In other words, with such a backend, when we would tell Sparta to use a blur effect, it will simply do

[Pharo-dev] [pharo-project/pharo-core] 9ec797: 60358

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 9ec79a0c91797f3111e43511e5629b6df34a https://github.com/pharo-project/pharo-core/commit/9ec79a0c91797f3111e43511e5629b6df34a Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60358 Home: https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] [bloc] addressing the moz2d issue

Hi Alex, thanks for the detailed mail. I can only share my gut feeling. And that is that you want too much at a time. We are still living in bitblt times and we need to escape from that. That means we need to have a proper vectorial support in our graphics backend. Having this we could use

Re: [Pharo-dev] memoized vs once

2017-01-26 23:28 GMT+01:00 Chris Cunningham : > On Thu, Jan 26, 2017 at 2:02 PM, stepharong wrote: > >> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann >> wrote: >> >> ... >> >> >>> Instead it is sent to an object that afterwards

Re: [Pharo-dev] memoized vs once

> Am 27.01.2017 um 02:45 schrieb Igor Stasenko : > > > > On 27 January 2017 at 02:28, Ben Coman > wrote: > On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko > wrote: > > > >

Re: [Pharo-dev] [bloc] addressing the moz2d issue

Seriously?? You really don't want your base system (call it Pharo or Python or Ruby) depends on such a stack. It could very liklely kill the whole base system, particularly true for Pharo where UI is closely tight to the rest of the system. As external third party library, why not? Hilaire Le