Some more debugger fixes: 1. Support for stepping into blocks (thanks to Henrik Gedenryd) 2. A NonBooleanReceiver exception 3. Balloon help for the debugger buttons 4. A problem with handling exceptions in the debugger was fixed (when you stepped into the exception handling code, and then did a step which executed the #signal method, it would open a separate notifier)
Cheers, Hans-Martin
Is there any need to file in the earlier debugger enhancement change sets before the most recent one?
Ross Boylan wrote:
Is there any need to file in the earlier debugger enhancement change sets before the most recent one?
Yes, the newer files are add-ons. I had to order the methods in the original changeset manually to make it file in without problems, so I don't want to do this every time I add something new to the debugger enhancements.
Cheers, Hans-Martin
This might be a bug, an artifact of my filing in cs 3 before 1 and 2, or some other peculiarity of my image. But here's the report.
I go into a project and hit "newer" on the orange tab. It finds a newer one (Star Ants) and I click to update it. This dumps me into the emergency debugger. Here's SqueakDebug.log--hmm, this does not look like what I saw in the emergency debugger. That showed some errors concerning the debugger and undefined objects.
So perhaps the modified debug stuff and the remote project code have some incompatibility.
3 August 2001 1:48:16 am Error: key not found
VM: unix - Squeak3.0 of 4 February 2001 [latest update: #3446] Image: Squeak3.1alpha [latest update: #4173]
SystemDictionary(Object)>>error: SystemDictionary(Dictionary)>>errorKeyNotFound [] in SystemDictionary(Dictionary)>>associationAt: SystemDictionary(Dictionary)>>associationAt:ifAbsent: SystemDictionary(Dictionary)>>associationAt: [] in DiskProxy>>comeFullyUpOnReload: Symbol class>>has! Interned:ifTrue: DiskProxy>>comeFullyUpOnReload: SmartRefStream(DataStream)>>next SmartRefStream(ReferenceStream)>>next SmartRefStream>>next SmartRefStream(DataStream)>>readArray SmartRefStream(DataStream)>>next SmartRefStream(ReferenceStream)>>next SmartRefStream>>next ImageSegment(Object)>>readDataFrom:size: SmartRefStream>>readInstanceSize:clsname:refPosn: SmartRefStream>>readShortInst SmartRefStream(DataStream)>>next SmartRefStream(ReferenceStream)>>next SmartRefStream>>next SmartRefStream>>scanFrom: ObjectScanner>>scanFrom: [] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: BlockContext>>on:do: [] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: ProgressInitiationException>>sendNotificationsTo: [] in ComplexProgressIndicator>>withProgressDo: ProgressInitiationException(Exception)>>handlerAction ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:fr! om:to:during: String>>displayProgressAt:from:to:during: RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: RWBinaryOrTextStream(PositionableStream)>>fileIn RWBinaryOrTextStream(ReadWriteStream)>>fileInObjectAndCode ProjectLoading class>>openName:stream:fromDirectory:withProjectView: ProjectLoading class>>installRemoteNamed:from:named:in: [] in Project>>loadFromServer: BlockContext>>on:do: [] in ComplexProgressIndicator>>withProgressDo: BlockContext>>on:do: ComplexProgressIndicator>>withProgressDo: Project>>loadFromServer: Project>>loadFromServer Project>>doArmsLengthCommand: [] in Project>>armsLengthCommand:withDescription: [] in DoCommandOnceMorph>>step BlockContext>>on:do: DoCommandOnceMorph>>step DoCommandOnceMorph(Morph)>>stepAt: StepMessage(MorphicAlarm)>>value: WorldState>>runLocalStepMethodsIn: WorldState>>runStepMethodsIn: PasteUpMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNe! wProcess [] in BlockContext>>newProcess
Ross Boylan wrote:
This might be a bug, an artifact of my filing in cs 3 before 1 and 2, or some other peculiarity of my image. But here's the report.
(Picture Hans-Martin putting foot into mouth...)
Sorry, stupid me, I filed stuff out without testing whether it would successfully file in. Don't know exactly what happened this time. Attached you'll find a quick fix for the Debugger opening method. Somehow the checks for nil context have found their way out of this code. I've reinserted them now, and everything works fine.
So, after filing in those 3 debugger changesets, file in the attached method definition which fixes the bug you reported. Note that filing in 3 before 2 does not hurt, but 1 should be filed in first because otherwise it will overwrite part of the stuff in 2 & 3.
Cheers, and thanks Ross for reporting this blatant bug! Hans-Martin
On Fri, Aug 03, 2001 at 01:13:11PM +0200, Hans-Martin Mosner wrote:
Ross Boylan wrote:
This might be a bug, an artifact of my filing in cs 3 before 1 and 2, or some other peculiarity of my image. But here's the report.
(Picture Hans-Martin putting foot into mouth...)
Sorry, stupid me, I filed stuff out without testing whether it would successfully file in. Don't know exactly what happened this time. Attached you'll find a quick fix for the Debugger opening method. Somehow the checks for nil context have found their way out of this code. I've reinserted them now, and everything works fine.
So, after filing in those 3 debugger changesets, file in the attached method definition which fixes the bug you reported. Note that filing in 3 before 2 does not hurt, but 1 should be filed in first because otherwise it will overwrite part of the stuff in 2 & 3.
Cheers, and thanks Ross for reporting this blatant bug! Hans-Martin
I filed in the latest changes, and I think it cured the problem. I no longer get thrown into the emergency evaluator and the error I do get is not obviously debugger related.
The bad news is that I still can't update to a newer version of StarAnts; it looks as if I'm getting about the same error I originally reported in SqueakDebug.log. In particular, it is complaining that #StarLogoTrees is not in the SystemDictionary. An obvious possibility is that things may be in a bad state because of the previous failures, and that all is well code-wise.
Hi Ross, I suspect that now that the debugger problem is fixed, you just see a problem with the StarLogoAnts project. Here I'm not the right one to help; I suspect that the project itself is broken somehow. John Maloney is probably able to identify the reason.
Cheers, Hans-Martin
Ross Boylan wrote:
I filed in the latest changes, and I think it cured the problem. I no longer get thrown into the emergency evaluator and the error I do get is not obviously debugger related.
The bad news is that I still can't update to a newer version of StarAnts; it looks as if I'm getting about the same error I originally reported in SqueakDebug.log. In particular, it is complaining that #StarLogoTrees is not in the SystemDictionary. An obvious possibility is that things may be in a bad state because of the previous failures, and that all is well code-wise.
A question of confirmation: Does this mean I have to file in _all_ change sets you sent to the list or just the first and the last?
Hannes Hirzel
On Fri, 3 Aug 2001, Hans-Martin Mosner wrote:
Ross Boylan wrote:
Is there any need to file in the earlier debugger enhancement change sets before the most recent one?
Yes, the newer files are add-ons. I had to order the methods in the original changeset manually to make it file in without problems, so I don't want to do this every time I add something new to the debugger enhancements.
Cheers, Hans-Martin
Hannes Hirzel wrote:
A question of confirmation: Does this mean I have to file in _all_ change sets you sent to the list or just the first and the last?
All changesets. I've simply created additional changesets after sending out each one, so that each new method goes into the new changeset.
Cheers, Hans-Martin
squeak-dev@lists.squeakfoundation.org