Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » why does the code generator include this in the editor?
why does the code generator include this in the editor? [message #523473] Fri, 26 March 2010 10:04 Go to next message
Paul E. Keyser is currently offline Paul E. KeyserFriend
Messages: 878
Registered: July 2009
Senior Member
Using the defaults (i.e., no changes of settings or editing of eCore),
and for two different simple models (defined in annotated Java), the
code generator includes in the FooEditor class, method createPages(),
this code:

<code>
getSite().getShell().getDisplay().asyncExec
(new Runnable() {
public void run() {
updateProblemIndication();
}
});
</code>

This is causing an annoying problem in our system (sometimes including
deadlock), and anyway seems strange - why would the create-pages method
want to clear off all problem markers?

What is the intent of generating that code there?

thanks,
Paul
Re: why does the code generator include this in the editor? [message #523474 is a reply to message #523473] Fri, 26 March 2010 10:04 Go to previous messageGo to next message
Sven Krause is currently offline Sven KrauseFriend
Messages: 119
Registered: July 2009
Senior Member
Hi Paul,

you will find such construct at many places within eclipse. It deferres
the operations execution into the display thread, those are updating any
ui stuff - and those are requested to do the manipulation exact there.
Otherwise you will get an access error from the ui.

Sven
Re: why does the code generator include this in the editor? [message #523478 is a reply to message #523473] Fri, 26 March 2010 15:04 Go to previous messageGo to next message
Sven Krause is currently offline Sven KrauseFriend
Messages: 119
Registered: July 2009
Senior Member
Hi Paul,

you will find such construct at many places within eclipse. It deferres
the operations execution into the display thread, those are updating any
ui stuff - and those are requested to do the manipulation exact there.
Otherwise you will get an illegal thread access error from the ui.

Sven
Re: why does the code generator include this in the editor? [message #523480 is a reply to message #523478] Fri, 26 March 2010 15:13 Go to previous messageGo to next message
Paul E. Keyser is currently offline Paul E. KeyserFriend
Messages: 878
Registered: July 2009
Senior Member
Right, I understand why "asyncExec()" is used; what I meant was, why is
the editor, in the createPages() method, updating the markers at all?

-Paul


Sven Krause wrote:
> Hi Paul,
>
> you will find such construct at many places within eclipse. It deferres
> the operations execution into the display thread, those are updating any
> ui stuff - and those are requested to do the manipulation exact there.
> Otherwise you will get an illegal thread access error from the ui.
>
> Sven
Re: why does the code generator include this in the editor? [message #523486 is a reply to message #523473] Fri, 26 March 2010 10:32 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26287
Registered: July 2009
Senior Member
Paul,

Loading resources might encounter problems that you'll want to know
about. I'm not sure why the construct below would cause deadlock.


Paul E. Keyser wrote:
> Using the defaults (i.e., no changes of settings or editing of eCore),
> and for two different simple models (defined in annotated Java), the
> code generator includes in the FooEditor class, method createPages(),
> this code:
>
> <code>
> getSite().getShell().getDisplay().asyncExec
> (new Runnable() {
> public void run() {
> updateProblemIndication();
> }
> });
> </code>
>
> This is causing an annoying problem in our system (sometimes including
> deadlock), and anyway seems strange - why would the create-pages
> method want to clear off all problem markers?
>
> What is the intent of generating that code there?
>
> thanks,
> Paul
Re: why does the code generator include this in the editor? [message #523504 is a reply to message #523486] Fri, 26 March 2010 15:30 Go to previous messageGo to next message
Paul E. Keyser is currently offline Paul E. KeyserFriend
Messages: 878
Registered: July 2009
Senior Member
The fault for the deadlock might of course lie in the large existing
code-base into which we are trying to plug a small addendum. (So far,
our small addendum does so very little, there is no opportunity for it
to deadlock.) The deadlock only occurs at start-up -- and of course not
always then (as is ever the way with deadlocks).

Anyway, on those occasions when the deadlock doesn't happen, the effect
of the code below is to *remove* all markers that were on the resource
at shut-down time, so even without the deadlocking problem, the code
does what we don't want.

-Paul

Ed Merks wrote:
> Paul,
>
> Loading resources might encounter problems that you'll want to know
> about. I'm not sure why the construct below would cause deadlock.
>
>
> Paul E. Keyser wrote:
>> Using the defaults (i.e., no changes of settings or editing of eCore),
>> and for two different simple models (defined in annotated Java), the
>> code generator includes in the FooEditor class, method createPages(),
>> this code:
>>
>> <code>
>> getSite().getShell().getDisplay().asyncExec
>> (new Runnable() {
>> public void run() {
>> updateProblemIndication();
>> }
>> });
>> </code>
>>
>> This is causing an annoying problem in our system (sometimes including
>> deadlock), and anyway seems strange - why would the create-pages
>> method want to clear off all problem markers?
>>
>> What is the intent of generating that code there?
>>
>> thanks,
>> Paul
Re: why does the code generator include this in the editor? [message #523506 is a reply to message #523504] Fri, 26 March 2010 15:41 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26287
Registered: July 2009
Senior Member
Paul,

Until you invoke validation, there's no way to be sure the markers
aren't completely stale, so while it might not do what you want, it does
do what's intended...


Paul E. Keyser wrote:
> The fault for the deadlock might of course lie in the large existing
> code-base into which we are trying to plug a small addendum. (So far,
> our small addendum does so very little, there is no opportunity for it
> to deadlock.) The deadlock only occurs at start-up -- and of course
> not always then (as is ever the way with deadlocks).
>
> Anyway, on those occasions when the deadlock doesn't happen, the
> effect of the code below is to *remove* all markers that were on the
> resource at shut-down time, so even without the deadlocking problem,
> the code does what we don't want.
>
> -Paul
>
> Ed Merks wrote:
>> Paul,
>>
>> Loading resources might encounter problems that you'll want to know
>> about. I'm not sure why the construct below would cause deadlock.
>>
>>
>> Paul E. Keyser wrote:
>>> Using the defaults (i.e., no changes of settings or editing of
>>> eCore), and for two different simple models (defined in annotated
>>> Java), the code generator includes in the FooEditor class, method
>>> createPages(), this code:
>>>
>>> <code>
>>> getSite().getShell().getDisplay().asyncExec
>>> (new Runnable() {
>>> public void run() {
>>> updateProblemIndication();
>>> }
>>> });
>>> </code>
>>>
>>> This is causing an annoying problem in our system (sometimes
>>> including deadlock), and anyway seems strange - why would the
>>> create-pages method want to clear off all problem markers?
>>>
>>> What is the intent of generating that code there?
>>>
>>> thanks,
>>> Paul
Re: why does the code generator include this in the editor? [message #523515 is a reply to message #523506] Fri, 26 March 2010 16:24 Go to previous messageGo to next message
Paul E. Keyser is currently offline Paul E. KeyserFriend
Messages: 878
Registered: July 2009
Senior Member
Ed --

Well, I think I am implicitly using as my mental model the way that
Eclipse JDT behaves.

a) If I have auto-build off, and have a problem marker on some bit of
Java, and start up Eclipse, the problem marker is not removed. Since
auto-build is off, if I correct the code, the marker remains, and will
do so when I shut down and start up. So the staleness is independent of
start-up and loading issues.

b) If I have auto-build on, and have a problem marker on some bit of
Java, and start up Eclipse, the problem marker is removed and then
recreated. Since auto-build is on, if I correct the code, the marker is
immediately removed. So here staleness is irrelevant.

So, on that model, I am surprised that the EMF editor acts to remove
markers. Can you describe the mental model that I could use to
understand the EMF bahavior?

The large existing code-base has its own validation system, which is
what I am (told I should be) using to create markers; it seems to be
turned on by default, a bit like auto-build for Eclipse JDT. Now I'm
wondering if perhaps I shouldn't connect our use of that system to the
EMF validation system (as ch. 18 of the EMF book, sec. ed.) ...

-Paul

Ed Merks wrote:
> Paul,
>
> Until you invoke validation, there's no way to be sure the markers
> aren't completely stale, so while it might not do what you want, it does
> do what's intended...
>
>
> Paul E. Keyser wrote:
>> The fault for the deadlock might of course lie in the large existing
>> code-base into which we are trying to plug a small addendum. (So far,
>> our small addendum does so very little, there is no opportunity for it
>> to deadlock.) The deadlock only occurs at start-up -- and of course
>> not always then (as is ever the way with deadlocks).
>>
>> Anyway, on those occasions when the deadlock doesn't happen, the
>> effect of the code below is to *remove* all markers that were on the
>> resource at shut-down time, so even without the deadlocking problem,
>> the code does what we don't want.
>>
>> -Paul
>>
Re: why does the code generator include this in the editor? [message #523570 is a reply to message #523515] Fri, 26 March 2010 16:54 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26287
Registered: July 2009
Senior Member
Paul,

Comments below.

Paul E. Keyser wrote:
> Ed --
>
> Well, I think I am implicitly using as my mental model the way that
> Eclipse JDT behaves.
No doubt, but JDT automatically builds things so it's rather difficult
for things to be out of sync.
>
> a) If I have auto-build off, and have a problem marker on some bit of
> Java, and start up Eclipse, the problem marker is not removed. Since
> auto-build is off, if I correct the code, the marker remains, and will
> do so when I shut down and start up. So the staleness is independent
> of start-up and loading issues.
I've never worked in this mode...
>
> b) If I have auto-build on, and have a problem marker on some bit of
> Java, and start up Eclipse, the problem marker is removed and then
> recreated. Since auto-build is on, if I correct the code, the marker
> is immediately removed. So here staleness is irrelevant.
Even before you save?
>
> So, on that model, I am surprised that the EMF editor acts to remove
> markers. Can you describe the mental model that I could use to
> understand the EMF bahavior?
The normal expected behavior (because that's all that's implemented by
default for a generated editor) is that the editor itself creates the
markers when you invoke Validate and click OK. Only the editor ever
removes them. Even if there are validation errors, they're not marked
until you invoke validate. When you open the editor, the state will be
cleaned until you invoke validate; only errors that are encountered by
loading, i.e., XML syntactic errors are reported initially upon opening.
>
> The large existing code-base has its own validation system, which is
> what I am (told I should be) using to create markers; it seems to be
> turned on by default, a bit like auto-build for Eclipse JDT. Now I'm
> wondering if perhaps I shouldn't connect our use of that system to the
> EMF validation system (as ch. 18 of the EMF book, sec. ed.) ...
I expect EMF to only delete markers for it's own marker IDs. Perhaps
you want to be invoking validation during initial loading so that stale
markers are removed but fresh ones are created...
>
> -Paul
>
> Ed Merks wrote:
>> Paul,
>>
>> Until you invoke validation, there's no way to be sure the markers
>> aren't completely stale, so while it might not do what you want, it
>> does do what's intended...
>>
>>
>> Paul E. Keyser wrote:
>>> The fault for the deadlock might of course lie in the large existing
>>> code-base into which we are trying to plug a small addendum. (So
>>> far, our small addendum does so very little, there is no opportunity
>>> for it to deadlock.) The deadlock only occurs at start-up -- and of
>>> course not always then (as is ever the way with deadlocks).
>>>
>>> Anyway, on those occasions when the deadlock doesn't happen, the
>>> effect of the code below is to *remove* all markers that were on the
>>> resource at shut-down time, so even without the deadlocking problem,
>>> the code does what we don't want.
>>>
>>> -Paul
>>>
Previous Topic:generically get item provider for an EObject
Next Topic:adapter list and concurrent modifications
Goto Forum:
  


Current Time: Mon Dec 22 00:48:54 GMT 2014

Powered by FUDForum. Page generated in 0.05167 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software