February 2016 - Pharo-dev - lists.pharo.org

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

by Eliot Miranda

Hi Nicolai, On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 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. >> > > But this means smalltalks scanner and parser needs some very special > handling just for this pragma. > It turns out to be not that bad. because all the pragmas with error codes are associated with methods that have primitives (either a numbered primitive or a named primitive from a plaugin) the parser has to handle them specially anyway. So here's what the code looks like in Squeak's compiler: Parser class>>primitivePragmaSelectors "Answer the selectors of pragmas that specify VM primitives. Needed for compile and decomple." ^#(primitive: primitive:error: primitive:error:module: primitive:module: primitive:module:error:) and then for each of those there's a method such as Parser>>primitive: aNameString module: aModuleStringOrNil error: errorCodeVariableOrNil "Create named primitive with optional error code." (aNameString isString and: [ aModuleStringOrNil isNil or: [ aModuleStringOrNil isString ] ]) ifFalse: [ ^ self expected: 'Named primitive' ]. self allocateLiteral: (Array with: (aModuleStringOrNil isNil ifFalse: [ aModuleStringOrNil asSymbol ]) with: aNameString asSymbol with: 0 with: 0). errorCodeVariableOrNil ifNotNil: [encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]. ^117 that answers the number of the primitive for the method. So there are three methods that contain "errorCodeVariableOrNil ifNotNil: [encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]" to declare the error temp. I think that's acceptable. What do you think? > Scanner and/or parser explicit check for the name > <primitive: ....> > of the pragma of this error var. > Right, which is why it is simple to handle. >> 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 >> >> 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 >> >> ? >> >> 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 >> > > -- _,,,^..^,,,_ best, Eliot

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Eliot Miranda

On Tue, Feb 23, 2016 at 12:47 AM, stepharo <stepharo(a)free.fr> wrote: > Hi > > I saw that something <return: #Point> or <return: Point> > I do not know why but I have the impression that <return: #Point> is > better. > Because we may have code not present and still want to load the code. > Given the current semantics of pragmas only <return: #Point> is valid. _,,,^..^,,,_ best, Eliot

Feb. 23, 2016

curiousity, ensure unwind block priority inheritance

by Ben Coman

Just thought I'd share something enlightening I learnt today, a curious surprise... When a process is terminated, the #ensure: unwind block effectively inherits the priority of the terminator process. Thus the following... log := OrderedCollection new. s := Semaphore new. p := [ [ log add: 1. s signal. log add: 4. ] ensure: [log add: 5] ] forkAt: 30. s wait. log add: 2. "p terminate." log add: 3. 100 milliSeconds wait. Transcript crShow: log. ...gives {1 2 3 4 5} as expected. However uncommenting the terminate statement produces {1 2 5 3}. Quite non-intuitive** to have the "5" code inside the priority 30 block execute before the "3" code of the priority 40 of the UI/Playground. **meaning it bit me for a few hours trying to understand some ProcessTests related to Case 17588. cheers -ben

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Ben Coman

On Tue, Feb 23, 2016 at 8:17 PM, stepharo <stepharo(a)free.fr> wrote: > I do not think that Pharo will become a static language :) > For the moment we can let it as a documentation. > Now I would prefer to have tests because such annotations may be obsolete. Maybe not if those pragmas become *active* when the unit tests are run. Then they might be treated like asserts without application runtime penalty. The benefit over unit tests for package A, would be these asserts would be active when called from the unit tests of package B. (??) cheers -ben

Feb. 23, 2016

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. > But this means smalltalks scanner and parser needs some very special handling just for this pragma. Scanner and/or parser explicit check for the name <primitive: ....> of the pragma of this error var. > > 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 > > 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 > > ? > > 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 >

Feb. 23, 2016

Re: [Pharo-dev] 50603 highlighting broken

by Nicolai Hess

2016-02-23 14:48 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 23 Feb 2016, at 14:41, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > in pharo 50603, if you open a sendersOf MessageBrowser, the first > selected > > methods code is not or wrongly highlightey (all red). > > You have to change the selected item to get the right result! > > Yes, this is a side effect of not deferring syntax highlighting for small > methods: > > > https://pharo.fogbugz.com/f/cases/16020/Syntax-Highlighting-Rubric-First-sh… > > (which > a) makes looking at code feel much faster (no double rendering) > b) works around a race condition for rendering in the background > that made all CI jobs fails 8 times our of 10) > ) > > I think this just makes a bug visible that was hidden by the double > renderingâ¦ we should find how to fix it. > Oh yes thats bad :-( setEditingModeFor: textArea withBehavior: behavior behavior ifNil: [ self isForSmalltalkCode ifTrue: [ textArea beForSmalltalkScripting ] ifFalse: [ textArea beForPlainText ] ] ifNotNil: [ :class | self haltOnce. textArea classOrMetaClass: class; beForSmalltalkCode ] here we set the classOrMetaClass attribute of the styler, but at this point it is not configured for styling and the classOrMetaClass setting is ignored. After that we set the styler #beForSmalltalkCode, but now, styleing does not know about the classOrMetaClass. If we exchange the calls: textArea beForSmalltalkCode; classOrMetaClass: class it wouldn't work either, because now the styler is called without the classOrMetaClass is set. And if we set the classOrMetaClass, the styling does not change because the code did not change :-( > > Marcus >

Feb. 23, 2016

Re: [Pharo-dev] fork during debugging to auto spawn new debugger

by Denis Kudriashov

Hi Ben 2016-02-23 14:08 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Maybe if somehow a Process new it was > being debugged and the new process inherited that state. > I plan to introduce inheriting state for spawn processes. Idea is to add InheritedProcessSpecificVariable. Particularly I want mark processes which was forked during test execution and maybe manage it automatically: terminating on test completion, collecting failures as additional test result.

Feb. 23, 2016

Re: [Pharo-dev] 50603 highlighting broken

by Marcus Denker

> On 23 Feb 2016, at 14:41, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > in pharo 50603, if you open a sendersOf MessageBrowser, the first selected > methods code is not or wrongly highlightey (all red). > You have to change the selected item to get the right result! Yes, this is a side effect of not deferring syntax highlighting for small methods: https://pharo.fogbugz.com/f/cases/16020/Syntax-Highlighting-Rubric-First-sh… (which a) makes looking at code feel much faster (no double rendering) b) works around a race condition for rendering in the background that made all CI jobs fails 8 times our of 10) ) I think this just makes a bug visible that was hidden by the double renderingâ¦ we should find how to fix it. Marcus

Feb. 23, 2016

Re: [Pharo-dev] 50603 highlighting broken

by Henrik Nergaard

Caused by: Build 50601 16020 Syntax Highlighting Rubric: First shows non-highlighted text, then color. Looks slow https://pharo.fogbugz.com/f/cases/16020 From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess Sent: Tuesday, February 23, 2016 2:41 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] 50603 highlighting broken in pharo 50603, if you open a sendersOf MessageBrowser, the first selected methods code is not or wrongly highlightey (all red). You have to change the selected item to get the right result!

Feb. 23, 2016

Re: [Pharo-dev] fully self-contained Linux VM

by Peter UhnÃ¡k

On Tue, Feb 23, 2016 at 2:00 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 23-02-16 13:35, Peter UhnÃ¡k wrote: > >> Could something like that be done also for the remaining lib32 libraries >> required to run the VM? >> > > Sure. And then you need to release updates whenever one of the underlying > lib32 libraries changes. OpenSSL comes to mind. But that would be true for windows & mac VMs, which unlike linux already are self-contained (including OpenSSL). So I infer it should be possible with some minor changes. :) Thanks, Peter

Feb. 23, 2016