Info: Users of Eiffel Graph library from Eiffel Software

[Jocelyn.Fiat.ES]

Hi all,

At EiffelSoftware, we are thinking about modifying the Eiffel Graph library.

For now, mainly to separate the XML import/export functionalities from
the Graph library.
This would break existing code, but the "migration" should be easy
(mostly a matter of moving code from the figure's class, to a new
visitor's class)

So prior to make any work, and any change on this library, we would like
to know who is using Eiffel Graph?
Any active project based on Eiffel Graph?

Please tell us, since we don't want to break any application based on
Eiffel Graph.
And according to your usage, we will see what we can do.
(in any case, if we do something, this will happen after the 6.5 release)

Thanks for any feedback,

--
Jocelyn
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  

[Jocelyn.Fiat.ES]

Hi Eiffel users,

It seems that no one is actively using the Eiffel Graph  (figure, world,
..., diagram) library.
So any change in the interface related to XML export/import should not
break any user code.

The change will not occur tomorrow, but more likely after the next
release (6.5).
In the meantime, if you realize this might break your code, please let
EiffelSoftware know.

Kind regards,
--Jocelyn

Jocelyn Fiat [ES] wrote:

> Hi all,
>
> At EiffelSoftware, we are thinking about modifying the Eiffel Graph library.
>
> For now, mainly to separate the XML import/export functionalities from
> the Graph library.
> This would break existing code, but the "migration" should be easy
> (mostly a matter of moving code from the figure's class, to a new
> visitor's class)
>
> So prior to make any work, and any change on this library, we would like
> to know who is using Eiffel Graph?
> Any active project based on Eiffel Graph?
>
> Please tell us, since we don't want to break any application based on
> Eiffel Graph.
> And according to your usage, we will see what we can do.
> (in any case, if we do something, this will happen after the 6.5 release)
>
> Thanks for any feedback,
>
>  

--
Jocelyn
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  

[peter7723]

The question prompts me to ask, precisely, what purposes are ditingished by Eiffel Vision 2 Figures (EV_FIGURE and friends) and Eiffel Vision 2 Model (EV_MODEL and friends)?

Similarly, what about EG_GRAPH and friends?

Peter Horan

[Emmanuel Stapf]

> The question prompts me to ask, precisely, what purposes are ditingished
> by Eiffel Vision 2 Figures (EV_FIGURE and friends) and Eiffel Vision 2
> Model (EV_MODEL and friends)?

There were some shortcomings in EV_FIGURE classes, and in order to solve them it
required some API changes. With EV_MODEL, you can translate and rotate most
figures or group of figures which was not the case with EV_FIGURE. We kept both as
they were users of EV_FIGURE and we did not want them to be penalized if we were
to remove those classes.
 
> Similarly, what about EG_GRAPH and friends?

EG_GRAPH is a library to draw graphs based on the EV_MODEL classes which is
equipped with physics support for force-directed graph. This is the library behind
EiffelStudio's diagram tool.

Regards,
Manu

[peter7723]

Interesting. I don't recall the difficulty rotating and translating with EV_FIGURE classes.

I wrote a program using EV_FIGURE six years ago which animated a cycloidal crank - a circle of diameter D, rotating without slipping inside a circle of diameter 2D. The locus of motion of all points on the circumference of the small circle are straight lines which are diameters of the large circle.

The small circle was rotated and translated as a group as I recall. It was build out of four pieces of "pie" of different colours.

I compiled it just now without error, but when I executed it, a Catcall was detected. The option "Catcall detection (experimental)" was False. Detection was a surprise. Why was it detected?

The error message was "Catcall detected for  argument#1 `args': expected  TUPLE [EV_FIGURE_ELLIPSE] but got TUPLE [EV_FIGURE]"

Peter Horan

[peter7723]

Not thinking straight.

The Catcall detection applies to compile time, of course. I'll have to check the code. But the catcall cropped up in EV_DRAWING_AREA_PROJECTOR.

Peter Horan

[Emmanuel Stapf]

> Interesting. I don't recall the difficulty rotating and translating with
> EV_FIGURE classes.

In EV_FIGURE there is not features to do those operations. The only way you can
achieve that was most likely to change the projector or to create the figures with
the right coordinates to start with.

In EV_MODEL, you can do scaling, rotation, transform for most figures out of the
box.
 
> I compiled it just now without error, but when I executed it, a Catcall
> was detected. The option "Catcall detection (experimental)" was False.
> Detection was a surprise. Why was it detected?
>
> The error message was "Catcall detected for  argument#1 `args': expected
> TUPLE [EV_FIGURE_ELLIPSE] but got TUPLE [EV_FIGURE]"

Do you mind sharing the code with everyone? It would be nice to have it available
for new users. As for the catcall, I believe we fixed that in the latest 6.5, can
you give it a try?

Thanks,
Manu

[Peter Horan]

Do you mind sharing the code with everyone? It would be nice to have it available
for new users. As for the catcall, I believe we fixed that in the latest 6.5, can
you give it a try?

I'll install 6.5 and see how it compiles.

The original code is non-void safe, so do I compile it straight or in experimental mode?
--
Peter Horan             Faculty of Science and Technology
[hidden email]     Deakin University
[phone] (Voice) Geelong, Victoria 3217, AUSTRALIA
[phone] (Mobile)

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

[Emmanuel Stapf]

> The original code is non-void safe, so do I compile it straight or in
> experimental mode?

If it compiles out of the box in normal or experimental then it does not matter,
the code should run the same way. The experimental mode matters only if you want
to make your code void-safe. Of course ideally it would be nice to have your code
void-safe but that's not a requirement.

Regards,
Manu

[Peter Horan]

Manu wrote:
>> Do you mind sharing the code with everyone? It would be nice to have it available
>> for new users. As for the catcall, I believe we fixed that in the latest 6.5, can
>> you give it a try?

I wrote:
> I'll install 6.5 and see how it compiles.

Using Eiffel 6.5, not in experimental mode, I still get the cat-call(s) like "Catcall detected for  argument#1 `args': expected  TUPLE [EV_FIGURE_PIE_SLICE] but got TUPLE [EV_FIGURE]".

Can I ask the compiler to turn off catcall detection? The finalised code works fine.
--
Peter Horan             Faculty of Science and Technology
[hidden email]     Deakin University
[phone] (Voice) Geelong, Victoria 3217, AUSTRALIA
[phone] (Mobile)

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

[Emmanuel Stapf]

> Using Eiffel 6.5, not in experimental mode, I still get the cat-call(s)
> like "Catcall detected for  argument#1 `args': expected  TUPLE
> [EV_FIGURE_PIE_SLICE] but got TUPLE [EV_FIGURE]".

Most likely it is only fixed in the experimental mode. Can you try and if this is
still happen send a bug report with the full callstack trace?
 
> Can I ask the compiler to turn off catcall detection? The finalised code
> works fine.

In workbench mode they are always displayed when running out of EiffelStudio. From
EiffelStudio you can disable them from the "Execution" menu.

Regards,
Manu

[Peter Horan]

> Most likely it is only fixed in the experimental mode. Can you try
> and if this is still happen send a bug report with the full
> callstack trace?

Compiling in experimental mode gives two VCCH errors and three Obsolete class warnings.

A global search shows that I do not use EV_CURSOR or EV_POINTER_STYLE in my code. Ditto for EV_MULTI_COLUMN_LIST

In the following, I have removed the duplicated text:
===============================
Error code: VCCH(1)

Error: class has deferred feature(s), but is not declared as deferred.  
What to do: make feature(s) effective, or include `deferred' before
  `class' in Class_header.  

Class: EV_POINTER_STYLE
Deferred feature: create_interface_objects From: EV_ANY

The second VCCH error refers to:
Class: EV_MULTI_COLUMN_LIST_ROW_IMP
Deferred feature: old_make From: EV_ANY_I
================================
Warning code: Obsolete Class

Warning: type relies on obsolete class.
What to do: update to new class at your earliest convenience. The
  class is still available but may be removed in the future.

Class: EV_POINTER_STYLE
Feature: make_with_cursor
Obsolete class: EV_CURSOR
Obsolete message: [090630] Use EV_POINTER_STYLE instead

Class: EV_POINTER_STYLE_I
Feature: init_from_cursor
Obsolete class: EV_CURSOR
Obsolete message: [090630] Use EV_POINTER_STYLE instead

Class: EV_POINTER_STYLE_IMP
Feature: init_from_cursor
Obsolete class: EV_CURSOR
Obsolete message: [090630] Use EV_POINTER_STYLE instead
--
Peter Horan             Faculty of Science and Technology
[hidden email]     Deakin University
[phone] (Voice) Geelong, Victoria 3217, AUSTRALIA
[phone] (Mobile)

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

[Peter Horan]

I did not receive any response to this query.

I wrote:
> Using Eiffel 6.5, not in experimental mode, I still get the cat-call(s)
> like "Catcall detected for argument#1 `args': expected TUPLE
> [EV_FIGURE_PIE_SLICE] but got TUPLE [EV_FIGURE]".

Manu suggested:

> Most likely it is only fixed in the experimental mode. Can you try
> and if this is still happen send a bug report with the full
> callstack trace?

I did this and replied:

> Compiling in experimental mode gives two VCCH errors and three
> Obsolete class warnings.
>
> A global search shows that I do not use EV_CURSOR or
> EV_POINTER_STYLE in my code. Ditto for EV_MULTI_COLUMN_LIST
>
> In the following, I have removed the duplicated (boilerplate) text:
> ===============================
> Error code: VCCH(1)
>
> Error: class has deferred feature(s), but is not declared as deferred.
> What to do: make feature(s) effective, or include `deferred' before
> `class' in Class_header.
>
> Class: EV_POINTER_STYLE
> Deferred feature: create_interface_objects From: EV_ANY
>
> The second VCCH error refers to:
> Class: EV_MULTI_COLUMN_LIST_ROW_IMP
> Deferred feature: old_make From: EV_ANY_I
> ================================
> Warning code: Obsolete Class
>
> Warning: type relies on obsolete class.
> What to do: update to new class at your earliest convenience. The
> class is still available but may be removed in the future.
>
> Class: EV_POINTER_STYLE
> Feature: make_with_cursor
> Obsolete class: EV_CURSOR
> Obsolete message: [090630] Use EV_POINTER_STYLE instead
>
> Class: EV_POINTER_STYLE_I
> Feature: init_from_cursor
> Obsolete class: EV_CURSOR
> Obsolete message: [090630] Use EV_POINTER_STYLE instead
>
> Class: EV_POINTER_STYLE_IMP
> Feature: init_from_cursor
> Obsolete class: EV_CURSOR
> Obsolete message: [090630] Use EV_POINTER_STYLE instead
>

--
Peter Horan             Faculty of Science and Technology
[hidden email]     Deakin University
[phone] (Voice) Geelong, Victoria 3217, AUSTRALIA
[phone] (Mobile)

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)

[Emmanuel Stapf]

> Compiling in experimental mode gives two VCCH errors and three Obsolete
> class warnings.

You should not get any VCCH errors. Looking at the errors it seems that you must
be referencing the wrong EiffelVision2 library or not compiling with the latest
6.5 release. It should be `$ISE_LIBRARY/library/vision2/vision2.ecf'.

As for the obsolete it is because now we are forcing the display of warnings even
in our own library.

Regards,
Manu

[Peter Horan]

Manu wrote:
> You should not get any VCCH errors. Looking at the errors it seems that you
> must be referencing the wrong EiffelVision2 library or not compiling with
> the latest 6.5 release. It should be `$ISE_LIBRARY/library/vision2/vision2.ecf'.

All is as required.

I suspect that a non-experimental compile intervened. (E.g. delete EIFGENs and then double-click on the .ecf file would do it).

When I do that, the project compiles with 6.5 and then gives the VCCH errors. Switching to 6.5 experimental, the compiler asks the question about changing the library reference, but it picks up the old compile. If I force it to do a clean, the changeover works. It is a minor problem which will go away with "experiment" mode, but you may want to fix it for the short term.

I have put the code on http://softmodels.com.au (don't forget the .au or you will find yourself somewhere unexpected).

> As for the obsolete it is because now we are forcing the display of warnings even
> in our own library.

Interesting to know. I can live with that.
--
Peter Horan             Faculty of Science and Technology
[hidden email]     Deakin University
[phone] (Voice) Geelong, Victoria 3217, AUSTRALIA
[phone] (Mobile)

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)