- Pharo-dev - lists.pharo.org

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

[Pharo-project] CI Current Status

by Marcus Denker

Hi, We have moved more or less everything to the new Jenkins setup. https://ci.inria.fr with the Jenkins at https://ci.inria.fr/pharo Not everything is working yet, but it gets better every day. The setup is *much* faster then the old, very reliable and we have a lot of space for builds. The platform has a cloudstack based virtualization behind, we can define slaves as needed (win and linux), and even externals can ssh to them as root. Mac is covered by a trusted mac mini in the serve room right now, but work has started to add MacOS virtulalized, this will be ready in maybe 2-3 Months. What stays to be done -> for 2.0, the one click is missing -> work on the vm build side is ongoing -> Migrate and delete the existing jobs on the old jenkins -> Retire the old setup -> fix all broken builds -> Staging. Never make a broken build public (both vm and image) Later we are thinking of splitting the Pharo Jenkins in two, one for the official release and dev, one for more experimental projects. But with this we will definitely wait for the Virtual Mac Slaves. Marcus

Jan. 17, 2013

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

by Sean P. DeNigris

Camillo Bruni-3 wrote > - full smalltalk implementation (no more ruby) Yay!!!! -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4663964.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 17, 2013

Re: [Pharo-project] SmalltalkHub update

by Sean P. DeNigris

Wow, SmalltalkHub looks *really* nice! Thanks!! -- View this message in context: http://forum.world.st/SmalltalkHub-update-tp4663339p4663959.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 17, 2013

[Pharo-project] Issue 7281: OSProcess is not loadable/working in 2.0 (was Re: The monkey is back in town)

by Sean P. DeNigris

Camillo Bruni-3 wrote >>> OSProcess should load fine and without legacy when 2.0 is released > I think once 2.0 is declared stable someone will take care of OSProcess. I opened an issue... >From http://code.google.com/p/pharo/issues/detail?id=7281 : > I realize this is not a problem with Pharo itself, but OSProcess is > extremely important and we should track it to make sure it gets loadable > into 2.0. > > I'll email Dave and see what we can come up with... > > Pharo2.0a > Latest update: #20476 > > UndefinedObject(Object)>>doesNotUnderstand: #wait > UnixOSProcessAccessor>>grimReaperProcess in Block: [[event wait.... > BlockClosure>>newProcess in Block: [self value.... > > > At least one problem seems to be updating for FileSystem. > Also, deprecation warnings for OSPlatform class>>osVersion -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4663955.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 17, 2013