On 30 April 2018 at 13:23, David T. Lewis <lewis at mail.msen.com> wrote:

> On Fri, Apr 27, 2018 at 10:36:17PM -0500, Tim Johnson wrote:
> > Hi,
> >
> > I ran some tests and found a couple that are failing.  I also checked
> > and found these tests don't fail in my 5.1 image.
> >
> > BrowserTest>>#testBuildMessageCategoryBrowserEditString
> > DebuggerExtensionsTest>>#testCollectionsGeneralise
> >
> > I think the first one might actually be a case where a bug was fixed.
> > The test fails because of a timeout, because there is a dialog on-screen
> > which is not returning.  Not sure, but the test may be intended to
> > declare that the dialog should appear, and now it is (?).
> >
> > The second one, I don't understand.  There is no comment.
>
> I don't understand it either, and strangely it has no method timestamp.
> But the test was was introduced in April 2013 in this update:
>
>   Name: ToolsTests-fbs.62
>   Author: fbs
>   Time: 19 April 2013, 8:43:40.116 am
>   UUID: 926d563e-d57b-44ec-b4e7-672010293c2b
>   Ancestors: ToolsTests-nice.61
>
>   Tests for the new #canonicalArgumentName Debugger methods.
>
> This is part of test coverage for #canonicalArgumentName, which is
> implemented
> in Object and also has no method timestamp or comment (!!!).
>
> The canonicalArgumentName method is sent by many unit tests, so it has very
> good coverage (even though I don't know the significance of this failing
> test).
>
> Aside from unit tests, it is sent by Message>>createStubMethod and appears
> to be used when the debugger provides a template for implementing a missing
> method, or for implementing a method override.
>
> The test does this:
>
>   testCollectionsGeneralise
>       self assert: Collection name equals: Array new canonicalArgumentName.
>       self assert: Collection name equals: OrderedCollection new
> canonicalArgumentName.
>       self assert: Collection name equals: LinkedList new
> canonicalArgumentName
>
>
> This looks like a regression that should be fixed such that the tests pass
> again, and that also deserves a good method comment in
> Object>>cononicalArgumentName.
>
> I think that some more background and explanation can probably be found on
> squeak-dev circa April 2013, notably this reference:
>
>   http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-
> April/170506.html
>
> Which points to this:
>
>   Name: Tools-fbs.460
>   Author: fbs
>   Time: 19 April 2013, 8:40:24.143 am
>   UUID: d5cf82c4-bda7-48ff-bfbd-e8b27d0a07d7
>   Ancestors: Tools-fbs.459
>
>   When creating a stub method, give the argument names that represent the
>   (usual) desired name more accurately. For instance, Arrays,
> OrderedCollections
>   and Sets all result in 'aCollection', ByteStrings and WideStrings in
> 'aString',
>   and so on.
>
> So perhaps that last paragraph about "when creating a stub method..."
> might serve
> as a method comment for Object>>cononicalArgumentName?
>
> Dave
>

It was part of my work to improve the "JIT development" workflow, aka
"debugger driven development". See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-April/170693.html
and http://bugs.squeak.org/view.php?id=7761

frank


>
> >
> > Image/VM info:
> >
> > Squeak6.0alpha
> > latest update: #17922
> > Image format 6521 (32 bit)
> >
> > Virtual Machine
> > ---------------
> > C:\Users\tcj\Desktop\squeak.cog.spur_win32x86_201803080952\Squeak.exe
> > Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives
> > VMMaker.oscog-eem.2347]
> > Win32 built on Mar  8 2018 11:08:39 GMT Compiler: 6.4.0
> > platform sources revision VM: 201803080952
> >
> > Cheers,
> > Tim
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180430/3dbfa475/attachment.html>