- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] .source file

by Henrik Johansen

> On 24 Oct 2014, at 3:25 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 24 Oct 2014, at 3:20 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 24 Oct 2014, at 15:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> Isn't that for what NativeBoost prepareForProduction is used? >>>> >>>> >>> Yes! Now I remember, we solved that usecase already. >>> >>> Good. >> >> Nice! >> >> Maybe it should run after each build, or is that platform dependent ? >> > > > Nonononono. > The NB trailer only knows how to reinstall source from an original trailer with source pointer, so after first invocation, it will lose the source and start failing at next image startup. > > Cheers, > Henry Disregard that, prepareForProduction is implemented differently from what I described, and the argument mapping no longer works they way I seemed to remembered, using the cache if present. It should be safe to called when building, and allows dropping the changes file later on with no bad side-effects like my little hack. Cheers, Henry

Oct. 24, 2014

Re: [Pharo-dev] .source file

by Henrik Johansen

> On 24 Oct 2014, at 3:20 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 24 Oct 2014, at 15:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> Isn't that for what NativeBoost prepareForProduction is used? >>> >>> >> Yes! Now I remember, we solved that usecase already. >> >> Good. > > Nice! > > Maybe it should run after each build, or is that platform dependent ? > Nonononono. The NB trailer only knows how to reinstall source from an original trailer with source pointer, so after first invocation, it will lose the source and start failing at next image startup. Cheers, Henry

Oct. 24, 2014

Re: [Pharo-dev] RemotesManager Fishiness

by stepharo

I completely agree with you and one of the problems is that some people did not take well reviews of their code. I hope that we will be able to change this spirit. > [rant] > This is a weird class! It's protocol seems convoluted to me (even though it > only contains one operation!). > > The standard dialog #actionBlock: is eschewed for #selectedChangedBlock:, > which lets you know every time an item is checked or unchecked. I'm not > clear on the use case for that verbose level of updating. I would think > you'd mostly be interested in the final state once the dialog was accepted. > > In addition, there is a #selectedRemotes instVar, but it never gets updated > and has no getter. > > Maybe I'm just not getting it, but it seems like something was quickly > hacked together as an experiment to serve an immediate purpose without much > design thought. While I love new features, this worries me because it sounds > very familiar and three forks may be one too many ;) Maybe we should have a > more formal code review procedure for shiny new features (non-bug > fix/enhancement)? > [/rant] > > 14303 RemotesManager: Make more generally useful > https://pharo.fogbugz.com/default.asp?14303 > Initial slice incoming... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/RemotesManager-Fishiness-tp4786315.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Oct. 24, 2014

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

by kilon alios

thanks max, i completely forgotten about esug videos, looks like i found what to watch during the weekend :D On Fri, Oct 24, 2014 at 4:12 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 24.10.2014, at 15:06, kilon alios <kilon.alios(a)gmail.com> wrote: > > very nice > > so any more information to this, how exactly this optimization works and > which kind of data will benefit from this ? > > > ClÃ©mentâs byte code set talk at ESUG: > http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRL… > ClÃ©mentâs Sista talk at ESUG (2 parts): > > http://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > > http://www.youtube.com/watch?v=gZOk3qojoVE&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > > Eliotâs Spur talk at ESUG (3 parts): > > http://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL… > > http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRL… > > http://www.youtube.com/watch?v=1Vg0iFeg_pA&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > > > 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 Sven Van Caekenberghe

> On 24 Oct 2014, at 15:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Isn't that for what NativeBoost prepareForProduction is used? >> >> > Yes! Now I remember, we solved that usecase already. > > Good. Nice! Maybe it should run after each build, or is that platform dependent ?

Oct. 24, 2014

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

by Max Leske

> On 24.10.2014, at 15:06, kilon alios <kilon.alios(a)gmail.com> wrote: > > very nice > > so any more information to this, how exactly this optimization works and which kind of data will benefit from this ? ClÃ©mentâs byte code set talk at ESUG: http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRL… <http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRL…> ClÃ©mentâs Sista talk at ESUG (2 parts): http://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… http://www.youtube.com/watch?v=gZOk3qojoVE&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… Eliotâs Spur talk at ESUG (3 parts): http://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL… http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRL… <http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRL…> http://www.youtube.com/watch?v=1Vg0iFeg_pA&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl… > > On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@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 <mailto:maxleske@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 15:05, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-10-24 14:09 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > >> On 24 Oct 2014, at 14:06, stepharo <stepharo(a)free.fr <mailto:stepharo@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 > > > Isn't that for what NativeBoost prepareForProduction is used? > > Yes! Now I remember, we solved that usecase already. Good. Ceterum Censeo: We need to get rid of .sources and .changes. Marcus

Oct. 24, 2014

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