Hi
> I therefore hope to have the code in good shape by the end of
the weekend, so a commit for M5 could be considered.
Hopelessly optimistic. I'm finding quite a few troublesome areas. The T
and T2 'types' are very simplistic. Performance could be a significant
issue. A new library was built for each new environment since for
instance an additional OclAny operation might be provided for use
within that environment, but not in other environments. This cost is
perhaps unavaoidable for a first query but very undesirable for a
second and third query. Many of our customers are probably doing many
simple individual queries, so performance could suffer badly. I've
therefore created a new lightweight MergedLibrary layer that is built
lazily saving simple queries the overhead of configuring unwanted
tuples etc, and allowing the main OCLLibrary layer to be read-only.
> Getting 100% green on the tests will be very difficult
I'm finding a significant number of tests for very suspect
functionality often associated with ParsingOptions such as LAX_NULL and
USE_COMPARE_TO etc. Making Comparable.compareTo work requires an
additional OCLJavaType capability to support a java.lang.Class rather
than EClass meta-class. I'm also having trouble wuth the UML2 binding
since UML2 does not realise MOF's Element::getMetaClass() operation.
UML2 seems to use Ecore as its meta-model. Still working on this.
As you can see, many issues to work on. It would be irresponsible to
rush this out. Best to leave OCL 3.0.0 as relatively familiar without
late hiccoughs. (A shame we can't call it 1.4.0 :-) )
Ed
On 20/01/2010 16:52, Ed Willink wrote:
Hi Alex
I've found that I can make a one-line change in each of
{Ecore,UML}Environment.define{Attribute,Operation} to install the
defined constraints in the ReflectiveLibrary; no need to touch the
analyzer. 'phase 2' (analysis) and 'phase 1' (evaluator) are therefore
separate. I therefore hope to have the code in good shape by the end of
the weekend, so a commit for M5 could be considered. Note that much of
the new code such as NumericMaxOperation is extremely boring and
isolated, and that nearly all the CollectionXXXOperation classes just
invoke the old CollectionUtil methods with easily reviewed fixes. So
while the new line count is large, the review/risk is not as high as it
might seem.
Getting 100% green on the tests will be very difficult because there
are a number of tests with very questionable results, and other with
errors such as String::toUpper rather than String::toUpperCase and
others with embarrassing extensions such as a secret Integer::asLong().
Regards
Ed Willink
On 20/01/2010 15:16, Alexander Igdalov wrote:
Hi Team,
I think it's the right
decision, though having the new engine in Helios would be very tempting.
If we're clever, we might manage to
provide a separate ReflectiveLibrary add-on for Helios. At present the
ReflectiveLibrary has only very small API extensions, these could be
added with null implementations, perhaps allowing the library to be
used after all. Since the add-on would just be an entry on the update
site, it could be changed all the way to RC4 (and beyond).
I think we shouldn't try to
join the old codebase and the one from the branch. I would rather have
it as a different MDT OCL version (experimental edition) available at a
separate update site in the same manner we wanted to do with 1.4.0. The
only difference would be that there would be no intention to make the
official and the experimental versions co-exist together.
We therefore need to partition the
outstanding bugs and only tackle those that are independent of the move
to the ReflectiveLibrary. This will be a few parser niceties such as
_'xxx'.
Regards,
- Alex.
Hi Alex
I've decided that it is just too ambitious/risky to get this in for M6.
We are sure to provoke unhappy customers. Let's try to have it ready
for M6 but not commit till M1, so that we have plenty of time to polish
before anyone sees it at M1, and even more thereafter. We may even have
time to develop an OCL_1_3_0.oclstdlib.
We therefore need to partition the outstanding bugs and only tackle
those that are independent of the move to the ReflectiveLibrary. This
will be a few parser niceties such as _'xxx'.
Regards
Ed Willink
On 19/01/2010 18:38, Alexander Igdalov wrote:
Hi Ed,
Although I like very much the new approach in the reflective
branch, I am not sure we should merge it with HEAD in this release. Even if we make all tests green and provide patches for QVTO we won't have enough time to get the
feedback from our users/downstream projects to check that the new
version is stable. Since it is quite a big amount of changed code, we (and consequently
the downstream projects) are as well at
risk of overlooking something while reviewing...
As you have mentioned it is
challenging to get all this by the API freeze to avoid a major
increment next year, so let's see what we will have by M5 and M6...
Regards,
- Alex.
Hi Alex
Getting all this ready for M5/6 is certainly challenging, but unless we
do a major increment next year too, it's almost now or never. That is
why I have reorganised my plans to put as much time in before M6 as
possible and to fudge the editors etc as examples a bit later for M7
with QVTd deferred again.
The 'phase 2' in the analyzer may merge forward into a 'phase 3' the
remaining major API activity; revising the Environments to support
nested environments in the style that QVTd parsing exploits.
Constructive reviews, particularly of APIs will be very helpful. We
cannot easily change them later, so let's try to get them right.
Minor contributions of tests of operations are differently helpful.
Laurent has done many of these identifying a frightening number of
problems in the 1.3.0 behaviour. A fair number of Laurent's results
have changed as a result of OCL resolutions on invalid and null. So a
review of all the new GenericEvaluatxxxx tests would be useful.
However it will be helpful to defer long philosophical discussions
about subtle invalid handling till M7/M8. Such discussions are
important but time consuming. The requisite bug fixes/OMG issues should
not affect the API framework and should be localised in a library entry
or operation class.
I do not expect QVTo to track these changes, so we must provide a high
degree of compatibility withy patches for QVTo where compatibility is
not 100%. However if Sergey likes the look of OCL.oclstdlib and feels
motivated to develop QVTo.oclstdlib immediately we could put less
effort into patches.
Regards
Ed
On 19/01/2010 14:47, Alexander Igdalov wrote:
Ed,
I could do tests/reviews.
I am hoping to have a closer look at what has to be done in the
analyzer and let you know if I could help with it in the middle of next
week.
As regards the branch, I
liked very much the implementation of the model-driven library approach
you did there. However, I am not sure it can substitute the old
codebase in Helios. Even if it becomes stable before M6 (API freeze) we
should remember about our downstream projects... I wouldn't merge it
with HEAD after M5 unless we provide patches for QVTO, etc...
Ed, how would you estimate
the time needed to make the branch stable (by 'stable' I mean a stable
interim state, e.g. with phase1 only)? Moreover, do you think it makes
sense to have a stable but a logically unfinished engine in this
release with pending breaking changes in the next release?
Regards,
- Alex.
Hi Alex
Yes. In so far as possible everything that could be defined by an
XXX.oclstdlib should be, so that just by changing to YYY.oclstdlib you
get a different configuration of behaviour. The most important change
is for lookup to search the generic library rather than the Ecore/UML
library.
Everything in the analysis field is part of 'phase 2' though I'm
beginning to suspect that 'phase 1' may stall without doing 'phase 2'
anyway since 'def' constraints must be added to the library by the
analyzer.
How much time do you have available?
Small amounts of time could help with tests/reviews.
More substantial time could help with perhaps 'phase 2'.
Beware: the branch is my development area. It is not equivalent in
quality to committed code. There is much still to do.
Ed
On 19/01/2010 13:41, Alexander Igdalov wrote:
Hi Ed,
Thanks for informing me.
I am now merging my patch for collections conformance to OclAny with the
Reflective Library branch. As I see it, there is conformance information in
the OCL.oclstdlib file, i.e. it is mentioned there that Collections conform
to OclAny. Still this information is not used in
AbstractTypeChecker.getRelationShip() and etc. Are you planning to update
the type checker so that it would use the library model rather than perform
by-hand conformance resolution like in getRelationship methods?
Cheers,
- Alex.
-----Original Message-----
From: Ed Willink [mailto:ed@xxxxxxxxxxxxx]
Sent: Tuesday, January 19, 2010 4:23 PM
To: Alexander Igdalov
Subject: Reflective Library progress
Hi Alex
The UML tests now 'work' as well; 116 failures rather than 400.
I've added Status.txt at the foot of o.e.o to remind myself (tell you) what
needs to be done.
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 270.14.150/2632 - Release Date: 01/19/10 07:34:00
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 270.14.151/2633 - Release Date: 01/19/10 17:49:00
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 270.14.151/2633 - Release Date: 01/19/10 17:49:00
|
