[Vm-dev] Re: pharo 4.0 Crashed in the VM thread again
manaa.sabine at gmail.com
Sun Aug 9 17:09:26 UTC 2015
It is in a new pharo 4 image and yes, I know about method size. This was my
own lazyness within a method gathering data for a report...as I was saying,
punishment was hard.
2015-08-09 18:56 GMT+02:00 Nicolai Hess [via Smalltalk] <
ml-node+s1294792n4841830h25 at n4.nabble.com>:
> Pharo or Squeak ?
> In squeak, this stackframe / large stackframe bug was introduced some
> months ago by a change for the compiler but it is already fixed.
> In pharo, we have a simliar bug (in pharos compiler (opal), not related to
> the change on the squeak compiler).
> This is a bug that is known but not yet fixed
> 13854 <https://pharo.fogbugz.com/default.asp?13854>
> frameSize calculated wrongly for #lineSegmentsDo: !
> 2015-08-09 18:39 GMT+02:00 tim Rowledge <[hidden email]
>> As a general rule of thumb, if a method is too long to see at a glance -
>> in practice this means too long to fit on your screen - then it almost
>> certainly needs splitting up. I have been forcibly reminded of this a lot
>> recently due to having to decode insanely long Python routines; seriously -
>> 1100 lines for a single function?
>> tim Rowledge; [hidden email]
>> Strange OpCodes: FSRA: Forms Skip and Run-Away
> If you reply to this email, your message will be added to the discussion
> To unsubscribe from pharo 4.0 Crashed in the VM thread again, click here
View this message in context: http://forum.world.st/pharo-4-0-Crashed-in-the-VM-thread-again-tp4836826p4841832.html
Sent from the Squeak VM mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev