liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Liberty-eiffel Digest, Vol 54, Issue 1


From: Hans Zwakenberg
Subject: Re: Liberty-eiffel Digest, Vol 54, Issue 1
Date: Thu, 3 Mar 2022 09:15:12 +0100 (CET)

Hi Paolo,

thank you for your effort.  So you hit a brick wall of sorts...   I reckon that 
- before you commit changes of this magnitude - it would be a good idea to use 
EiffelTest at your site before committing anything to the repository.
I can see why you would want to have this implemented in Eiffel only, if only 
to ease bug hunting.
On the other side, Cyril has done a lot to implement thread-local storage (TLS) 
on the C-side.  I'll have a look to see whether this can be used in the 
C-runtime for deep_twin as well. Perhaps we'll end up with a thread-safe 
deep_twin() that way.

cheers
Hans

> liberty-eiffel-request@gnu.org hat am 02.03.2022 18:00 geschrieben:
> 
>  
> Send Liberty-eiffel mailing list submissions to
>       liberty-eiffel@gnu.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.gnu.org/mailman/listinfo/liberty-eiffel
> or, via email, send a message with subject or body 'help' to
>       liberty-eiffel-request@gnu.org
> 
> You can reach the person managing the list at
>       liberty-eiffel-owner@gnu.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Liberty-eiffel digest..."
> 
> 
> Today's Topics:
> 
>    1. Deep twin in pure Eiffel (Paolo Redælli)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 2 Mar 2022 11:11:37 +0100
> From: Paolo Redælli <paolo.redaelli@gmail.com>
> To: liberty-eiffel mailing list <liberty-eiffel@gnu.org>
> Subject: Deep twin in pure Eiffel
> Message-ID: <b63ba9de-fa49-065d-31bc-09b63990bbc1@gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> I've dived in the deep ocean of deep twinning... discovering huge monsters.
> 
> As I wrote to Hans some weeks ago, in the beginning of SmallEiffel 
> deep_twin has been implemented in the runtime because the compiler 
> lacked the required object introspection support required to implement 
> deep twinning in pure Eiffel.
> 
> I think that the thinner the runtime the better for at least a couple of 
> reasons.
> 
> Firstly because the more Eiffel the better... some runtime of course 
> will be always be necessary, but I'd rather hunt bugs in Eiffel than in 
> C. For example deep_twin in the runtime uses static variables and this 
> requires a redesign to achieve thread-safety. I'm sure my threading 
> abilities is too weak to hung bugs across the boundaries of two languages.
> 
> Then there's an old dream of mine, i.e. having other backends beside C. 
> Today the world see widespread usage of Javascript and WebAssembly, JVM 
> is being used by several languages beside Java like, Scala, Kotlin and 
> so on. There is another reason to thin-out the C runtime: GCC has been 
> offering libgccjit, an API for embedding GCC inside programs (see 
> https://gcc.gnu.org/wiki/JIT and https://gcc.gnu.org/onlinedocs/jit/ ) 
> for a while and we may use it to turn  LibertyEiffel into a "proper" 
> compiler as libgccjut "can also be used for ahead-of-time code 
> generation, for building standalone compilers (so the "jit" part of the 
> name is now something of a misnomer)".
> 
> I also shall describe the "monsters" I encountered....
> 
> Monsters like making this little change in ANY:
> 
>      deep_clone: like Current
> 
>          do
> 
>              clone(create {HASHED_DICTIONARY[ANY,POINTER])
> 
>          end
> 
> feature {} -- Deep twin implementation
> 
>      clone(already_done: HASHED_DICTIONARY[ANY,POINTER])
> 
>      do
> 
>          .... something innocent....
> 
>      end
> 
> 
> an "innocent" change that triggers something into short so that even 
> those addition made "short ANY" explode. I had to kill it after having 
> allocated 4-5Gb of memory.
> 
> Then I moved the login into the ad-hoc class DEEP_TWINNER, implemented 
> it in the most "reasonable" way, i.e. using recursion, but recursion 
> coupled with internals triggers an obscure bug in the compiler which 
> does not update the calling stack.
> 
> I know that I should have armed myself with the sword of bug solving, 
> but I must confess that I don't know the forest of the compiler enough 
> to dwelve it in a bug hunt.
> 
> I'm created a branch in my repository called "deep-twin-in-pure-eiffel". 
> Do you think I can push it in the main repository before I have a viable 
> demo?
> 
> Thanks in advance for your time and efforts,
> 
>      Paolo
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <https://lists.gnu.org/archive/html/liberty-eiffel/attachments/20220302/ef4978dd/attachment.htm>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Liberty-eiffel mailing list
> Liberty-eiffel@gnu.org
> https://lists.gnu.org/mailman/listinfo/liberty-eiffel
> 
> 
> ------------------------------
> 
> End of Liberty-eiffel Digest, Vol 54, Issue 1
> *********************************************



reply via email to

[Prev in Thread] Current Thread [Next in Thread]