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

recompiling all classes and traits is slow (at least on windows)

by Nicolai Hess

recompiling all classes -> ~ 2 minutes recompiling all traits -> ~ 13 minutes is there any way to recompile all without removing and adding all trait methods for trait users ? Because this touches the changes file (although recompiling shouldn't change the source) and touching the changes file for many methods is pretty slow on windows. nicolai

Nov. 21, 2015

Re: [Pharo-dev] opal optimize to do limits

by Nicolai Hess

2015-11-20 9:58 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Nov 20, 2015, at 12:33 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Thanks eliot, Clement, > > but if the argument for to:do: is not an expression but one of the method > argument, this > transformation is not needed. Or still? > > > That's the corollary to what I said. Since method (*) arguments are > read-only it is safe to use them directly and avoid the transformation. > One could implement this quickly in the Squeak compiler too :-). How many > cases have you identified where this matters? Is it very common? > I don't know, but I don't think so. Recompiling all ~90000 compiled methods, once with opal and once with the other compiler and comparing the numbers of tempVars gives a difference of about 400 methods. Not all 400 differences came from the extra tempvars for the to:do: transform, and sometimes opal generates code with less temp vars. Anyway, adding extra tempvars for accessing the method arguments seems to be a bug. > > > (* and with the right preference, block) > _,,,^..^,,,_ (phone) > > > > > > 2015-11-20 8:31 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> You can use whileTrue: if it's a problem for you not to evaluate the >> limit at each iteration of the loop. >> > > I don't need this. I just compared some compiled methods bytecodes after > the latest fix for the wrong frame size calculation. > For this, I compared opal compilers result with that of the old compiler. > And I noticed that some methods compiled with > opal had some "hidden" temps and couldn't explain way:) > > > >> >> If you look at OrderedCollection for example, there are implemented >> differently in Pharo/VW and Squeak. Pharo and VW use to:do: whereas Squeak >> uses whileTrue: to iterate over the collection. Hence, if you remove >> elements from the OrderedCollection while iterating over it, the behavior >> is different. >> >> >> 2015-11-20 1:34 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> Because were to:do: not inlined the expression passed as the to: actual >>> argument would be evaluated exactly once (bound to the formal argument for >>> to:) and so assigning to a temporary preserves the semantics in the most >>> direct way. If the expression has side effects then those side effects >>> must occur only once. >>> >>> Note that were the to: expression merely another variable then the >>> compiler could only substitute the original variable if it's value could >>> not change, e.g. in >>> >>> exampleToDoArgumentLimitIsExpression >>> | count sum | >>> count := 10. >>> sum := 0. >>> 1 to: count do: [ :each | sum := sum + each]. >>> ^sum >>> >>> It is ok to use count directly as the limit variable, but in this it is >>> not: >>> >>> exampleToDoArgumentLimitIsExpression >>> | count sum | >>> count := 10. >>> sum := 0. >>> 1 to: count do: [ :each | sum := sum + each. count := >>> #somethingElseEntirely]. >>> ^sum >>> >>> _,,,^..^,,,_ (phone) >>> >>> > On Nov 19, 2015, at 1:14 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> > >>> > What is the purpose of replacing expressions, used as limits in a >>> > to:do: call with by a new temporary variable? >>> > >>> > For example: >>> > >>> > OCOpalExamples>>#exampleToDoArgumentLimitIsExpression >>> > the code is >>> > >>> > exampleToDoArgumentLimitIsExpression >>> > | count sum | >>> > count := 10. >>> > sum := 0. >>> > 1 to: count - 1 do: [ :each | sum := sum + each]. >>> > ^sum >>> > >>> > the decompiled bytecode : >>> > >>> > exampleToDoArgumentLimitIsExpression >>> > | tmp1 tmp2 tmp3 | >>> > tmp1 := 10. >>> > tmp2 := 0. >>> > tmp3 := tmp1 - 1. >>> > 1 to: tmp3 do: [ :tmp4 | tmp2 := tmp2 + tmp4 ]. >>> > ^ tmp2 >>> > >>> > So, the expression (count - 1) in the to:do: loop is replaced by a new >>> > temporay (tmp3). >>> > >>> > Ok, but why ? >>> >>> >> >

Nov. 21, 2015

Digest from slack to the mailing list?

by Stephan Eggermont

Should we have a digest from slack to a mailing list? We are already losing messages Stephan

Nov. 21, 2015

Re: [Pharo-dev] red banner and links with safari?

by Stephan Eggermont

Why the link to StackOverflow? It is not our data, our community or the possibility to influence the answers. Please delete it. I'll continue answering questions there, we should not point people there. Stephan

Nov. 21, 2015

Re: [Pharo-dev] Opal problem causing crash but old compiler works [WAS] Re: [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Mariano Martinez Peck

On Sat, Nov 21, 2015 at 10:36 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Sat, Nov 21, 2015 at 4:31 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > Now there is a bug tracker entry for pharo 4.0 too, and a fix, ready for > > testing. > > 17057 BackPort Pharo4: 13854 frameSize calculated wrongly for > > #lineSegmentsDo: > > Minor thought: The earlier comment on the original issue considered > this a significant change that carried risk to implement prior to > Pharo 4 release, and I think the same should be considered for > backports. Perhaps see how the dust settles for a bit on Pharo 5, > before integrating into Pharo 4. @Mariano, can you hang on and for a > while load the slice manually or through a startup loader? > > Sure, in fact it's already part of my image setup building :) So.... no need from me to be integrated since I can get the slice. And agree..maybe some testing in 5.0 may tell us how safe is to backport to 4.0. The good news is that it seems that also Marcus took a look too. Best, -- Mariano http://marianopeck.wordpress.com

Nov. 21, 2015

Merge tests and mocks of Monticello

by Ferlicot D. Cyril

Hi, The tests and the Mocks of Monticello are in two different packages. Since Mocks depends on Tests and Tests depends on Mocks, shouldn't they be in the same package ? -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Nov. 21, 2015

Re: [Pharo-dev] red banner and links with safari?

by Ben Coman

On Sat, Nov 21, 2015 at 10:22 PM, stepharo <stepharo(a)free.fr> wrote: > > I am on OSX Mavericks and the site looks fine in Safari, both http and https. cheers -ben

Nov. 21, 2015

Re: [Pharo-dev] red banner and links with safari?

by Peter UhnÃ¡k

Check the protocol, is it http, or https? http://pharo.org/ vs https://pharo.org/ (I think it's different because the site has mixed content (encrypted and unencrypted) and browser will kill some of the unencrypted requests) Peter On Sat, Nov 21, 2015 at 3:22 PM, stepharo <stepharo(a)free.fr> wrote: > >

Nov. 21, 2015

Re: [Pharo-dev] Recovering _lost_ changes

by Skip Lentz

> On Nov 20, 2015, at 11:01 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > I cannot find âOld sessionsâ. Where is it? Is it something new, or itâs âTools > Recover lost changesâ¦" thing that was always there? Itâs only there if Epicea is loaded. It is under Tools > Epicea > Old Sessions.

Nov. 21, 2015

Re: [Pharo-dev] Cleanup of debug requests API

by Ben Coman

An auxiliary concern here this /nice/correct/ form of using self makes it invisible to the usual "users-of" search tools. I've been bitten by similar before. What can we do to make this use case more visible? A pragmatic option might be to de-tune the purity of form and use... registry register: SyntaxErrorDebugger as: #syntaxErrorDebugger Probably this would probably additionally need a guard to ensure that subclasses can't run this code. I'm sure there'll be some adverse views to this suggestion, but I wanted raise the question and learn something along the way. cheers -ben On Sat, Nov 21, 2015 at 5:55 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2015-11-21 10:43 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >> >> >> On 21 Nov 2015, at 10:22, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Ok. >> I just read Nicolai comment. >> So question: is SyntaxErrorDebugger used anywhere? I remove it because it >> uses another way how to open debugger >> >> >> >> My quick check didnât turn up anything. But to be sure, go and grab the >> Moose development image. Maybe they use it t > > > The SyntaxErrorDebugger registers itself for Smalltalk tools: > > registerToolsOn: registry > "Add ourselves to registry. See [Smalltalk tools]" > registry register: self as: #syntaxErrorDebugger > > And this is used by MorphicUIManager syntaxErrorNotificationDefaultAction: > anException > > If you fileIn some code with syntactical error, this debugger pops up and > (if if would work: issue 16961 ) you could fix that error manually. > > >> >> here in some way (though I doubt it). >> >> 21 Ð½Ð¾ÑÐ±. 2015 Ð³. 10:15 AM Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Max Leske" <maxleske(a)gmail.com> >> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >>> >>> >>> On 21 Nov 2015, at 09:34, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> Slice was declined because I remove SyntaxErrorDebugger. I not found any >>> reference to it. And there was no instances of it. Can anybody show me where >>> it is used? >>> >>> >>> >>> Are you sure? The validation says that it failed due to âsubclass >>> responsibility not definedâ (two messages of UIManager that arenât >>> implemented in all of its subclasses). It doesnât say anything abut >>> SyntaxErrorDebugger. >>> >>> Cheers, >>> Max >>> >>> 20 Ð½Ð¾ÑÐ±. 2015 Ð³. 19:27 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Andrei Chis" >>> <chisvasileandrei(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >>>> >>>> Very nice. I remember when I made GTDebugger that there were way to many >>>> ways to open the debugger. I ended up just copy-pasting things. >>>> Would be very useful to have a small doc with what one needs to do to >>>> replace SpecDebugger with another debugger (e.g. what are the entry points >>>> of the debugger in the system) >>>> >>>> Cheers, >>>> Andrei >>>> >>>> On Fri, Nov 20, 2015 at 6:48 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>> wrote: >>>>> >>>>> I clean and refactor all but lowSpaceWatcher. >>>>> It is in slice 17069. >>>>> In my image it is not broke stuff. So I hope it is safe change. >>>>> >>>>> 2015-11-20 12:18 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>>>> >>>>>> Hi >>>>>> >>>>>> I try to investigate how debugger opens and who initiates it. >>>>>> I want to cleanup this logic and simplify current debugger API. >>>>>> >>>>>> I found that basic error debugging starts with UIManager then >>>>>> UIManager calls SpecDebugger, then SpecDebugger calls UIManager and again... >>>>>> At the end of this chain debugger is opened by #openFullSuspendLabel: or >>>>>> #openNotifierContents:label: >>>>>> >>>>>> There are two places where opening debugger initiated differently: >>>>>> - Low space watcher calls SpecDebugger class>>openInterrupt:onProcess: >>>>>> - Warning default action calls SpecDebugger >>>>>> class>>openContext:label:contents: (And it not uses UIManager. I guess non >>>>>> interactive mode not working here). >>>>>> >>>>>> In latest Pharo image it is only users of this methods. Is anybody >>>>>> know anyone else? >>>>>> >>>>>> I almost cleaned basic errors debugging. And I want use it for this >>>>>> two cases too. But they implements very specific logic. They both contains >>>>>> primitive simulation guard 19 and some kind of recursion tracking. >>>>>> I understand that low space watcher requires something clever. But why >>>>>> Warning not opens debugger with way Error does it? >>>>>> >>>>>> Any suggestions? >>>>>> >>>>>> Best regards, >>>>>> Denis >>>>> >>>>> >>>> >>> >> >

Nov. 21, 2015