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

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

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

by Dennis Schetinin

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] Issue 3830 in pharo: [Failing Test] Autotes TestHitCounter.testHitCountIncrements

by pharo＠googlecode.com

Comment #3 on issue 3830 by laurent....(a)gmail.com: [Failing Test] Autotes TestHitCounter.testHitCountIncrements http://code.google.com/p/pharo/issues/detail?id=3830 Autotest have not changed for a while ... I will have a look.

March 20, 2011

Re: [Pharo-project] Issue 3726 in pharo: Turn the orange corner into a real Morph object

by pharo＠googlecode.com

Comment #2 on issue 3726 by marcus.d...(a)gmail.com: Turn the orange corner into a real Morph object http://code.google.com/p/pharo/issues/detail?id=3726 It would be nice if the code would be provided in a form that we can merge it *without* manual work. The package in PharoTaskForces means for me that I need to - load it - move the class to where it makes sense in the system It would be much easier to provide code in a way that it can be loaded without this kind of manual work.

March 20, 2011

Re: [Pharo-project] Issue 1836 in pharo: Adding dedicated accessors for VM parameters

by pharo＠googlecode.com

Updates: Status: Started Comment #14 on issue 1836 by marcus.d...(a)gmail.com: Adding dedicated accessors for VM parameters http://code.google.com/p/pharo/issues/detail?id=1836 This bug report does not have any code attached. ('In the inbox' is not enough! Which package??). Therefore, I move it from status FixProposed to Started.

March 20, 2011