4.0 - some possible problems

Andy,

This glitch appears to have a happy ending, but, I got caught in a situation
where I was unable to save packages, and even unable to check for cyclic
prerequisites.  Ultimately, the problem was an ancient view resource that I
don't need, and was able to remove.  There was another view that I was able
to export from 3.06 and import into 4.0.  Finally, there was another view
that was having problems because of the changes in ActiveX hosting - no
points off for that one :)  This was more obvious than in the past because
of improvements in prerequisites detection.  At first, it looked like the
tree-based display was causing problems, but, I now think that it was simply
view conversions, some of which were bugs, some not.

Something caused Migrate some grief.  Most of the way through a package
load, it complained that the package in question was already loaded - it was
correct.  Perhaps something is seeing a dependency that was missed when the
migrate.txt file was written and is loading the package earlier than it
would have been otherwise.

Perhaps more serious, I've noticed a few strange things in the debugger.
The first sign of it was that a block temporary wasn't inspectable (unknown
symbol) when I felt it should have been; another temp was known but the
value was nil which clearly wasn't correct.  I've since seen a few cases in
which a variable is nil in one frame (walkback line anyway - hope I'm not
abusing terminology here) and has the correct value in the one above or
below it.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]
(352) 846-1287

Andy,

> Perhaps more serious, I've noticed a few strange things in the debugger.
> The first sign of it was that a block temporary wasn't inspectable
(unknown
> symbol) when I felt it should have been; another temp was known but the
> value was nil which clearly wasn't correct.  I've since seen a few cases
in
> which a variable is nil in one frame (walkback line anyway - hope I'm not
> abusing terminology here) and has the correct value in the one above or
> below it.

One caveat: I was debugging Migrate's progress-dialog loop at the time.  I
haven't yet noticed this kind of thing outside of progress loops.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

> > Perhaps more serious, I've noticed a few strange things in the debugger.
> > The first sign of it was that a block temporary wasn't inspectable
> (unknown
> > symbol) when I felt it should have been; another temp was known but the
> > value was nil which clearly wasn't correct.  I've since seen a few cases
> in
> > which a variable is nil in one frame (walkback line anyway - hope I'm
not
> > abusing terminology here) and has the correct value in the one above or
> > below it.
>
> One caveat: I was debugging Migrate's progress-dialog loop at the time.  I
> haven't yet noticed this kind of thing outside of progress loops.

I believe it is a long standing issue that the Debugger isn't able to cope
correctly with blocks homed in another process (the progress dialog forks a
process to run the monitored operation), as it assumes that everything is in
one process. This is on the list for fixing, but hasn't been a terribly high
priority because it is not often a problem in practice - in fact debugging
stuff at the base of progress dialog loops is the only case I ever come
across it, and what I usually do (as a workaround) is to arrange the code so
that I can debug the code without the progress dialog - a DeafObject
suffices for the target of the progress notifications.

I'd be interested to know if you think the problem is more severe or
different to 3.0.

Regards

Blair

Blair,

> > One caveat: I was debugging Migrate's progress-dialog loop at the time.
I
> > haven't yet noticed this kind of thing outside of progress loops.
> [snip]
> I'd be interested to know if you think the problem is more severe or
> different to 3.0.

Thanks for the DeafObject suggestion!  It's probably safe to say that it now
fails silently rather than giving walkbacks as before.  FWIW, I was able to
find frames that had the information I needed, so in some sense, it's
improved.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]