Error while setting jpeg background from file (primitive failed)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Error while setting jpeg background from file (primitive failed)

Petr-9
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


Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Edgar J. De Cleene
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 


Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Marcus Denker

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

Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Petr-9
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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Edgar J. De Cleene
In reply to this post by Marcus Denker
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 


Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Andreas.Raab
In reply to this post by Marcus Denker
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


Reply | Threaded
Open this post in threaded view
|

RE: Error while setting jpeg background from file (primitive failed)

Peter Crowther-2
In reply to this post by Petr-9
> From: [...] Andreas Raab
> 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.

Hmmm.  Does that potentially push Traits to the mythical "4.0"
timeframe?

                - Peter

Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Andreas.Raab
Peter Crowther wrote:
>>From: [...] Andreas Raab
>>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.
>
>
> Hmmm.  Does that potentially push Traits to the mythical "4.0"
> timeframe?

Or maybe it pulls the mythical 4.0 forward. I always thought that such
fundamental changes justify more than a minor version increase.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

timrowledge
In reply to this post by Andreas.Raab

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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Gates are down, the lights are flashing, but  
the train isn't coming.



Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Andreas.Raab
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


Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Adrian Lienhard
In reply to this post by Andreas.Raab

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


Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

stéphane ducasse-2
In reply to this post by Andreas.Raab
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
>
>


Reply | Threaded
Open this post in threaded view
|

Bump the version number early and often

Tony Garnock-Jones-2
In reply to this post by Andreas.Raab
Andreas Raab wrote:
> Or maybe it pulls the mythical 4.0 forward. I always thought that such
> fundamental changes justify more than a minor version increase.

+1.

(Here's to Squeak, version 10.0, 2007! :-) )


Reply | Threaded
Open this post in threaded view
|

Current traits implementation breaks VM compatibility (was: Error while setting jpeg background from file (primitive failed))

Daniel Vainsencher-2
In reply to this post by Andreas.Raab
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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

timrowledge
In reply to this post by Andreas.Raab

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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Permanently out to lunch.



Reply | Threaded
Open this post in threaded view
|

Re: Current traits implementation breaks VM compatibility

Andreas.Raab
In reply to this post by Daniel Vainsencher-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Andreas.Raab
In reply to this post by stéphane ducasse-2
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

Reply | Threaded
Open this post in threaded view
|

RE: Error while setting jpeg background from file (primitive failed)

Ron Teitelbaum
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



Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

joshscholar
In reply to this post by Andreas.Raab
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" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Error while setting jpeg background from file (primitive failed)

Bert Freudenberg-3
And I thought Scholar was your last name ...

- Bert -

Am 31.01.2006 um 05:59 schrieb <[hidden email]>  
<[hidden email]>:

> 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" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> 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
>>
>>
>