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

Re: [Pharo-dev] Case 16725: why no reaction?

by Marcus Denker

> On 02 Nov 2015, at 16:30, webwarrior <reg(a)webwarrior.ws> wrote: > > https://pharo.fogbugz.com/f/cases/16725 > > Almost a month has passed > yes, there are 600 open issuesâ¦ Marcus

Nov. 2, 2015

Re: [Pharo-dev] Case 16725: why no reaction?

by Nicolai Hess

2015-11-02 16:30 GMT+01:00 webwarrior <reg(a)webwarrior.ws>: > https://pharo.fogbugz.com/f/cases/16725 > > Almost a month has passed > > - there are many other things to do - we don't have a real spec maintainer - the issue has milestone "Later" - ~ 300 for milestone pharo 5 if you can create slices for the changes, I can help with testing and reviewing them. > > > -- > View this message in context: > http://forum.world.st/Case-16725-why-no-reaction-tp4858968.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Nov. 2, 2015

WhatsUp from: 2015-11-02 until: 2015-11-15

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2015-11-15 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Nov. 2, 2015

Case 16725: why no reaction?

by webwarrior

https://pharo.fogbugz.com/f/cases/16725 Almost a month has passed -- View this message in context: http://forum.world.st/Case-16725-why-no-reaction-tp4858968.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 2, 2015

Re: [Pharo-dev] Metacello and preparing a release?

by stepharo

Yes now I remember :) Stef Le 1/11/15 15:51, Tudor Girba a Ã©crit : > We released this as Snapshotcello :) > > http://www.smalltalkhub.com/#!/~girba/Snapshotcello/ > <http://www.smalltalkhub.com/#%21/%7Egirba/Snapshotcello/> > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… > http://www.tudorgirba.com/blog/snappier-snapshotcello > > Doru > > > On Mon, Nov 2, 2015 at 12:39 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > I implemented something like that for Moose. > It walked all the configuration and generate a <frozen> method > with all the versions packages > So I did not have to ask people to version their versions. > > I can dig it up if you want (it is draft). > > Stef > > Le 30/10/15 10:04, Eliot Miranda a Ã©crit : > > Hi Dale, > > but why can't Metacello provide something really simple > that automatically generates a configuration with all the > prerequisites fully defined as fixed specific versions? Then > Holger can easily freeze his release using the new confit and > continue his internal development using his current > configuration. Why is is about the repository and not the > versions? Seems like the tail wagging the dog to me. > > _,,,^..^,,,_ (phone) > > On Oct 30, 2015, at 12:44 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > Holger ... > > Frankly this is one of the main reasons I have headed down > the path of using "git" (or any other disk-based scm) for > GsDevKit/GLASS .... > > If all of the applications that you use are managed under > "git", then for production you make local clones for all > of the projects including your own ... Use the Metacallo > lock[1] command and lock each project to reference your > local filtree/clone ... then when you use "Metacello new" > to load projects, the "locked" versions have precedence > and there is no need to modify all of the > configurations/baselines or try the half a dozen other > hacks ... > > With the approach you can have a development set of > project clones, a sandbox set and a production set ... and > all three subsystesm use the exact same load scripts ... > you simply change which repositories are locked ... > > Managing locks can be tricky, but it's a problem that I've > solved with tODE as well, use .ston files that contain a > "project entry" specification object with a number of > fields including whther or not the spec is locked... when > an image (stone in the case of GemStone) comes up it > looks for "project entries" on disk and it then registers > those projects in the Metacello Project registry ... voila > _if_ you load one of those locked projects your local > clone will be used ... > > I will talking about these things at the upcoming > Smalltalks in Buenos Aires ... > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… > > On 10/30/2015 03:10 AM, Holger Freyther wrote: > Hi, > > I have an application that is about to be moved into > production. Currently it is > pulling "stable" or sometimes bleedingEdge of other > configurations. After the > system moves from testing into production I would like > to have tight control of > which packages are updated from one version to > another. E.g. not have a > Voyage "stable" upgrade just because there is a new > stable version but probably > at the same time still use a symbolic reference > myapp-stable-5 to load the > package? > > Is there a common/known to work approach. I could > identify all used Metacello > configs and move them to my own infrastructure and > then copy the use packages > as well. Is there tooling support for adding such a > "freeze"? How do other handle > a release of an application that needs to be updated > in an "incremental" way? > > cheers > holger > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Nov. 2, 2015

Re: [Pharo-dev] Metacello and preparing a release?

by Tudor Girba

We released this as Snapshotcello :) http://www.smalltalkhub.com/#!/~girba/Snapshotcello/ http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-re… http://www.tudorgirba.com/blog/snappier-snapshotcello Doru On Mon, Nov 2, 2015 at 12:39 AM, stepharo <stepharo(a)free.fr> wrote: > I implemented something like that for Moose. > It walked all the configuration and generate a <frozen> method with all > the versions packages > So I did not have to ask people to version their versions. > > I can dig it up if you want (it is draft). > > Stef > > Le 30/10/15 10:04, Eliot Miranda a Ã©crit : > > Hi Dale, >> >> but why can't Metacello provide something really simple that >> automatically generates a configuration with all the prerequisites fully >> defined as fixed specific versions? Then Holger can easily freeze his >> release using the new confit and continue his internal development using >> his current configuration. Why is is about the repository and not the >> versions? Seems like the tail wagging the dog to me. >> >> _,,,^..^,,,_ (phone) >> >> On Oct 30, 2015, at 12:44 PM, Dale Henrichs < >>> dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> Holger ... >>> >>> Frankly this is one of the main reasons I have headed down the path of >>> using "git" (or any other disk-based scm) for GsDevKit/GLASS .... >>> >>> If all of the applications that you use are managed under "git", then >>> for production you make local clones for all of the projects including your >>> own ... Use the Metacallo lock[1] command and lock each project to >>> reference your local filtree/clone ... then when you use "Metacello new" to >>> load projects, the "locked" versions have precedence and there is no need >>> to modify all of the configurations/baselines or try the half a dozen other >>> hacks ... >>> >>> With the approach you can have a development set of project clones, a >>> sandbox set and a production set ... and all three subsystesm use the exact >>> same load scripts ... you simply change which repositories are locked ... >>> >>> Managing locks can be tricky, but it's a problem that I've solved with >>> tODE as well, use .ston files that contain a "project entry" specification >>> object with a number of fields including whther or not the spec is >>> locked... when an image (stone in the case of GemStone) comes up it looks >>> for "project entries" on disk and it then registers those projects in the >>> Metacello Project registry ... voila _if_ you load one of those locked >>> projects your local clone will be used ... >>> >>> I will talking about these things at the upcoming Smalltalks in Buenos >>> Aires ... >>> >>> Dale >>> >>> [1] >>> https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… >>> >>> On 10/30/2015 03:10 AM, Holger Freyther wrote: >>>> Hi, >>>> >>>> I have an application that is about to be moved into production. >>>> Currently it is >>>> pulling "stable" or sometimes bleedingEdge of other configurations. >>>> After the >>>> system moves from testing into production I would like to have tight >>>> control of >>>> which packages are updated from one version to another. E.g. not have a >>>> Voyage "stable" upgrade just because there is a new stable version but >>>> probably >>>> at the same time still use a symbolic reference myapp-stable-5 to load >>>> the >>>> package? >>>> >>>> Is there a common/known to work approach. I could identify all used >>>> Metacello >>>> configs and move them to my own infrastructure and then copy the use >>>> packages >>>> as well. Is there tooling support for adding such a "freeze"? How do >>>> other handle >>>> a release of an application that needs to be updated in an >>>> "incremental" way? >>>> >>>> cheers >>>> holger >>>> >>> >>> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 1, 2015

Re: [Pharo-dev] Metacello and preparing a release?

by stepharo

I implemented something like that for Moose. It walked all the configuration and generate a <frozen> method with all the versions packages So I did not have to ask people to version their versions. I can dig it up if you want (it is draft). Stef Le 30/10/15 10:04, Eliot Miranda a Ã©crit : > Hi Dale, > > but why can't Metacello provide something really simple that automatically generates a configuration with all the prerequisites fully defined as fixed specific versions? Then Holger can easily freeze his release using the new confit and continue his internal development using his current configuration. Why is is about the repository and not the versions? Seems like the tail wagging the dog to me. > > _,,,^..^,,,_ (phone) > >> On Oct 30, 2015, at 12:44 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> Holger ... >> >> Frankly this is one of the main reasons I have headed down the path of using "git" (or any other disk-based scm) for GsDevKit/GLASS .... >> >> If all of the applications that you use are managed under "git", then for production you make local clones for all of the projects including your own ... Use the Metacallo lock[1] command and lock each project to reference your local filtree/clone ... then when you use "Metacello new" to load projects, the "locked" versions have precedence and there is no need to modify all of the configurations/baselines or try the half a dozen other hacks ... >> >> With the approach you can have a development set of project clones, a sandbox set and a production set ... and all three subsystesm use the exact same load scripts ... you simply change which repositories are locked ... >> >> Managing locks can be tricky, but it's a problem that I've solved with tODE as well, use .ston files that contain a "project entry" specification object with a number of fields including whther or not the spec is locked... when an image (stone in the case of GemStone) comes up it looks for "project entries" on disk and it then registers those projects in the Metacello Project registry ... voila _if_ you load one of those locked projects your local clone will be used ... >> >> I will talking about these things at the upcoming Smalltalks in Buenos Aires ... >> >> Dale >> >> [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… >> >>> On 10/30/2015 03:10 AM, Holger Freyther wrote: >>> Hi, >>> >>> I have an application that is about to be moved into production. Currently it is >>> pulling "stable" or sometimes bleedingEdge of other configurations. After the >>> system moves from testing into production I would like to have tight control of >>> which packages are updated from one version to another. E.g. not have a >>> Voyage "stable" upgrade just because there is a new stable version but probably >>> at the same time still use a symbolic reference myapp-stable-5 to load the >>> package? >>> >>> Is there a common/known to work approach. I could identify all used Metacello >>> configs and move them to my own infrastructure and then copy the use packages >>> as well. Is there tooling support for adding such a "freeze"? How do other handle >>> a release of an application that needs to be updated in an "incremental" way? >>> >>> cheers >>> holger >> >

Nov. 1, 2015

Re: [Pharo-dev] tests should be green

by stepharo

if it makes sense self environment at: else Smalltalk globals at: like that it is clear and the environment is under control not the class. Le 1/11/15 02:40, Peter UhnÃ¡k a Ã©crit : > >> 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

Re: [Pharo-dev] tests should be green

by stepharo

great! Le 1/11/15 01:00, Marcus Denker a Ã©crit : > >> On 01 Nov 2015, at 02:06, stepharo <stepharo(a)free.fr >> <mailto:stepharo@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/ >>> >> 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] [ANN] CalipeL: a benchmarking tool for Smalltalk/X and Pharo

by Jan Vrany

Hi Max, I looked at some version of SMark years ago and never usedÂ it extensively, so I might be wrong, but:Â * SMark executor does some magic with numbers. It tries toÂ Â calculate a number of iterations to run in order to getÂ Â "statistically meaningful results". Maybe it's me, but Â I could not fully understand what it does and why it does it Â so.Â Â CalipeL does no magic - it gives you raw numbers (no average, no mean, Â rather a sequence of measurements). It's up to the one who processes and Â interprets the data to use whatever method she likes (and whichever Â gives the numbers she'd like to see :-) This transparency wasÂ Â important for our needs.Â * SMark, IIRC, requires benchmarks to inherit from some base class Â (like SUnit). Also, not sure if SMark allows you to specify a warmup- Â phase (handy for example to measure peak performance when caches are Â filled or so).Â Â CalipeL, OTOH, uses method annotations to describe the benchmark, Â so one can turn a regular SUnit test method into benchmark as simply Â as annotating it with <benchmark>. A warmup method and setup/teardown Â methods can be specified per-benchmark.Â * SMark has no support for parametrization.Â Â In Calipel, support for benchmark parameters was one of theÂ Â requirements from the very beginning. A little example:Â Â I had to optimize performance of Object>>perform: family of methods Â for they was thought to be slowish. I came up with severalÂ Â variants of of a "better" implementation, no knowing which oneÂ Â is the best. How does each of them behave under different workloads?Â Â Like - how the number of distinct receivier classes affects the performance?Â Â How the number of distinct selectors affects the performance?Â Â Is the performance different when receiver classes are distributed Â uniformly or normally (which seems to be more common case).Â Â Same for selectors? Is 256 row, 2-way associative cache Â better than 128 rows, 4-way associative?Â Â You have number of parameters, for each parameter you define Â a number of values and CalipeL work out all possible combinations Â and run benchmarks using each. Without parametrization, the number Â of benchmark methods would grow exponentially, making hardÂ Â to experiment with different setups. For me, this is one ofÂ Â key things.Â * SMark measures time only.Â Â CalipeL measures time, too, but has the facility to provide aÂ Â user-defined "measurement instrument", which can be anythingÂ Â (what can be measured, indeed). For example, for some webÂ Â application the execution time might not be that useful, perhaps Â a number of SQL queries it makes is more important. No problem,Â Â define your own measurement instrument and tell CalipeL to use it Â in addition to time, number of GCs, you name it. All results ofÂ Â all instruments are part of machine-readable report, indeed.Â * SMark had no support for "system" profilers and similar.Â Â CalipeL integrates with systemtap/dtrace and cachegrind so oneÂ Â can have a full profile, including VM code and see things likeÂ Â L1/L2 I/D cache misses, mispredicted branches or count eventsÂ Â like context switches, monitor signaling, context evacuation.Â Â Useful only for VM engineers I think, but I cannot image doingÂ Â my work without this. Available only for Smalltalk/X, but should Â not be a big deal adding this to Pharo (simple plugin would do it,Â Â IMO) * Finally, SMark spits out a report and that's it.Â Â CalipeL, OTOH, goes beyond that. It tries for provide toolsÂ Â to gather, store and query results in a centralised way soÂ Â nothing is forgotten. Â (no more: hmm, where are the results of #perform: benchmarks Â I run three months ago? Is it this file? Or that file? Or did IÂ Â deleted them when my laptop run out of disk space?)Â Â And yes, I know that in this area there's a lot of space for Â improvements. What we have now is certainly not ideal, to put Â it mildly :-)Â Hope that gives you the idea.Â Jan On Sun, 2015-11-01 at 12:11 +0100, Max Leske wrote: > 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