Hello Squakers! I tried to set background image in the latest image (6718). However, I am getting an error calling a primitive.
primJPEGReadImage: aJPEGDecompressStruct fromByteArray: source onForm: form doDithering: ditherFlag errorMgr: aJPEGErrorMgr2Struct
<primitive: 'primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgr' module: 'JPEGReadWriter2Plugin'> self primitiveFailed
I tracked down, that this error was introduced in (6706). Before this version the problem doesn't appear. I tried this under windows only.
Petr
Petr puso en su mail :
Hello Squakers! I tried to set background image in the latest image (6718). However, I am getting an error calling a primitive.
primJPEGReadImage: aJPEGDecompressStruct fromByteArray: source onForm: form doDithering: ditherFlag errorMgr: aJPEGErrorMgr2Struct
<primitive: 'primJPEGReadImagefromByteArrayonFormdoDitheringerrorMgr' module: 'JPEGReadWriter2Plugin'> self primitiveFailed
I tracked down, that this error was introduced in (6706). Before this version the problem doesn't appear. I tried this under windows only.
Petr
Welcome to wonderful promised Traits !! You must use, if clever , 6705 until whose what insist on destroy Squeak change his mind
Edgar
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
Hello, this error has some connection with traits (6706 is first with traits), however, I don't see a reason why would traits cause breaking a primitive call, when others work without problems. How can I fix this?
Petr
Marcus Denker wrote:
On 29.01.2006, at 10:22, Lic. Edgar J. De Cleene wrote:
Petr
Welcome to wonderful promised Traits !! You must use, if clever , 6705 until whose what insist on destroy Squeak change his mind
What does Traits have do do with this?
Marcus
Marcus Denker puso en su mail :
What does Traits have do do with this?
Marcus
I only know what 6705 works and still no Traits on it or maybe I wrong.
Here we have a said, "El que rompe paga" or who cause what we don't have jpeg now should fix.
Some masters understimate the Butterfly effect, still having troubles by changing all from old String and Symbol to new.
But this was necessary for non western languages.
And Traits is for some super masters , they should do a fork as others do before and let the common guy happy in his/her ignorance.
Edgar
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
Marcus Denker wrote:
What does Traits have do do with this?
Quite a bit. The traits installation adds two variables to Behavior (traitComposition and localSelectors) and it looks like this isn't as harmless for the VM as most people (including myself) thought. It seems like there are a few places where the class name is assumed in a specific position, including Interpreter>>printNameOfClass:count: and Interpreter>>classNameOf:is:. The latter is what's causing the problem since it is used by Interpreter>>is:KindOf: which in turn is used by SmartSyntaxPluginCodeGenerator>>ccgLoad:expr:asKindOf:from: which is applied as the generic prologue for classes that have no more specific type checks (in this case we have a Form argument to which this applies).
Therefore, all primitives using this pattern will fail with post 6706 images. What's potentially worse is that we don't know where else any of those functions are being used (I wonder if they are used in the FFI for some of the type checks...)
Fixing this will not be easy - if a VM change is required it means that older images will fail on newer VMs and vice versa.
Cheers, - Andreas
On 29-Jan-06, at 10:58 AM, Andreas Raab wrote:
Fixing this will not be easy - if a VM change is required it means that older images will fail on newer VMs and vice versa.
Ah, well, not absolutely definite. It's tacky but one could make a vm that works out the offset to the class name and uses a var from then on. Assuming for example that the traitsComposition is in the place where name was expected we could check for a byte array (implying name, old image) against oop array (traits, new image). Very yucky but functional and doable- had to do something of this sort in VW once. Old vm would support old image, new vm would support either. Old vm with new image would work kinda - as shown by the fact that nobody had noticed this in all the traits development. And we never claim total compatability in both directions.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Gates are down, the lights are flashing, but the train isn't coming.
tim Rowledge wrote:
On 29-Jan-06, at 10:58 AM, Andreas Raab wrote:
Fixing this will not be easy - if a VM change is required it means that older images will fail on newer VMs and vice versa.
Ah, well, not absolutely definite. It's tacky but one could make a vm that works out the offset to the class name and uses a var from then on.
You mean searching the iVars of a well-known class (like Point) for the string "Point"? Yes, that would work. Very clever. And very tacky ;-)
Cheers, - Andreas
On 29-Jan-06, at 9:35 PM, Andreas Raab wrote:
tim Rowledge wrote:
On 29-Jan-06, at 10:58 AM, Andreas Raab wrote:
Fixing this will not be easy - if a VM change is required it means that older images will fail on newer VMs and vice versa.
Ah, well, not absolutely definite. It's tacky but one could make a vm that works out the offset to the class name and uses a var from then on.
You mean searching the iVars of a well-known class (like Point) for the string "Point"? Yes, that would work. Very clever. And very tacky ;-)
Sometimes tacky is all that saves you. Remember, we carefully collect tacky and spread it onto strips of fabric and call it duct tape. Doesn't come much more useful than that.
A cleaner interface for the future that would allow for changing the ivar layout of behaviour (and by extension do the same for object if really needed) would be a prim that tells the vm the right offset. There would be some interesting times if there were a problem before that prim had run of course. Done well it could allow the layout to change whilst running the image, which might be useful in a hyper- expanding system like Spoon.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Permanently out to lunch.
On Jan 29, 2006, at 19:58 , Andreas Raab wrote:
Quite a bit. The traits installation adds two variables to Behavior (traitComposition and localSelectors) and it looks like this isn't as harmless for the VM as most people (including myself) thought.
yes, we were not aware of the fact that not only the first three ivars are hardcoded but also the ninth of Class!
[..]
Fixing this will not be easy - if a VM change is required it means that older images will fail on newer VMs and vice versa.
An easy fix would be to pull the two new ivars down into Class and Metaclass (declaring the accessors abstract in Behavior and implement them in Class and Metaclass). Although this is not that nice, it seams to be simpler than changing the VM.
Adrian
Arghhhhh. Damned!
It is a pity that we get a system that is so fragile to change. Changing compiledMethod to real objects would help too.
Stef
Marcus Denker wrote:
What does Traits have do do with this?
Quite a bit. The traits installation adds two variables to Behavior (traitComposition and localSelectors) and it looks like this isn't as harmless for the VM as most people (including myself) thought. It seems like there are a few places where the class name is assumed in a specific position, including Interpreter>>printNameOfClass:count: and Interpreter>>classNameOf:is:. The latter is what's causing the problem since it is used by Interpreter>>is:KindOf: which in turn is used by SmartSyntaxPluginCodeGenerator>>ccgLoad:expr:asKindOf:from: which is applied as the generic prologue for classes that have no more specific type checks (in this case we have a Form argument to which this applies).
Therefore, all primitives using this pattern will fail with post 6706 images. What's potentially worse is that we don't know where else any of those functions are being used (I wonder if they are used in the FFI for some of the type checks...)
Fixing this will not be easy - if a VM change is required it means that older images will fail on newer VMs and vice versa.
Cheers,
- Andreas
stéphane ducasse wrote:
Arghhhhh. Damned!
It is a pity that we get a system that is so fragile to change. Changing compiledMethod to real objects would help too.
<amused rant> Researchers! I think only an engineer can truly grasp what an amazing feat it is that such a change is possible at all. Calling this "fragile" is ... well, it's so far out there, it's not even funny. </amused rant>
Cheers, - Andreas
My favorite quote from a fellow programmer:
"It's not unusual that it breaks sometimes, what's really amazing is that it works at all!"
Ron
I'm amused that you think that adding a field to a record/object should be hard. And you use smalltalk, amazing.
Joshua Scholar
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, January 30, 2006 10:45 AM Subject: Re: Error while setting jpeg background from file (primitive failed)
stéphane ducasse wrote:
Arghhhhh. Damned!
It is a pity that we get a system that is so fragile to change. Changing compiledMethod to real objects would help too.
<amused rant> Researchers! I think only an engineer can truly grasp what an amazing feat it is that such a change is possible at all. Calling this "fragile" is ... well, it's so far out there, it's not even funny. </amused rant>
Cheers,
- Andreas
And I thought Scholar was your last name ...
- Bert -
Am 31.01.2006 um 05:59 schrieb joshscholar@nightstudies.net joshscholar@nightstudies.net:
I'm amused that you think that adding a field to a record/object should be hard. And you use smalltalk, amazing.
Joshua Scholar
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, January 30, 2006 10:45 AM Subject: Re: Error while setting jpeg background from file (primitive failed)
stéphane ducasse wrote:
Arghhhhh. Damned!
It is a pity that we get a system that is so fragile to change. Changing compiledMethod to real objects would help too.
<amused rant> Researchers! I think only an engineer can truly grasp what an amazing feat it is that such a change is possible at all. Calling this "fragile" is ... well, it's so far out there, it's not even funny. </amused rant>
Cheers,
- Andreas
As one of the people involved in the implementation, I apologize for that, I didn't notice that effect.
Note that an in-the-image fix (or rather, hack) is to take those variables outside Behavior, and store them in an IdentityDictionary. This is simple to code, but it is not necessarily trivial to convert to this (requires recompiling all metaclasses, again).
Since in the stable state, the right thing to do is probably to have those variables in Behavior, it might be better to bite the bullet and change the VM. BTW, any chance this dependecy of the VM on the image can be removed, instead of just changed? that would make the VM change backwards compatible...
While I can see that, for example, printing a debug stack requires the VM to know about class names, it is not obvious to me that type checks should use names rather than identities. Then again, there is a lot about the VM that I don't understand...
Daniel
Andreas Raab wrote:
Marcus Denker wrote:
What does Traits have do do with this?
Quite a bit. The traits installation adds two variables to Behavior (traitComposition and localSelectors) and it looks like this isn't as harmless for the VM as most people (including myself) thought. It seems like there are a few places where the class name is assumed in a specific position, including Interpreter>>printNameOfClass:count: and Interpreter>>classNameOf:is:. The latter is what's causing the problem since it is used by Interpreter>>is:KindOf: which in turn is used by SmartSyntaxPluginCodeGenerator>>ccgLoad:expr:asKindOf:from: which is applied as the generic prologue for classes that have no more specific type checks (in this case we have a Form argument to which this applies).
Therefore, all primitives using this pattern will fail with post 6706 images. What's potentially worse is that we don't know where else any of those functions are being used (I wonder if they are used in the FFI for some of the type checks...)
Fixing this will not be easy - if a VM change is required it means that older images will fail on newer VMs and vice versa.
Cheers,
- Andreas
Daniel Vainsencher wrote:
As one of the people involved in the implementation, I apologize for that, I didn't notice that effect.
Nobody did. If there's a lesson to be learned here then it's that large scale changes always have some unforeseen consequences. Which is simply another reason for thorough testing before this kind of change get integrated.
Since in the stable state, the right thing to do is probably to have those variables in Behavior, it might be better to bite the bullet and change the VM. BTW, any chance this dependecy of the VM on the image can be removed, instead of just changed? that would make the VM change backwards compatible...
Short of Tim's hack I don't see how this could be achieved.
While I can see that, for example, printing a debug stack requires the VM to know about class names, it is not obvious to me that type checks should use names rather than identities. Then again, there is a lot about the VM that I don't understand...
You're right it *should* use identities but those aren't always available (the VM doesn't support lookup of classes either so you cannot find a class if all you've got is a name).
Cheers, - Andreas
squeak-dev@lists.squeakfoundation.org
-
Adrian Lienhard -
Andreas Raab -
Bert Freudenberg -
Daniel Vainsencher -
joshscholar＠nightstudies.net -
Lic. Edgar J. De Cleene -
Marcus Denker -
Petr -
Ron Teitelbaum -
stéphane ducasse -
tim Rowledge