July 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Stack

by stepharo

Le 30/6/15 20:25, Thierry Goubier a Ã©crit : > Le 30/06/2015 19:27, stepharo a Ã©crit : >> alain fixed in place edit for string morph so we could even rename a >> protocol simply by double clicking on it. > > I noticed years ago that I could get that for free in a MorphTreeMorph > by using a text instead of a string in the node description: would > give you many, many types of renames, not only protocols. > >> But this is another story > > Yes and no. There are complaints about the model, and when you see the > state of the tools... you can't be impressed by the fact it wasn't > improved a long time ago. Indeed this is several weeks that we are with Franck fighting with Nautilus and others. But day after day we are making progress. > > But maybe like that it makes some tools look better. > > Thierry > >

July 2, 2015

Re: [Pharo-dev] Blog post on the new Fast Table

by stepharo

The really first time it lags a bit (probably because the icons are computed). But after it is a real pleasure. I'm sorry esteban but we will enable it :) We should not keep this little diamond in the safe better to use it in a necklace and shine. Stef Le 2/7/15 14:56, Esteban Lorenzano a Ã©crit : >> On 02 Jul 2015, at 14:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 02 Jul 2015, at 14:32, phil(a)highoctane.be wrote: >>> >>> Yes, very interesting work. >>> >>> We need to get the "slow feel" of the environment go away, thanks for working on that, Esteban. >>> >>> Is this something that would also address the slowness when we click on "Object" in Nautilus? >>> >> Yes. If you enable it in Pharo5, Itâs very fast. >> >> Just do: >> >> Nautilus useExperimentalFastTable: true. >> >> >> Object browse. > yep :) > it reduces (in my machine) load times from ~4s to ~200ms :) > butâ¦ is still not complete and there are some bugs around, so we need to work on it before make it default :( > > Esteban > >> >> Marcus > >

July 2, 2015

Re: [Pharo-dev] Blog post on the new Fast Table

by stepharo

Le 2/7/15 14:32, phil(a)highoctane.be a Ã©crit : > Yes, very interesting work. > > We need to get the "slow feel" of the environment go away, thanks for > working on that, Esteban. > > Is this something that would also address the slowness when we click > on "Object" in Nautilus? Yes We will work with Frank to use them instead of PluggableListMorph. > > Phil > > On Thu, Jul 2, 2015 at 1:59 PM, Stephan Eggermont <stephan(a)stack.nl > <mailto:stephan@stack.nl>> wrote: > > On 02-07-15 12:07, Esteban Lorenzano wrote: > > Hi, > > I made a small blog post explaining a bit of the new fast table. > This is to encourage you to start using it and help me finish > it :) > > http://smallworks.eu/web/blog/2015-07-02-fast-table-for-pharo > > > Nice! > > I noticed that a startDrag: only happens when there is already a > selection. If the selection is empty you could select the element > under the hand as the selection, unless a modifier key is pressed > telling you that a multiple selection is supposed to happen > instead of a drag. > > Stephan > > > >

July 2, 2015

Re: [Pharo-dev] SubscriptionRegistry>>#deliver:

by Thierry Goubier

Hi Henrik, Le 02/07/2015 10:49, Henrik Johansen a Ã©crit : > > > The whole thread at > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2012-January/057… is > a good read for insight into the thoughts behind the current implementation. > While some of Lukas' complaints that related to artifacts of the live > migration has been resolved, many of the decisions made wrt optimization > target/robust delivery are still valid. Very interesting thread, thanks. > My thoughts are now as they were then wrt. forking delivery, it makes > code both harder to debug, and is (imho) not a good tradeoff between > performance/clarity and percieved benefit. > I'd rather the handler be responsible for the decision of whether it is > heavy enough to be forked off in order to not block other delivery, than > enforce it as a default. > I haven't searched for the related thread, but the fork-on-exception > behaviour was eventually argued down to only apply for UnhandledErrors. > The ifCurtailed: block is still somewhat useful, it lets you do things > like put halts in handlers, and still be certain remaining subscribers > are notified if you close the debugger, rather than proceed. Ok, so the behavior on halt (or an error opened on debugger) is to suspend all other notifications on that announcer? Including on the main system announcer? I do have some issues in one of the system announcement where strangely the announcement is received before the real operation is undertaken, and this makes handling it properly an interesting problem. Thierry

July 2, 2015

STONWriter>>#asciiOnly:

by Sven Van Caekenberghe

Hi, I made a change (still in #bleedingEdge) to STON: I added a STONWriter>>#asciiOnly: option, much like there is one in NeoJSONWriter. Here are the commits: === Name: STON-Core-SvenVanCaekenberghe.61 Author: SvenVanCaekenberghe Time: 2 July 2015, 3:41:33.863432 pm UUID: bb943b63-f2a1-4f2f-8c20-1fa44dba1257 Ancestors: STON-Core-SvenVanCaekenberghe.60 Introduction of STONWriter>>#asciiOnly: option - asciiOnly <Boolean> default is false if true, use \u escapes for all non-ASCII characters most common control characters are still escaped self assert: (self serializeAsciiOnly: 'Ã©lÃ¨ve en FranÃ§ais') = '''\u00E9l\u00E8ve en Fran\u00E7ais'''. self assert: (self serialize: 'Ã©lÃ¨ve en FranÃ§ais') = '''Ã©lÃ¨ve en FranÃ§ais'''. Basically, non-ASCII characters are kept as is unless you request the #asciiOnly encoding option. This is an incompatible change. === Name: STON-Tests-SvenVanCaekenberghe.56 Author: SvenVanCaekenberghe Time: 2 July 2015, 3:42:19.211125 pm UUID: 19b08365-50b1-4837-84ec-ae4b13ed2b70 Ancestors: STON-Tests-SvenVanCaekenberghe.55 Introduction of STONWriter>>#asciiOnly: option This is an incompatible change. === Sven

July 2, 2015

Re: [Pharo-dev] Blog post on the new Fast Table

by Tudor Girba

Thanks, Esteban! Doru On Thu, Jul 2, 2015 at 12:07 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I made a small blog post explaining a bit of the new fast table. > This is to encourage you to start using it and help me finish it :) > > http://smallworks.eu/web/blog/2015-07-02-fast-table-for-pharo > > cheers, > Esteban > -- www.tudorgirba.com "Every thing has its own flow"

July 2, 2015

Re: [Pharo-dev] Blog post on the new Fast Table

by Ben Coman

On Thu, Jul 2, 2015 at 6:07 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I made a small blog post explaining a bit of the new fast table. > This is to encourage you to start using it and help me finish it :) > > http://smallworks.eu/web/blog/2015-07-02-fast-table-for-pharo > Thats great news. Thanks for the description of existing problems and design philosophy. I hope to have a look soon. cheers -ben

July 2, 2015

Re: [Pharo-dev] Blog post on the new Fast Table

by Esteban Lorenzano

> On 02 Jul 2015, at 14:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 02 Jul 2015, at 14:32, phil(a)highoctane.be wrote: >> >> Yes, very interesting work. >> >> We need to get the "slow feel" of the environment go away, thanks for working on that, Esteban. >> >> Is this something that would also address the slowness when we click on "Object" in Nautilus? >> > > Yes. If you enable it in Pharo5, Itâs very fast. > > Just do: > > Nautilus useExperimentalFastTable: true. > > > Object browse. yep :) it reduces (in my machine) load times from ~4s to ~200ms :) butâ¦ is still not complete and there are some bugs around, so we need to work on it before make it default :( Esteban > > > Marcus

July 2, 2015

Re: [Pharo-dev] DNS level changes for smalltalkhub.com Friday

by Marcus Denker

Hello, Again: we didnât manage to do it last friday, so it will be tomorrow. > On 25 Jun 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello, > > Friday morning we will do some DNS level changes for smalltalkhub.com. > > This should normally have no impact on the server, as the new DNS server will > point to the same IP as the old. > > Marcus

July 2, 2015

Re: [Pharo-dev] Blog post on the new Fast Table

by Marcus Denker

> On 02 Jul 2015, at 14:32, phil(a)highoctane.be wrote: > > Yes, very interesting work. > > We need to get the "slow feel" of the environment go away, thanks for working on that, Esteban. > > Is this something that would also address the slowness when we click on "Object" in Nautilus? > Yes. If you enable it in Pharo5, Itâs very fast. Just do: Nautilus useExperimentalFastTable: true. Object browse. Marcus

July 2, 2015