Eifflel-Loop & desktop GUI

[Saša Janiška]

Hello,

in recent few days I had nice exchange with Finnian - author of Eiffel-Loop
library consiѕting of many classes useful for Eiffel development.

It looks great, but, as he told me, using of the library would restrict me to
not use ES higher than 16.05.

I plan to start working on multi-platform desktop GUI application, so would
like from Eiffel developers workin on GUI apps whether the quality of
Eiffel-Loop library justifies the price of being restricted to older version of
compiler or is it more advisable to sacrifice Eiffel-Loop library to have
access to new(er) versions of ES compiler?


Sincerely,
Saša

--
As the embodied soul continuously passes, in this body,
from boyhood to youth to old age, the soul similarly passes
into another body at death. A sober person is not bewildered
by such a change.

[Larry Rix]

Sasa,

I highly recommend writing Eiffel-based software using Complete Void Safety and SCOOP. I also highly recommend the Code Analysis tool as a matter of common practice as you write your software.

Below is a selected list (not comprehensive or exhaustive) of new features or updates to ES GUI, Compiler, Libraries, EiffelWeb, and other matters. By being forever locked in to 16.05 means that you not only miss all the improvements since then, but anything that is coming.

The EV library is quite sufficient. Also, if you really like a class (or classes) from EiffelLoop, might I suggest that you copy over the code and recreate what is in EL in something you might call EL-safe.ECF and get the benefits of both worlds.

Kindest regards,

Larry

17.01

- Code templates (new)

- Import settings (new or reworked)

17.05

- ES Inspector tool check for obsolete features and calls

- New Ctrl-Shift-T to restore recently closed tab

- Pick tokens for local variables and arguments

- Improved completion mechanism

- VS 2017 Support for C-compilation on Windows

- Improved object init performance

- Relaxed typing rules for conditional expressions

- Update libs for libpng and zlib

- Update to JSON lib

- Updates to EiffelWeb

- Improvements to ROC CMS

18.01

- Menu/toolbar items for code analysis on class (active editor)

- New X-tool for command line build-and-launch

- ES support for error message filting by free text

- New support for auto-completion of manifest values in paren

- BG colors in error messages can now be customized

- Improved generated docs with filter for HTML style-sheets

- No more VWCE error

- New support for typed manifest arrays

- New support for class post-conditions and instance-free features

- New support for Unicode white space characters

- Control for reporting obsolete features

- Precise location for error messages VIPR(1), VRLE(1), VREG, VRFA

- CHARACTER_PROPERTIES now Unicode 10.0.0, instead of 6.2.0

- Updated cURL lib to 7.56.1

- Updated OpenSSL lib to 1.1.0f

- Now possible to compile with EiffelCurl w/ or w/o dep .dll/.so)

- New OpenSSL Eiffel Wrapper LIbrary

- Many EiffelWeb related

18.07

- Extended code analysis and removed some false-positives

- New JSON string debugger is available

- New icons for class feature (implying minor changes)

- Auto-completion is not triggered anymore for |. or .. cases.

- Many compiler and library updates

18.11

- Many GUI updates

- Many compiler updates

- All container classes are now ITERABLE (can use across)

- Other many library changes

- New SCOOP example

19.05

- Many excellent imporovements worth having

[Larry Rix]

BTW—I happen to like the EL library and have encouraged that it be updated to Void Safety and other matters it is presently deficient in.

[Saša Janiška]

On Thu, 26 Sep 2019 16:44:00 -0700 (PDT)
Larry Rix <lar...@moonshotsoftware.com>
wrote:

Hello Larry,

> I highly recommend writing Eiffel-based software using Complete Void
> Safety and SCOOP. I also highly recommend the Code Analysis tool as a
> matter of common practice as you write your software.

OK.

> Below is a selected list (not comprehensive or exhaustive) of new
> features or updates to ES GUI, Compiler, Libraries, EiffelWeb, and
> other matters. By being forever locked in to 16.05 means that you not
> only miss all the improvements since then, but anything that is
> coming.

Well, that's clear.

> The EV library is quite sufficient. Also, if you really like a class
> (or classes) from EiffelLoop, might I suggest that you copy over the
> code and recreate what is in EL in something you might call
> EL-safe.ECF and get the benefits of both worlds.

In our exchange I mentioned the type of application I'd like to write (see
http://saravali.de/screenshots.html) and I'm told that for that I'd probably
need e.g. Graphic Library: Pango-Cairo 2D Graphics
(http://www.eiffel-loop.com/library/vision2-x.pango_cairo.html).

> BTW—I happen to like the EL library and have encouraged that it be updated to
> Void Safety and other matters it is presently deficient in.

That would be great, indeed!

Another thing I wonder about is if it was considered to e.g. use wxWidgets (or
Qt) library as GUI abstraction for ES since it would provide (almost) native
support and autoamtically bring support for Mac OS (since GTK is not really 2st
class citizen on that platform)?


Sincerely,
Gour

--
Never was there a time when I did not exist,
nor you, nor all these kings; nor in the future
shall any of us cease to be.

[Larry Rix]

1. I cannot speak to Pango-Cairo, but it does appear the EL wraps this library quite extensively. This is another reason it ought to be fully ported into 19.05 (or 19.11 upcoming) so that it gains all of the goodness added to ES GUI, compiler, and libraries since 16.05! The issue is time, resources, motivation, and cost and who has those things to devote.

2. Eiffel on Mac OS is a realm I don't live or operate in with enough knowledge to give good feedback. However, I think all OS platforms would benefit from a wrapping of the Qt library!

I don't have the C/C++ skills sufficient enough to easily handle such a task. If I did, I already would have!

Others with more experience in these matters will hopefully chime in.

I really do wish that EL was updated to 19.05 and beyond! If there is any effort needed in this matter, that's a high priority, as I see it.


Larry

[Larry Rix]

@Finnian

The EL on GitHub needs the EIFGENs removed from the repo. It's painful! :-)

[Saša Janiška]

On Fri, 27 Sep 2019 12:10:50 -0400
Larry Rix <lar...@moonshotsoftware.com>
wrote:

> 1. I cannot speak to Pango-Cairo, but it does appear the EL wraps this
> library quite extensively.

OK. I'll inspect it in more details, although as being total Eiffel noob, there
are probably other areas that I have to tackle before GUI, like binding 3rd
party C lib, writing CLI app etc.

> This is another reason it ought to be fully ported into 19.05 (or 19.11
> upcoming) so that it gains all of the goodness added to ES GUI, compiler, and
> libraries since 16.05!

It definitely looks logical to have support for latest version of compiler and
not beign stuck with few years old one.

> 2. Eiffel on Mac OS is a realm I don't live or operate in with enough
> knowledge to give good feedback.

I also do not have access to Mac OS and Linux is my native platform. Actually,
these days I do not have any maching Windows either - XP was the last one I had
license and did use seldom.

> However, I think all OS platforms would benefit from a wrapping of the Qt
> library!

"(Eiffel) Workers of the world, unite!" :-)

> I don't have the C/C++ skills sufficient enough to easily handle such
> a task.

Same here. If I'd have enough C(++) skills I'd even consider using it for the
app itself, but these days when I plan to do hobby project Eiffel looks as much
more fun and, moreover, C++ did evolve a lot from the days when I used on the
university (Zortech) C++ compiler long ago.

> Others with more experience in these matters will hopefully chime in.

Let's hear...

> I really do wish that EL was updated to 19.05 and beyond! If there is
> any effort needed in this matter, that's a high priority, as I see it.

Yeah, it looks as very useful library providing many things.


Sincerely,
Saša

-
But for one who takes pleasure in the self, whose human life
is one of self-realization, and who is satisfied in the self only,
fully satiated — for him there is no duty.

[Finnian Reilly]

The EL on GitHub needs the EIFGENs removed from the repo. It's painful! :-)

Hi Larry

this was an accident that happened several weeks ago, and has since been corrected. But I double checked in the local and remote copy, and it is still ok.

But thanks for the heads up

regards

Finnian

[Finnian Reilly]

Larry Rix wrote:

By being forever locked in to 16.05 means that you not only miss all the improvements since then, but anything that is coming.

I think this is a bit of an exaggeration. I have previously updated Eiffel-Loop a number of times for the latest compiler, and barring a fatal accident, will do so again in the future.

-- Finnian

[Finnian Reilly]

The EL on GitHub needs the EIFGENs removed from the repo. It's painful! :-)

I have also made sure to remove them from the commit history along with some other rubbish that found it's way in there

All is good again

-- Finnian

[Larry Rix]

RE: "forever locked" — yes, I agree! It's not really forever, but not knowing when in the future deters folks from reusing and that is the thing I'd like to see EL get beyond in the present state-of-affairs of Eiffel et al.

[Larry Rix]

RE: EIFGENs—Excellent! Yep—all I did was to add an appropriate gitignore and everything became manageable once more. :-)

[Larry Rix]

Finnian—You are quite welcome!

BTW—I thought I'd take an hour or two and see if I could bring the EL_base project into 19.05. At first, I thought I was being successful because I was getting errors having to do with Void Safety. BUT—now I think I am beyond those and I am starting to run into just general type conformance problems. They are coming in two really interesting flavors:

1. It appeared that all of the EL_REFLECTED_* classes needed to be creation constrained to "create default_create end", but several of the descendant classes are based on Generics whose class is deferred, which has no creation procedure (obviously)—so it fails.
   
2. There are a number of classes built around KI_CHARACTER_INPUT_STREAM and KI_CHARACTER_OUTPUT_STREAM, where even though the target argument conforms perfectly with the sent object type, the compiler still complains. That's a head scratcher to me. So—in each case, I commented the offending line out and wrapped it in a "check broken_code: False then ...  end" so that it would fail if executed.

I think that all of these are appearing because the compiler is being put into Void Safe mode (transitional in this case) and suddenly a bunch of hitherto-unknown conformance issues are cropping up because now the compiler can see them and complain (rightfully so).

All this leads me to believe that the Void Safety process is working because it is revealing possible type conformance bugs in just the EL_base library. Lord only knows what lies beyond.

This is precisely why this very fine library needs to be brought kicking-and-screaming into 19.05 and beyond so all of the bugs the compiler can reveal will be revealed and dealt with.

ALSO—I noted that you have no testing target or ECF with which to exercise the code and prove that the bugs have been beaten out in these revealed areas. That's not a good thing. I understand it seems like building test code is an "overhead", but at the end of the day, this seems to be a classic case study of "here-is-why-we-test".

Please don't take this as super-critical of your work! NOT AT ALL! You've built a very fine library and I'd love to see it keep up with the rest of the libraries (like GOBO et al)!!!

OH YES—I did note that to get around conflicts with the most recent GOBO, you've done the only thing you can given the state of EL—you made a copy of the last compatible and working version of GOBO that doesn't break EL. One of my chores today was to remove those library-copy-dependencies and switch over to the most recent version of GOBO. There ended up being no issues from the EL point of view except a few Void Safe matters that were quickly handled.

All-in-all—I think you or someone on your team ought to be the one to ultimately tackle this.

WHAT-I-CAN-DO—I have this work in a place where I can create a GitHub project for it (e.g. Eiffel-Loop-safe) and then place my code where it is right now (broken and all) and make it available to you to view and tinker with to see what you think.

Please let me know if you'd like me to do that. I don't want to muddy the repo-waters too much and have folks trying to download copies of this still very broken version of EL_base.


Sincerely,

Larry R

[Larry Rix]

Below are some examples. I am not saying these are the right choices to make, but they are the ones I made given the compiler errors.

The compiler complained about line #30 not having a Generic Parameter. I think this is now being picked up because of Void Safety and the compiler is doing a more comprehensive type checking and conformance checking job?

There were a ton of the following. In 19.05, we can no longer lazy-set features like "count". We must either use the "set_item" call or create an assigner, yes? In this case, the compiler was complaining that "count" as a target could not be directly assigned.

There were several instances where features were referenced in "redefinitions", but did not in fact exist! Again—I think with Void Safety turned on, the compiler is smarter at catching such things.

This is a case where the feature "owner" just does not exist at all! Once again—having the code looked at in 19.05 with Void Safety set to Transitional seems to have revealed this, which is another very serious error!

The following code has two issues:

First—the compiler picked up on the fact that the descendant class did not in fact implement these deferred features (above with the "+").

Second—the missing "then" on the "ensure" is just very odd. I have to wonder why the 16.05 compiler is not picking this one up!

Next is another very bizarre error—the compiler picked up on a repeated inheritance issue between "debug_output" and "to_string". The changed code is most likely incorrect and it is the "to_string" that is desired in repeated inheritance. I did not look back to the parent ancestors to discover the reasoning, all I did was "pick-one" to satisfy the compiler.

The idea I work from is to wrap such "questionable choices" in "check False then ... end" code so that it breaks and then write a test to reveal the broken code so it is not forgotten. This is why I complained about not seeing a test target where I could write just such a test to ensure the bug or change is revealed and corrected.

That's the highlights. I think I will stop now as I am out of my depth at this point. Perhaps some of this will make sense to you!


Larry

[Larry Rix]

FYI—I thought I'd spend a little more time with this and discovered that a lot of the "creation constraint" issues on the REFLECTION classes was might fault—that is—I applied creation constraints where they did not need to be. I am presently down to just two error where the Generic is not conforming. I'll deal with that best I can.

What is encouraging is to see 562 individual errors, concentrated on just a few types of errors: 16 types to be precise. One could hope that this is the end of the line and that resolving those 16 would resolve everything, leaving EL_base in Void Safe.

What appears to be very obvious is that many of these errors have to do with directly inheriting from Eiffel base classes (like HASH_TABLE and so on). Years ago now, we decided against the direct inheritance model and chose to go with wrapper classes precisely for this reason—direct inheritance of many of the base classes results in very complex code and is prone to breaking. We also found that we did not need many of the ancestor features in the descendant, so it was easier to wrap the ancestor, create the specialized features in the descendant and then wrap any ancestor features, exposing them in the descendant as well. BUT—that was a design choice.

[Finnian Reilly]

Hi Larry

many thanks for taking the time to do an assessment of EL for 19.05. I have inserted my comments below.

Finnian—You are quite welcome!

1. It appeared that all of the EL_REFLECTED_* classes needed to be creation constrained to "create default_create end", but several of the descendant classes are based on Generics whose class is deferred, which has no creation procedure (obviously)—so it fails.
   

This reminds me of one very useful class  EL_OBJECT_FACTORY [G]  that I wonder if it will present problems  implementing as void safe code. A typical routine is

instance_from_alias (a_alias: READABLE_STRING_GENERAL; initialize: PROCEDURE [G]): G

which creates an instance from some alias using {REFLECTOR}.new_instance_of and then initializes it with initialize

1. There are a number of classes built around KI_CHARACTER_INPUT_STREAM and KI_CHARACTER_OUTPUT_STREAM,

These are of course GOBO dependencies

1. where even though the target argument conforms perfectly with the sent object type, the compiler still complains. That's a head scratcher to me. So—in each case, I commented the offending line out and wrapped it in a "check broken_code: False then ...  end" so that it would fail if executed.

I think that all of these are appearing because the compiler is being put into Void Safe mode (transitional in this case) and suddenly a bunch of hitherto-unknown conformance issues are cropping up because now the compiler can see them and complain (rightfully so).

I wonder if you have full_class_checking turned on, because usually I leave it off as I find it overly restrictive.

All this leads me to believe that the Void Safety process is working because it is revealing possible type conformance bugs in just the EL_base library. Lord only knows what lies beyond.

This is precisely why this very fine library needs to be brought kicking-and-screaming into 19.05 and beyond so all of the bugs the compiler can reveal will be revealed and dealt with.

ALSO—I noted that you have no testing target or ECF with which to exercise the code and prove that the bugs have been beaten out in these revealed areas.

Testing targets are mostly to be found under project test/test.ecf which has about 40 or so test sets. Some of them may need some maintenance to make them 100% passing.

The reason I keep them there and not in the respective library is because I can use external classes to help with the testing that are outside the target library. Also I like the idea of having a "testing central" where I can browse all the source code in one place.

That's not a good thing. I understand it seems like building test code is an "overhead", but at the end of the day, this seems to be a classic case study of "here-is-why-we-test".

I certainly agree. To develop a class like EL_ZSTRING, would be impossible with a comprehensive set of tests. But sometimes I opt for a just doing simple regression tests, either in test.ecf or some example project such as manage-mp3.ecf.  It has about a dozen CRC-32 regression tests that are manually set by inspecting outputs. I was able to make substantial changes to classes related to EL_PATH and then use regressions to give a reasonable assurance that nothing was broken. Maybe it's a lazy way to do things compared with having a proper test suites, but it does save time.

Please don't take this as super-critical of your work! NOT AT ALL! You've built a very fine library and I'd love to see it keep up with the rest of the libraries (like GOBO et al)!!!

Thank you for your kind words

OH YES—I did note that to get around conflicts with the most recent GOBO, you've done the only thing you can given the state of EL—you made a copy of the last compatible and working version of GOBO that doesn't break EL.

In fact I am just using the GOBO source code that is distributed with ES 16.05. The only thing I did was to make a customized copy of the ECF so I could leave out many classes I didn't need, and harmonize the ECF settings with those used generally in EL.

One of my chores today was to remove those library-copy-dependencies and switch over to the most recent version of GOBO. There ended up being no issues from the EL point of view except a few Void Safe matters that were quickly handled.

All-in-all—I think you or someone on your team ought to be the one to ultimately tackle this.

WHAT-I-CAN-DO—I have this work in a place where I can create a GitHub project for it (e.g. Eiffel-Loop-safe) and then place my code where it is right now (broken and all) and make it available to you to view and tinker with to see what you think.

I was thinking to set up a new project under my github.com account and give you whatever permissions you need to contribute

https://github.com/finnianr/Eiffel-Loop
https://github.com/finnianr/Eiffel-Loop-VS

Please let me know if you'd like me to do that. I don't want to muddy the repo-waters too much and have folks trying to download copies of this still very broken version of EL_base.

I can always put a notice in the readme.md something like

Experimental and transitional repository for void-safe Eiffel-Loop on ES 19.05

For production code use Eiffel-Loop with EiffelStudio 16.05

Thank you Larry for your contributions

Finnian

[Finnian Reilly]

Hi Larry

what you have uncovered is interesting. I have insert my comments

Below are some examples. I am not saying these are the right choices to make, but they are the ones I made given the compiler errors.

The compiler complained about line #30 not having a Generic Parameter. I think this is now being picked up because of Void Safety and the compiler is doing a more comprehensive type checking and conformance checking job?

There were a ton of the following. In 19.05, we can no longer lazy-set features like "count".

My God, assigning a value to an attribute is now considered lazy !!!

We must either use the "set_item" call or create an assigner, yes? In this case, the compiler was complaining that "count" as a target could not be directly assigned.

There were several instances where features were referenced in "redefinitions", but did not in fact exist! Again—I think with Void Safety turned on, the compiler is smarter at catching such things.

This is a case where the feature "owner" just does not exist at all! Once again—having the code looked at in 19.05 with Void Safety set to Transitional seems to have revealed this, which is another very serious error!

in ES 16.05 owner exists in class MUTEX

feature -- Access

  owner: like current_thread_id
   -- Debugging facility to know the THREAD owning Current. The `owner' field might be invalid
   -- when Current is used with a condition variable.

I think what happened here is that the feature once did exist in an ancestor, and then at a later stage I made the feature deferred, but 16.05 considers a redefinition of a deferred feature as harmless.

The following code has two issues:

I am looking at routine item and wondering what on earth is going on because it looks nothing like the code I have

feature -- Access

   item alias "[]", at alias "@" (i: INTEGER): CHARACTER_32 assign put
         -- Unicode character at position `i'
      local
         c: CHARACTER
      do
         c := internal_item (i)
         if c = Unencoded_character then
            Result := unencoded_item (i)
         else
            Result := codec.as_unicode_character (c)
         end
      end

Has github got screwed up or something. I will need to check out a copy of the repository to check.

In the case of prepend_integer etc, they did not exist in STRING_GENERAL in 16.05

First—the compiler picked up on the fact that the descendant class did not in fact implement these deferred features (above with the "+").

Second—the missing "then" on the "ensure" is just very odd. I have to wonder why the 16.05 compiler is not picking this one up!

Next is another very bizarre error—the compiler picked up on a repeated inheritance issue between "debug_output" and "to_string". The changed code is most likely incorrect and it is the "to_string" that is desired in repeated inheritance. I did not look back to the parent ancestors to discover the reasoning, all I did was "pick-one" to satisfy the compiler.

The idea I work from is to wrap such "questionable choices" in "check False then ... end" code so that it breaks and then write a test to reveal the broken code so it is not forgotten. This is why I complained about not seeing a test target where I could write just such a test to ensure the bug or change is revealed and corrected.

See class ZSTRING_TEST_SET in test.ecf

That's the highlights. I think I will stop now as I am out of my depth at this point. Perhaps some of this will make sense to you!

I am a bit alarmed by the source for item. Where did this come from?

regards

Finnian

[Larry Rix]

Hi Finnian!

I have created a new "issue" on the ELS repo in GitHub. I will take any further communication either there, Slack, or to email from here forward.No need to clutter this thread with chatter.

Kindest regards,

Larry