March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3830 in pharo: [Failing Test] Autotes TestHitCounter.testHitCountIncrements

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #7 on issue 3830 by laurent....(a)gmail.com: [Failing Test] Autotes TestHitCounter.testHitCountIncrements http://code.google.com/p/pharo/issues/detail?id=3830 Thank you ! Seems to work. I've created Autotest v1.0.1 and updated ConfigurationOfPharo. Waiting for next build....

March 20, 2011

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

by Igor Stasenko

On 20 March 2011 20:33, Matthew Fulmer <tapplek(a)gmail.com> wrote: > > On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote: >> Except that its my branch and I've been using oscog from the start. Â Igor >> had no need to use the same name line as me. Â I don't want to change now. >> Â oscog refers to my branch of VMMaker for "open source Cog". > > It's not really open source if nobody else can contribute to > that branch. Squeaksource apparently allows versions to be > overwritten. I didn't know that either. Maybe that's part of the > reason the naming convention has been adopted: > Package-author.version > > The best supported convention for maintaining a branch is to use > a different repository. MC is distributed, so packages can be > merged between repositories no problem. > > So http://squeaksource.com/VMMaker/VMMaker-IgorStasenko.53.mcz > would be a trunk commit, and > http://squeaksource.com/OSCog/VMMaker-IgorStasenko.54.mcz would > be a cog commit. > > Changing the package name is not really supported; Most MC > implementations can't merge between packages (MC1.5 could, but I > havn't ported that to any MC that's actually in use) > > I like seperate repositories better anyway; then you can know if > there is a newer version of your branch available just by seeing > if VMMaker package is bold in the repo browser; if they are in > the same repository, you have to pay attention to the commits > I agree that having different repos could simplify things. Except things which will otherwise complicate them: - publishing new VMMaker version sends nice email to mailing list - configuration(s) to automatically load VMMaker with all dependencies relying on having VMMaker package at certain known location, not at multiple ones. So, lets keep pushing to SqS/VMMaker but use different naming scheme. > -- > Matthew Fulmer (a.k.a. Tapple) > -- Best regards, Igor Stasenko AKA sig.

March 20, 2011

Re: [Pharo-project] [ANN] More on Keymappings

by Tudor Girba

Excellent! I can't wait to use it when it's ready :) Doru On 20 Mar 2011, at 17:33, Camillo Bruni wrote: > The keymapping framework is already close to be completely rewritten. Most tests work (except for 3). Half of the methods are gone and the event matching works directly on Event level, no more evil string matching. > > I'll ping as soon as the rest of the tests work properly. > > camillo > > On 2011-03-19, at 13:37, Mariano Martinez Peck wrote: >> Add keymappings to >> >> http://book.pharo-project.org/book/PharoTools/ > > I will add it as soon as the cleanup is complete and all tests work again :). -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

March 20, 2011

Re: [Pharo-project] Issue 3837 in pharo: Can not build Pharo Full 1.3

by pharo＠googlecode.com

Comment #1 on issue 3837 by stephane...(a)gmail.com: Can not build Pharo Full 1.3 http://code.google.com/p/pharo/issues/detail?id=3837 Ok we should remove this pop up...

March 20, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

>> >>> Stef, >>> >>> I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty. >> >> No this is not a problem, because we can save the package with the * notation and category even if we do not need that. > ........... >> >> Now what other system like gemstone could do is also to copy the pharo package implementation because these are two classes. > > Stef, > > Over the long haul I would agree that migration to the newer model is a good idea and gemstone could install the code (when tool support becomes available in GemStone) and as long as there is a transition period where RPackage isn't _required_, then I think that things can work smoothly... Yes I understand. Now we should be able to find a solution based on category (without subcat matching). > > Dale

March 20, 2011

Re: [Pharo-project] [ANN] ConfigurationOfRFB with symbolic versions

by StÃ©phane Ducasse

tx! On Mar 20, 2011, at 8:07 PM, Miguel CobÃ¡ wrote: > Hi all, > > I have updated the ConfigurationOfRFB with symbolic versions. > It can load RFB on PharoCore 1.1 and PharoCore 1.2. > > To load it, evaluate in a workspace: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfRFB'; > load. > > ((Smalltalk at: #ConfigurationOfRFB) > project version: #stable) load. > > This will load the correct version of RFB for the given PharoCore > version (thanks Dale!): > > RFB-lr.34.mcz for PharoCore 1.1 > RFB-MiguelCoba.36 for PharoCore 1.2 > > Enjoy! > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

March 20, 2011

Re: [Pharo-project] Issue 3830 in pharo: [Failing Test] Autotes TestHitCounter.testHitCountIncrements

by pharo＠googlecode.com

Comment #6 on issue 3830 by snoob...(a)yahoo.ie: [Failing Test] Autotes TestHitCounter.testHitCountIncrements http://code.google.com/p/pharo/issues/detail?id=3830 This is caused by the same issue in 3581. The method cache is returning the wrong CompiledMethod or delegate (AutoTestHitCounter). As an example the cache could be flushed by adding a method to AutoTestHitCounter>> flushCache method selector flushCache.

March 20, 2011

Re: [Pharo-project] Annoying No version found for #stable of ConfigurationOfOmniBrowser while loading Seaside

by Dennis Schetinin

This helps, thank you! 2011/3/20 Dale Henrichs <dhenrich(a)vmware.com> > ConfigurationOfMetacello project updateProject. > ConfigurationOfMetacello load. > -- Dennis Schetinin

March 20, 2011

Re: [Pharo-project] Issue 3830 in pharo: [Failing Test] Autotes TestHitCounter.testHitCountIncrements

by pharo＠googlecode.com

Comment #5 on issue 3830 by laurent....(a)gmail.com: [Failing Test] Autotes TestHitCounter.testHitCountIncrements http://code.google.com/p/pharo/issues/detail?id=3830 I'm puzzled. I take the Pharo-1.2-AfterRunningTests image, open TestRunner and run all Autotest tests, sometimes (??) AutotestTestHitCounter.testHitCountIncrements fails. So to debug I've added a log on Transcript to check that AutotestHitCounter wrapper works: AutotestHitCounter>>run: aSelector with: anArray in: aReceiver self hit. Transcript show: thisContext sender asString; space; show: self hitCount asString; cr. ^ aReceiver withArgs: anArray executeMethod: method but then tests never fail; always green !! Remove/comment Transcript instructions, then sometimes the test fail again. So this come out of my knowledge - what should I check ?

March 20, 2011

Re: [Pharo-project] We are preparing to this year Google Summer of Code (GSoC)

by Carla F. Griggio

That's true, sadly. On Sunday, March 20, 2011, Eric Lavigne <lavigne.eric(a)gmail.com> wrote: > It looks like ESUG wasn't accepted this year. > > http://www.google-melange.com/gsoc/program/accepted_orgs/google/gsoc2011 > > 2011/3/9 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: >> Dear Smalltalkers, >> >> I'd like to inform you that we are preparing an application to this year >> Smalltalk Google Summer of Code under ESUG umbrella, as last year. >> >> If accepted, Google will pay few stipendiums to students on our >> Smalltalk projects. Please start thinking about ideas what projects >> would be nice to have. Also start looking around for students. How to >> approach the universitites near by you, do you know who to contact >> there, etc. To see last year ideas and accepted/done projects, visit >> last year http://gsoc2010.esug.org. >> >> More on our already open special Smalltalk GSoC 2011 website: >> >> Â Â Â Â http://gsoc2011.esug.org >> >> I'm specially inviting mentors of all past GSoCs to rejoin the mentors >> mailing list, where we discuss all details about this year GSoC: >> >> Â Â Â Â http://groups.google.com/group/smalltalk-gsoc-mentors >> >> Best regards >> Janko >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >> > >

March 20, 2011