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 <[email protected]>:
>>>
>>> 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
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
