Ace or project files

Technical (archive)
1

Hi,

I have some problems with the Eiffel-sources.
I made my way to understanding and even loving the Eiffel compiler, and now I want to use its power for better understanding of the openehr kernel.
I start puzzling what belongs to what and, oh, I discover classes with duplicate names.

I found now duplicate
APPLICATION, both in file application.e (on different locations)
and
VERSIONED_FOLDER
one in
ref_impl_eiffel\libraries\openehr\src\rm\ehr\ehr_directory.e
and one in
ref_impl_eiffel\libraries\openehr\src\rm\common\directory\versioned_folder.e

Maybe there is an instruction how to handle those duplicate classnames, because my Eiffel-compiler does not eat them.

Maybe there are ace-files, or some other way to help me out, if yes, please tell me where they are, I had my source trees with SVN, but I had to make distinctions, for not to get everything, and maybe I missed them

thanks
Bert Verhees

2

Bert Verhees wrote:

Hi,

I have some problems with the Eiffel-sources.
I made my way to understanding and even loving the Eiffel compiler, and now I want to use its power for better understanding of the openehr kernel.

firstly, not much of the Eiffel kernel internals are yet implemented in the Eiffel version - the Java version is the most advanced. The Eiffel kernel has to wait until I have more time;-)

I start puzzling what belongs to what and, oh, I discover classes with duplicate names.

I found now duplicate
APPLICATION, both in file application.e (on different locations)

this is natural - there are probably 5 or more applications in the archive. You have to build each system from the relevant Ace file. Have you looked at the developer's page? http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/developer_page.htm?op=file&rev=0&sc=0.

Also, make sure you have done a recent update from subversion.

and
VERSIONED_FOLDER
one in
ref_impl_eiffel\libraries\openehr\src\rm\ehr\ehr_directory.e
and one in
ref_impl_eiffel\libraries\openehr\src\rm\common\directory\versioned_folder.e

I will chekc this, but at the moment, my copy of this system compiles correctly.

- thomas

3

Aye ; this would appear to imply that classes can share names as long
as they don't appear in the same cluster.

http://www.pi.informatik.tu-darmstadt.de/inf1/eiff-ref/chap3.htm#cluster

But when I add a class using EiffelStudio, it just complains that
there is already a class of the same name, regardless of which cluster
you add it in... the only way I could get around this was....

* Create a class with the filename desired, but a different classname.
* Manually edit the class name in the file to the desired classname
* Compile (this updates the name in the cluster treeview)

Please someone (Mr Beale?) tell us it's not really that fiddly.

I've heard complaints about the "quirkiness" of EiffelStudio on this
list, and I'm beginning to see why. Of course, Bert doesn't say
whether he is using it :slight_smile:

4

Adrian Wilkins wrote:

Aye ; this would appear to imply that classes can share names as long
as they don't appear in the same cluster.

http://www.pi.informatik.tu-darmstadt.de/inf1/eiff-ref/chap3.htm#cluster

But when I add a class using EiffelStudio, it just complains that
there is already a class of the same name, regardless of which cluster
you add it in... the only way I could get around this was....

* Create a class with the filename desired, but a different classname.
* Manually edit the class name in the file to the desired classname
* Compile (this updates the name in the cluster treeview)

Please someone (Mr Beale?) tell us it's not really that fiddly.

Eiffel currently does not support namespaces, so it means that if you have an Ace file that mentions 2 clusters (=packages) each with a class of the same name, it won't work. In practice this doesn't matter in software you have control over. It can create a problem when you want to integrate with an external package, in in openEHR in fact we had to rename a couple of classes due to this.

But - as I have said before, there is nothing forcing people to use Eiffel. You can use the Java or (soon to be published) C#.Net implementations of openEHR that are underway. A Release 1.0-compliant version of the Java classes will be uploaded soon.

Since people seem to find Eiffel a strange choice, I will simply say that I continue to use Eiffel because it is far more powerful than these other languages (and I have to say, working somewhat more closely than usual with the Java effort, I am continually amazed at how semantically weak Java is - there are so many things you just can't do easily...). And we use it to do basic formal testing on the openEHR models, since Eiffel implements everything in UML+OCL. I recommend it to anyone interested in safety, correctness, and writing as few lines of code as possible. Recently it was open sourced, and now is offered under a dual license.

On the other hand, there are various reasons why people use other languages, and they should not take my remarks above to mean that a) openEHR needs Eiffel (it doesn't) or b) that good software can't be written in other languages (it can; it just takes longer to write the same code, but due to larger amounts of available libraries and tools, there are often more things you can do.).

hope this answers a few frequent questions.

- thomas beale

5

Aye ; this would appear to imply that classes can share names as long
as they don't appear in the same cluster.

http://www.pi.informatik.tu-darmstadt.de/inf1/eiff-ref/chap3.htm#cluster

But when I add a class using EiffelStudio, it just complains that
there is already a class of the same name, regardless of which cluster
you add it in... the only way I could get around this was....

* Create a class with the filename desired, but a different classname.
* Manually edit the class name in the file to the desired classname
* Compile (this updates the name in the cluster treeview)

Please someone (Mr Beale?) tell us it's not really that fiddly.

I've heard complaints about the "quirkiness" of EiffelStudio on this
list, and I'm beginning to see why. Of course, Bert doesn't say
whether he is using it :slight_smile:

I am using EiffelStudio, and in the past I never had complains from the
compiler like that, but I will investigate it further, and come back to this

As Thomas says, the Eiffel sources are not up top date, and I do not have much
time, regretly, so, too bad ......

Thanks
Bert

6

this is natural - there are probably 5 or more applications in the
archive. You have to build each system from the relevant Ace file. Have
you looked at the developer's page?
http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/developer_page.htm?op=file
&rev=0&sc=0.

Maybe stupid, but I didn't look at that page, I never saw it.
I''ll do now, and come back to this

Thanks
bert

7

I have just fixed one problem; please do a new update from Subversion and recompile.

If there is enough interest in the Eiffel version of openEHR, I will get an Eiffel project group list created and we can operate within that, and avoid annoying the main list with such details. People who are interested in that please let me know.

- thomas beale

Bert Verhees wrote:

8

Bert Verhees wrote:

this is natural - there are probably 5 or more applications in the
archive. You have to build each system from the relevant Ace file. Have
you looked at the developer's page?
http://my.openehr.org/wsvn/ref_impl_eiffel/TRUNK/developer_page.htm?op=file
&rev=0&sc=0.
    
Maybe stupid, but I didn't look at that page, I never saw it.
I''ll do now, and come back to this
  

See the "Developers" section on the Eiffel project home page at http://svn.openehr.org/ref_impl_eiffel/TRUNK/project_page.htm
If you think we can make the web pages clearer, please let us know.

- thomas

9

The link to the developer-page is a bit hidden below, easy to miss.
I am not professional in usability in websites, but for me there are a few
golden rules,
(you asked for it!)

10

I would appreciate that, for following reasons:
- It could give us a platform-independent way of describing the
openehr-kernel. Eiffel is easy to understand and easy to translate to most
other languages. The only problem I can think of is that many languages do
not support multiple inheritance, but there is a workaround for that, using
interfaces.
- I discovered that in my opinion there is a need for a formal point of where
development of specificitions is. I noticed this week that some PDF's are not
completely up to date. It really is safd when one spents an afternoon trying
to understand something which is skipped from the formal specifications. A
formal checkpoint makes it always possible to find out what really is the
truth.

And there are some things in the advantage of Eiffel (for those who don't
know):
- EiffelStudio is free and even open sourced now (for non-commercial use). It
is a bit strange, and I must urge people to follow the instructions, takes
about an afternoon to learn how to handel the IDE, there is a good
instruction on the website:
http://docs.eiffel.com/eiffelstudio/general/guided_tour/environment/index.html
Also follow the presentations from the website. And there is a very helpful
and friendly Eiffel-community on comp.lang.eiffel. Without any problem the
even help with stupid questions. They welcome new Eiffel-users. Takes some
time, but it is easier to learn then most other languages
- Eiffel is a very effective Object Oriented Language, you can write almost
anything with/in it. It has some extra's, easy ways to find out which methods
are inherited, dependency-graphics, many more things in their IDE
- Eiffel has Design By Contract build in, you can do that in other languages
to, but in Eiffel, some language features are really only there for this.
When you see the presentations on www.eiffel.com, you will see

regards
Bert Verhees

11

Bert Verhees wrote:

------------------------
Concluding, The openehr could use a makeover. I know it is a lot of work, I know that people are proud of it, I don't want to be unfriendly or unpolite.
  

actually, we are not nearly so proud of the website as you might think - most of us consider it is quite poor compared to good standards and presentation. The problem is simply one of funding: we need to a) change the technology to something more content management based (e.g. Cocoon, mambo etc), b) employ someone to rebuild and maintain the site, and c) ensure that the content is kept up to date. At the moment, all we can do is stick with the basic web page technology since we don't have the resources to do otherwise.

However, for your amusement, I did try a few improvements to the Eiffel project page....http://svn.openehr.org/ref_impl_eiffel/TRUNK/project_page.htm :wink:

- thomas beale

12

page....http://svn.openehr.org/ref_impl_eiffel/TRUNK/project_page.htm :wink:

Much better!

13

Bert Verhees wrote:

  

I have just fixed one problem; please do a new update from Subversion
and recompile.

If there is enough interest in the Eiffel version of openEHR, I will get
an Eiffel project group list created and we can operate within that, and
avoid annoying the main list with such details. People who are
interested in that please let me know.
    
I would appreciate that, for following reasons:
- It could give us a platform-independent way of describing the openehr-kernel. Eiffel is easy to understand and easy to translate to most other languages. The only problem I can think of is that many languages do not support multiple inheritance, but there is a workaround for that, using interfaces.
  

BTW, code can be recompiled on most machines to native code, because it goes via gcc or any other equivalent compiler (MS vc++ on windows). We have recompiled the ADL workbench on a Mac and it works, with a couple of little annoying GUI problems...well nothing's perfect, but that's not bad for no lines of code changed.

- I discovered that in my opinion there is a need for a formal point of where development of specificitions is. I noticed this week that some PDF's are not completely up to date. It really is safd when one spents an afternoon trying to understand something which is skipped from the formal specifications. A formal checkpoint makes it always possible to find out what really is the truth.
  

I agree - we are not always perfect in this regard. But - can you indicate what the particular problem was? Also, since you are working at the "bleeding edge", please use the 1.1 candidate specs - http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html

- thomas

14

I agree - we are not always perfect in this regard. But - can you
indicate what the particular problem was? Also, since you are working at
the "bleeding edge", please use the 1.1 candidate specs -
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publish
ing/index.html

I wouldn't say that,
But it is true that I am working with experimental code, but it uses the
excellent java-kernel from Rong Chen (ACode)

There was a problem, but it was also my misunderstanding, I forgot how I came
there, it had to do with EhrExtract.
I think, Iam wrong, and was my remark that the specifications are sometimes
not up to date based on a very rarely occuring situation.

Bert

15

Bert Verhees wrote:

I agree - we are not always perfect in this regard. But - can you
indicate what the particular problem was? Also, since you are working at
the "bleeding edge", please use the 1.1 candidate specs -
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publish
ing/index.html
    
I wouldn't say that, But it is true that I am working with experimental code, but it uses the excellent java-kernel from Rong Chen (ACode)
  

please note that this is only 0.95 version of openEHR, and Yin Su Lim at UCL has been working hard on getting it up to Release 1.0. She will upload one set of changes today hopefully, which is the full set of compiling classes, but there is still a lot of work to go to rework the test cases etc, so don' expect miracles just yet....

There was a problem, but it was also my misunderstanding, I forgot how I came there, it had to do with EhrExtract.
  

well that specification hasn't been re-issued yet - it will be in about a week's time, in draft form, for comment.

I think, Iam wrong, and was my remark that the specifications are sometimes not up to date based on a very rarely occuring situation.
  

we certainly hope it is rare!

- thomas

16

Thomas Beale schreef:

Bert Verhees wrote:

I agree - we are not always perfect in this regard. But - can you
indicate what the particular problem was? Also, since you are working at
the "bleeding edge", please use the 1.1 candidate specs -
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publish

ing/index.html
    
I wouldn't say that, But it is true that I am working with experimental code, but it uses the excellent java-kernel from Rong Chen (ACode)
  

please note that this is only 0.95 version of openEHR, and Yin Su Lim at UCL has been working hard on getting it up to Release 1.0. She will upload one set of changes today hopefully, which is the full set of compiling classes, but there is still a lot of work to go to rework the test cases etc, so don' expect miracles just yet....

There is a lot of work to do in this Release-1.0
I hope it will be done quick. If I can do something, please let me know.

There is something I noticed, I don't know if it is on purpose.
I noticed that the Release-0.95 is not in sync with the TRUNK release, in fact, it is running behind (maybe months).

This is, in my opinion, confusing, because when the next version (Release-1.0?) will enter TRUNK, it will never be possible again to retrieve an actual copy of Release-0.95.
In my opinion, but I am not a SVN-maintainer, this could be solved by having a symlink between 0.95 and TRUNK
And create a new symlink when a new release will come into TRUNK

Maybe I am wrong in understanding this perception of source-code maintenance. I am glad to learn every day, so please tell me, if I am wrong, where it is explained.

regards
Bert Verhees

17

Bert Verhees wrote:

Thomas Beale schreef:
There is a lot of work to do in this Release-1.0
I hope it will be done quick. If I can do something, please let me know.

if you want to work on the Java kernel, please let us know.

There is something I noticed, I don't know if it is on purpose.
I noticed that the Release-0.95 is not in sync with the TRUNK release, in fact, it is running behind (maybe months).

you mean the 0.95 branch of of ref_impl_java? That branch was declared 29/mar/2006. Also for release 1.0.

This is, in my opinion, confusing, because when the next version (Release-1.0?) will enter TRUNK, it will never be possible again to retrieve an actual copy of Release-0.95.

why not - it has its own branch - see http://my.openehr.org/wsvn/ref_impl_java/BRANCHES/?rev=0&sc=0 - this is where it will be maintained for as long as it is needed.

hope this helps.

- thomas

18

Thomas Beale schreef:

Bert Verhees wrote:

Thomas Beale schreef:
There is a lot of work to do in this Release-1.0
I hope it will be done quick. If I can do something, please let me know.

if you want to work on the Java kernel, please let us know.

If I can help, I would like to do some jobs, I don't know who coördinates it.
My reading/writing of java-code is quite good, maybe there are small well defined jobs to do, for easy step in the project. Or easy classes, or writing class-bodies, something like that.
Do not hesitate to ask me, also if you think of something yourself.
I could maybe spent average one hour everyday.

There is something I noticed, I don't know if it is on purpose.
I noticed that the Release-0.95 is not in sync with the TRUNK release, in fact, it is running behind (maybe months).

you mean the 0.95 branch of of ref_impl_java? That branch was declared 29/mar/2006. Also for release 1.0.

Yes, and the TRUNK is the 0.95 Release? Am I right?
After this date there were made some changes at the TRUNK, not many, but still.
These changes were not made at the BRANCHES/Release-0.95, so they are not in sync.
The BRANCHES/0.95 Release is not maintained, while the TRUNK-0.95 is, so there are two 0.95 releases.

In my perception, the BRANCHES/0.95 should have the latest version, and the TRUNK should be patch from the BRANCHES/0.95
In this way the TRUNK should always be in sync.

I learned this wisdom from document
http://svn.openehr.org/specification/TRUNK/publishing/CM/CM_plan.pdf

Page 19, figure 5, where you make a clone of the TRUNK to a defined release, and eventually bugs are repaired below BRANCHES and patches of that release are patched back to the TRUNK, so in this case, TRUNK should, in my perception be in sync with BRANCHES/0.95

If I misunderstand, please correct me

thanks
Bert Verhees

19

Bert Verhees wrote:

Thomas Beale schreef:

Bert Verhees wrote:

Thomas Beale schreef:
There is a lot of work to do in this Release-1.0
I hope it will be done quick. If I can do something, please let me know.

if you want to work on the Java kernel, please let us know.

If I can help, I would like to do some jobs, I don't know who coördinates it.
My reading/writing of java-code is quite good, maybe there are small well defined jobs to do, for easy step in the project. Or easy classes, or writing class-bodies, something like that.
Do not hesitate to ask me, also if you think of something yourself.
I could maybe spent average one hour everyday.

There is something I noticed, I don't know if it is on purpose.
I noticed that the Release-0.95 is not in sync with the TRUNK release, in fact, it is running behind (maybe months).

you mean the 0.95 branch of of ref_impl_java? That branch was declared 29/mar/2006. Also for release 1.0.

Yes, and the TRUNK is the 0.95 Release? Am I right?
After this date there were made some changes at the TRUNK, not many, but still.
These changes were not made at the BRANCHES/Release-0.95, so they are not in sync.
The BRANCHES/0.95 Release is not maintained, while the TRUNK-0.95 is, so there are two 0.95 releases.

No, the TRUNK is gradually moving forward particularly the ADL parser and AOM classes. The Release-0.95 branch should only receive bug fixes, while the TRUNK will eventually land on Release 1.0 and beyond. Some bug fixes on the TRUNK should also be done on the Release-0.95, I agree.

Rong

20

>> declared 29/mar/2006. Also for release 1.0.
>
> Yes, and the TRUNK is the 0.95 Release? Am I right?
> After this date there were made some changes at the TRUNK, not many,
> but still.
> These changes were not made at the BRANCHES/Release-0.95, so they are
> not in sync.
> The BRANCHES/0.95 Release is not maintained, while the TRUNK-0.95 is,
> so there are two 0.95 releases.

No, the TRUNK is gradually moving forward particularly the ADL parser
and AOM classes. The Release-0.95 branch should only receive bug fixes,
while the TRUNK will eventually land on Release 1.0 and beyond. Some bug
fixes on the TRUNK should also be done on the Release-0.95, I agree.

OK, I misunderstood, maintaining the 0.95 version should be done in the
BRANCHES while the TRUNK only is to move forward (to 1.0).

But what is the development goal of the TRUNK then at this moment.
Because there is BRANCHE-work at the 1.0 version, will that be moved to the
TRUNK at a certain moment?, and at a certain moment be copied back?
Or will the TRUNK be moved back to the BRANCHE, ro wil,l they both undergo a
painful process of merge.
Are there two different working-trails toward 1.0 (The TRUNK and BRANCHE 1.0)
Isn't it too early to have a BRANCHE 1.0 release?

It is confusing

II have my doubts for several reasons

- the arrows in the documentation (CM_plan.pdf) point in the wrong direction,
the text in Figure5 page 19 explain that the fixes are made in the BRANCHE
and after that applied to the TRUNK. This is the situation at this moment.
- at the same time the same documents explains at page 17 that the TRUNK is
the mainline current development and the BRANCHES is for branche development
or test work.
I would understand the terminology "branche development" as:
The BRANCHE is to freeze a certain TRUNK-situation, and after that, for
offering a place for maintaining a certain (major) release, it is not a place
for growing towards a new release

When you apply these rules to 0.95, it works like it should, more or less
(0.95 should be patched, you are right) but applied to 1.0, I am really
confused, what is the main 1.0 version workline, when do we have a 1.0
release which is ready for production, how can we recognise this version in
SVN, because at this moment, we have two version which are both in
pre-beta-condition. I think the BRANCHE-1.0 should have another name

regards
Bert