Base Ext2

[lrix]

A library where I am capturing new array and string features based on inspiration from Python.

https://github.com/ljr1981/base_ext2

[lrix]

BTW/FYI -- The {TUPLE}.arrayed and {TUPLE}.item being "detachable separate ANY" is a royal pain in the backside! It makes what ought to be simple exchanges between ARRAY and TUPLE turn into a hot-mess of conversion code (see the library).

[Finnian Reilly]

Class ZSTRING in Eiffel-Loop also has some features inspired by Python. Most notably is the tuple substitution operator #$ which functions like the Python % operator for Python tuples: Eg. print "%s = \"%s\"" % ('a', 1)

This sample code is from the class EL_SOFTWARE_VERSION. The list.joined ('.') line might also be familiar to Pythonistas.

The code for the #$ operator is found in the ancestor class EL_CONVERTABLE_ZSTRING

Also inspired by Python is the String translate ()  which is found in the ancestor class EL_TRANSFORMABLE_ZSTRING

    translate (old_characters, new_characters: EL_READABLE_ZSTRING)
        do
            translate_deleting_null_characters (old_characters, new_characters, False)
        end

    translate_deleting_null_characters (old_characters, new_characters: EL_READABLE_ZSTRING; delete_null: BOOLEAN)
        -- substitute characters occurring in `old_characters' with character
        -- at same position in `new_characters'. If `delete_null' is true, remove any characters
        -- corresponding to null value '%U'
        require
            each_old_has_new: old_characters.count = new_characters.count
        local

-- Finnian

[Finnian Reilly]

Incidentally lately I have further optimized ZSTRING and the benchmarks now compare very favorably to STRING_32 with many operations performing faster or only marginally slower, depending on the characters being used. In all cases there is a hugh memory saving which is the whole raison d'etre of ZSTRING. The fastest performance happens when the characters coincide with the Latin or Windows character set nominated as the base set (Latin-15 by default, but you can set any character set as the base). Characters are augmented by Unicode on the fly when required but then the performance slows down somewhat, but still within 10% of STRING_32 in most cases, or in some cases faster than STRING_32.

BENCHMARKS

Comparison of ZSTRING against STRING_32 for basic string operations

• Latin-1 base encoding
• Latin-15 base encoding

[Finnian Reilly]

Regarding ARRAY_COMPARABLE [G -> HASHABLE]

I am not sure I understand why you would want to sort things by hash code. Can you give a use case for this please.

Incidentally you can achieve this with routine `order_by' from the EL_ARRAYED_LIST class in Eiffel-Loop

feature -- Reorder items

    order_by (sort_value: FUNCTION [G, COMPARABLE]; in_ascending_order: BOOLEAN)
        local
            l_item: like item; comparison: BOOLEAN
        do
            if not off then
                l_item := item
            end
            make_from_array (ordered_by (sort_value, in_ascending_order).to_array)
            if attached l_item then
                comparison := object_comparison
                compare_references
                start; search (l_item)
                object_comparison := comparison
            end
        end

The routine `ordered_by' is found in the ancestor class EL_CHAIN

SORTING BY HASH CODE EXAMPLE
    local
        list: EL_ARRAYED_LIST [STRING]
    do
        create list.make_from_array (<< "cat", "dog" >>)
        list.order_by (agent {STRING}.hash_code, True) -- order by hash code in ascending order
    end
   

On Saturday, 13 February 2021 at 17:10:42 UTC lrix wrote:

[lrix]

HI Finnian!

All of this is really great. However, have you had any success at all in making Eiffel-loop Void-safe and SCOOP-friendly?

Kindest regards,

Larry

[lrix]

I have spent another hour-plus this morning trying to isolate even a small part of Eiffel-loop to where I can get it to compile in a version of Eiffel Studio beyond 16.05. I have once again failed. I would love to use some of this lovely and well-crafted code you have created, but asking me (any of us) to hang back with 16.05 and ignore the bug-fixes and excellent changes applied to 20.11 and beyond is just unthinkable. I am really sorry and sad that you did not take the time when Void-safety came along to handle that matter and then also with SCOOP. Personally, I have grown so dependent on Void-safety from the compiler that it is unthinkable to return to a non-void-safe environment. It is high time to tear down Eiffel-loop to nothing and start building it back, class-by-class in a Void-safe project, handling the issues one class at a time. Otherwise, suggesting Eiffel-loop to me will simply fall on deaf ears. This makes me really really sad to have to say it to you because the code you've written is just rotting and going to waste.

[Finnian Reilly]

Hi Larry,

All of this is really great. However, have you had any success at all in making Eiffel-loop Void-safe and SCOOP-friendly?

Unfortunately not, but if enough people are interested to sponsor this gargantuan task here is my offer:

I am willing to undertake the task for € 24.00 EUR/hour (USD $29 or GBP £21).

Sponsors get to vote which libraries are attended to first but Eiffel-Loop base.ecf is a good place to start.

Eiffel-Loop currently clocks in at 2985 classes containing 641006 words* of code. Total size: 6.3 mb.

* Code words include keywords, identifier words and quoted strings, but exclude comments and indexing notes.

Other good stuff

Other good stuff that has been happening in Eiffel-Loop lately

Eco-DB.ecf

This powerful reflective object database system has been further enhanced

• CRC checksums on data structures to protect data integrity against accidental field changes or ordering
• Automatic export of data structure
  
• Automatic import/export to Pyxis plaintext format as way to have a bullet proof backup in the unlikely event of data corruption. (Trivial conversion to XML)
• Pyxis parser BTW has been optimized for massive performance increase X 10.
• Convenient way to enhance the reflective system with support for reading/writing miscellaneous reference types. INTEGER_X for example (new_reader_writer_interfaces)

TESTING

Testing has got a lot more organized in 2020 with full migration to EQA test sets grouped by library. Most importantly they are designed to be run as both as workbench and finalized code. Many finalized bugs can go undetected without this approach.

Best regards

Finnian

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/531fe961-d5e5-4c37-8578-5b5c97186e0en%40googlegroups.com.

-- 
SmartDevelopersUseUnderScoresInTheirIdentifiersBecause_it_is_much_easier_to_read

[Finnian Reilly]

Dear Larry

my apologies again for confusing with someone called "Irix". Silly me!

I have spent another hour-plus this morning trying to isolate even a small part of Eiffel-loop to where I can get it to compile in a version of Eiffel Studio beyond 16.05. I have once again failed.

I have an idea! Since you have honored me already with making some attempts to migrate Eiffel-Loop I have an idea to make it less frustrating. I will create a tool for you that will facilitate the process. The problem seems to be that you are being overwhelmed with thousands of errors so this relatively simple tool will ease the task for you by reducing the number of classes to deal with at any one time time. Here is how it will work

The tool will accept as an argument two directories. The first is a source directory within the Eiffel-Loop codebase. The second is the home directory for a new Eiffel-Loop-20.11 (as a reference to current EiffelStudio version)

For example:

  el_eiffel -class_dependency_layer -source $HOME/Eiffel/libraries/Eiffel-Loop/library/base -output $HOME/Eiffel/libraries/Eiffel-Loop-20.11

The tool will read all the classes for the source tree, and identify all the classes that only depend on classes in ISE libraries, it will then copy this layer of classes into the output, recreating the directory structure of the original. The program will then pause with a user prompt

Hit <return> top copy the next layer: 

You can then proceed to get this first layer of classes in the output to compile. When finished you hit return to copy the next layer of dependencies, and I think you can see where this is going. The next layer is only those classes which only depend on ISE libraries and those classes already copied in the first layer. It's a recursive program which exits when all the classes have been copied to the output.

Or the tool can even be made more granular and only copy one class at a time, between prompts.

Let me know if you like this idea and what platform you are using I will make this tool for you. Should only be a days work at most to make something like that.

best regards

Finnian

-- 
SmartDevelopersUseUnderScoresInTheirIdentifiersBecause_it_is_much_easier_to_read

[Finnian Reilly]

More thoughts

Or the tool can even be made more granular and only copy one class at a time, between prompts.

Or the tool can be easily  made to create a tabular menu of all the classes in the current dependency layer, and lets you choose which one you want to work on next, perhaps by first letting you inspect the class in a text editor and then choose whether to copy that class or not.

-- 
SmartDevelopersUseUnderScoresInTheirIdentifiersBecause_it_is_much_easier_to_read

[Finnian Reilly]

Dear Larry

I have spent another hour-plus this morning trying to isolate even a small part of Eiffel-loop to where I can get it to compile in a version of Eiffel Studio beyond 16.05. I have once again failed.

Sorry you experienced this frustration. It might be easier with a tool such as I have suggested to make for you.

I would love to use some of this lovely and well-crafted code you have created, but asking me (any of us) to hang back with 16.05 and ignore the bug-fixes and excellent changes applied to 20.11 and beyond is just unthinkable.

I do not expect people to hang back with 16.05 but regardless Eiffel-Loop is still there as a source of ideas and code to work with to make new libraries that work with latest compiler. I guarantee you it is still faster to spend time migrating Eiffel-Loop code then to start again from scratch. Most of these classes have gone through many design iterations and refinement over many years.

I am really sorry and sad that you did not take the time when Void-safety

I have been programming with Eiffel since 2000, long before Void-safety came into vogue, and my lived experience is that calls on void references are hardly ever an issue for me, in other words extremely rare. So why make a hugh effort to prevent something that hardly ever happens. Makes no sense to me unless you a designing for the nuclear/aero industry and need to offer better guarantees. In that case it is worth the extra trouble (and ugly code) because this industry pays handsomely.

came along to handle that matter and then also with SCOOP.

SCOOP took a long time to evolve to being mature, and in the mean time I got very good at using the traditional thread model and created many classes to make it more error proof. It is still a very unknown quantity how well and quickly I can learn SCOOP and make it bend to my will. It looks to me at least as difficult to learn as classic threads augmented by wrapper classes.

Personally, I have grown so dependent on Void-safety from the compiler that it is unthinkable to return to a non-void-safe environment.

So prior to that, you frequently had problems with calls on void references. I find that interesting.

It is high time to tear down Eiffel-loop to nothing and start building it back, class-by-class in a Void-safe project, handling the issues one class at a time.

If people are willing to pay for that to happen, (see my other post) I am more than willing to do it. but I have too many other things (besides programming) I want to do with my life to do it for free.

Otherwise, suggesting Eiffel-loop to me will simply fall on deaf ears.

Regardless of whether is compiles on the latest compiler, it still exists as a source of idea and could be worth spending the time to migrate when compared with how much effort it would take to develop the classes again from scratch.

This makes me really really sad to have to say it to you because the code you've written is just rotting and going to waste.

Actually it's not rotting, it's constantly being maintained, expanded, improved upon, documented and tested. Go look at my github commits chart.

But I do admit it is going to waste in that more people do not use it. It doesn't make me sad, it's just a fact. I feel proud of what i have achieved with 15+ years work. And even if nobody else has a use for it, I have a use for it and I have learned a lot  by creating it.

regards

--Finnian

[lrix]

Dear Finnian!

All of what you have stated is largely true. 15-plus years of coding effort is excellent and worthwhile. It really needs to be usable to 20.11 and beyond.

Given all of this, there is a possible dove-tail. There is a consideration out there to make a pitch to possible clients where if they take Eiffel Studio on in their paid/commercial project, then that opens the gate to paying you (and perhaps a team with you) to get Eiffel-loop 100% Void-safe and SCOOP-compliant.

Everyone here is starving for work or working for very little or even for nothing. The pool of money is simply very very small. Anyone who gets a part of that feels very grateful for it. However, that doesn't change the facts that there is not enough money (that I can see) to respond with a "Yes" to your offer (in and of myself--I cannot speak for others).

HOWEVER--I think what that really means for you (as a suggestion) is to come up with a conversion plan and estimate of ball-park cost for such a modernization and upgrade to Eiffel-loop. You are the only one who has the knowledge to know what that scope of work is. Once you have a ballpark estimate (being very very realistic--aka--take your best estimate and multiply it by 4-5 times in both time and money)--once you have this, then that value of Eiffel-loop can be shopped out as a potential tool in the toolbox. The net result of that will be taking the lovely and excellent code you have built and perhaps turning it into a an a-la-carte paid library if not just flat out free (open source).

Whatever those details work out to be, the reality of it seems very clear. What is needed is a real ballpark estimate of the cost of conversion and what value is there that is not already present in the base Eiffel libraries and GOBO libraries.


Kindest regards,

Larry