Tue Mar 10 04:27:45 2009: Request 33485 was acted upon.
Transaction: Correspondence added by jploski
Queue: Win32-OLE
Subject: Problem with EPIC debugger and Win32::OLE
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: oliver.k...@linde-le.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=33485 >
On Mon Mar 09 15:17:46 2009, JDB wrote:
> As I wrote in my email reply, this problem is a "known limitation" and
> working as designed. The debugger will need to work around this as the
> module itself doesn't know when it is being invoked by a debugger, and
> when it isn't.
I wasn't aware of this RT thread when posting my first assessment in the
EPIC bug repository. Thanks to Oliver for pointing it out.
You are correct that the problem now needs to be solved in the debugger,
mostly because you have a published API and other clients who may
already rely on this problematic behavior. From a design point of view,
I think that your implementation is flawed, same goes for any other tied
hash implementation with side effects. What looks like a memory access
should be a memory access. Calls to (remote) procedures that may fail
should look like calls to procedures. The semantics are quite different,
as you correctly noted.
I'll see what and whether anything can be done in EPIC to work around
this Win32::OLE limitation. I suggest that the RT tickets here and for
Padwalker should be closed and the issue further tracked on the EPIC side.
