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

[pharo-project/pharo-core]

by GitHub

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

June 3, 2016

[pharo-project/pharo-core] 0ca84c: 60059

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 0ca84c5e6380b23d9d5df27c43806840887eefa8 https://github.com/pharo-project/pharo-core/commit/0ca84c5e6380b23d9d5df27c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-03 (Fri, 03 Jun 2016) Changed paths: A OpalCompiler-Core.package/OCLiteralVariable.class/instance/testing/isGlobalClassNameBinding.st A OpalCompiler-Core.package/OCLiteralVariable.class/instance/testing/isWritable.st M OpalCompiler-Tests.package/OCCompilerTest.class/instance/running/setUp.st M OpalCompiler-Tests.package/OCCompilerTest.class/instance/running/tearDown.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test readonly vars/testAssignmentOfClassNameBinding.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test readonly vars/testAssignmentOfGlobalVarBinding.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60058.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60059.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60058.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60059.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60059 18376 Do not allow assignments to global vars https://pharo.fogbugz.com/f/cases/18376 18381 ConfigurationOfCatalog is not in sync with current Pharo package versions https://pharo.fogbugz.com/f/cases/18381 18377 ConfigurationOfGTEventRecorder is not in sync with the current package versions https://pharo.fogbugz.com/f/cases/18377 18396 Glamour-FastTable extends projects that are loaded after it https://pharo.fogbugz.com/f/cases/18396 http://files.pharo.org/image/60/60059.zip

June 3, 2016

Re: [Pharo-dev] install GitFileTree from catalog --> missing class

by Thierry Goubier

2016-06-03 13:38 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > yes, but then GitFileTree from catalog is downloading a wrong version :) > I'll update and see if this change was pushed upstream (in the FileTree repository). Thierry > > > On 03 Jun 2016, at 13:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > STON is now (in 6.0) used as JSON parser. > > > >> On 03 Jun 2016, at 13:24, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> > >> this class is not there anymore : > >> > >> MCFileTreeJsonParser > >> > >> (Pharo 6.0 version) > > > > > > >

June 3, 2016

Re: [Pharo-dev] install GitFileTree from catalog --> missing class

by Esteban Lorenzano

yes, but then GitFileTree from catalog is downloading a wrong version :) > On 03 Jun 2016, at 13:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > STON is now (in 6.0) used as JSON parser. > >> On 03 Jun 2016, at 13:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> this class is not there anymore : >> >> MCFileTreeJsonParser >> >> (Pharo 6.0 version) > >

June 3, 2016

Re: [Pharo-dev] install GitFileTree from catalog --> missing class

by Sven Van Caekenberghe

STON is now (in 6.0) used as JSON parser. > On 03 Jun 2016, at 13:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > this class is not there anymore : > > MCFileTreeJsonParser > > (Pharo 6.0 version)

June 3, 2016

install GitFileTree from catalog --> missing class

by Esteban Lorenzano

this class is not there anymore : MCFileTreeJsonParser (Pharo 6.0 version)

June 3, 2016

Re: [Pharo-dev] [Vm-dev] Context>>copyTo: doesn't update closure home

by Max Leske

> On 03 Jun 2016, at 12:30, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > The way I understand it the closure is shared between the original and the copied stack. If you change the closure outerContext to match the copied context, then non local returns / debugging won't work any more on the original stack. Thatâs true, I didnât think of that. > > As you mentioned, updating all the closures referencing the context as their outer context is non trivial. I believe you can do it lazily (at least that's my conclusion from the sista experience where I need to do that if the outer context is deoptimized). The only cases where the outerContext is used are non local returns and debugging. If a non local return fails, it calls the #cannotReturn: call-back. You can change the code there to do the right think if the outer context is not correct (like setting the correct outer context and retrying the non local return). You can also change the BlockClosure code to check at each outerContext in-image read if the outerContext is valid or not. I think that's much better than updating ahead of time all the closure instances. I think Iâll have to do something like this, yes. > > Alternatively, if you feel like it, you could try something like 'context becomeForward: copyOfContextâ. No, I donât want to risk anything. Although it probably wouldnât hurt in most cases. Thanks ClÃ©ment. > > On Fri, Jun 3, 2016 at 11:02 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > I see at least one problem: at the point where we make a copy of a context, the closures that reference it are either in callees or not on the stack at all. Therefore we would need to take note of all the closures we meet on the way and update the outer contexts only if we find them on the stack. That makes copying a whole lot harder. > > Max > > > Hi, > > > > Is anybody aware of a reason for why Context>>copyTo: should not update the home of closures (which is currently the case)? This behaviour becomes a problem when I want to simulate #stepThrough: on a copied stack, since the home of a closure will never be found on the stack. > > > > My proposal is to implement > > > > Context>>postCopy > > closureOrNil ifNil: [ ^ self ]. > > > > closureOrNil outerContext: self > > > > and > > > > BlockClosure>>outerContext: aContext > > outerContext := aContext > > > > > > Thoughts? > > > > Cheers, > > Max >

June 3, 2016

Re: [Pharo-dev] [Vm-dev] Context>>copyTo: doesn't update closure home

by ClÃ©ment Bera

The way I understand it the closure is shared between the original and the copied stack. If you change the closure outerContext to match the copied context, then non local returns / debugging won't work any more on the original stack. As you mentioned, updating all the closures referencing the context as their outer context is non trivial. I believe you can do it lazily (at least that's my conclusion from the sista experience where I need to do that if the outer context is deoptimized). The only cases where the outerContext is used are non local returns and debugging. If a non local return fails, it calls the #cannotReturn: call-back. You can change the code there to do the right think if the outer context is not correct (like setting the correct outer context and retrying the non local return). You can also change the BlockClosure code to check at each outerContext in-image read if the outerContext is valid or not. I think that's much better than updating ahead of time all the closure instances. Alternatively, if you feel like it, you could try something like 'context becomeForward: copyOfContext'. On Fri, Jun 3, 2016 at 11:02 AM, Max Leske <maxleske(a)gmail.com> wrote: > > I see at least one problem: at the point where we make a copy of a > context, the closures that reference it are either in callees or not on the > stack at all. Therefore we would need to take note of all the closures we > meet on the way and update the outer contexts only if we find them on the > stack. That makes copying a whole lot harder. > > Max > > > Hi, > > > > Is anybody aware of a reason for why Context>>copyTo: should not update > the home of closures (which is currently the case)? This behaviour becomes > a problem when I want to simulate #stepThrough: on a copied stack, since > the home of a closure will never be found on the stack. > > > > My proposal is to implement > > > > Context>>postCopy > > closureOrNil ifNil: [ ^ self ]. > > > > closureOrNil outerContext: self > > > > and > > > > BlockClosure>>outerContext: aContext > > outerContext := aContext > > > > > > Thoughts? > > > > Cheers, > > Max >

June 3, 2016

Context>>copyTo: doesn't update closure home

by Max Leske

I see at least one problem: at the point where we make a copy of a context, the closures that reference it are either in callees or not on the stack at all. Therefore we would need to take note of all the closures we meet on the way and update the outer contexts only if we find them on the stack. That makes copying a whole lot harder. Max > Hi, > > Is anybody aware of a reason for why Context>>copyTo: should not update the home of closures (which is currently the case)? This behaviour becomes a problem when I want to simulate #stepThrough: on a copied stack, since the home of a closure will never be found on the stack. > > My proposal is to implement > > Context>>postCopy > closureOrNil ifNil: [ ^ self ]. > > closureOrNil outerContext: self > > and > > BlockClosure>>outerContext: aContext > outerContext := aContext > > > Thoughts? > > Cheers, > Max

June 3, 2016

[pharo-project/pharo-core]

by GitHub

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

June 3, 2016