- Pharo-dev - lists.pharo.org

WhatsUp from: 2015-05-18 until: 2015-05-31

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2015-05-31 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

May 18, 2015

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

and the gods, right on time, have smitten me down. The Slang changes have broken the VM, so I've taken the VMs down. On Sun, May 17, 2015 at 8:23 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > ...at http://www.mirandabanda.org/files/Cog/VM/VM.r3349. > > I hope that the Squeak VMs here-in are final Spur 5.0 and Squeak 4.6 VMs. > The last known serious bug in Spur has been found and fixed with these > VMs. Of course uch hubris is asking for it. I await the wrath of the gods. > > CogVM binaries as per VMMaker.oscog-eem.1313/r3349 > > General: > Make the bounds check in primitiveObject:perform:... > more restrictive and fix bugs in the commentary. > > Make stack pages a reasonable size. My math was > wrong and the size was half as big as intended. > > Extend the fastPrimTrace scheme to trace stack overflow, prim failure and > prim > retry to help debug the phantom stack frame bug in Cog Spur. > > Fix old bug in ceMNUFromPICMNUMethod:receiver: that has been masked by > cacheing of MNU method in MNU PIC entries. ceMNUFromPICMNUMethod:receiver: > must set up lkupClass before calling handleMNU:... > > Spur: > Fix ceActivateFailingPrimitiveMethod: to return properly after retrying > a primitive after checkForAndFollowForwardedPrimitiveState. e.g. fixes > | s | 1 to: 5 do: [:i| s := 'bar'. s becomeForward: 'bzzt' copy. 'foo' > <= s] > > Fix bug in followForwardedFrameContents:stackPointer: so that arguments are > actually followed. N.B. drives the above bug underground ;-). > so that named constants (defines) are not elided. > > Make accessor depth calculation more accurate by not considering > fetchInteger:ofObject: and arraySize: et al as object accessors. > > Make the read-before-written initializer safer, only initialzing simple > types. > > Newspeak: > Remove landmine left from restructing implicit receiver and outer sends as > clean sends. > > Plugins: > Regenerated because of changes in accessorDepth calculation, > constant elimination, and read-before-use initialization. > -- > best, > Eliot > -- best, Eliot

May 18, 2015

New Cog VMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r3349. I hope that the Squeak VMs here-in are final Spur 5.0 and Squeak 4.6 VMs. The last known serious bug in Spur has been found and fixed with these VMs. Of course uch hubris is asking for it. I await the wrath of the gods. CogVM binaries as per VMMaker.oscog-eem.1313/r3349 General: Make the bounds check in primitiveObject:perform:... more restrictive and fix bugs in the commentary. Make stack pages a reasonable size. My math was wrong and the size was half as big as intended. Extend the fastPrimTrace scheme to trace stack overflow, prim failure and prim retry to help debug the phantom stack frame bug in Cog Spur. Fix old bug in ceMNUFromPICMNUMethod:receiver: that has been masked by cacheing of MNU method in MNU PIC entries. ceMNUFromPICMNUMethod:receiver: must set up lkupClass before calling handleMNU:... Spur: Fix ceActivateFailingPrimitiveMethod: to return properly after retrying a primitive after checkForAndFollowForwardedPrimitiveState. e.g. fixes | s | 1 to: 5 do: [:i| s := 'bar'. s becomeForward: 'bzzt' copy. 'foo' <= s] Fix bug in followForwardedFrameContents:stackPointer: so that arguments are actually followed. N.B. drives the above bug underground ;-). so that named constants (defines) are not elided. Make accessor depth calculation more accurate by not considering fetchInteger:ofObject: and arraySize: et al as object accessors. Make the read-before-written initializer safer, only initialzing simple types. Newspeak: Remove landmine left from restructing implicit receiver and outer sends as clean sends. Plugins: Regenerated because of changes in accessorDepth calculation, constant elimination, and read-before-use initialization. -- best, Eliot

May 18, 2015

Re: [Pharo-dev] FogBuz - Parent Cases

by Sergio Fedi

Great explanation, thanks Ben. âIs this behaviour documented somewhere? I found these articles: http://www.fogcreek.com/fogbugz/docs/70/topics/basics/LinkingCases.html http://www.fogcreek.com/fogbugz/docs/70/topics/basics/Subcases.html But some behaviours you listed weren't documented there.

May 18, 2015

Re: [Pharo-dev] FogBuz - Parent Cases

by Ben Coman

Two main behaviours of interest: * The CI monkey will not test a slice on a case that has an open sub-case. * Parent cases can only be closed when all sub-cases are closed. So parent cases are useful: * When its required that a fix needs to be staged into several steps. The last step is the parent case. As each sub-case is closed, the CI will immediately test the parent slice. * While trying to fix issue A, you find another issue B that its better to deal with spearately, that A depends on. Make B a sub-case of A. * When its useful to break up a task into several smaller steps. For example: Convert *all* "xxx" method calls to "yyy" method calls might be too much to manage all at once. or "Make all CI tests green". In this case you might create an "over-arching" case. cheers -ben On Mon, May 18, 2015 at 9:50 AM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > What are Parent Cases? > > What problem do they address? When should they be used? >

May 18, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Sergio Fedi

> > Case created: > > > https://pharo.fogbugz.com/f/cases/15557/New-PackageManifests-should-be-clas… > Case Resolved (Review needed)

May 18, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Sergio Fedi

I want to add a test to ensure #packageManifest answers a Class. Since RPackage is in RPackageCore, but the #packageManifest method is in Manifest-Core I'm not sure whether: 1. I have to make the test in RPackageTest but make the test method from the Manifest-Core package 2. I have to make the test in RPackageTest but make the test method from the Manifest-Tests package 3. Create a new class in Manifest-Tests to hold this new test (and someupcoming tests as well) â

May 18, 2015

FogBuz - Parent Cases

by Sergio Fedi

What are Parent Cases? What problem do they address? When should they be used?

May 18, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Sergio Fedi

Case created: https://pharo.fogbugz.com/f/cases/15557/New-PackageManifests-should-be-clas…

May 18, 2015

Please integrate 15523 and 15468

by Sean P. DeNigris

If there is no objection, please integrate: Issue 15523: Code Cruft Rule Only Matches One-Liners https://pharo.fogbugz.com/default.asp?15523 Issue 15468: Enhance the Welcome window https://pharo.fogbugz.com/default.asp?15468 Especially the second one, which was aimed at supporting our new users for the 4.0 release. Thanks! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Please-integrate-15523-and-15468-tp4826949.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 18, 2015