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

Re: [Pharo-dev] Thank you so much for Pharo 3.0

by Tudor Girba

Hi, Thanks everyone for making this happen. It's great to hear this kind of reports from real life projects. I am sure that Pharo 4 will be even better! Cheers, Doru On Fri, Oct 24, 2014 at 3:03 PM, GastÃ³n Dall' Oglio < gaston.dalloglio(a)gmail.com> wrote: > No more to say, a big big THANK YOU for make and continuously improve > Pharo and the related infrastructure tools. This is a really big job. > I'm always in the path of to show Pharo to my friends and try to use it in > my work, and really that's every time more and more easy :) > > Best regard. > > 2014-10-23 4:29 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > > Fortunately my experience with people I introduced in pharo has been a lot >> more positive than your, they were facinated by what Pharo offers and find >> it very useful, productive and fun environment. Actually one person hated >> it but he was a big troll so I dont count him in. >> >> But none of the people I introduced to Pharo ended keep using it, mainly >> because they were too tied into other platforms and languages and cant >> blame them. It took me 1 year to switch from python and I had to redefine >> the way I was coding and thinking about code. >> >> Even though Stef keeps stressing that Pharo does not have the resources >> of big companies and of course he is correct on other hand we see a clear >> and steady improvement, I think Pharo is on the right path and will correct >> many of the mistakes of Smalltalk and eventually bring much more people in. >> The future is certainly exciting and I am glad I have joined this ride :) >> >> Phareos certainly makes my dreams about coding a reality. Thanks to all >> pharoers for giving us such amazing functionality and working hard and >> thinking outside the box. >> >> On Thu, Oct 23, 2014 at 8:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> Mariano, >>> >>> It is good to hear from you, and it is even better to hear such nice >>> words. Thanks you ! >>> >>> I think that in general, in our day to day struggles, people >>> underestimate just how good Pharo is and how useful it is to do real work >>> in the real world, in other words, to be successful. >>> >>> Do we already have your story as a 'success story' for the website ? >>> >>> Sven >>> >>> > On 23 Oct 2014, at 03:15, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> > >>> > Hi guys, >>> > >>> > I just wanted to share my happiness with you. I joined a team 2 years >>> ago almost to develop a Seaside 3.0 app, using and old Magritte version, >>> and Pharo 1.4. As soon as I started, I created a ConfigurationOfMyApp, and >>> migrated to Pharo 2.0. >>> > >>> > That worked fine for almost 2 years. Since several weeks/months, I >>> wanted to update to new Seaside versions and Pharo. Of course, you never >>> have time, there are always other problems to fix first, etc...But 10 days >>> ago, I stopped everything, and I migrated to Seaside 3.1.3, latest >>> Magritte, latest Bootstrap (very very cool project too...we are using it >>> everywhere), latest everything...and... of course...Pharo 3.0!!! >>> Also..the "port" was almost nothing...everything almost worked out of the >>> box. Thanks to contributors maintaining great softwares like Metacello and >>> all existing configurations. >>> > >>> > Btw...I am also deploying my app in GemStone since almost an year, >>> and this also is being good. Gemstone people also have a great support via >>> mailing list which I very much appreciate. >>> > >>> > I played with Pharo 3.0 when it was released and some time also before >>> that. But not that much. Now..I am using the very same image since at least >>> 10 days. Working full time. All my projects are working great. I cannot >>> believe so good it feels developing in Pharo 3.0. I am using the great Dark >>> Theme from Esteban. Everything is super fast, super nice, super stable. And >>> with my 2.0 images..they always grew too much (up to 500MB), that >>> everything started to be very very slow. I needed to start again with a >>> fresh image, etc. This 3.0 image has almost the same size as I started and >>> continues to be super fast. >>> > >>> > So...I cannot repeat myself how good Pharo 3.0 feels. I should have >>> migrated long ago. Thanks all the contributors and developers for such a >>> great and professional product. >>> > >>> > Best, >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> >>> >>> >> > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 24, 2014

[pharo-project/pharo-core] 75f755: 40325

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 75f7550347358cbfd15771a2a2917d1abd433685 https://github.com/pharo-project/pharo-core/commit/75f7550347358cbfd15771a2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-24 (Fri, 24 Oct 2014) Changed paths: M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/visitor/visitAssignmentNode_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/visitor/visitVariableNode_.st A OpalCompiler-Core.package/OCAbstractVariable.class/instance/read%2Fwrite usage/isRepeatedWrite.st M OpalCompiler-Core.package/OCAbstractVariable.class/instance/read%2Fwrite usage/isWrite.st A OpalCompiler-Core.package/OCAbstractVariable.class/instance/read%2Fwrite usage/markRepeatedWrite.st M OpalCompiler-Core.package/OCTempVariable.class/instance/escaping/markEscapingWrite.st A OpalCompiler-Core.package/OCTempVariable.class/instance/escaping/markRepeatedWrite.st A OpalCompiler-Tests.package/OCASTClosureAnalyzerTest.class/instance/tests - blocks/testExampleWhileNoModification.st A OpalCompiler-Tests.package/OCOpalExamples.class/instance/examples-blocks-optimized/exampleWhileNoModification.st A Polymorph-Widgets.package/TickDialogWindow.class/instance/accessing/selectItems_.st A Polymorph-Widgets.package/TickDialogWindow.class/instance/accessing/selectedItems.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script325.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40325.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeInspector.class/class/tools registry/registerToolsOn_.st M System-Support.package/VirtualMachine.class/instance/attributes/maxExternalSemaphores_.st Log Message: ----------- 40325 14309 add #selectItems: and #selectedItems protocols to TickDialogWindow https://pharo.fogbugz.com/f/cases/14309 14256 wrong number of tempvars for optimized loops https://pharo.fogbugz.com/f/cases/14256 10839 VirtualMachine>>#maxExternalSemaphores: has bogus implementation (sort of) https://pharo.fogbugz.com/f/cases/10839 14308 EyeInspector should not register as #basicInspector https://pharo.fogbugz.com/f/cases/14308 http://files.pharo.org/image/40/40325.zip

Oct. 24, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 24, 2014

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

by kilon alios

very nice so any more information to this, how exactly this optimization works and which kind of data will benefit from this ? On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > remarkable!!! > > congratulations for the impressive results > > thanks for sharing! > > sebastian > > o/ > > > On 23/10/2014, at 17:40, Max Leske <maxleske(a)gmail.com> wrote: > > > > For those of you who missed this on IRC: > > > > henriksp: estebanlm: Care to run a small bench Cog vs Spur for me? > > [3:32pm] henriksp: int := ZnUTF8Encoder new. > > [3:32pm] henriksp: [int decodeBytes:#[67 97 115 104 44 32 108 105 107 > 101 32 226 130 172 44 32 105 115 32 107 105 110 103 0]] bench. > > [3:32pm] henriksp: had a 16x speedup with assembly implementation vs > Cog, if it's 8x vs Spur, that's just really impressive > > [3:44pm] Craig left the chat room. (Quit: Leaving.) > > [3:53pm] Craig joined the chat room. > > [4:08pm] VitamineD joined the chat room. > > [4:20pm] estebanlm: checking > > [4:21pm] estebanlm: Cog: 167,000 per second. > > [4:22pm] estebanlm: Cog[Spur]: 289,000 per second. > > [4:23pm] estebanlm: henriksp: ping > > [4:33pm] tinchodias left the chat room. (Ping timeout: 245 seconds) > > [4:33pm] tinchodias joined the chat room. > > [4:34pm] henriksp: 70% more work done, nice! > > [5:09pm] > > > > > > Yay! :) > >

Oct. 24, 2014

Re: [Pharo-dev] .source file

by Nicolai Hess

2014-10-24 14:09 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 24 Oct 2014, at 14:06, stepharo <stepharo(a)free.fr> wrote: > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > > Few NB-FFI methods will work without sources, as many rely on the > automatic argument name -> signature mapping. > This happens the first time a method is called after startup, and > platform-specific recompilation occurs. When the argument names are > decompiled as arg1, arg2, the mapping will fail. > (Other NB methods that generate machine code without using NB-FFI, will > still work though) > > Theoretically, one could solve this by internalizing the source of all > NB-FFI calling method in the method trailer* at the end of deployment > preparation process. (so no NB methods have a chance to trigger before > image save) > NB puts native code into the same trailer space, and combing different > method trailer types is currently unsupported (AFAIK), but the transition > TrailerWithEmbeddedSource** -> TrailerWithNBCode should happen only once. > > > Yes it would be good to have a method for doing that. > https://pharo.fogbugz.com/default.asp?14311 > > > No, pleaseâ¦ we need to simplify, not make everything complex. > > It would be much better to spend engery on getting rid of .sources and > changesâ¦ we are drowning in complexity with > the current stuff. > > Marcus > > Isn't that for what NativeBoost prepareForProduction is used?

Oct. 24, 2014

Re: [Pharo-dev] Thank you so much for Pharo 3.0

by GastÃ³n Dall' Oglio

No more to say, a big big THANK YOU for make and continuously improve Pharo and the related infrastructure tools. This is a really big job. I'm always in the path of to show Pharo to my friends and try to use it in my work, and really that's every time more and more easy :) Best regard. 2014-10-23 4:29 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > Fortunately my experience with people I introduced in pharo has been a lot > more positive than your, they were facinated by what Pharo offers and find > it very useful, productive and fun environment. Actually one person hated > it but he was a big troll so I dont count him in. > > But none of the people I introduced to Pharo ended keep using it, mainly > because they were too tied into other platforms and languages and cant > blame them. It took me 1 year to switch from python and I had to redefine > the way I was coding and thinking about code. > > Even though Stef keeps stressing that Pharo does not have the resources of > big companies and of course he is correct on other hand we see a clear and > steady improvement, I think Pharo is on the right path and will correct > many of the mistakes of Smalltalk and eventually bring much more people in. > The future is certainly exciting and I am glad I have joined this ride :) > > Phareos certainly makes my dreams about coding a reality. Thanks to all > pharoers for giving us such amazing functionality and working hard and > thinking outside the box. > > On Thu, Oct 23, 2014 at 8:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Mariano, >> >> It is good to hear from you, and it is even better to hear such nice >> words. Thanks you ! >> >> I think that in general, in our day to day struggles, people >> underestimate just how good Pharo is and how useful it is to do real work >> in the real world, in other words, to be successful. >> >> Do we already have your story as a 'success story' for the website ? >> >> Sven >> >> > On 23 Oct 2014, at 03:15, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > >> > Hi guys, >> > >> > I just wanted to share my happiness with you. I joined a team 2 years >> ago almost to develop a Seaside 3.0 app, using and old Magritte version, >> and Pharo 1.4. As soon as I started, I created a ConfigurationOfMyApp, and >> migrated to Pharo 2.0. >> > >> > That worked fine for almost 2 years. Since several weeks/months, I >> wanted to update to new Seaside versions and Pharo. Of course, you never >> have time, there are always other problems to fix first, etc...But 10 days >> ago, I stopped everything, and I migrated to Seaside 3.1.3, latest >> Magritte, latest Bootstrap (very very cool project too...we are using it >> everywhere), latest everything...and... of course...Pharo 3.0!!! >> Also..the "port" was almost nothing...everything almost worked out of the >> box. Thanks to contributors maintaining great softwares like Metacello and >> all existing configurations. >> > >> > Btw...I am also deploying my app in GemStone since almost an year, and >> this also is being good. Gemstone people also have a great support via >> mailing list which I very much appreciate. >> > >> > I played with Pharo 3.0 when it was released and some time also before >> that. But not that much. Now..I am using the very same image since at least >> 10 days. Working full time. All my projects are working great. I cannot >> believe so good it feels developing in Pharo 3.0. I am using the great Dark >> Theme from Esteban. Everything is super fast, super nice, super stable. And >> with my 2.0 images..they always grew too much (up to 500MB), that >> everything started to be very very slow. I needed to start again with a >> fresh image, etc. This 3.0 image has almost the same size as I started and >> continues to be super fast. >> > >> > So...I cannot repeat myself how good Pharo 3.0 feels. I should have >> migrated long ago. Thanks all the contributors and developers for such a >> great and professional product. >> > >> > Best, >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> >> >> >

Oct. 24, 2014

Re: [Pharo-dev] .source file

by Hilaire

Le 24/10/2014 13:03, Sven Van Caekenberghe a Ã©crit : > Yes, I believe NativeBoost needs to know the argument names of primitives to match method arguments to C primitives, and this cannot be done with decompilation or something like that GLURP! -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Oct. 24, 2014

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

by Sebastian Sastre

remarkable!!! congratulations for the impressive results thanks for sharing! sebastian o/ > On 23/10/2014, at 17:40, Max Leske <maxleske(a)gmail.com> wrote: > > For those of you who missed this on IRC: > > henriksp: estebanlm: Care to run a small bench Cog vs Spur for me? > [3:32pm] henriksp: int := ZnUTF8Encoder new. > [3:32pm] henriksp: [int decodeBytes:#[67 97 115 104 44 32 108 105 107 101 32 226 130 172 44 32 105 115 32 107 105 110 103 0]] bench. > [3:32pm] henriksp: had a 16x speedup with assembly implementation vs Cog, if it's 8x vs Spur, that's just really impressive > [3:44pm] Craig left the chat room. (Quit: Leaving.) > [3:53pm] Craig joined the chat room. > [4:08pm] VitamineD joined the chat room. > [4:20pm] estebanlm: checking > [4:21pm] estebanlm: Cog: 167,000 per second. > [4:22pm] estebanlm: Cog[Spur]: 289,000 per second. > [4:23pm] estebanlm: henriksp: ping > [4:33pm] tinchodias left the chat room. (Ping timeout: 245 seconds) > [4:33pm] tinchodias joined the chat room. > [4:34pm] henriksp: 70% more work done, nice! > [5:09pm] > > > Yay! :)

Oct. 24, 2014

Re: [Pharo-dev] .source file

by Marcus Denker

> On 24 Oct 2014, at 14:06, stepharo <stepharo(a)free.fr> wrote: > > >>> -- >>> Dr. Geo - http://drgeo.eu <http://drgeo.eu/> >>> iStoa - http://istoa.drgeo.eu <http://istoa.drgeo.eu/> >> >> Few NB-FFI methods will work without sources, as many rely on the automatic argument name -> signature mapping. >> This happens the first time a method is called after startup, and platform-specific recompilation occurs. When the argument names are decompiled as arg1, arg2, the mapping will fail. >> (Other NB methods that generate machine code without using NB-FFI, will still work though) >> >> Theoretically, one could solve this by internalizing the source of all NB-FFI calling method in the method trailer* at the end of deployment preparation process. (so no NB methods have a chance to trigger before image save) >> NB puts native code into the same trailer space, and combing different method trailer types is currently unsupported (AFAIK), but the transition >> TrailerWithEmbeddedSource** -> TrailerWithNBCode should happen only once. > > Yes it would be good to have a method for doing that. > https://pharo.fogbugz.com/default.asp?14311 <https://pharo.fogbugz.com/default.asp?14311> No, pleaseâ¦ we need to simplify, not make everything complex. It would be much better to spend engery on getting rid of .sources and changesâ¦ we are drowning in complexity with the current stuff. Marcus

Oct. 24, 2014

Re: [Pharo-dev] PackageChooser logic

by stepharo

Hilaire could you describe how to get the PackageChooser because people may interpret it in different ways. On 24/10/14 11:53, Hilaire wrote: > I found the logic of the PackageChooser from the finder to be pretty weird. > > You can't directly select the packages you want to search in: you need > to select all, reject, then reselect the ones you want to search in. > > > How do you think about it? > >

Oct. 24, 2014