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

Re: [Pharo-dev] Run Spur run!!

by Eliot Miranda

Hi Thierry, On Oct 25, 2014, at 2:52 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 24/10/2014 19:50, Eliot Miranda a Ã©crit : >> >> >> On Fri, Oct 24, 2014 at 10:12 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 24/10/2014 19:07, Eliot Miranda a Ã©crit : >> >> >> >> On Fri, Oct 24, 2014 at 7:34 AM, Esteban Lorenzano >> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> >> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: >> >> >> On 24 Oct 2014, at 16:21, Thierry Goubier >> <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com> >> <mailto:thierry.goubier@gmail.__com >> <mailto:thierry.goubier@gmail.com>>> wrote: >> >> >> >> 2014-10-24 15:50 GMT+02:00 ClÃ©ment Bera >> <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com> >> <mailto:bera.clement@gmail.com >> <mailto:bera.clement@gmail.com>__>>: >> >> >> The current x2 speed boost is due only to spur, not >> to sista. >> Sista will provide additional performance, but we >> have still >> things to do before production. >> >> The performance gain reported is due to (from most >> important >> to less important): >> - the new GC has less overhead. 30% of the >> execution time used >> to be spent in the GC. >> - the new object format speeds up some VM internal >> caches >> (especially inline caches for message sends due to an >> indirection for object classes with a class table). >> - the new object format allows some C code to be >> converted >> into machine code routines, including block >> creation, context >> creation, primitive #at:put:, which is faster because >> switching from jitted code to C then back to jitted >> code >> generate a little overhead. >> - characters are now immediate objects, which >> speeds up String >> accessing. >> - the new object format has a larger hash which >> speeds up big >> hashed collections such as big sets and dictionaries. >> - become is faster. >> >> >> All this is really cool :) And if I remember well, >> there is 64 >> bitness coming as well. >> >> Will Spur also cover ARM ? >> >> >> Spur is an object format, it does not have anything to do with >> underlying architecture (well, at least in theoryâ¦ Eliot >> should be >> able to say more on this). >> Cog, in the other side is a jitter, and it has everything >> to do with >> the architecture so is difficult to have it running on ARM (but >> there is work on that direction, so we hope it will be there >> eventually). >> >> It looks like there is a misunderstanding (probably not you, >> Thierry, but since Iâve seen it time to time, I take the >> chance to >> clarify): Spur is not a replacement for Cog, both are >> orthogonal (in >> fact, Spur runs in Stack vm too). >> Real new VM is not âSpurâ vm, is "Cog+Spur" vm. >> >> >> +1. Spur changes the object representation, so it has a new heap >> layout, a new layout for objects, and a new garbage collector. >> Because >> the object format is simpler it allows the Cog JIT to generate >> machine >> code versions of more operations, in particular basicNew, >> basicNew: and >> closure and context creation. This is the main reason for the >> speedups >> in Cog+Spur. As far as the Stack VM goes if you see speedups for >> Stack+Spur vs Stack+V3 that's all due to the Spur object >> representation >> & GC, because there's no JIT. >> >> Now at the moment the Cog JIT only has an x86 back-end in >> production. >> Tim Rowledge is working on finishing the ARM back end started by >> Lars >> Wassermann in the GSoC a few years ago. So soonish we should be >> able to >> have Cog+V3 or Cog+Spur on e.g. Android. >> >> As part of 64-bit Spur I will be doing a back end for x86-64. >> >> >> Which is then a 64bits Spur+Cog+Sista, right? >> >> >> It should be able to be used for Spur+Cog or Spur+Cog+Sista. Depends >> how quickly I can write the 64-bit Spur and how quickly ClÃ©ment can put >> Sista into production. > > Ok. > >> And Doug McPherson is also in the mix, having written the ARM >> version of >> the new FFI plugin, and is going to be building Stack ARM VMs >> and soon >> enough Cog ARM VMs. >> >> >> Thanks for all those news, this is really great. >> >> >> Yes, I'm very excited. It's so great to have strong collaborators like >> ClÃ©ment, Ronie, Doug and Tim. But there's lots of room for more to join >> us. For a really cool project how about grabbing Bert Freudenberg's >> VMMakerJS Squeak-vm-on-JavaScript, extract the event handling and >> rendering part and connect it to the Cog VM via sockets to give us a >> really fast web plugin? > > Is that one really needed? I had the feeling web plugins were so last year and that we could just do: Amber, or even a remote desktop client in the web browser with Squeak/Pharo RDP support (which is a bit more general than a really fast web plugin). If Amber is useful then a Squeak/Pharo/Scratch/whatever plugin is useful. Amber has limitations (no thisContext, no become, no run-time class redefinition, no instance migration there-on, limited performance, especially for non-local return), but it is still useful enough for people to go through that extra deployment and verification step to check that the code still works under Amber. If one can't live with those limitations or if one doesn't want to pay the cost of the extra deployments step then a plugin solves that problem. Don't confuse an absence as a lack of need. Because there has been no "plugin" solution for a few years doesn't mean it's not needed. That people have put significant effort into alternatives like Amber and JalapeÃ±o proves it is useful. > Moreover, I see that the only thing with potential linked to the web today is to handle tablets/smartphones, and this is a bit why I'm asking about ARM support (also embedding in small stuff, like Cortex M0-M4 stuff with BLE, solar cells and batteries). For now, the only use we have for Smalltalk in there is as C code generation / deployment IDEs on the desktop (aka B. Pottier Netgen), and as back-end on web deployment with Seaside + others. There doesn't need to be an either/or in a growing community. > > Thierry >

Oct. 25, 2014

Re: [Pharo-dev] [Pharo-users] [ANN] new GT features: disk memory, ws.stfx.eu sharing, closeable panes and others

by Sven Van Caekenberghe

Very nice. What would be the correct way to load this ahead of integration in Pharo 4 ? ConfigurationOfGTPlayground loadDevelopment ? I improved the deployment of ws.stfx.eu a bit, it is very old. Browser detection was broken. I am trying to improve the look, but I am not yet finished. I would like to use solarized dark styling. We also need a way to open a shared workspace in/as a GT Playground, give a URL on the clipboard or typed in. Then I can updated the contents of the help workspace, http://ws.stfx.eu/1WS4U I like the 'save in cloud' formulation ! Sven > On 25 Oct 2014, at 06:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are quite actively working on GT. > > First of all, thanks everyone for the feedback. We take it quite seriously and we do our best to take it into account. Please keep the discussions flowing. > > I summarized some of the things that happened recently in the playground and inspector here: > http://www.humane-assessment.com/blog/gt-developments-endless-playground-me… > > Let us know what you think. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 25, 2014

Re: [Pharo-dev] Run Spur run!!

by Thierry Goubier

Le 24/10/2014 19:50, Eliot Miranda a Ã©crit : > > > On Fri, Oct 24, 2014 at 10:12 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Le 24/10/2014 19:07, Eliot Miranda a Ã©crit : > > > > On Fri, Oct 24, 2014 at 7:34 AM, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > > On 24 Oct 2014, at 16:21, Thierry Goubier > <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.__com > <mailto:thierry.goubier@gmail.com>>> wrote: > > > > 2014-10-24 15:50 GMT+02:00 ClÃ©ment Bera > <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com> > <mailto:bera.clement@gmail.com > <mailto:bera.clement@gmail.com>__>>: > > > The current x2 speed boost is due only to spur, not > to sista. > Sista will provide additional performance, but we > have still > things to do before production. > > The performance gain reported is due to (from most > important > to less important): > - the new GC has less overhead. 30% of the > execution time used > to be spent in the GC. > - the new object format speeds up some VM internal > caches > (especially inline caches for message sends due to an > indirection for object classes with a class table). > - the new object format allows some C code to be > converted > into machine code routines, including block > creation, context > creation, primitive #at:put:, which is faster because > switching from jitted code to C then back to jitted > code > generate a little overhead. > - characters are now immediate objects, which > speeds up String > accessing. > - the new object format has a larger hash which > speeds up big > hashed collections such as big sets and dictionaries. > - become is faster. > > > All this is really cool :) And if I remember well, > there is 64 > bitness coming as well. > > Will Spur also cover ARM ? > > > Spur is an object format, it does not have anything to do with > underlying architecture (well, at least in theoryâ¦ Eliot > should be > able to say more on this). > Cog, in the other side is a jitter, and it has everything > to do with > the architecture so is difficult to have it running on ARM (but > there is work on that direction, so we hope it will be there > eventually). > > It looks like there is a misunderstanding (probably not you, > Thierry, but since Iâve seen it time to time, I take the > chance to > clarify): Spur is not a replacement for Cog, both are > orthogonal (in > fact, Spur runs in Stack vm too). > Real new VM is not âSpurâ vm, is "Cog+Spur" vm. > > > +1. Spur changes the object representation, so it has a new heap > layout, a new layout for objects, and a new garbage collector. > Because > the object format is simpler it allows the Cog JIT to generate > machine > code versions of more operations, in particular basicNew, > basicNew: and > closure and context creation. This is the main reason for the > speedups > in Cog+Spur. As far as the Stack VM goes if you see speedups for > Stack+Spur vs Stack+V3 that's all due to the Spur object > representation > & GC, because there's no JIT. > > Now at the moment the Cog JIT only has an x86 back-end in > production. > Tim Rowledge is working on finishing the ARM back end started by > Lars > Wassermann in the GSoC a few years ago. So soonish we should be > able to > have Cog+V3 or Cog+Spur on e.g. Android. > > As part of 64-bit Spur I will be doing a back end for x86-64. > > > Which is then a 64bits Spur+Cog+Sista, right? > > > It should be able to be used for Spur+Cog or Spur+Cog+Sista. Depends > how quickly I can write the 64-bit Spur and how quickly ClÃ©ment can put > Sista into production. Ok. > And Doug McPherson is also in the mix, having written the ARM > version of > the new FFI plugin, and is going to be building Stack ARM VMs > and soon > enough Cog ARM VMs. > > > Thanks for all those news, this is really great. > > > Yes, I'm very excited. It's so great to have strong collaborators like > ClÃ©ment, Ronie, Doug and Tim. But there's lots of room for more to join > us. For a really cool project how about grabbing Bert Freudenberg's > VMMakerJS Squeak-vm-on-JavaScript, extract the event handling and > rendering part and connect it to the Cog VM via sockets to give us a > really fast web plugin? Is that one really needed? I had the feeling web plugins were so last year and that we could just do: Amber, or even a remote desktop client in the web browser with Squeak/Pharo RDP support (which is a bit more general than a really fast web plugin). Moreover, I see that the only thing with potential linked to the web today is to handle tablets/smartphones, and this is a bit why I'm asking about ARM support (also embedding in small stuff, like Cortex M0-M4 stuff with BLE, solar cells and batteries). For now, the only use we have for Smalltalk in there is as C code generation / deployment IDEs on the desktop (aka B. Pottier Netgen), and as back-end on web deployment with Seaside + others. Thierry

Oct. 25, 2014

Re: [Pharo-dev] [Vm-dev] Weird rehashing problem

by Max Leske

> On 24.10.2014, at 20:49, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > On Fri, Oct 24, 2014 at 7:29 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > Hi > > I have a rather strange problem with rehasing that occurred simultaneously multiple times on the same day but not since. Luckily Iâve saved an image with the debugger in it. The mean thing is: that doesnât help me at all because from what I can tell either the Debugger is broken or thereâs a VM problem. > > I'm interested in taking a look at that image... (and I'm relieved you saw it on both the Cog and the Interpreter VMs ;-) ) Cool! Iâll send you a private message with a link to the image. > > Note: > The image is a Pharo 1.3 image. The problem occurred on two different VMs independently, an NBCog VM (Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-EstebanLorenzano.166] 21.0) and a Squeak VM (Squeak3.10.2 of '5 June 2008' [latest update: #7179]). > The operation during which this happened was the loading of an ImageSegment (in both instances). > > > Hereâs what happened. I got a SubscriptOutOfBounds error during rehashing of a Dictionary. When I look at the debugger itâs clear why the exception got signaled but not how that situation could ever happen. > > These are the top three contexts on the stack: > > Array(Object)>>errorSubscriptBounds: > Array(Object)>>at:put: > CBConfiguration(Dictionary)>>noCheckAdd: > > This is the #noCheckAdd: methodâ > > noCheckAdd: anObject > "Must be defined separately for Dictionary because (self findElementOrNil:) expects a key, not an association. 9/7/96 tk" > > array at: (self findElementOrNil: anObject key) put: anObject. > tally := tally + 1 > > and hereâs #at:put: where the exception is signaled: > > at: index put: value > <primitive: 61> > index isInteger ifTrue: > [self class isVariable > ifTrue: [(index >= 1 and: [index <= self size]) > ifTrue: [self errorImproperStore] > ifFalse: [self errorSubscriptBounds: index]] <âââ signaled > ifFalse: [self errorNotIndexable]]. > index isNumber > ifTrue: [^self at: index asInteger put: value] > ifFalse: [self errorNonIntegerIndex] > > Hereâs the weird thing: according to the debugger âarray' in #noCheckAdd: IS NOT THE SAME INSTANCE as âselfâ in #at:put:!!!!!! ????????? When I look at the pointers to both arrays, the correct one is pointed to by the dictionary while the other is only being referenced by the exception context: > > Bad array: > 1: SubscriptOutOfBounds: 88 > 2: Array(Object)>>errorSubscriptBounds: > 3: Array(Object>>at:put: > 4: an Inspector > â¦ > > Good array: > 1: aCBConfiguration(size 107) > > > I really have no clue how this could have happened. Iâd appreciate any thoughts you might haveâ¦ > > Cheers, > Max > > > > -- > best, > Eliot

Oct. 25, 2014

Re: [Pharo-dev] Run Spur run!!

by Hilaire

Le 24/10/2014 14:02, stepharo a Ã©crit : > > On 24/10/14 10:31, Hilaire wrote: >> Le 23/10/2014 21:49, Tudor Girba a Ã©crit : >>> This is amazing. If we add to it that we will be able to have >>> significantly larger images ... dreaming ... :) >>> >> Hey, but some time you also need smaller one ;-) > Guille got a 11k image :) so we are getting there too :) Fantastic ! For now I stopped the DrGeo maintenance on tablet for multiple reasons. One of the reason was the growing image of Pharo 3 and the difficulty to shrink it. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 25, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 25, 2014

[pharo-project/pharo-core] a0ee53: 40326

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: a0ee53a37393ed75c77489e021fbe8b45e0c3bcd https://github.com/pharo-project/pharo-core/commit/a0ee53a37393ed75c77489e0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-25 (Sat, 25 Oct 2014) Changed paths: A Komitter.package/RemotesManager.class/instance/accessing/selectedRemotes.st M Komitter.package/RemotesManager.class/instance/initialization/initialize.st M Komitter.package/RemotesManager.class/instance/private/selected_changed_.st M RPackage-SystemIntegration.package/extension/RPackageOrganizer/instance/registerInterestToAnnouncer_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script326.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40326.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A SmartSuggestions.package/SugsSuggestionFactory.class/class/block/commandsForBlock.st A SmartSuggestions.package/SugsSuggestionFactory.class/class/private/collectorForBlock.st M SmartSuggestions.package/SugsSuggestionFactory.class/class/source/createExtractMethod.st M SmartSuggestions.package/SugsSuggestionFactory.class/class/source/createExtractToLocalVariable.st A SmartSuggestions.package/extension/RBBlockNode/instance/specialCommands.st Log Message: ----------- 40326 14313 Replace Announcer>>#on:send:to:s senders in RPackage-SystemIntegration https://pharo.fogbugz.com/f/cases/14313 14303 RemotesManager: Make more generally useful https://pharo.fogbugz.com/f/cases/14303 11065 Blocks should have some suggestions (at least the same as expressions so far) https://pharo.fogbugz.com/f/cases/11065 http://files.pharo.org/image/40/40326.zip

Oct. 25, 2014

Re: [Pharo-dev] Shout is strange with GT

by Tudor Girba

Hi, There is no difference between the Shout in Rubric and the one in Nautilus. Could you give us the complete text you are typing? Cheers, Doru On Sat, Oct 25, 2014 at 8:30 AM, stepharo <stepharo(a)free.fr> wrote: > this is strange > > if I type > > tr -> italized tr > > tra -> red plain > > while there is translated so it should italicized all the way. > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 25, 2014

Re: [Pharo-dev] [ANN] new GT features: disk memory, ws.stfx.eu sharing, closeable panes and others

by Tudor Girba

Hi Steph, No. It's just a stupid dump on the harddisk of the current contents as soon as there is a change. Where do I find more about the undo mechanism? Cheers, Doru On Sat, Oct 25, 2014 at 8:40 AM, stepharo <stepharo(a)free.fr> wrote: > For Instant caching did you use the undo mechanism of Alain? > > Stef > On 25/10/14 06:19, Tudor Girba wrote: > > Hi, > > We are quite actively working on GT. > > First of all, thanks everyone for the feedback. We take it quite > seriously and we do our best to take it into account. Please keep the > discussions flowing. > > I summarized some of the things that happened recently in the playground > and inspector here: > > http://www.humane-assessment.com/blog/gt-developments-endless-playground-me… > > Let us know what you think. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 25, 2014

Re: [Pharo-dev] [ANN] new GT features: disk memory, ws.stfx.eu sharing, closeable panes and others

by stepharo

For Instant caching did you use the undo mechanism of Alain? Stef On 25/10/14 06:19, Tudor Girba wrote: > Hi, > > We are quite actively working on GT. > > First of all, thanks everyone for the feedback. We take it quite > seriously and we do our best to take it into account. Please keep the > discussions flowing. > > I summarized some of the things that happened recently in the > playground and inspector here: > http://www.humane-assessment.com/blog/gt-developments-endless-playground-me… > > Let us know what you think. > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 25, 2014