| Re: [mdt-ocl.dev] Making useful progress |
|
Hi All, The following are my thoughts around the said topics: Communications: I agree that we should mainly use dev.list and/or bugzilla for OCL related discussions. The reason for using an IM client by the OCL team is the following. When you are working on an issue or whatever, some times you may have a doubt which may can be resolved very quickly without interrupting the work. Besides, not only every doubts will be related to OCL, but any Eclipse/Committer/etc concerns, which are not scoped in an ocl-dev mailing list at all. I like GTalk because it can be easily used in a web browser (port 80). In any case, I don't mind if we are not agreeing on using this kind of communications. I think that Alex (the project lead) said that he uses Skype, so I think I'm going to use it to get quick responses from him. MDT-OCL 2.0.0: I worked on several issues as an OCL-RTF member so I could try to oversee which kind of API changes could arise if we try to adopt the new version of the OCL specifications. API Changes: Adopting the new specificication would undoubtedly provoke API changes. Besides there are some problems with the current MDT-OCL 1.3.0 version which are not coherent with the current specification (i.e., the Standard Library OclInvalid type has been erroneously considered as Invalid in the implementation). Some points which I would like to include in the discussion are the following: - The current Standard Library must be reworked. - If we step on the MDT-OCL 2.0.0 version I would strongly recommend thinking about changing the LPG parser. LPG v1.1 parser is 3 years old . I have been recently experimenting the backtracking parser incorporated by Ed in the MDT-OCL 1.3.0 release, and I have found out inefficient problems. For instance the current parser uses an IntTuple initialized with 1<<20 slots (around 4 megabytes of memory). However, in LPG v2 the backtracking parser has been fixed to use an IntSegmentedTuple which reallocotes slots when needed and it's initialized with 1024 slots (around 4 kbytes of memory). The difference is substantial.... I guess that LPG's v2 IP must not be a problem since it should have been solved for the IMP project. The main problem, is that OCL project would have to accurate the grammars, and therefore M2M-QVT OML, M2M-QVT Declarative and M2T-Acceleo. Fortunately, we have a representative member of each project in the OCL Team, so we could get their opinion about assuming this challenge in their projects. BTW, I worked on one of the first releases of LPG 2.0 (the current version is 2.0.17) 2 years ago and there weren't too much differences. Nevertheless, I don't how much efforts would be needed to adopt grammars and parsing infraestructure with the current LPG 2.0.17 version. - About the related issues : If my memory doesn't fail me, these non-standard operations will be included in the specification, although with different names. I'll check that point. I'm really inclined to include this feature in the OCL - Project. In addition. Víctor Sanchez (Open Canarias's mate) has developed a modification of the .edit item providers so that the getText is exploited to better see the OCL expressions in the Sample Core Editor. Open Canarias could make some contributions in this way. We could also think about delegating the ToStringVisitor mission to the .edit item providers. I think that we must tackle this enhancement. I have even read some times a request about including the example as part of the UI of the project. Cheers, Adolfo. --
|
