liberty-eiffel
[Top][All Lists]
Advanced

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

Re: [Liberty-eiffel] Limited resources should perhaps leed to a feature


From: Raphael Mack
Subject: Re: [Liberty-eiffel] Limited resources should perhaps leed to a feature freeze?
Date: Thu, 25 Sep 2014 18:46:22 +0000
User-agent: Internet Messaging Program (IMP) H5 (6.2.1)

Hans, you are somehow right, we should get the available things working. BUT: some of the bugs are only of marginal relevance and sometimes it may be better to do it anew as fixing the existing stuff (think of the GC: there is the specialized SE-GC, which has some bug. Understanding that code to find and fix this problem is probably harder than adding support for an external GC as BDW. So is it better to add the new feature BDW or fix the existing code. I'd say it is not so clear, as your demand reads ;-) And yes, sometime it is better to implement a new feature, than fixing an existing bug, because it may really be more fun. - We all do this here "just for fun" and we need to keep the motivation.

But honestly: if an existing bug is relevant for an user it also gains interest - much more than if it is just ET who finds a failing test case. So please guys continue to report your real life problems with Liberty...

Rapha

Zitat von Hans Zwakenberg  |  Ocean Consulting GmbH <address@hidden>:

Zitat von Hans Zwakenberg | Ocean Consulting GmbH <address@hidden>:
> noticing that thread safety is on the agenda again, I wondered whether the
> implementation of SCOOP would be made easier if the Intel
> CILK-library would be

Quite interesting, for sure. But for now I think there are many
interesting tasks in the "simple" (i. e. single-threaded) eiffel world
open which we should finish one after the other. SCOOP is probably not
one of the first 5 ;-(

It is so sad, that time is no unlimited resource ;-)

Rapha


Hi Rapha,

I agree, there are more pressing matters. I provided the information as 'food
for thought', not to suggest to work on it right away.   On the contrary, I'd
rather suggest a complete feature freeze until all outstanding issues are
solved, i.e. I'd suggest to not work on any new stuff before the open issues are out of the way... I know it's hard to commit to that, as most programmers much
prefer to do new stuff rather than to maintain existing code  ;)

cheers
Hans






reply via email to

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