[Top][All Lists]

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

Re: [Liberty-eiffel] Liberty-eiffel Digest, Vol 4, Issue 1

From: Raphael Mack
Subject: Re: [Liberty-eiffel] Liberty-eiffel Digest, Vol 4, Issue 1
Date: Sun, 15 Sep 2013 22:00:55 +0200

Hi there,

thanks Cyril for the clear vision to have a first release soon. I think
it is very important to have this first release soon and I do not care
too much about tcc support in this first release. Having one C compiler
working on windows out of the box looks already quite good for me. We
need to show liveness out there not win the next olympic games with our
first sign of life ;-)

Am Samstag, den 14.09.2013, 16:26 +0200 schrieb Cyril ADRIAN: 
> 2013/9/14 H. Zwakenberg | Ocean Consulting GmbH
> <address@hidden>
>         indeed, I'm working on Windows, but within the timeframe Cyril
>         references, I will not be able (due to available time) to get
>         TCC working.  Since we have Pelles-C working now, I _might_ be
>         able to get the proper configuration to use Pelles-C with
>         Liberty nailed down in time.  TCC support would be part of a
>         release after the first release.  This is solid marketing, we
>         would have a reason to release 'a next' release sooner by
>         treating TCC support separately.

I have nothing to add to Cyril's words about this topic. 

>         Another of my many questions:  would we also be able to (one
>         day) include a toolchain for the ARM line of processors?
>         These processors are used in most any mobile device and seem
>         to be making inroads in realtime embedded areas as well.
>         Likely, Raphael is best positioned to comment on this personal
>         observation...

Actually we already do. It works "out of the box" with cross gcc. It is
nothing more than adding a c mode which uses the cross-toolchain. Of
course there could be many nice gimmicks, but for now I think the
support is acceptable.

> I'd like to, too. The embedded world is one the SmartEiffel core team
> wanted to reach.

> The first thing is to come back to a gc-less tools suite, and to
> enhance a few young core libraries to be able to live without the gc
> (I think about log, xml, json).
Yes, this seems important. We could think of some sort of manual memory
management or a tool which analyzes object creation to be able to write
applications which allocate memory only at startup or on the stack with
some kind of compiler check that objects are only used while alive. All
that need not to end in the single-threaded world and we could imagine
some kind of interrupt support. But all that is future.

> Why does speaking embedded world makes me trigger discussion about GC?
> Dominique was dead right on that point.
> See

True. But on the other hand, in safety related systems we have
RAM-testing in the background anyhow, so why not also collect some dead
objects during these cycles? - Don't get me wrong, I personally am not
yet convinced, that garbage collection is the best we could do.

> On a totally different line of thinking, linux+arm means also Android.
> We may approach other Android communities such as SL4A.

This kind of mobile technology seem too short-lived and too much in flow
for us. We cannot follow these changing requirements right now.

>         Perhaps, before release-1, we should IRC-meet and discuss
>         marketing?  Just doing a release will not even cause ripples
>         in the smallest of ponds, my opinion is that some sort of
>         project/release promotion needs to be done... 
> You are right. I have fuzzy ideas on how to communicate: slashdot,
> lwn, other specialist sites, and social nets… If you have ideas,
> please share.

I think that for the adler release we do not need too much. We can make
the release, announce it here and there and continue on bell. BUT your
right if you say we cannot only concentrate on code and technology. If
we fail to build up a community (of at least a few users) Liberty will
fail, because we will loose motivation. Anyhow, I see this more as a
parallel task of "community building", which is more or less independent
from the releases but very important. 
> BTW: we should also come up with a list of "improvements" since
> SmartEiffel 2.2.

definitly yes, I see it in the 

>          Also, has anyone of you mailing lists from the old SE-days?
>          Can we re-activate (part of) the old guard?
> I contacted the old core guys. Almost all said they definitely would
> not come back, one or two replied "maybe later".

The biggest source of "high potentials" I see at ETH. I fear it's the
only university where they teach with Eiffel and students are often open
for diversity.


reply via email to

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