Smalltalk › Squeak › Squeak - Dev

Error while setting jpeg background from file (primitive failed)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

20 messages Options

Petr-9

Error while setting jpeg background from file (primitive failed)

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

Edgar J. De Cleene

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

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

Marcus Denker

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

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

Petr-9

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

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

Edgar J. De Cleene

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

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

Andreas.Raab

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

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

Peter Crowther-2

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

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

Andreas.Raab

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

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

timrowledge

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

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.

Andreas.Raab

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

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

Adrian Lienhard

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

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

stéphane ducasse-2

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

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

Tony Garnock-Jones-2

Bump the version number early and often

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! :-) )

Daniel Vainsencher-2

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

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

timrowledge

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

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.

Andreas.Raab

Re: Current traits implementation breaks VM compatibility

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

Andreas.Raab

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

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

Ron Teitelbaum

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

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

joshscholar

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

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

Bert Freudenberg-3

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

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