Home » Modeling » EMF » why does the code generator include this in the editor?
| | | | |
| 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   |
 Paul E. Keyser
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 |
Ed Merks
Messages: 33137
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| 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 |
Paul E. Keyser
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 |
Ed Merks
Messages: 33137
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
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 20:08:35 GMT 2024
Powered by FUDForum. Page generated in 0.03478 seconds |
] 
Search
Help
Register
Login
Home
