I'm afraid I forgot to subscribe myself to this list until just now
(being the list owner and all;-), so I missed the previous posts from
Bert. Bert - can you resend them - sorry about that, but at least the
threading will be more normal if we do that.
- thomas
Quoting Thomas Beale:
... I missed the previous posts from Bert.
Bert - can you resend them - sorry about that, but at least the
threading will be more normal if we do that.
Allow me 
This was the first message I saw from Bert:
Hi
I reported last week, I was missing an Eiffel class which was referenced
from (a maybe never referenced) class ADL_EXPR_CONSTRAINTNow I am missing a referenced class which is inherited from, the child
is C_DATE_TIME, the missing parent is ADL_DEFINITIONS, it is used a
perent at more locations, f.e. C_DURATIONMaybe it is not important, or maybe I just don't find those classes
Can someone explain this
thanks
bert
And this was the second message I saw from Bert:
Hi
I reported last week, I was missing an Eiffel class which was referenced
from (a maybe never referenced) class ADL_EXPR_CONSTRAINTNow I am missing a referenced class which is inherited from, the child
is C_DATE_TIME, the missing parent is ADL_DEFINITIONS, it is used a
perent at more locations, f.e. C_DURATIONMaybe it is not important, or maybe I just don't find those classes
Bert, which application were you trying to build?
Hi Thomas, I guess you are the one to address for these issues
Just like the java-sources, I am getting lost in the Eiffel sources.
First Question,
there are three branches, I do not understand their purpose
ADL2
dotnet
java_adl
Can you point me to a location where this is explained? The
project_page.htm's look to me the same.
we are not using the branches at the moment - they were created for
specific purposes. The ADL2 one might go back into action later. All the
current work is on the TRUNK.
Second Question,
I compiled the project from TRUNK/libraries/openehr/test/app amd
discoverd that a file ADL_DEFINITIONS is missing, I found it somewhere
I don't understand that - ADL_DEFINITIONS is not used by that
application at all.
under components, but it made me doubt. Is that the same file, is it the
good version, why isn't it in somewhere in a position where a project
referencing this file can find it?Third Question
Is the TRUNK the best tree to follow?
this is where all the work is occurring right now...
Fourth Question
Am I the only one with questions like this, and how does thjat come, do
you think
a few things you have asked are to do with being new(ish) to Eiffel I
suspect, but some are due to only myself current working on the Eiffel
project so far - I wouldn't guarantee that the directory structures are
completely perfect yet. We are just getting into serious software
building now, as the specification work becomes less
time-consuming...but questions are no problem. As we find problems, we
can fix them quickly.
One problem I would like to fix is the makefiles. At the moment I used
really dumb makefiles because I wasn't able to make microsoft nmake work
properly with unix-style makefiles. But maybe one of you can show how to
do it...
- thomas
Thomas Beale wrote:
One problem I would like to fix is the makefiles. At the moment I used
really dumb makefiles because I wasn't able to make microsoft nmake work
properly with unix-style makefiles. But maybe one of you can show how to
do it...
I've been experimenting with SCons (www.scons.org). It seems much more flexible
and portable than make. You have to install Python (www.python.org) to use
SCons, but that's painless.
So far, I've figured out how to get it to freeze a hierarchy of Eiffel projects.
Executing this from the top of the source code tree will build all projects in
the hierarchy:
$ scons
If you cd down the tree into a particular project or group of projects, then it
will build just that part of the hierarchy:
$ scons -u
To achieve this, create a file in each project directory (the directory
containing the Ace file) called "SConscript", containing these two lines:
Import('env')
env.Eiffel('ace')
Then, at the top of the source hierarchy, create a file called "SConstruct"
containing this:
import os
env = Environment(ENV = os.environ)
Export('env')
actions = [
Delete('${SOURCE.dir}/EIFGEN'),
'ec -batch -ace ${SOURCE.abspath} -project_path ${SOURCE.dir.abspath} -freeze
-c_compile'
]
env.Append(BUILDERS = {'Eiffel': Builder(action = actions, src_suffix =
'ace')})
SConscript(dirs = [
'apps/myapp1/app',
'apps/myapp2/app',
'apps/group/pair1/app',
'apps/group/pair2/app'
])
This SConstruct file is doing three things:
1. It's importing your environment so that it knows where to find ec.exe. Note
that $ISE_EIFFEL\studio\spec\windows\bin must be in your path.
2. It's teaching SCons how to freeze an Eiffel project. SCons knows about C,
Java, etc. but we need to teach it about Eiffel 
3. It's specifying where to find the SConscript files.
Getting it to finalise the projects rather the freeze them is easy, but I'm new
to SCons and I haven't quite figured out the best way to specify that we want a
'final' target rather than a 'workbench' target. SCons has the concepts of
targets and default targets, sort of like make, but different.
- Peter
Thomas Beale schreef:
Hi
I reported last week, I was missing an Eiffel class which was referenced
from (a maybe never referenced) class ADL_EXPR_CONSTRAINTNow I am missing a referenced class which is inherited from, the child
is C_DATE_TIME, the missing parent is ADL_DEFINITIONS, it is used a
perent at more locations, f.e. C_DURATIONMaybe it is not important, or maybe I just don't find those classes
Bert, which application were you trying to build?
Please excuse me, I forgot.
I build applications for understanding the sourcecode, see my post in
the implementorlist, I understand classes best when I see them in
interaction.
And sometimes I read sourcecode, and the EiffelStudio is very handy, but
it has a shortcoming.
It is only possible to navigate (jump) throught the code if it is compiled.
Classes which are not compiled inside a project, because they are not
referenced (the appear as grey, instead of blue in the Studio), one
cannot navigate through. But classes which are not referenced in a
certatain application, does not mean, these classes are there for no
reasons. maybe when the framework is used in another application, these
classes will be compiled.
This is clearily a shortcoming of EiffelStudio, I had many times a
problem with that, also when buidling a set of classes, I always had to
make a dummy reference to make features of the IDE for that class work.
So I study the Eiffel code, you told me, you used Eiffel as a kind of
case-tool, and I think, it is very suitable for this purpose, though not
perfect (see above, why), (but nothing is perfect).
Thus, because it is a case-tool, I read classes which are not
referenced, because I cannot judge if they will never be referenced,
they exist, don't they.
And then I come to a class which does inherit from a class which does
not exist, and that was my question about.
The problem is that I work in the TRUNK, I should work in a TAG which
ought to be stable. The TRUNK does not need to be stable, and things can
change. It is a pity that there is no TAG for Eiffel.
So if you find a question from me from a week ago about a certain Eiffel
class, missing in the TRUNK, I learned to live without that knowledge.
I found the class ADL_DEFINITIONS somewhere else (in
components/adl_parser/src/interface).
Hi Thomas, I guess you are the one to address for these issues
Just like the java-sources, I am getting lost in the Eiffel sources.
First Question,
there are three branches, I do not understand their purpose
ADL2
dotnet
java_adl
Can you point me to a location where this is explained? The
project_page.htm's look to me the same.
we are not using the branches at the moment - they were created for
specific purposes. The ADL2 one might go back into action later. All the
current work is on the TRUNK.
This good to know, it takes away uncertainty.
Second Question,
I compiled the project from TRUNK/libraries/openehr/test/app amd
discoverd that a file ADL_DEFINITIONS is missing, I found it somewhere
I don't understand that - ADL_DEFINITIONS is not used by that
application at all.
under components, but it made me doubt. Is that the same file, is it the
good version, why isn't it in somewhere in a position where a project
referencing this file can find it?Third Question
Is the TRUNK the best tree to follow?
this is where all the work is occurring right now...
Fourth Question
Am I the only one with questions like this, and how does thjat come, do
you thinka few things you have asked are to do with being new(ish) to Eiffel I
suspect, but some are due to only myself current working on the Eiffel
project so far - I wouldn't guarantee that the directory structures are
completely perfect yet. We are just getting into serious software
building now, as the specification work becomes less
time-consuming...but questions are no problem. As we find problems, we
can fix them quickly.
That is possible, I am new to Eiffel, but Eiffel is a very easy
environment, too bad it is not recognized more.
The first steps are difficult, different then other environments, one
does need to read the getting started guide.
Too bad there are not more people reading your Eiffelcode, and are
involved at that level.
One problem I would like to fix is the makefiles. At the moment I used
really dumb makefiles because I wasn't able to make microsoft nmake work
properly with unix-style makefiles. But maybe one of you can show how to
do it...
Why should you want to make makefiles, it is to build applications, but
you always said, Eiffel is a case tool, building the application is only
something to proof the concept.
In my concept, Eiffel is not too good for building applications, people
at Eiffel think so to. they translate the code to C, and now also to CLI.
There should be more translators to Java, C#, intelligent translators
which handle the multiple inheritance (perhaps by using interfaces?) and
the invariants , the DbC
But they will never come, the Eiffel community is too small I am afraid.
We are stuck on doing this by hand. (Ocean does, Acode does)
(It wouldn't be too hard, perhaps a project for making money, there are
examples, there are open source eiffel compilers, one can learn how to
build C-code, so there must be enough knowledge in that to do the same
for java and C# (only fantasy, life is too short))