November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] CalipeL: a benchmarking tool for Smalltalk/X and Pharo

by Max Leske

Hi Jan, That looks pretty cool! We use SMark (http://smalltalkhub.com/#!/~PharoExtras/SMark) for benchmarking and CI integration for Fuel. If you know SMark, could you give me an idea of what the differences are? Cheers, Max > On 23 Oct 2015, at 10:47, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > Hi there, > > After more than 2 years of (time-to-time) development and about > that much time of use, I'd like to announce CalipeL, a tool for > benchmarking and monitoring performance regressions. > > The basic ideas that drove the development: > > * Benchmarking and (especially) interpreting benchmark results > is always a monkey business. The tool should produce raw numbers, > letting the user to use whichever statistics she need to make up > (desired) results. > * Benchmark results should be kept and managed at a single place so > one can view and retrieve all past benchmark results pretty much > the same way as one can view and retrieve past versions of > the software from a source code management tool. > > Features: > > - simple - creating a benchmark is as simple as writing a method > in a class > - flexible - a special set-up and/or warm-up routines could be > specified at benchmark-level as well as set of parameters > to allow fine-grained measurements under different conditions > - batch runner - contains a batch runner allowing one to run > benchmarks from a command line or at CI servers such as Jenkins. > - web - comes with simple web interface to gather and process > benchmark results. However, the web application would deserve > some more work. > > Repository: > > https://bitbucket.org/janvrany/jv-calipel > > http://smalltalkhub.com/#!/~JanVrany/CalipeL-S (read-only export > from the above and Pharo-specific code) > > More information: > > https://bitbucket.org/janvrany/jv-calipel/wiki/Home > > I have been using CalipeL for benchmarking and keeping track of > performance of Smalltalk/X VM, STX:LIBJAVA, a PetitParser compiler > and other code I was working over the time. > > Finally, I'd like to thank to Marcel Hlopko for his work on the > web application and Jan Kurs for his comments. > > I hope some of you may find it useful. If you have any comments > or questions, do not hesitate and let me know! > > Regards, Jan >

Nov. 1, 2015

Re: [Pharo-dev] tests should be green

by Peter UhnÃ¡k

> > Marcus we should NOT use asClass in the system. > > What is the appropriate retrieval of classes from a string/symbol? Asking the Globals table? Peter

Nov. 1, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 1, 2015

[pharo-project/pharo-core] 0fffa4: 50416

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0fffa43bcc8dcaec3e70b6d36160c9bd8e3920cd https://github.com/pharo-project/pharo-core/commit/0fffa43bcc8dcaec3e70b6d3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-01 (Sun, 01 Nov 2015) Changed paths: M Collections-Sequenceable.package/Interval.class/README.md M Morphic-Widgets-Windows.package/CollapsedMorph.class/README.md M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/classRenamed_.st M Refactoring-Critics.package/RBInconsistentMethodClassificationRule.class/instance/running/basicCheck_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50415.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50416.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50415.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50416.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50416 16896 Update Nautiluss title when we Rename the browed class. https://pharo.fogbugz.com/f/cases/16896 16904 Comment for CollapsedMorph https://pharo.fogbugz.com/f/cases/16904 16909 Improve Interval comment https://pharo.fogbugz.com/f/cases/16909 16907 Can not inspect doIt methods https://pharo.fogbugz.com/f/cases/16907 http://files.pharo.org/image/50/50416.zip

Nov. 1, 2015

Re: [Pharo-dev] Sista cons

by ClÃ©ment Bera

Hello Ben, In short: - Sista hotspot detection can be used for other things than the optimizer easily, so you can do what you want with it and it has been stable for a while now. - If you want to optimize your code, you can already use the time profiler, it's likely to be better than the hot spot detection to find out what to optimize and it gives you information about which method call what method. - You can't solve the problem of instruction selection / register allocation from the image with the current interface image-VM, hence a human doing it instead of the optimizer doesn't solve the issue. I've already worked on the JIT back for these problems, there is still some work to do but we are solving at least partially the issue. Cheers Clement 2015-11-01 2:59 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > I just bumped into a very nice read on Sista that I had missed before... > http://www.slideshare.net/esug/sista-talkesug2 > > Slide 52 states cons are... > Some optimisations are difficult: > * Instruction selection > * Instruction scheduling > * Register selection > and just thinking out loud, I wonder what possibility there might be > after Sista that its hotspot detection could be used to > flag/prioritise methods which a human could manually optimise, > providing & recording the conditions under which that human-optimised > method/call-stack can be used ?? > > cheers -ben > >

Nov. 1, 2015

Re: [Pharo-dev] tests should be green

by Marcus Denker

> On 01 Nov 2015, at 02:06, stepharo <stepharo(a)free.fr> wrote: > >>> > we need to write a script to delete all the wrong methods. >>> >> >> I inspected the failing lint rule and executed on the dictionary: >> >> self keys do: [:classSymbol | >> (self at: classSymbol) do: [:selector | >> classSymbol asClass removeSelector: selector. >> ]] >> >> resulting slice is committed: >> <https://pharo.fogbugz.com/f/cases/16254/>https://pharo.fogbugz.com/f/cases/16254/ <https://pharo.fogbugz.com/f/cases/16254/> >> > Marcus we should NOT use asClass in the system. Yes, it was just a throw-away script. Not in the image. Marcus

Nov. 1, 2015

Re: [Pharo-dev] Does anyone remember details of a "pro-Smalltalk" merger circa 2013?

by Eliot Miranda

I know of a similar case, but the numbers are 200 Java vs 80 St. It's not at all surprising since the St team is doing at least as much at less cost. If the merged company is rational, what other choice would it make? I'm not willing to discuss details. _,,,^..^,,,_ (phone) > On Oct 30, 2015, at 11:23 AM, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > I heard an anecdote of a recent merger between two companies in which one had > over 200 people supporting a Java application and the other had ~25 people > supporting a Smalltalk application. The surprising result was that the > Smalltalk application was selected for the merged company rather than the > Java one. > > I would like to know which companies were involved, when this occurred, and > what the precise details were. > > > Thank you! > > > > -- > View this message in context: http://forum.world.st/Does-anyone-remember-details-of-a-pro-Smalltalk-merge… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 1, 2015

Re: [Pharo-dev] Does anyone remember details of a "pro-Smalltalk" merger circa 2013?

by Phil (list)

On Fri, 2015-10-30 at 11:23 -0700, Richard Sargent wrote: > I heard an anecdote of a recent merger between two companies in which > one had > over 200 people supporting a Java application and the other had ~25 > people > supporting a Smalltalk application. The surprising result was that > the > Smalltalk application was selected for the merged company rather than > the > Java one. > > I would like to know which companies were involved, when this > occurred, and > what the precise details were. > If it's the one I'm thinking of the details got mixed up in translation: GemStone (best known for their Smalltalk database) got bought by a division of VMware in 2010. Â However, I remember it as VMware wanting the Java piece, not the Smalltalk piece. Â In 2013 the previous owners of GemStone (i.e. the ones that sold it in 2010) acquired back the rights to the Smalltalk piece leaving VMware with the Java piece that was the driver behind the original deal. Â I have no first-hand or insider information, just what I remember being reported when those deals happened... > Thank you! > > > > -- > View this message in context: http://forum.world.st/Does-anyone-remem > ber-details-of-a-pro-Smalltalk-merger-circa-2013-tp4858715.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. >

Nov. 1, 2015

Re: [Pharo-dev] Does anyone remember details of a "pro-Smalltalk" merger circa 2013?

by S Krish

Surprising from a "follow the herd" psyche amongst the corporate management and all institutions. They are wary of Smalltalk in general with very few competent resources available makes them more incapable to drive their personal agenda. Also for institutions, the insecure nature of Smalltalk, the lack of standardized monitoring tools et als is another factor that plays to opt for Java or .Net. I suspect this maybe an on the cloud, self managed service which is assessed purely on its merits... if its true. On Fri, Oct 30, 2015 at 11:53 PM, Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > I heard an anecdote of a recent merger between two companies in which one > had > over 200 people supporting a Java application and the other had ~25 people > supporting a Smalltalk application. The surprising result was that the > Smalltalk application was selected for the merged company rather than the > Java one. > > I would like to know which companies were involved, when this occurred, and > what the precise details were. > > > Thank you! > > > > -- > View this message in context: > http://forum.world.st/Does-anyone-remember-details-of-a-pro-Smalltalk-merge… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Nov. 1, 2015

Sista cons

by Ben Coman

I just bumped into a very nice read on Sista that I had missed before... http://www.slideshare.net/esug/sista-talkesug2 Slide 52 states cons are... Some optimisations are difficult: * Instruction selection * Instruction scheduling * Register selection and just thinking out loud, I wonder what possibility there might be after Sista that its hotspot detection could be used to flag/prioritise methods which a human could manually optimise, providing & recording the conditions under which that human-optimised method/call-stack can be used ?? cheers -ben

Nov. 1, 2015