- Pharo-dev - lists.pharo.org

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

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

by pharo＠googlecode.com

Comment #4 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. 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] [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

by Matthew Fulmer

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 -- Matthew Fulmer (a.k.a. Tapple)

March 20, 2011

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

by Dale Henrichs

Dennis, Try updating to a later version of Metacello: ConfigurationOfMetacello project updateProject. ConfigurationOfMetacello load. Symbolic versions were introduced in version 1.0-beta.28... Dale On Mar 20, 2011, at 11:21 AM, Dennis Schetinin wrote: Loading Seaside in Pharo 1.1.1 with a script below, I get a couple of 'No version found for #stable of' for ConfigurationOfOmniBrowser and ConfigurationOfRefactoringBrowser exception. Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. (Smalltalk at: #ConfigurationOfSeaside30) load. I can simply ignore these exceptions and everything seems to work. But they are still annoying. And more than that, they continue to appear (many times!) when I load other packages dependent on Seaside. Can it be disabled or fixed some how? -- Dennis Schetinin

March 20, 2011

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

by Miguel CobÃ¡

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] Annoying No version found for #stable of ConfigurationOfOmniBrowser while loading Seaside

by Dale Henrichs

Let me look into this ... something must have changed since I originally tested ConfigurationOfSeaside30 ... Thanks for reporting the problem... Dale On Mar 20, 2011, at 11:21 AM, Dennis Schetinin wrote: Loading Seaside in Pharo 1.1.1 with a script below, I get a couple of 'No version found for #stable of' for ConfigurationOfOmniBrowser and ConfigurationOfRefactoringBrowser exception. Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. (Smalltalk at: #ConfigurationOfSeaside30) load. I can simply ignore these exceptions and everything seems to work. But they are still annoying. And more than that, they continue to appear (many times!) when I load other packages dependent on Seaside. Can it be disabled or fixed some how? -- Dennis Schetinin

March 20, 2011

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

by Eliot Miranda

On Sun, Mar 20, 2011 at 11:23 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > Am 2011-03-20 um 19:17 schrieb Eliot Miranda: > > > > > > > On Sun, Mar 20, 2011 at 11:15 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > > > Am 2011-03-20 um 19:09 schrieb Eliot Miranda: > > > > > ------- > > > Name: VMMaker-oscog.52 > > > Author: IgorStasenko > > > Time: 18 March 2011, 12:45:14 am > > > UUID: a2810aac-4423-6740-b70e-7e821b979cb4 > > > Ancestors: VMMaker-oscog-IgorStasenko.50, > > > VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 > > > > > > Merge with oscog-49-51 & Esteban-50 > > > ------- > > > > > > I feel like you continuously ignoring my requests to merge the code > > > base.. and work together on merged instance > > > of VMMaker. > > > If you don't like this code, just say it. But don't ignore. > > > > > > Its not intentional. It's simply a matter of finding time to do the > merge. Mariano posted a bug. I fixed just that bug and published. I'm not > dissing you. I have very limited time. > > > > > > > Hmm, wouldn't applying the âdefaultâ naming scheme prevent such > overwrites? > > > > That is, now there would be > > VMMaker-oscog-eem.52 > > for Elliots version and > > VMMaker-oscog-IgorStasenko.52 > > for Igors version. > > What would prevent us from that? > > > > I don't see a naming conflict. I've been using VMMaker-oscog.NN since > the beginning and Igor has been using VMMaker-oscog-IgorStasenko.NN. This > isn't about names, it's about content. Igor is miffed I didn't merge in > some changes he made when I published VMMaker-oscog.52, right Igor? > > > > No, youâobviously accidentallyâoverwrote his version of the 18th of March: > So how did Monticello allow me to do that? That's a /bad/ bug. > > >>> > Name: VMMaker-oscog.52 > Author: IgorStasenko > Time: 18 March 2011, 12:45:14 am > UUID: a2810aac-4423-6740-b70e-7e821b979cb4 > Ancestors: VMMaker-oscog-IgorStasenko.50, > VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 > > Merge with oscog-49-51 & Esteban-50 > <<<< > > which has the same file name as yours: > > >>> > Name: VMMaker-oscog.52 > Author: eem > Time: 20 March 2011, 9:31:20 am > UUID: 1241a856-8570-4725-a069-a6d3d8a8a222 > Ancestors: VMMaker-oscog.51 > > Fix primitiveFlushCacheByMethod for objects-as-methods. > <<<< > > Since oscog is, as far as I can see, a kind-of branch of the > âdefaultâ VM-Maker, I think adding the developer initial/name to > the Package name would be in the spirit of monticello idioms. > 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". cheers Eliot > > So Long, > -Tobias > > > >

March 20, 2011