I guess this has to do with the cache I introduced a while ago. We will discuss about this at lunch. Cheers, Alexandre On 1 Dec 2009, at 11:40, Simon Denier wrote:
OK folks, thanks for your suggestions, I will see how to be more careful with such threads. The instance browser seems a very interesting idea and I will try to use it (although not necessarily for such problems, but for bugs popping up during very long computations, it can be great). As well is the idea of drawing in a bitmap canvas before displaying: I would like to see some kind of better sandboxing for such problems...
Another cup of big bad error this morning. After seeing the image freezes once again on a long process, out of frustration I tried to interrupt it multiple times. I didn't get any debugger and the VM just quit after a while, but at least it seems like the stack dump still works in this case. So the last stack dump looks like this:
Bitmap class(Behavior)>>basicNew: Receiver: Bitmap Arguments and temporary variables: sizeRequested: 206074 Receiver's instance variables: superclass: ArrayedCollection methodDict: a MethodDictionary(#asByteArray->a CompiledMethod(4056: Bitmap>>asB...etc... format: 33538 instanceVariables: nil organization: ('accessing' atAllPut: bitPatternForDepth: byteAt: byteAt:put: by...etc... subclasses: nil name: #Bitmap classPool: a Dictionary() sharedPools: nil environment: nil category: #'Graphics-Primitives' traitComposition: nil localSelectors: nil
Bitmap class(Behavior)>>basicNew: Bitmap class(Behavior)>>basicNew: Bitmap class(Behavior)>>basicNew: Bitmap class(Behavior)>>basicNew: etc.
while it's trying to open the debugger.
Now I would like to get a better understanding. Why does this primitive keep failing and retry? My best guess is that the VM runs out of ressources (memory) but can not report it.
On 1 déc. 2009, at 03:01, Hernán Morales Durand wrote:
Hi Simon, Have you tried http://www.squeaksource.com/LightweightClasses.html ? It's in an experimental stage, but I've used it succesfully for the recursive debugger problem. You may load it in Pharo-Core this way :
Gofer new squeaksource: 'LightweightClasses'; addPackage: 'ParametrizedCompiler'; addPackage: 'LightweightClasses'; addPackage: 'OBLightweightClass'; load; recompile.
Cordialement,
Hernán
2009/11/30 Simon Denier <simon.denier@inria.fr>:
Unfortunately, this is an issue which I cant easily reproduce, at least not without a third party tool (1525). Now I would like the general opinion/experience of debugging Morphic code especially in threads. Usually an exception raised from within Morphic code pops up a debugger as usual. However, from time to time, or for more complicated stuff, the situation runs out of hand and tons of debugger pop up everywhere because the same faulty gets obviously executed again and again. Now can somebody with some Morphic knowledge explain how this is supposed to work and how to deal with such issues? -- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.