May 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Compiler] #bindings: improvement: Global shadowing

by Marcus Denker

> On 23 May 2018, at 11:49, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Marcus, > > can you do inheritence / masking of a hierarchy of system dictionaries ? > > Could be used to make "kind of" sandboxes, around, say, user code so > that it does not have the ability to override a certain system core. > Yes, I was starting to think about exactly thatâ¦ I will do some experiments. Marcus

May 23, 2018

[Pharo 7.0-dev] Build #938: 21953-Fixing-failing-test-in-Traits-TraitFileOutTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #938 was: SUCCESS. The Pull Request #1405 was integrated: "21953-Fixing-failing-test-in-Traits-TraitFileOutTest" Pull request url: https://github.com/pharo-project/pharo/pull/1405 Issue Url: https://pharo.fogbugz.com/f/cases/21953 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 23, 2018

Re: [Pharo-dev] [Compiler] #bindings: improvement: Global shadowing

by Thierry Goubier

Marcus, can you do inheritence / masking of a hierarchy of system dictionaries ? Could be used to make "kind of" sandboxes, around, say, user code so that it does not have the ability to override a certain system core. Thierry 2018-05-23 11:45 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> A second iteration now makes it work correctly for assignments: >> >> https://github.com/pharo-project/pharo/pull/1397 >> >> Smalltalk compiler >> bindings: {(#test -> Point)} asDictionary; >> evaluate: 'test := 42â. > > While #bindings: allows us now to add additional bindings or override global bindings from Smalltalk globals, there is another feature missing that would be nice: be able to set the global environment > > I want to be able to tell the compiler: Do not use Smalltalk globals, but this SystemDictionary instead. > > https://github.com/pharo-project/pharo/pull/1406 > > with this, we can create a SystemDictionary with just one binding in it: > > environment := SystemDictionary new. > environment at: #MyClass put: Point. > > then we compile a method: > > method := Smalltalk compiler > environment: environment; > compile: 'tt ^MyClassâ. > > and if we execute it, it shows that compilation used the environment: > > return := method valueWithReceiver: nil arguments: #(). > self assert: return equals: Point. > > If we try to compile a ref to Object, we get a nil ref: > > method := Smalltalk compiler > environment: environment; > compile: 'tt ^Object'. > return := method valueWithReceiver: nil arguments: #(). > self assert: return equals: nil. > > But, as the Undeclared mechanism is not aware of it, it puts an undeclared for Object there. > > In the same direction, all objects the compiler creates come still from Smalltalk globals (CompiledMethod, all Literalsâ¦). > > But all this can be improved, we do pass the environment down the compiler chain already so that it is even available in the Parser/Scanner. Thus we could e.g. create Literals as instances from the classes in the environment. But how exactly has to be seen. > > Marcus > > >

May 23, 2018

Re: [Pharo-dev] [Compiler] #bindings: improvement: Global shadowing

by Marcus Denker

> > A second iteration now makes it work correctly for assignments: > > https://github.com/pharo-project/pharo/pull/1397 > > Smalltalk compiler > bindings: {(#test -> Point)} asDictionary; > evaluate: 'test := 42â. While #bindings: allows us now to add additional bindings or override global bindings from Smalltalk globals, there is another feature missing that would be nice: be able to set the global environment I want to be able to tell the compiler: Do not use Smalltalk globals, but this SystemDictionary instead. https://github.com/pharo-project/pharo/pull/1406 with this, we can create a SystemDictionary with just one binding in it: environment := SystemDictionary new. environment at: #MyClass put: Point. then we compile a method: method := Smalltalk compiler environment: environment; compile: 'tt ^MyClassâ. and if we execute it, it shows that compilation used the environment: return := method valueWithReceiver: nil arguments: #(). self assert: return equals: Point. If we try to compile a ref to Object, we get a nil ref: method := Smalltalk compiler environment: environment; compile: 'tt ^Object'. return := method valueWithReceiver: nil arguments: #(). self assert: return equals: nil. But, as the Undeclared mechanism is not aware of it, it puts an undeclared for Object there. In the same direction, all objects the compiler creates come still from Smalltalk globals (CompiledMethod, all Literalsâ¦). But all this can be improved, we do pass the environment down the compiler chain already so that it is even available in the Parser/Scanner. Thus we could e.g. create Literals as instances from the classes in the environment. But how exactly has to be seen. Marcus

May 23, 2018

[Pharo 7.0-dev] Build #937: 21948 Use uppercase menu items also in extendedSearchMenuOn: and smalltalkEditorShiftedMenuOn:

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #937 was: SUCCESS. The Pull Request #1404 was integrated: "21948 Use uppercase menu items also in extendedSearchMenuOn: and smalltalkEditorShiftedMenuOn:" Pull request url: https://github.com/pharo-project/pharo/pull/1404 Issue Url: https://pharo.fogbugz.com/f/cases/21948 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 23, 2018

[Pharo 7.0-dev] Build #936: 21944 Comment FileDialogWindowTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #936 was: SUCCESS. The Pull Request #1400 was integrated: "21944 Comment FileDialogWindowTest" Pull request url: https://github.com/pharo-project/pharo/pull/1400 Issue Url: https://pharo.fogbugz.com/f/cases/21944 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 23, 2018

Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7

by Torsten Bergmann

May 22, 2018

[Pharo 7.0-dev] Build #935: 21828-Slot-defined-a-trait-used-by-a-superclass-does-not-invoke-slot-accessing-method-when-used

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #935 was: FAILURE. The Pull Request #1399 was integrated: "21828-Slot-defined-a-trait-used-by-a-superclass-does-not-invoke-slot-accessing-method-when-used" Pull request url: https://github.com/pharo-project/pharo/pull/1399 Issue Url: https://pharo.fogbugz.com/f/cases/21828 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 22, 2018

Re: [Pharo-dev] FileDoesNotExist vs FileDoesNotExistException

by Alistair Grant

On Mon, May 21, 2018 at 09:17:24PM +0300, Denis Kudriashov wrote: > > 2018-05-21 21:14 GMT+03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > > On 21 May 2018, at 20:07, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > If I'm recalling well (which I might not :)) there is one thing (that I > don't quite like) that prevents these two classes to be easily merged into > one: their #defaultAction. > > We need a good talk/discussion about default actions. > > I am pretty confused by them, and my first reaction is that I don't like > them, too much UI in there. > > > I am 100% with you. UI queries to users should be in UI. Guille, thanks for the heads-up. I haven't thought about default actions until now, so I need to investigate before going much further. But having UI operations as part of the default action seems wrong for one of the core classes. My primary focus at the moment is to get the file attribute enhancements I've made integrated in to Pharo: https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… but I'll continue to work on this at the same time. Cheers, Alistair

May 22, 2018

Re: [Pharo-dev] [Compiler] #bindings: improvement: Global shadowing

by Thierry Goubier

Interesting... Thierry 2018-05-22 14:18 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > >> On 18 May 2018, at 10:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> the #binding: API until now did not allow to shadow globals. But there is actually no reason to forbid that >> (and it can actually be interesting, e.g. to compile code where one class ref is switched to another). >> >> The Pull Request does: >> >> - add comment to OCExtraBindingScope >> - categorize tests >> - change #lookupVar: to allow shadowing of Globals. >> - change test to reflect the new behaviour >> >> This means you can do: >> >> result := Smalltalk compiler >> bindings: {(#Object -> Point)} asDictionary; >> evaluate: 'Object new'. >> >> https://github.com/pharo-project/pharo/pull/1379 >> > > A second iteration now makes it work correctly for assignments: > > https://github.com/pharo-project/pharo/pull/1397 > > Smalltalk compiler > bindings: {(#test -> Point)} asDictionary; > evaluate: 'test := 42'. > > Marcus > >

May 22, 2018