- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] .source file

by stepharo

>> -- >> 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 > > Cheers, > Henry > > * something along the lines of: > | nativeMethods | > nativeMethods := (Pragma allInstances select: [ :each | each arguments > = #(#primitiveNativeCall #NativeBoostPlugin) ]) collect: #method. > > nativeMethods do: [ :nativeMethod | > nativeMethod methodClass methodDict at: nativeMethod selector put: > (nativeMethod copyWithTrailerBytes: > (CompiledMethodTrailer new sourceCode: nativeMethod sourceCode))] > > ** TrailerWithEmbeddedTemps would probably be sufficient, but other > than a reserved type, I can't see there's working code for it > >

Oct. 24, 2014

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

by stepharo

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 :) >

Oct. 24, 2014

Re: [Pharo-dev] Playground/Rubric bracket highlighting in the System Browser

by stepharo

> Hi! > > Playground has a very nice feature that it highlights matching > bracket. I guess Rubric does it. The default editor does it too. if you go at the end of the [ ] ^ you get the first one in bold check also the settings Stef > Is this something that is planned to be implemented into the System > Browser editor? That would probably mean replacing the > PluggableTextMorph, but I don't know if there are any problems with > doing so. > > Also is there a keyboard shortcut for jumping to the matching > brace/bracket? > > Peter

Oct. 24, 2014