[ref_impl_eiffel] ADLworkbench in Linux

Reference Implementation: Eiffel (archive)
1

I have it running, the Eiffel Studio 6.0 for Linux, the workbench
compiles and opens single archetypes
Everything looks good and the application is stable. It is a wonder how
code can run multi-platform. Bravo!

So this is all fine. There is only some small problems.
1) I am not able to set the reference-repository. I try to set it to
/home/verhees/OpenEhr/knowledge/archetypes/
That is where my SVN-archetypes directory is.

2) There is a mousepointer missing in the compiled resources. It has all
the mouspointers which are standard, like resizing panel-parts, etc. But
it misses the mousepointer for the treeviews, it only shows a white
square then.

Maybe they are easy to repair?

Thanks
Bert Verhees
.

There is an uncaught exception:

2

Bravo, Bert!

1) I am not able to set the reference-repository. I try to set it to
/home/verhees/OpenEhr/knowledge/archetypes/
That is where my SVN-archetypes directory is.

Thanks for the stack trace. I know that bug: I fixed it a month ago in a
branch of the source code (revision 367), but we haven't done a merge back
into the TRUNK since then. I've just committed the same fix into the TRUNK:
revision 400. The bug was caused by the trailing slash in your repository
path.

2) There is a mousepointer missing in the compiled resources. It has all
the mouspointers which are standard, like resizing panel-parts, etc. But
it misses the mousepointer for the treeviews, it only shows a white
square then.

That's interesting. I've seem the same problem on Mac OS X, which is
basically the same platform, i.e. GTK running on a variant of Unix. Maybe
it's a bug in the GTK version of EiffelVision. I think I'll submit a bug
report to Eiffel Software.

- Peter

3

Peter Gummer schreef:

Bravo, Bert!

1) I am not able to set the reference-repository. I try to set it to
/home/verhees/OpenEhr/knowledge/archetypes/
That is where my SVN-archetypes directory is.
    
Thanks for the stack trace. I know that bug: I fixed it a month ago in a
branch of the source code (revision 367), but we haven't done a merge back
into the TRUNK since then. I've just committed the same fix into the TRUNK:
revision 400. The bug was caused by the trailing slash in your repository
path.
  

Thanks for your quick reply, you are right, Mac is also a posix platform

I removed the trailing slash, got another stacktrace (the repository-box
remains open after clicking ignore, and the repository path is not set)

about the mousepointer, looks like you are right.

regards
Bert

4

Bert Verhees wrote:

about the mousepointer, looks like you are right.

I've submitted the problem report below to Eiffel Software. Let's see what
they come up with. It looks like a bug to me, though I guess there's still a
chance that I might be using the wrong technique to restore the mouse
pointer.

If you have time, Bert, it would be interesting to see if you get the same
behaviour when you follow the steps written below. It might encourage them
to prioritise a fix for this.

- Peter

5

Peter Gummer schreef:

Bert Verhees wrote:

about the mousepointer, looks like you are right.

I've submitted the problem report below to Eiffel Software. Let's see what
they come up with. It looks like a bug to me, though I guess there's still a
chance that I might be using the wrong technique to restore the mouse
pointer.

If you have time, Bert, it would be interesting to see if you get the same

next tuesday, I am working on the computer where Eiffel is installed

Bert

6

Excuse me for the delay (busy, busy)

but I can reproduce the problem, following the steps you described.

regards
Bert

Peter Gummer schreef:

7

Bert Verhees wrote:

Excuse me for the delay (busy, busy)

but I can reproduce the problem, following the steps you described.

Thanks, Bert. I'll let EiffelSoftware know.

- Peter

8

Bert Verhees wrote:

I removed the trailing slash, got another stacktrace (the repository-box
remains open after clicking ignore, and the repository path is not set)
...
TWO_WAY_TREE set_specialisation_parent @8
                                          parent_validity:

I've spent a while looking at this error, Bert, but I haven't figured out
how to reproduce it. I think there must be something strange in your
repository, possibly an archetype with a strange file name. I tried a few
hypotheses, but no luck: I don't get the error. I've also spent quite a
while looking at the relevant features
(ARCH_REP_ARCHETYPE.set_specialisation_parent, ARCH_DIRECTORY.merge_enter,
and related), but I can't see a flaw in the logic that could have caused the
exception.

So (again, if you have time), could you repeat whatever you did to cause the
error, but this time do it within the EiffelStudio debugger? Then, when it
breaks on the exception:

1. In the Call Stack, double-click the second routine from the top
(ARCH_REP_ARCHETYPE.set_specialisation_parent).

2. In the Object Viewer have a look at specialisation_parent.id.semantic_id
and id.semantic_parent_id. The exception is a failure of
ARCH_REP_ARCHETYPE's invariant 'parent_validity', which asserts that these
two ids are equal. Apparently they are not equal, so it would be interesting
to discover what they are. This would also tell us exactly which archetype
is causing the failure.

- Peter

9

Sorry Peter for the delay, I really would like to get it running in
Linux, but I am busy all the times.
Today I did a svn-update to have the latest version, and wanted to try
your steps, but the workbench hangs at starting up, it gives an
unfinished Window, and the only way to get it down is Ctrl+C.
This happens from the command-prompt, but also from witin the Eiffel IDE.

I copied it to the root directory of the source, because of the
"icons"-directory

10

Bert Verhees wrote:

... the workbench hangs at starting up, it gives an
unfinished Window, and the only way to get it down is Ctrl+C.
This happens from the command-prompt, but also from witin the Eiffel IDE.

I copied it to the root directory of the source, because of the
"icons"-directory

Hi Bert,

It appears to hang because it is building an in-memory tree of your whole
file system.

Don't copy it to the root directory. ADL Workbench works on a repository of
archetypes, and the first time you run ADL Workbench, it initialises the
repository path to be equal to the application's start-up directory. So, by
copying the application to the root directory, you have caused it to
initialise the repository path to the root!

This is a known problem with ADL Workbench. We haven't fixed it yet because
we haven't devised a better way of initialising the repository path. We also
ought to think of a way of preventing it from trying to scan a huge
directory tree, just in case someone manually sets the repository path to
"/" or "C:\".

Why did you copy it to the root? You said something about the "icons"
directory, but I don't understand.

- Peter

11

Peter Gummer schreef:

Bert Verhees wrote:

... the workbench hangs at starting up, it gives an
unfinished Window, and the only way to get it down is Ctrl+C.
This happens from the command-prompt, but also from witin the Eiffel IDE.

I copied it to the root directory of the source, because of the
"icons"-directory
    
Hi Bert,

It appears to hang because it is building an in-memory tree of your whole
file system.

Don't copy it to the root directory. ADL Workbench works on a repository of
archetypes, and the first time you run ADL Workbench, it initialises the
repository path to be equal to the application's start-up directory. So, by
copying the application to the root directory, you have caused it to
initialise the repository path to the root!

This is a known problem with ADL Workbench. We haven't fixed it yet because
we haven't devised a better way of initialising the repository path. We also
ought to think of a way of preventing it from trying to scan a huge
directory tree, just in case someone manually sets the repository path to
"/" or "C:\".

Why did you copy it to the root? You said something about the "icons"
directory, but I don't understand.

- Peter

I said, the root directory of the source, whcih is "app" I believe,
where the Icon directory is (almost weekend :wink:

But maybe this is the problem, I start it again and let it do its job

Bert

12

Bert Verhees wrote:

I said, the root directory of the source, whcih is "app" I believe,
where the Icon directory is (almost weekend :wink:

Oops, so you did. There's no need to copy it to the "app" directory of the
source. Normally it expects the icons directory to be in the same directory
as the application, but in order for it to work where it has been built it
looks in "../../../icons" if the application's start-up path ends with
"EIFGENs/*/[FW]_code". See SHARED_RESOURCES.application_full_path.

On the other hand, although copying it to the "app" directory would
increased the number of directories that it has to scan, it should not have
caused it to appear to hang, unless your computer is very slow. Perhaps you
just need to wait a bit longer for it to finish.

- Peter

13

I crashes if I let it hang sometime, same stacktrace, I renamed the old
"knowledge" directory, there must be something rotten in there, because
- I succeeded to stop the application in the debugger, and I saw it
scanning a directorty in this archetype-directory
- I runs fine after renaming this directory

Then I tried to point it to the renamed the directory and it crashes
again, but now in the debugger, I try to give you as much information as
possible

Code: 4 (Postcondition violated.) Tag: correct_path

This is:
    directory_at (path: STRING_8): DIRECTORY
            -- A directory object representing `path'.
            -- Strips any trailing backslash to avoid Windows API defect.
            -- (from SHARED_RESOURCES)
            -- (export status {NONE})
        require -- from SHARED_RESOURCES
            path_attached: path /= Void
            path_not_empty: not path.is_empty
        do
            create Result.make (file_system.canonical_pathname (path))
        ensure -- from SHARED_RESOURCES
            attached: Result /= Void
--> correct_path: path.substring (1,
Result.name.count).is_equal (Result.name)
        end

This is in ARCHETYPE_INDEXED_FILE_REPOSITORY_IMP

The value of "path" is /home/verhees/OpenEhr/k//BRANCHES
You see, the double "//"

The error is, correct_path receives the value: path.substring (1,
Result.name.count) which will be in this case:
/home/verhees/OpenEhr/k//BRANCHE
(you see, the "S" is missing)

Result.name= /home/verhees/OpenEhr/k/BRANCHES
(single slash)

So, concluding
correct_path: path.substring (1, Result.name.count).is_equal (Result.name)

Because path has a double slash, it differs from Result.name which has a
single slash

Maybe you can find out why.

Thanks,
Bert

Bert Verhees schreef:

14

Bert Verhees wrote:

Code: 4 (Postcondition violated.) Tag: correct_path

This is:
   directory_at (path: STRING_8): DIRECTORY
           ...
--> correct_path: path.substring (1,
Result.name.count).is_equal (Result.name)
       end

This is in ARCHETYPE_INDEXED_FILE_REPOSITORY_IMP

The value of "path" is /home/verhees/OpenEhr/k//BRANCHES
You see, the double "//"

That's great information, Bert. Thanks.

I discovered similar problems last week when I was trying to figure out the
cause of the error that you reported back then.

I've made major changes as a result of this, but they are all in the
specialisation branch, not the TRUNK. (I did these changes last week, but
I've only just committed them.) Unfortunately, the specialisation branch is
not in a fit state to merge back into the TRUNK yet, and the changes were
too extensive for me to apply them manually. (Well, I could try, but it
would take me a long time!)

You could try building the specialisation branch rather than the TRUNK, but
I don't recommend it because a few things are still broken in that branch.

A much easier solution for you would be to make sure that you don't have a
"/" at the end of your repository path. I think this double "//" problem is
caused if you have a "/" at the end.

- Peter

15

A much easier solution for you would be to make sure that you don't have a
"/" at the end of your repository path. I think this double "//" problem is
caused if you have a "/" at the end.
  

Maybe it is another problem, because without slash it hangs, and with
slash it crashes.

Bert

16

Bert Verhees wrote:

Maybe it is another problem, because without slash it hangs, and with
slash it crashes.

When you say "it hangs", Bert, how long do you wait for it? How many
subdirectories are there in the repository path that you have specified?
It's probably just taking a very long time to scan a big directory tree.

Also, note that it takes a much longer time if you run a build with
assertions enabled (e.g. the workbench build) than if you run a build
without assertions (e.g. finalized). The effect appears even worse if you
run the workbench build in the debugger.

- Peter

17

Peter Gummer schreef:

Bert Verhees wrote:

Maybe it is another problem, because without slash it hangs, and with
slash it crashes.

When you say "it hangs", Bert, how long do you wait for it? How many
subdirectories are there in the repository path that you have specified?
It's probably just taking a very long time to scan a big directory tree.

It is the archetype-directory-tree I downloaded with SVN, cannot be to
deep, maybe 5 levels at its most deep, and maybe five hundred files

Should be able t scan in less ten seconds, I have modern PC's (more of
them, all with Suse Linux 10.2

My archetype path is (without trailing slash, a valid path),
representing the bad directory-naming on my notebook, in the hurry to
find the error: /home/verhees/OpenEhr/Eiffel/archetypes

I am stepping through, now I am at:
(ARCH_DIRECTORY)valid_repository_path, and
dir_name=/home/verhees/OpenEhr/Eiffel/archetypes

It says if directory_at (dir_name).exists then = TRUE, so I do get into
a loop now:

and so on and so on, I let you know, if I find what the problem is

18

I have good news, it just runs, it takes a lot of time before it has
done scanning all the directories, maybe two minutes, I was too impatient

Thanks for bothering

regards
Bert

Bert Verhees schreef:

19

One last question (for today)

I do ot have much experience with Eiffel, how can I get my executable
smaller, I already finalized it without assertions, but it still is 53
Mb. Is there a way, or is this normal, it runs OK, that is no problem

regards
Bert

Bert Verhees schreef:

20

Bert Verhees wrote:

I do ot have much experience with Eiffel, how can I get my executable
smaller, I already finalized it without assertions, but it still is 53
Mb. Is there a way, or is this normal, it runs OK, that is no problem

That seems strange that it's so large, Bert. The Windows build of ADL
Workbench is about 7 Mb. The Macintosh PowerPC build is about 7 Mb too.

Are you sure that you aren't looking at the W_code executable?

- Peter