I've got an endless loop in VW 7.6 trying to print the border of a widget to a scaled MockMedium. In particular, the problem happens when printing the bottom of line of the border. Here is the repeating part of the stack:
    ScreenGraphicsContext(GraphicsContext)>>displayClippedPolygon:
    ScreenGraphicsContext>>roundedDisplayPolygon:at:
    ScreenGraphicsContext>>primDisplayPolygon:at:
    ScreenGraphicsContext(GraphicsContext)>>displayPolygon:at:
    ScreenGraphicsContext(GraphicsContext)>>displayPolygon:
     ScreenGraphicsContext(GraphicsContext)>>displayClippedPolygon:
    ...

And the relevant data:
    pointCollection = #(3 <at> 25 3 <at> 24 797 <at> 24 797 <at> 25)
    clippingBounds = 0 <at> 0 corner: 800 <at> 25
Note that the pointCollection is aligned with the bottom of the clippingBounds.

At issue is an apparent mismatch between Rectangle and GraphicsContext as to whether the bottom points (3 <at> 25 or 797 <at> 25) are inside the clippingBounds. Rectangle thinks it is out:
    Rectangle>>containsPoint:
    optimized [] in GraphicsContext>>isPolygon:inside:
    Array(ArrayedCollection)>>allSatisfy:
    ScreenGraphicsContext(GraphicsContext)>>isPolygon:inside:
    ScreenGraphicsContext(GraphicsContext)>>displayClippedPolygon:

because it checks for aPoint < corner, bu t aPoint y is not less than corner y, so it answers false:

    Rectangle>>containsPoint: aPoint
        "Answer whether the argument aPoint is within the receiver."
        ^origin <= aPoint and: [aPoint < corner]

    Point>>< aPoint
        "Answer whether the receiver is 'above and to the left' of the
        argument, aPoint."
        | p |
        p := aPoint asPoint.
        ^x < p x and: [y < p y]

But GraphicsContext thinks it is in:
    ScreenGraphicsContext(GraphicsContext)>>clipPolygon:toBottom:
    ScreenGraphicsContext(GraphicsContext)>>displayClippedPolygon:

because it checks for point y <= aNumber, and they are indeed equal:

    GraphicsContext>>clipPolygon: pointCollection toBottom: aNumber
        ^self
            clipPolygon: pointCollection
            insideBlock: [:point | point y <= aNumber]
            intersectionBlock: [:point1 :point2 | aNumber - point1 y * (point2 x - point1 x) // (point2 y - point1 y) + point1 x <at> aNumber]

So the difference of #< in #containsPoint: and #<= in #clipPolygon:toBottom: means the pointCollection never gets clipped, and we happily spin the cpu. The relevant code appears unchanged in the 7.8 beta.

Any recommendations as to how to fix or work around this?

Thanks,

Dave Stevenson
dave.stevenson <at> pacbell.net

This seems like a wondeful way to find out what's going on:

 

http://www.cincomsmalltalk.com/main/2010/11/introducing-new-cincom-smalltalk-spy-tool/

It seems to be implied it will be part of VisualWorks 7.8, but I don't see a mention of "Spy" in the 7.8 release document.  Is this feature available?

 

 

            Regards,

 

            Rick

Not cool.

Sent from my iPhone

On 2011-05-02, at 22:58, "McNeil, Andrew" <AMcNeil <at> cincom.com> wrote:

Hi,

 

We’ve a web server running Windows 2K3-SP1 with IIS6 and VW-7.2.1 ISAPI (localhost <at> 2223.dll, 40,960 bytes, created on 7/28/04).  VW External Web Server is configured with Hostname: localhost, Port: 2223, Virtual Directories: cgi. 

 

The setup work fine until we applied the latest Windows security updates.  Unloading the Windows security updates didn’t resolve the problem.

 

In VW 7.2.1 client app, we get the following error message dialog when trying to upload a small file, ~24kb.  “Error handling HTTP request: Net.HttpObjectNotFound (404 Not Found)”

 

In Windows IIS log, we see the following error message.

“date time hostIP POST /cgi/upload – 80 cgi destIP HTTP/1.1 – hostIP 404  2  1772  24848”

 

We’ve check and re-check the Web Service Extension (localhost <at> 2223.dll) is added and allowed.  We’ve verified NETWORK SERVICES account has read/write access to the upload area and is the identity defined in IIS application pool.  Short of throwing the server out the window, we can’t seem to get the old setup working again.  If anyone can shed some more light into our uploading issue, much will be appreciated.

 

Thanks,

Linh