Back in the Saddle

[Larry Rix]

What are immediate community project needs? My house renovation is complete and I am ready to dive headlong into Eiffel tasks.

[williams Lima]

Good day Larry. What about some from https://www.eiffel.org/resources/wish_list

I will soon prepare one from myself!

regards

Williams

[Larry Rix]

Hi Williams!

Thanks for reminding me of this list. The PDF generation library I am working on seems to be in line with the following:

wish# 1026 Additional Classes

Submitter: javier 

Category: Other 

Date: 2015/08/26 

Number: 1026

Status: Open 

Synopsis: Additional Classes 

Description

It would be nice to have classes in the basic eiffel libraries for handling serial port communication, zip compression, encryption, smtp, pop3, ftp, http, TCP/IP, usb, pdf generation, print engine for report writing. I am sure their are others but the basic idea is that it would be nice to have a complete multi-OS tool for developing business applications with quick access to classes needed. Presently you have to search the internet to find some of these classes. It would be nicer to have a more complete library available from within the IDE.

Specifically, "pdf generation" and its follow-on item, "print engine for report writing"

My efforts are focused there at the moment.

[Colin Adams]

Isn't there already PDF generation code in Paul's libraries (I forget the name)?

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

[Larry Rix]

Hi Colin,

I attempted to use the library, but I could not make it work. As I recall, the library was rather stale with external dependencies (I could be wrong).

[Colin Adams]

Here:

https://github.com/safe-eiffel/epdf

[Larry Rix]

Hi Colin,

Yes—that is the library (epdf). The code is 7 to 17 years stale, depends on xace, is pre-void-safe, and has external dependencies and complexities equally stale.

Looking at the PDF specification, it seemed correct that it was just text, which can be generated quite readily. I know this leaves of compression and encryption, but for raw report generation, I did not see these as a blocking requirement for simply generating a report.

Therefore—instead of trying to resurrect epdf from where it presently is, I decided to make an attempt at writing a pure Eiffel PDF generating solution. My first attempt has been a learning curve as well as fraught with errors in design and implementation. However, it was needful to walk that trail to discover and now to regroup and try again based upon what I have learned.

Nevertheless—if anyone knows how to quickly handle the stale code and dependencies, I'd be quite happy to make epdf a "phoenix" project and attempt to raise it from the ashes. :-)

[Larry Rix]

This is the specification I am remembering.

[Anders Persson]

Hi Larry

This project would be interesting for me if you could help Javier and me with.

Hi Larry and Anders,

I've updated the code, to use JSON Serialization API updated HTTP_CLIENT to use DEFAULT_HTTP_CLIENT, so now we can use cURL and EiffelNet.

I've been checking the Selenium site and it seems the JSONWireProtocol is now deprecated https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol  and now they have an RFC https://w3c.github.io/webdriver/

The old code has been moved v0 branch.

So if someone wants to collaborate and review the new RCF  (https://w3c.github.io/webdriver/).

Collaboration is more than welcome.

Vänligen

Anders Persson

BSharp AB

Linked in profile

+46 763 17 23 25

On Wed, 16 Jan 2019 at 05:19, Larry Rix <lar...@moonshotsoftware.com> wrote:

What are immediate community project needs? My house renovation is complete and I am ready to dive headlong into Eiffel tasks.

--

[Gerrit Leder]

Hello Larry,

 

welcome back again and thank you for your offer. I am still struggling to get unit testing working on my Project: the library for non-void safe Project is not working correct, this is a blocker. I can send an Archive of the current source Code to you, I have not checked in anything. Otherwise please see the Compiler error here which states, that test_extension_unsafe.ecf has complete void-safety: s. below

 

Bye

Gerrit

 

Gesendet von Mail für Windows 10

 

-------------------------------------------------------------------------------

 

Error code: VD88

 

Configuration error: a class relies on another class with less strict void safety settings.

What to do: change void safety options so that ancestor or supplier provides higher or equal void safety.

 

Class: TEST_SET_BRIDGE

Void safety: Complete

Configuration: /home/leder/Source/Eiffel/library/test_extension/test_extension_unsafe.ecf

Provider class: PATH

Provider option: Void safety: No

Provider configuration: /home/leder/Eiffel_16.05/library/base/base.ecf

Line: 33

 

->  test_folder: PATH

        -- A path targeted at the `test' folder of current project.

 

-------------------------------------------------------------------------------

--

[Larry Rix]

Hi Anders,

I will contact Javier and see how to coordinate and get back to you.

[Larry Rix]

Hi Gerrit,

Yes—you will need to send me your project in a ZIP file. I am working in Windows 10. Will that be a problem?

[Gerrit Leder]

Hi Larry,

 

unfortunately I am working in bash and therefore I only have gzip: is that OK for you, too?

 

I used this structure:

Source

• Eiffel
• library
• Eiffel-Loop
• test_extension
• pfhp-PF_HP-mt

 

Please extract Archive accordingly…

 

Cheers

Gerrit

 

Gesendet von Mail für Windows 10

 

--

[javier hector]

Hi Larry and Anders

The Eiffel-WebDriver library has been updated to use the latest JSON library and now supports HTTP_CLIENT with Curl and EiffelNet 

Now there is a new RCF  https://w3c.github.io/webdriver/,  

toff.tillman already compare the old protocol and the new one:  

I attached a quick comparison of the JSONWireProtocol and WebDriver API commands from those referenced pages. It seems the WebDriver is mostly a subset of JSONWireProtocol, with a few extensions and new commands. There are also a couple of semantic differences, e.g. size/position vs. rect. 

The document is here 

/Javier

[Larry Rix]

Send me what you have. I will see what I can do.

[Larry Rix]

Javier,

Just to confirm--you have already handled these needs?

[Gerrit Leder]

Yes, I sent you the Project sources attached to the last E-Mail. Please have a look in your spam Folder. They are attached to eiffel-users, too. Both the libraries „Eiffel-Loop“ and „test_extension_unsafe“ are on GitHub:

 

https://github.com/finnianr/eiffel-loop

 

Thank you in Advance and please let me know, if you have further Questions!

 

Gerrit

 

Gesendet von Mail für Windows 10

 

Von: Larry Rix
Gesendet: Donnerstag, 17. Januar 2019 13:38
An: Eiffel Users
Betreff: Re: [eiffel-users] Back in the Saddle

 

Send me what you have. I will see what I can do.

--

[gerrit.leder]

P. S. You need eiffel compiler 16.05 for eiffel-loop library compatibility!

Am Donnerstag, 17. Januar 2019 13:44:21 UTC+1 schrieb gerrit.leder:

Yes, I sent you the Project sources attached to the last E-Mail. Please have a look in your spam Folder. They are attached to eiffel-users, too. Both the libraries „Eiffel-Loop“ and „test_extension_unsafe“ are on GitHub:

 

https://github.com/finnianr/eiffel-loop

 

Thank you in Advance and please let me know, if you have further Questions!

 

Gerrit

 

Gesendet von Mail für Windows 10

 

Von: Larry Rix
Gesendet: Donnerstag, 17. Januar 2019 13:38
An: Eiffel Users
Betreff: Re: [eiffel-users] Back in the Saddle

 

Send me what you have. I will see what I can do.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

[Larry Rix]

Gerrit,

What is in the gz file? I see only one file in it.

[Colin Adams]

A .gz file always has only one file in it. It's a compression format, not an archiving format.

Often that file is a .art archive, which itself may contain many files.

On Thu, 17 Jan 2019 at 14:54, Larry Rix <lar...@moonshotsoftware.com> wrote:

Gerrit,

What is in the gz file? I see only one file in it.

--

[Larry Rix]

7-Zip was able to handle it.

[Larry Rix]

Hi Gerrit,

I am using Eiffel 18.11 and do not know a way for me to install and back up to 16.05.

I get the same error I did before (click link).

There is an override that is resulting in a cURL duplicate class error. I do not know what the override is for and I am unsure how that interacts with versions of the cURL library beyond 16.05. I do not know if the issue that the override is addressing has been resolved in later versions of that library in later versions of Eiffel Studio or not.

What we need to move forward on this is for the Eiffel Loop author(s) to bring EL up to 18.x (preferably v11) and then we can move forward.

[Larry Rix]

Looking further ...

I am looking at these "override" libraries, which are not actual overrides (in the Eiffel Studio ECF definition), but appear to be libraries captured at a particular point in time and perpetuated into the future instead of updating the EL code to work with the newer versions of the "overridden" libraries. If this is the case, then I do not see why anyone would want to use the EL at all in the first place (even leaving off the matter of Void Safety). Someone please help me out here, because I do not have the time nor the inclination or knowledge of the EL to tackle this issue.

My apologies to Finnian and to Gerrit if I am getting something here really wrong.

Perhaps if the "override" references were removed and the code brought up to date with the current libraries, then perhaps EL would be compatible with the code at the 18.x level and we could then handle the Void-safety issues as well and bring EL fully into the flock, yes?

[Gerrit Leder]

OK, thank you for your opinion. I was always using 16.05 and had no luck in moving Eiffel loop to a later compiler version. 😒

Am Do., 17. Jan. 2019, 16:42 hat Larry Rix <lar...@moonshotsoftware.com> geschrieben:

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

[Larry Rix]

Hi Gerrit,

I made an attempt to move just Eiffel Loop Base to 18.11 and ran into a myriad of issues. There appear to be a couple of flavors of error:

1. Compiler-nuance errors—for example: EL_REFLECTED_EXPANDED_FIELD [G], which generates a VDRD(2) error (Redeclaration has non-conforming signature). The quick correction is to add a type constraint to the Generic: EL_REFLECTED_EXPANDED_FIELD [G -> ANY]

2. Staleness errors—for example: EL_STRING_EDITION_HISTORY [S -> STRING_GENERAL create make_empty end], where perhaps STRING_GENERAL at one time was not deferred, but now it is. Because it is deferred, the creation constraint no longer works.

This reminds me of a design choice we made early on in our Eiffel project. We were faced with opting for either an IS-A or HAS-A inheritance relationship. We found many times how direct inheritance (IS-A (type of) relationships) incurred many problems later on. So, we opted to write HAS-A relationship classes, where a class would wrap the class with the needed functionality rather than inheriting from it directly.

The example of EL_STRING_EDITION_HISTORY is a great example of how changes to an underlying library can have very bad consequences in the consumers through an IS-A form of direct inheritance.

Had the EL_STRING_EDITION_HISTORY been constructed as a HAS-A wrapper of STRING_GENERAL, perhaps (but not always) the work to manage the change in STRING_GENERAL would have been more manageable. However, there is no guarantee.

It is regrettable that underlying library changes have this negative impact. It does appear that bring Eiffel Loop to 18.11 and beyond would be a very labor intensive task.

Still—the functional notions contained in Eiffel Loop are quite good and valid. Perhaps the effort ought rather to be to rewrite those functional notions into an Eiffel Loop II and begin again with 18.11 and complete void safety. This does nothing for existing code that is dependent upon EL-1 in 16.05, but it does mean that the goodness of EL could be brought forward to current and future work. Also, it may be that the underlying base and base-ext libraries in ELKS are now sufficiently stable that the IS-A form of inheritance would not be a terrible risk going forward.

All this to communicate that I think the direction of EL is great. It is just regrettable to me that it all got stuck back at 16.05 and was not brought forward together with Eiffel to the current versions and beyond.

Kind regards,

Larry

[Finnian Reilly]

Hi Larry and Gerrit

just a few comments on these migration issues.

I wonder if the compiler errors are because you are trying to compile with full_class_checking =  "true". Usually i leave it as false.

1. Compiler-nuance errors—for example: EL_REFLECTED_EXPANDED_FIELD [G], which generates a VDRD(2) error (Redeclaration has non-conforming signature). The quick correction is to add a type constraint to the Generic: EL_REFLECTED_EXPANDED_FIELD [G -> ANY]

This is strange since every class conform should conform to ANY

2. Staleness errors—for example: EL_STRING_EDITION_HISTORY [S -> STRING_GENERAL create make_empty end], where perhaps STRING_GENERAL at one time was not deferred, but now it is. Because it is deferred, the creation constraint no longer works.

 

This is strange indeed since  STRING_GENERAL has always been deferred

It is regrettable that underlying library changes have this negative impact. It does appear that bring Eiffel Loop to 18.11 and beyond would be a very labor intensive task.

This is precisely why I only upgrade to the latest compiler every 2 or 3 years. These are all the tasks it entails for my situation.

1. Install EiffelStudio for 3 platforms: linux-x86-64, windows and win64
2. Migrate execution argument setup from screenshots for 2 platforms (there is no backup file) across many projects
3. Migrate visual settings for 2 platforms
4. Migrate keyboard shortcuts for 2 platforms
   
5. Migrate external tools configuration for 2 platforms
6. Fix myriad compiler issues
7. Fix ecf files which nearly always have some breaking change
   
8. Fix new bugs in general software that were not there before
   
9. Re-examine all libraries that required over rides to accomplish something special or fix bug to see if the over-ride is still necessary. This could easily be a few days work.
   
10. Fix other random stuff
    

So I think I can be forgiven for keeping Eiffel-Loop stuck on 16.05, but perhaps I might make 2019 the year when I bite the bullet, but I don't wish to commit to anything.

regards

Finnian

 

[Eric Bezault]

On 19/01/2019 19:22, Finnian Reilly wrote:
> It is regrettable that underlying library changes have this negative
> impact. It does appear that bring Eiffel Loop to 18.11 and beyond

> would*be a very labor intensive tas*k.

>
> This is precisely why I only upgrade to the latest compiler every 2 or 3
> years.

Personally, for the Gobo project, I find it easier to upgrade often,
at each EiffelStudio release. If you wait too long as you are doing,
it becomes unmanageable.

And if one wants a library be reused by others, it ought to be
compilable by the version of the compiler that others are using.
That's why the Gobo libraries were a success in the early 2000's:
it's because it was compilable with all (incompatible) Eiffel
compilers available at that time.

Otherwise the library is not reused, it is just used by you.
You are the only user, so you won't get any feedback nor help
for it. Instead, what you get in return is just frustration by
possible users. You tell them all the nice things which are
in the library, but they can't use it.

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

[Larry Rix]

Eric,

I agree fully. Libraries ought to be tested and then upgraded with each new ES release to ensure they can be utilized by the widest audience. One might maintain older versions for those who (for whatever reason) don't or cannot upgrade, but those are the edge cases and outliers and not the norm.

Eiffel Loop has a lot of great stuff that truly needs to find its way into ES 18.11 and beyond.

[Gerrit Leder]

Hello Eric, Larry and Finnian,

 

so what do we do now? I would love to see my Project running again!

@Larry you write the library should be tested with the new ES release:

I have some experience with JUnit and NUnit. But I am still struggling with your unit test structure. Do you have an example for me?

 

Thank you all!

 

Gerrit

 

Gesendet von Mail für Windows 10

 

Von: Larry Rix
Gesendet: Sonntag, 20. Januar 2019 00:21
An: Eiffel Users
Cc: Finnian Reilly
Betreff: Re: [eiffel-users] Back in the Saddle

 

Eric,

 

I agree fully. Libraries ought to be tested and then upgraded with each new ES release to ensure they can be utilized by the widest audience. One might maintain older versions for those who (for whatever reason) don't or cannot upgrade, but those are the edge cases and outliers and not the norm.

Eiffel Loop has a lot of great stuff that truly needs to find its way into ES 18.11 and beyond.

--

[Larry Rix]

Hi Gerrit,

The way I have learned to configure the ECF targets is not standard. If I were in your shoes, I would put my attention on how Auto Test sets itself up by default in your project and just go with that. What my learned configuration is really about is segregating the testing bits from the production or library bits. However, this is not necessary. Again—given your 16.05 situation, I recommend you use the default configuration that Auto Test does automatically (even in 16.05).

[Gerrit Leder]

Hi Larry,

 

this is what I am used to do in a Maven/JUnit4 or .NET core/NUnit Project: separate the Tests from the production or library. Everything else would be a pain!

 

G.

 

Gesendet von Mail für Windows 10

 

Von: Larry Rix
Gesendet: Sonntag, 20. Januar 2019 14:35
An: Gerrit Leder
Cc: eiffel...@googlegroups.com; Finnian Reilly; er...@gobosoft.com
Betreff: Re: [eiffel-users] Back in the Saddle

 

Hi Gerrit,

 

[Larry Rix]

Please let me assure you that in Eiffel, such a thing is far from and certainly NOT a painful experience!

We simply set it up that way for convenience and because we were (and are) "neat freaks" (perfectionists or whatever :-) )!

Just allow Auto Test to do its own thing.

I would like others to weigh in, but I am going to create a new Post (Thread) here for that purpose and not continue to clutter this thread. You are probably not the only one who will need this information in the future, so we will isolate it to another thread that I will start now.