# [ref_impl_eiffel] ADLworkbench in Linux

**Category:** [Reference Implementation: Eiffel (archive)](https://discourse.openehr.org/c/reference-implementation-eiffel-archive/161)
**Created:** 2007-11-01 12:37 UTC
**Views:** 24
**Replies:** 25
**URL:** https://discourse.openehr.org/t/ref-impl-eiffel-adlworkbench-in-linux/14681

---

## Post #1 by @system

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:

---

## Post #2 by @Peter_Gummer1

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

---

## Post #3 by @system

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

---

## Post #4 by @Peter_Gummer1

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

---

## Post #5 by @system

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

---

## Post #6 by @system

Excuse me for the delay \(busy, busy\)

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

regards
Bert

Peter Gummer schreef:

---

## Post #7 by @Peter_Gummer1

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

---

## Post #8 by @Peter_Gummer1

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

---

## Post #9 by @system

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

---

## Post #10 by @Peter_Gummer1

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

---

## Post #11 by @system

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 ;\-\)

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

Bert

---

## Post #12 by @Peter_Gummer1

Bert Verhees wrote:

> I said, the root directory of the source, whcih is "app" I believe,
> where the Icon directory is \(almost weekend ;\-\)

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

---

## Post #13 by @system

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:

---

## Post #14 by @Peter_Gummer1

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

---

## Post #15 by @system

> 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

---

## Post #16 by @Peter_Gummer1

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

---

## Post #17 by @system

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

---

## Post #18 by @system

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:

---

## Post #19 by @system

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:

---

## Post #20 by @Peter_Gummer1

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

---

## Post #21 by @system

> 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?

Yes, I am, should there be another?
I studied the Eiffel language, but I don't have much  experience with
building applications the Eiffel\-IDE\. \(in fact, no experience\)

---

## Post #22 by @Peter_Gummer1

Bert Verhees wrote:
>> Are you sure that you aren't looking at the W\_code executable?
>
> Yes, I am, should there be another?

The W\_code directory contains EiffelStudio's "workbench" executable \(i\.e\.
the debug executable\)\.

The "finalized" executable, which is what you would distribute to end users,
is in the F\_code directory\.

As well as being about 15% of the size, the finalized executable runs much
faster, especially if you build it with assertions discarded\. When you build
a finalized version, EiffelStudio asks whether you want to keep assertions\.
We normally tell it to discard assertions, because they slow the application
down a lot\.

\- Peter

---

## Post #23 by @system

> Bert Verhees wrote:
>>> Are you sure that you aren't looking at the W\_code executable?
>>
>> Yes, I am, should there be another?
>
> The W\_code directory contains EiffelStudio's "workbench" executable \(i\.e\.
> the debug executable\)\.
>
> The "finalized" executable, which is what you would distribute to end
> users,
> is in the F\_code directory\.

I learn every day, thanks, I take a look tomorrow or day after and let you
know

Bert

---

## Post #24 by @system

Peter Gummer schreef:
> Bert Verhees wrote:
>  
>>> Are you sure that you aren't looking at the W\_code executable?
>>>      
>>
>> Yes, I am, should there be another?
>>    
> The W\_code directory contains EiffelStudio's "workbench" executable \(i\.e\.
> the debug executable\)\.
>
> The "finalized" executable, which is what you would distribute to end users,
> is in the F\_code directory\.
>  

I found it, it is 9Mb, and runs very good\.
If you want a copy I can send it to you \(would be good to have on the
openehr\-website\)

thanks for helping, regards,
Bert

---

## Post #25 by @Peter_Gummer1

Bert Verhees wrote:

>> The "finalized" executable, which is what you would distribute to end
>> users,
>> is in the F\_code directory\.
>>
>
> I found it, it is 9Mb, and runs very good\.

Excellent\!

Do you know whether you told EiffelStudio to discard assertions? I was
expecting it to be 7Mb\. 9Mb is more like the size I see on Windows if I tell
it to keep assertions\.

Linux could be different, of course\.

\- Peter

---

## Post #26 by @system

Peter Gummer schreef:
> Bert Verhees wrote:
>
>>> The "finalized" executable, which is what you would distribute to end
>>> users,
>>> is in the F\_code directory\.
>>>
>>
>> I found it, it is 9Mb, and runs very good\.
>>    
> Excellent\!
>
> Do you know whether you told EiffelStudio to discard assertions? I was
> expecting it to be 7Mb\. 9Mb is more like the size I see on Windows if I tell
> it to keep assertions\.
>  

I checked it again, it is without assertions

Bert

---


**Canonical:** https://discourse.openehr.org/t/ref-impl-eiffel-adlworkbench-in-linux/14681
**Original content:** https://discourse.openehr.org/t/ref-impl-eiffel-adlworkbench-in-linux/14681