- Pharo-dev - lists.pharo.org

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

50603 highlighting broken

by Nicolai Hess

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

[pharo-project/pharo-core]

by GitHub

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

Feb. 23, 2016

[pharo-project/pharo-core] a8609c: 50603

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a8609c784255b249c46006004e78a224022e4e8d https://github.com/pharo-project/pharo-core/commit/a8609c784255b249c4600600… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-23 (Tue, 23 Feb 2016) Changed paths: R Deprecated50.package/extension/SmalltalkImage/instance/addToShutDownList_.st R Deprecated50.package/extension/SmalltalkImage/instance/addToStartUpList_.st M SUnit-UITesting.package/SimulateKeystrokesSpecification.class/instance/tests/testSimulateCmdKeystroke.st M SUnit-UITesting.package/SimulateMouseSpecification.class/instance/tests/testSimulateRightClick.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50602.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50603.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50602.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50603.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Support.package/SmalltalkImage.class/instance/startup - shutdown/addToShutDownList_.st A System-Support.package/SmalltalkImage.class/instance/startup - shutdown/addToStartUpList_.st Log Message: ----------- 50603 17676 Building Pharo-5.0-Issue-Tracker-Image fails!! https://pharo.fogbugz.com/f/cases/17676 16534 SimulateMouseSpecification broken https://pharo.fogbugz.com/f/cases/16534 http://files.pharo.org/image/50/50603.zip

Feb. 23, 2016