October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] New Spur trunk image available

by Eliot Miranda

Hi Levente, On Oct 17, 2014, at 5:40 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 16 Oct 2014, Eliot Miranda wrote: > >> Hi All, >> finally the Spur Squeak trunk image is updateable. The image in http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can >> be updated independently of the non-Spur trunk. Spur VMs are available in http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they appear). Without wanting to appear too overconfident the Spur >> system looks to be ready for use apart from image segments (which I hope to have working some time next month). I'm really interested in having this stress tested by as many people as possible. Spur really >> does offer a significant performance and functionality improvement over the current system, but it needs testing to ensure its reliability. > > Great news. > >> Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope Pharo 4 Spur will be available soon. >> As far as trunk goes, using Spur alongside non-Spur trunk is going to be difficult to manage for the near future. Right now, Spur modifies the Collections, Compiler, Kernel and System packages, and this is >> done by auto-editing the non-Spur versions of those packages, something I do periodically as new versions arrive. I also auto-edit trunk configurations (the part of the image update scheme that ensures >> packages are loaded in the right order when there are dependencies between packages) from non-Spur "update" to Spur "update.spur" forms. This at east means that Spur can keep up with trunk. But it does >> /not/ provide a way of committing to Collections.spur, Compiler.spur, Kernel.spur or System.spur without getting out of sync with non-Spur trunk. Note that apart from these packages, one /can/ safely commit >> any other package from a Spur image to trunk. >> Right now the plan is to release both V3 (the pre-Spur format) and Spur versions of Squeak 4.6 (I hope it'll be called Squeak 5.0). This isn't my preference. I'd like to see just Spur released, once >> reliability is verified. But I understand the safety and backward-compatibility concerns (Spur won't be able to load V3 image segments, and vice verse). The issue is of course that we have this tricky >> package situation to manage where, to keep the two systems in sync, modifications to Collections, Compiler, Kernel and System need to be committed from V3 and auto-edited to Spur. I think that's too clumsy to >> be practicable. Perhaps allowing the two systems to fork and doing a manual merge will be acceptable, but it'll be work to keep them in sync. > > How about releasing the V3 version as Squeak 4.6, and the Spur version as Squeak 5.0 at the same time? > This way we could keep Trunk as is; pushing all changes to Trunk until 4.6 is released, then - leaving V3 behind - use the Trunk for Spur-only. > Then any changes could be backported manually to the future squeak46 repository if needed. Works for me. Good idea! Objections? > Levente > >> -- >> best,Eliot Eliot (phone)

Oct. 17, 2014

Re: [Pharo-dev] [squeak-dev] New Spur trunk image available

by Levente Uzonyi

On Thu, 16 Oct 2014, Eliot Miranda wrote: > Hi All, > Â Â finally the Spur Squeak trunk image is updateable.Â The image inÂ http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can > be updated independently of the non-Spur trunk.Â Spur VMs are available inÂ http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they appear).Â Without wanting to appear too overconfident the Spur > system looks to be ready for use apart from image segments (which I hope to have working some time next month).Â I'm really interested in having this stress tested by as many people as possible.Â Spur really > does offer a significant performance and functionality improvement over the current system, but it needs testing to ensure its reliability. Great news. > > Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope Pharo 4 Spur will be available soon. > > As far as trunk goes, using Spur alongside non-Spur trunk is going to be difficult to manage for the near future.Â Right now, Spur modifies the Collections, Compiler, Kernel and System packages, and this is > done by auto-editing the non-Spur versions of those packages, something I do periodically as new versions arrive.Â I also auto-edit trunk configurations (the part of the image update scheme that ensures > packages are loaded in the right order when there are dependencies between packages) from non-Spur "update" to Spur "update.spur" forms.Â This at east means that Spur can keep up with trunk.Â But it does > /not/ provide a way of committing toÂ Collections.spur, Compiler.spur, Kernel.spur or System.spur without getting out of sync with non-Spur trunk.Â Note that apart from these packages, one /can/ safely commit > any other package from a Spur image to trunk. > > Right now the plan is to release both V3 (the pre-Spur format) and Spur versions of Squeak 4.6 (I hope it'll be called Squeak 5.0).Â This isn't my preference.Â I'd like to see just Spur released, once > reliability is verified.Â But I understand the safety and backward-compatibility concerns (Spur won't be able to load V3 image segments, and vice verse).Â The issue is of course that we have this tricky > package situation to manage where, to keep the two systems in sync, modifications to Collections, Compiler, Kernel and System need to be committed from V3 and auto-edited to Spur. I think that's too clumsy to > be practicable.Â Perhaps allowing the two systems to fork and doing a manual merge will be acceptable, but it'll be work to keep them in sync. How about releasing the V3 version as Squeak 4.6, and the Spur version as Squeak 5.0 at the same time? This way we could keep Trunk as is; pushing all changes to Trunk until 4.6 is released, then - leaving V3 behind - use the Trunk for Spur-only. Then any changes could be backported manually to the future squeak46 repository if needed. Levente > -- > best,Eliot > >

Oct. 17, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

by Marcus Denker

--Â Marcus Denker Sent with Airmail On 17 Oct 2014 at 12:46:28, Esteban Lorenzano (estebanlm(a)gmail.com) wrote: that i donât know.Â the change is already there or the slice is actually empty.Â nothing to do with the app, in that case :) But I checked: the Slices did show me content when I reviewed them, these change are *not* there, yet, the merge is empty. Esteban On 17 Oct 2014, at 12:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: On 17 Oct 2014, at 12:21, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: that means most probably a merge conflict (still not handled by new integrator app).Â Sorry, I will fix it soon :) But I wonder why when I merge the not-integrated slices, it claims that there is no change? Esteban On 17 Oct 2014, at 12:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: We will have to revert this. -> the changes are not there -> yet when I merge the Slice it claims there are no changes. -> So we have to revert. On Fri, Oct 17, 2014 at 11:56 AM, GitHub <noreply(a)github.com> wrote: Â Branch: refs/heads/4.0 Â Home:Â Â https://github.com/pharo-project/pharo-core Â Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db Â Â Â https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502ac… Â Author: Jenkins Build Server <board(a)pharo-project.org> Â Date:Â Â 2014-10-17 (Fri, 17 Oct 2014) Â Changed paths: Â Â A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script310.st Â Â A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40310.st Â Â M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Â Log Message: Â ----------- Â 40310 14246 CompiledMethod>>hash can produce clashes Â Â Â Â https://pharo.fogbugz.com/f/cases/14246 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core Â Â Â Â https://pharo.fogbugz.com/f/cases/14257 14253 MC dependency warning should name which package is failing to load Â Â Â Â https://pharo.fogbugz.com/f/cases/14253 http://files.pharo.org/image/40/40310.zip -- -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

Oct. 17, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Marcus Denker

--Â Marcus Denker Sent with Airmail On 17 Oct 2014 at 12:46:20, Nicolai Hess (nicolaihess(a)web.de) wrote: I ran some testcases with your changes and I expect some test are failing now, but actually they don't fail but others do. Yes, but I think these tests are wrong.Â (needs to be carefully checked). 2014-10-16 22:06 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: 2014-10-16 17:40 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> While in the write we need to mark: >> >> lookupVariableForWrite: aVariableNode >> >>Â Â Â | var | >> >>Â Â Â var := scope lookupVar: aVariableNode name. >> >>Â Â Â var ifNil: [^var]. >>Â Â Â var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable: aVariableNode ]. >>Â Â Â var isWritable ifFalse: [ self storeIntoReadOnlyVariable: aVariableNode ]. >> >>Â Â Â var isTemp ifTrue: [ >>Â Â Â Â Â Â Â "when in a loop, all writes escape" >>Â Â Â Â Â Â Â scope outerScope isInsideOptimizedLoop ifTrue: [ var markEscapingWrite ]. >>Â Â Â Â Â Â Â "else only escaping when they will end up in different closures" >>Â Â Â Â Â Â Â (var scope outerNotOptimizedScope ~= scope outerNotOptimizedScope) >>Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ var markEscapingWrite]]. >>Â Â Â ^var >> >> >> I checked that all Opal tests that are failing are actually testing wrong, and I double checked >> that all those methods are now compiled like with the old old compilerâ¦ >> Now recompilng the image. > > Hmmâ¦ nopeâ¦. something wrong. > the âouterScopeâ was wrong. So without that, I can recompile the image and your example is compiled without temp vectorsâ¦ Â Â Â Â Marcus good! I'll open an issue on fogbugz and create a slice with your changes. about reordering of tempvars: It would be nice if the order preserves, but I think we can live with it. Although there is an issue with the debugger: 14058 Inconsistent information in debugger I solved that one by using tempvar names instead if the index, but this has another issue (sometimes the last (or most nested) tempvar is always nil). The real error is, EyeDebuggerContextInspector does recognizes if the index changes (somewhere in EyeDebuggerContextInspector>>#updateList it compares the new elements (with new indices) with the old elements list and skips the update)

Oct. 17, 2014

Re: [Pharo-dev] [Pharo-users] [Ann] Phratch 4.0

by Sven Van Caekenberghe

Excellent work. Thank you. On 17 Oct 2014, at 11:48, jannik laval <jannik.laval(a)gmail.com> wrote: > Phratch 4.0 is out of the box ! > > Phratch 4.0 is cleaner, faster and more stable than phratch 3.0. > > After the version 3.0 that was a release for usability and stability, phratch 4.0 is released to prepare the future. > > The new features are: > > - phratch is more modular, eg having a kernel and lots of addons. > - cleaning a lot the source code > - customizable environment > - each block can be made visible or invisible > - each category can be made visible or invisible > - it is possible to add translation for addons with the pragma <phratchTranslation: âfrâ> in the class PhratchTranslator. This make the translation more modular. > - first integration of phratch with the pharo environment. Using the pragma at the class side of any class in Pharo make the class visible and usable in phratch. > - There is a lot of things to do with phratch, you are welcome to contribute ! The documentation for new features will arrive soon. > > See you on phratch.com > > -- > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info > http://car.mines-douai.fr/ >

Oct. 17, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

by Esteban Lorenzano

that i donât know. the change is already there or the slice is actually empty. nothing to do with the app, in that case :) Esteban > On 17 Oct 2014, at 12:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 17 Oct 2014, at 12:21, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> that means most probably a merge conflict (still not handled by new integrator app). >> Sorry, I will fix it soon :) >> > > But I wonder why when I merge the not-integrated slices, it claims that there is no change? > > >> Esteban >> >>> On 17 Oct 2014, at 12:19, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>> We will have to revert this. >>> >>> -> the changes are not there >>> -> yet when I merge the Slice it claims there are no changes. >>> -> So we have to revert. >>> >>> On Fri, Oct 17, 2014 at 11:56 AM, GitHub <noreply(a)github.com <mailto:noreply@github.com>> wrote: >>> Branch: refs/heads/4.0 >>> Home: https://github.com/pharo-project/pharo-core <https://github.com/pharo-project/pharo-core> >>> Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db >>> https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502ac… <https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502ac…> >>> Author: Jenkins Build Server <board(a)pharo-project.org <mailto:board@pharo-project.org>> >>> Date: 2014-10-17 (Fri, 17 Oct 2014) >>> >>> Changed paths: >>> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script310.st <http://script310.st/> >>> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40310.st <http://update40310.st/> >>> M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>> >>> Log Message: >>> ----------- >>> 40310 >>> 14246 CompiledMethod>>hash can produce clashes >>> https://pharo.fogbugz.com/f/cases/14246 <https://pharo.fogbugz.com/f/cases/14246> >>> >>> 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core >>> https://pharo.fogbugz.com/f/cases/14257 <https://pharo.fogbugz.com/f/cases/14257> >>> >>> 14253 MC dependency warning should name which package is failing to load >>> https://pharo.fogbugz.com/f/cases/14253 <https://pharo.fogbugz.com/f/cases/14253> >>> >>> http://files.pharo.org/image/40/40310.zip <http://files.pharo.org/image/40/40310.zip> >>> >>> >>> >>> >>> >>> -- >>> -- >>> Marcus Denker -- denker(a)acm.org <mailto:denker@acm.org> >>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >> >

Oct. 17, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Nicolai Hess

I ran some testcases with your changes and I expect some test are failing now, but actually they don't fail but others do. 2014-10-16 22:06 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > 2014-10-16 17:40 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> >> >> While in the write we need to mark: >> >> >> >> lookupVariableForWrite: aVariableNode >> >> >> >> | var | >> >> >> >> var := scope lookupVar: aVariableNode name. >> >> >> >> var ifNil: [^var]. >> >> var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable: >> aVariableNode ]. >> >> var isWritable ifFalse: [ self storeIntoReadOnlyVariable: >> aVariableNode ]. >> >> >> >> var isTemp ifTrue: [ >> >> "when in a loop, all writes escape" >> >> scope outerScope isInsideOptimizedLoop ifTrue: [ var >> markEscapingWrite ]. >> >> "else only escaping when they will end up in different >> closures" >> >> (var scope outerNotOptimizedScope ~= scope >> outerNotOptimizedScope) >> >> ifTrue: [ var markEscapingWrite]]. >> >> ^var >> >> >> >> >> >> I checked that all Opal tests that are failing are actually testing >> wrong, and I double checked >> >> that all those methods are now compiled like with the old old compilerâ¦ >> >> Now recompilng the image. >> > >> > Hmmâ¦ nopeâ¦. something wrong. >> > >> >> the âouterScopeâ was wrong. >> >> So without that, I can recompile the image and your example is compiled >> without temp vectorsâ¦ >> >> Marcus >> > > good! > I'll open an issue on fogbugz and create a slice with your changes. > > about reordering of tempvars: > It would be nice if the order preserves, but I think we can live with it. > Although there is an issue with the debugger: > 14058 <https://pharo.fogbugz.com/default.asp?14058> Inconsistent > information in debugger > I solved that one by using tempvar names instead if the index, but > this has another issue (sometimes the last (or most nested) tempvar is > always nil). > > The real error is, EyeDebuggerContextInspector does recognizes if the > index changes > (somewhere in EyeDebuggerContextInspector>>#updateList it > compares the new elements (with new indices) with the old elements list > and skips the update) > > > > >

Oct. 17, 2014

Re: [Pharo-dev] Context variables?

by Frank Shearar

Bear in mind that if you do any fancy stack slicing, you will get... *unexpected* behaviour from DynamicVariable. (See http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-expres… and follow-on links.) frank On 15 October 2014 16:34, Camille Teruel <camille.teruel(a)gmail.com> wrote: > Hi Jeff, > > I think you should look at DynamicVariable and ProcessSpecificVariable > classes. The first one is a read-only while the second is writable. > You have to subclass these class for each variable you want. > > Ex: > DynamicVariable subclass: #MyVar. > MyVar value: 4 during: [ MyVar value ] > > HTH, > Camiile > > > On 15 oct. 2014, at 17:09, J.F. Rick <self(a)je77.com> wrote: > > I remember there was some discussion on the list about support for variables > tied to the context rather than to the instance or class. This seems > particularly useful for a web application where you might want to access the > request and response from the context. What is the proper name for these > kind of variables and where can I read about how to use them? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > >

Oct. 17, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

by Marcus Denker

> On 17 Oct 2014, at 12:21, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > that means most probably a merge conflict (still not handled by new integrator app). > Sorry, I will fix it soon :) > But I wonder why when I merge the not-integrated slices, it claims that there is no change? > Esteban > >> On 17 Oct 2014, at 12:19, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> We will have to revert this. >> >> -> the changes are not there >> -> yet when I merge the Slice it claims there are no changes. >> -> So we have to revert. >> >> On Fri, Oct 17, 2014 at 11:56 AM, GitHub <noreply(a)github.com <mailto:noreply@github.com>> wrote: >> Branch: refs/heads/4.0 >> Home: https://github.com/pharo-project/pharo-core <https://github.com/pharo-project/pharo-core> >> Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db >> https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502ac… <https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502ac…> >> Author: Jenkins Build Server <board(a)pharo-project.org <mailto:board@pharo-project.org>> >> Date: 2014-10-17 (Fri, 17 Oct 2014) >> >> Changed paths: >> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script310.st <http://script310.st/> >> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40310.st <http://update40310.st/> >> M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> >> Log Message: >> ----------- >> 40310 >> 14246 CompiledMethod>>hash can produce clashes >> https://pharo.fogbugz.com/f/cases/14246 <https://pharo.fogbugz.com/f/cases/14246> >> >> 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core >> https://pharo.fogbugz.com/f/cases/14257 <https://pharo.fogbugz.com/f/cases/14257> >> >> 14253 MC dependency warning should name which package is failing to load >> https://pharo.fogbugz.com/f/cases/14253 <https://pharo.fogbugz.com/f/cases/14253> >> >> http://files.pharo.org/image/40/40310.zip <http://files.pharo.org/image/40/40310.zip> >> >> >> >> >> >> -- >> -- >> Marcus Denker -- denker(a)acm.org <mailto:denker@acm.org> >> http://www.marcusdenker.de <http://www.marcusdenker.de/> >

Oct. 17, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

by Esteban Lorenzano

that means most probably a merge conflict (still not handled by new integrator app). Sorry, I will fix it soon :) Esteban > On 17 Oct 2014, at 12:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > We will have to revert this. > > -> the changes are not there > -> yet when I merge the Slice it claims there are no changes. > -> So we have to revert. > > On Fri, Oct 17, 2014 at 11:56 AM, GitHub <noreply(a)github.com <mailto:noreply@github.com>> wrote: > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core <https://github.com/pharo-project/pharo-core> > Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db > https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502ac… <https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502ac…> > Author: Jenkins Build Server <board(a)pharo-project.org <mailto:board@pharo-project.org>> > Date: 2014-10-17 (Fri, 17 Oct 2014) > > Changed paths: > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script310.st <http://script310.st/> > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40310.st <http://update40310.st/> > M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 40310 > 14246 CompiledMethod>>hash can produce clashes > https://pharo.fogbugz.com/f/cases/14246 <https://pharo.fogbugz.com/f/cases/14246> > > 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core > https://pharo.fogbugz.com/f/cases/14257 <https://pharo.fogbugz.com/f/cases/14257> > > 14253 MC dependency warning should name which package is failing to load > https://pharo.fogbugz.com/f/cases/14253 <https://pharo.fogbugz.com/f/cases/14253> > > http://files.pharo.org/image/40/40310.zip <http://files.pharo.org/image/40/40310.zip> > > > > > > -- > -- > Marcus Denker -- denker(a)acm.org <mailto:denker@acm.org> > http://www.marcusdenker.de <http://www.marcusdenker.de/>

Oct. 17, 2014