January 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] CI down?

by StÃ©phane Ducasse

On Jan 17, 2013, at 1:53 AM, Sean P. DeNigris wrote: > Camillo Bruni-3 wrote >> thanks for checking, I am happy if someone else appreciates so much tidy >> server ;) > > When inventing the future, every little bit counts :) > excellent :) You made me laugh I forwarded your quote to our boss :) > > > -- > View this message in context: http://forum.world.st/CI-down-tp4659453p4663840.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 17, 2013

Re: [Pharo-project] the monkey is back in town

by StÃ©phane Ducasse

strange I cannot reach this page. Stef On Jan 16, 2013, at 7:23 PM, Camillo Bruni wrote: > the 100% smalltalk monkey is back at work: > > https://code.google.com/p/pharo/issues/detail?can=2&q=7268 > > let's hope it will stay like this for a while! >

Jan. 17, 2013

Re: [Pharo-project] CI Current Status

by Sven Van Caekenberghe

On 17 Jan 2013, at 18:10, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> We have moved more or less everything to the new Jenkins setup. >> ... >> it gets better every day. > > Bravo! Thanks for all the hard work, Marcus :) Yes, great work, from a whole team ! Sven

Jan. 17, 2013

Re: [Pharo-project] Where should SmalltalkHub bugs be reported?

by Camillo Bruni

I just opened a google code project, it's been too long since we don't have a proper issue tracker for smalltalkhub: https://code.google.com/p/smalltalk-hub On 2013-01-17, at 18:15, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Here's a small one... StHub provides a Monticello registration snippet, which > is cool: > MCHttpRepository > location: 'http://smalltalkhub.com/mc/dh83/fisleg/main' > user: 'SeanDeNigris' > password: '' > But in Pharo 2.0, since there is a user but no password, dialogs pop up > asking for credentials, which can not be ignored. Since the great majority > of uses is for downloading, I think it'd make more sense to leave the > username out. > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/Where-should-SmalltalkHub-bugs-be-reported-tp4663973.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 17, 2013

Re: [Pharo-project] Legacy FileDirectory

by Camillo Bruni

On 2013-01-17, at 18:16, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Camillo Bruni-3 wrote >> http://smalltalkhub.com/#!/~dh83/fisleg/packages/FileSystem-Legacy > > Fisleg!? Really?? This is not C, you know ;) j/k well I was not allowed to use dash in the smalltlakhub name, so consider it as silent protest :D

Jan. 17, 2013

Re: [Pharo-project] Class initialisation after loading

by Eliot Miranda

On Thu, Jan 17, 2013 at 3:25 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > After some thought i decided to contribute my 2cents. > > First, i think it is impossible to introduce a (re)initialization > logic which would suit all different scenarios. > Because it is really depends on what is stored in class variables and/or > pools > and if you add subclasses and then instances into the soup, you might > end up with something > which is really hard to safely reinitialize, because it may have some > inconsistent state at different stages > of initialization. It also, sometimes an order of initialization is > important. > Yes, but on *can* write idempotent class initialization code. So that if the system does reinitialize on every load old code may break until its fixed, but new code will have the advantage of always being correctly initialized. Note that in the VMMaker class reinitializations of the core VM classes (the interpreter, garbage collector, jit, etc) are done *on each launch of the simulator*, and *each vm generation*, let alone on each package load :). [ I'm not recommending this :) ]. One thing I do is when creating singletons for sentinels etc I check whether they've been initialized. e.g. initialize Sentinel ifNil: [Sentinel := Object new] This avoids breaking existing instances that would end up referring to an older value for Sentinel. Much the same goes for any class state that would end up in an instance. One can use become: here too. What we missing, i think is a package pre/post load/update action(s) > which tied directly to the package, > so developer can decide by himself what needs to be (re)initialized > and in what order without need of having some automated tool to decide > it (often wrongly). > The question is which is better, hooks to allow control of initialization on package load (be it Monticello or Fuel) or simple rules for (frequent) reinialization? The former allows one to write naive initialization but at the cost of mastering some complex mechanisms in package loading. The latter forces one to write careful initialization code but has the benefit of simple package loading rules. Further, writing idempotent class initialization code is only a problem with complex class initialization code, and presumably a programmer who is writing such complex code is up to the task of making it idempotent. In simple cases, writing idempotent code should be simple. Personally I'm starting to prefer the latter approach because the complexity ends up in common Smalltalk code (class initialization) and in one place instead of in special Smalltalk code (package loading hooks) in multiple places (all the various package systems). The tools always support common Smalltalk code better than these special hooks. For example, load scripts may be stored as strings in packages, and there-in senders and implementors won't find them. There are, I think, great advantages to having a system composed of freely reinitializable components. It is one of Gilad Bracha's design goals behind Newspeak to allow running programs to be updated on the fly as fixes are released. Gilad particularly likes the fact that this means one can discard legacy code, since all (if this vision is realized) Newspeak programs should be at the latest version. A Smalltalk system with this property would be far more reliable. Imagine a long-running server application that is simply updated as and when bug fixes are available. I think that forcing frequent class reinitialization and forcing users to write idempotent class initialization is consistent with Pharo's philosophical position on fixing broken things, and on good documentation and simplicity. I also think that it's a good idea. I would really like that one day we could have packages as a > first-class entities in a system, so we could express things in simple > way: > > Package named: #Foo. > > Foo>> onLoad > "perform an action when the package is first loaded into image" > MyClass initialize. > > Foo>> onUpdate: oldVersion > "perform an action when different version of package is loaded into > image" > MyClass reinitialize. > > of course, being able to control those actions is just a tip of the > iceberg. > Yes, this is exactly the route I took with VisualWorks parcels. And it was necessary because the code we packaged was legacy and we didn't have the cycles to rewrite that code. But I think it's too complex. It adds another layer to class loading, with its own conventions, that may be specific to a particular package system. Whereas if the rule is "your class will be reinitialized whenever it is loaded in whatever form" it's simple, unambiguous and something one can cope with. KISS. > P.S. i know that MC supports package pre/post load scripts (but > strangely i cannot find where). > so, it is really opaque to all of the tools, since it is outside of > the source codebase of the package. > > P.P.S. Metacello also supports pre/post actions, so i think right now > a best place where you can put (re)initialization code is into > metacello configuration, and initialize things explicitly, rather than > relying on implicit logic of tools. > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Jan. 17, 2013

Re: [Pharo-project] CI Current Status

by Mariano Martinez Peck

Thanks Marcus for keeping up informed. Good progress!!! Best, On Thu, Jan 17, 2013 at 2:10 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Marcus Denker-4 wrote > > We have moved more or less everything to the new Jenkins setup. > > ... > > it gets better every day. > > Bravo! Thanks for all the hard work, Marcus :) > > > > -- > View this message in context: > http://forum.world.st/CI-Current-Status-tp4663967p4663969.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2013

Re: [Pharo-project] Legacy FileDirectory

by Sean P. DeNigris

Camillo Bruni-3 wrote > http://smalltalkhub.com/#!/~dh83/fisleg/packages/FileSystem-Legacy Fisleg!? Really?? This is not C, you know ;) j/k -- View this message in context: http://forum.world.st/Legacy-FileDirectory-tp4658066p4663975.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 17, 2013

[Pharo-project] Where should SmalltalkHub bugs be reported?

by Sean P. DeNigris

Here's a small one... StHub provides a Monticello registration snippet, which is cool: MCHttpRepository location: 'http://smalltalkhub.com/mc/dh83/fisleg/main' user: 'SeanDeNigris' password: '' But in Pharo 2.0, since there is a user but no password, dialogs pop up asking for credentials, which can not be ignored. Since the great majority of uses is for downloading, I think it'd make more sense to leave the username out. Cheers, Sean -- View this message in context: http://forum.world.st/Where-should-SmalltalkHub-bugs-be-reported-tp4663973.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 17, 2013

Re: [Pharo-project] CI Current Status

by Sean P. DeNigris

Marcus Denker-4 wrote > We have moved more or less everything to the new Jenkins setup. > ... > it gets better every day. Bravo! Thanks for all the hard work, Marcus :) -- View this message in context: http://forum.world.st/CI-Current-Status-tp4663967p4663969.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 17, 2013