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

[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

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by GÃ¶ran Krampe

Hey! Got it installed in a Pharo 2.0 image etc. I am on Ubuntu 12.10 64. You wrote I need libclang.so for 32 bits? And version 3.1 specifically? Also, is there a "sanity test" I can run? That verifies libclang + NB etc. I want to try this on a quite simple little C lib. regards, GÃ¶ran

Jan. 17, 2013

[Pharo-project] [Job][Research] 3-year Researcher Positions Inria

by Marcus Denker

3YEAR RESEARCH POSITIONS IN LILLE, FRANCE ================== Inria-Lille, RMoD Research Group The RMoD research group invites applications to 3-year Starting Research and Advanced Research positions in the Inria center of Lille, France. Proficiency in French is not required. Starting Research Positions ---------------------------------------- This is a starting research position for a period of 3 years. Requirements: - Have a French doctorate or an equivalent international degree; - From 2 to 7 years'experience in research (after the thesis); - No age or nationality conditions. Advanced Research Positions ----------------------------------------- This is a senior research position for a period of 3 years. - Have a French doctorate or an equivalent international degree; - Be able to prove at least eight years of research and/or post-doctoral academic or industrial experience; - No age or nationality conditions. PROFILE ------------- The candidate must have a doctoral degree, a strong background in Computer Science, and internationally significant research achievements in software engineering (particularly software evolution) and/or programming languages. Duties include: - Research (no teaching). - Help manage the RMoD Research group. - Be involved with the self-governance of the Inria Lab and Inria as a whole. - Guide PhD students - Help acquire additional funds for PhD students, Postdocs and Engineers. - Transfer research results to the real world. MISSION ------------ Join one of our two lines of research: Tools for Software Maintenance or New Programming Language Constructs for Software Evolution. THE REGION ------------------ Lille is strategically located in Northern Europe with train connections to Paris (1h) , London (1h30) and Brussels (30 min.) The Nord Pas de Calais region is a dynamic area in both industry and research for computer science with companies that are european leaders in their branch. Lille, the capital of northern France is an attractive metropolis of over 1 million inhabitants. Cost of living in Lille is lower than that of very big cities such as Paris and London. THE TEAM --------------- RMoD is an Inria research project team. It consists of 6 permant researchers (Inria CR and DR, as well as University Assistant Professors) and Engineers, postdocs and students (Master and PhD). RMoD is an international team with more than 20 members from six countries. LINKS: --------- - RMoD: http://rmod.lille.inria.fr - INRIA Lille: http://www.inria.fr/lille/ - INRIA in General: http://www.inria.fr - INRIA Job Offers http://www.inria.fr/en/institute/recruitment/offers - Lille: - http://en.wikipedia.org/wiki/Lille - http://wikitravel.org/en/Lille APPLICATION -------------------- Please contact the head of the research team: Stephane.Ducasse(a)inria.fr or one of the following group members: Nicolas.Anquetil(a)inria.fr, Marcus.Denker(a)inria.fr or Damien.Cassou(a)inria.fr

Jan. 17, 2013

Re: [Pharo-project] Class initialisation after loading

by Sven Van Caekenberghe

Hi Igor, On 17 Jan 2013, at 12:25, 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. > > 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). > > 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. Your analysis is correct. We, library/framwork developers, have to work with what is available, across multiple versions of Pharo, so a solution based on the current situation is preferable. Of course, we can and should improve what we can. > 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. What about MCScriptDefinition and subclasses ? Not that I have any idea how to use this mechanism ;-) > 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. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 17, 2013

Re: [Pharo-project] Class initialisation after loading

by Igor Stasenko

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

Jan. 17, 2013

[Pharo-project] [update 2.0] #20477

by Marcus Denker

20477 ----- Issue 7268: Extended Nautilus Shortcuts for browsing the Class Hierarchys http://code.google.com/p/pharo/issues/detail?id=7268 Issue 7240: Failing Test: ReleaseTest>>.testInstanceSideMethodsWithNilKeyInLastLiteral http://code.google.com/p/pharo/issues/detail?id=7240 Issue 7216: Support the move of instance variables within an inheritance chain when MC forces reshaping the class http://code.google.com/p/pharo/issues/detail?id=7216 Diff information: http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.395.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.743.diff http://ss3.gemstone.com/ss/Pharo20/KernelTests-MarcusDenker.466.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1284.diff

Jan. 17, 2013

Re: [Pharo-project] ConfigurationOfPetitParser has broken #'common' section

by Frank Shearar

On 5 December 2012 22:33, Frank Shearar <frank.shearar(a)gmail.com> wrote: > The attached bootstraps Metacello and Gofer if they're not already > present. (They're not, in Squeak.) > > Offline loading - loading without a network connection - doesn't quite > work yet; I couldn't chase down the nil. But with a network connection > it works just fine. Even though I haven't nailed the offline loading, given that this configuration fixes the described issue and works when you _do_ have an internet connection, who should I talk to about getting this merged in? frank > frank > > On 4 December 2012 22:19, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> Thanks Camillo, that's done the trick. >> >> I've found _another_ problems with the configuration, but that I can >> fix. (The configuration only works if you have a network connection.) >> I'll hopefully post a fix in the very near future. >> >> frank >> >> On 4 December 2012 21:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> hard to guess if I don't know the project :P >>> for me it worked you have all the parsing capabilities minus the debug UIs >>> >>> On 2012-12-04, at 18:51, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>>> Oh, I see a minimal Petit... But isn't that going to be too small? >>>> Alternatively why not a ConfigurationOfGrosParser ? >>>> >>>> Nicolas >>>> >>>> 2012/12/4 Camillo Bruni <camillobruni(a)gmail.com>: >>>>> just load the minimal group and you're fine. That's what we do in 2.0 as well... >>>>> >>>>> >>>>> On 2012-12-04, at 18:32, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>> >>>>>> By "broken" I mean "it might work fine in Pharo but it doesn't in Squeak". >>>>>> >>>>>> That's because PetitParser now uses Glamour, which pulls in a whole >>>>>> host of things that probably don't work in Squeak. (I don't know, I >>>>>> haven't tried, but these are all UI things, and the UI is where Pharo >>>>>> and Squeak are least compatible.) >>>>>> >>>>>> I'm being a bit rude in that I don't yet have a fix for the issue. >>>>>> Ideally, a ConfigurationOf would have Pharo specific stuff and Squeak >>>>>> specific stuff in separate sections, with only the shared things >>>>>> (right now, not Glamour, nor its dependents) in the #'common' section. >>>>>> >>>>>> However, if someone doesn't beat me to it, I'll submit a fix soon, >>>>>> once Squeak 4.4 is out the door. >>>>>> >>>>>> frank >>>>>> >>>>> >>>>> >>>> >>> >>>

Jan. 17, 2013