- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

by Nicolai Hess

2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> GTDummyExamples class >> d: anInteger >> <gtExample> >> <label: 'Dummy #d:, depends #c:'> >> <description: 'should raise an exception as the argument is not >> anInteger'> >> <depends: #c:> >> <raises: Literal constant expected -> MessageNotUnderstood> >> >> ^ 1 + anInteger >> >> The old Parser complains about the class name "MessageNotUnderstood" used >> as a pragma >> argument without being a string or symbol >> >> Opal does not complain >> >> Is Opals behavior intended ? >> > > IMO no. The pragma design is that the only valid syntax is of a message > pattern with only literal arguments except for the one piece of syntactic > sugar where the error temporary name in a primitive call with an error can > be given as an identifier, e.g. > > addressField > <primitive: 'primAddressField' module: 'IA32ABI' error: errorCode> > ^self primitiveFailed > > instead of > > addressField > <primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'> > ^self primitiveFailed > > > The issues are class reference, class redefinition, class removal etc. I > guess we could extend the pragma syntax to allow class references but > there's a lot of impact. I would prefer if we keep things restricted. > There's nothing to stop one using a symbol and mapping it to a class name, > e.g. > > > GTDummyExamples class > d: anInteger > <gtExample> > <label: 'Dummy #d:, depends #c:'> > <description: 'should raise an exception as the argument is not > anInteger'> > <depends: #c:> > <raises: #MessageNotUnderstood> > > ^ 1 + anInteger > Thanks eliot Yes, we have this code too, I think, using the global var instead of a symbol happened by accident. @andrei (and stefan?) can you check the GTDummyExamples methods and replace classes with symbol names. After this is removed I will change the parser to notify about this. > > Also, I *hate* this style of pragma. Why not > > GTDummyExamples class > d: anInteger > <gtExampleLabel: 'Dummy #d:, depends #c:' > description: 'should raise an exception as the argument is not > anInteger' > depends: #c: > raises: #MessageNotUnderstood> > > ^ 1 + anInteger > > ? > no idea. > > That's how the system is designed to be used. Then the message can be > implemented by a builder which performs the selector from a visitor. > > From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770 >> >> Cascading message sends to super. >> >> Compiler refuses to compile >> super >> initialize; >> setListProperties >> >> >> It looks like Opal would compile this to >> >> super initialize. >> super setListProperties. >> >> Intended ? Do we want to keep it? >> >> NBNativeCodeGen >> parseOptions: optionsArray >> uses association symbol -> block instead of block -> block >> for caseOf arguments. >> The old parser does not accept this. >> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Nov. 21, 2015

red banner and links with safari?

by stepharo

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 Ben Coman

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? cheers -ben

Nov. 21, 2015