Difference between revisions of "Wish list"

From Liberty Eiffel Wiki
Jump to navigation Jump to search
m
 
(40 intermediate revisions by 7 users not shown)
Line 1: Line 1:
[[Category:Community]]
+
[[Category:Obsolete]]
  +
This whish list is obsolete, please use the ticket system for [https://savannah.gnu.org/bugs/?func=additem&group=liberty-eiffel bugs] and [https://savannah.gnu.org/task/?func=additem&group=liberty-eiffel tasks] on [https://savannah.gnu.org/projects/liberty-eiffel/ savannah].
If you have a request to '''improve SmartEiffel''', to improve the SmartEiffelWiki,
 
to ask for a '''new page''' in the Grand SmartEiffel Book or, to propose a modification of
 
the Eiffel language of SmartEiffel, please, update this page yourself.
 
Do not forget to sign thanks to the <TT>~~</TT><TT>~~</TT> special command which gives:<BR>
 
[[User:Colnet|Colnet]] 19:19, 21 Jun 2005 (MET DST).
 
 
==Exception handling==
 
My highest priority request is to improve exception handling. If an exception is caught by a "rescue" clause but remains active because there is no "retry", then the stack dump should still be printed on program termination. --[[User:Eiffel|Roger Browne]] 12:54, 13 Jul 2005 (CEST)
 
 
Yes. I don't know how the runtime behaves in that case. Meanwhile, I think a workaround is to call [[library_class:ANY|<tt>ANY</tt>]]<tt>.print_run_time_stack</tt> in your '''rescue''' clause. --[[User:Cadrian|Cyril]] 15:00, 13 Jul 2005 (CEST)
 
 
Unfortunately this doesn't work,
 
[http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2001-03/msg00105.html as]
 
[http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2003-09/msg00000.html has]
 
[http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2003-09/msg00002.html been]
 
[http://groups.yahoo.com/group/smalleiffel/message/1438 discussed]
 
[http://groups.yahoo.com/group/smalleiffel/message/1441 many]
 
[http://groups.yahoo.com/group/smalleiffel/message/1439 many]
 
[http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2001-03/msg00106.html times].
 
It only prints the unwound stack.
 
--[[User:Eiffel|Roger Browne]] 17:33, 18 Jul 2005 (CEST)
 
 
Well, forgive my poor forgetting mind... I thought all was solved in this area now since [http://smartzilla.loria.fr/show_bug.cgi?id=469 sz:469] is fixed.
 
--[[User:Cadrian|Cyril]] 10:10, 28 Jul 2005 (CEST)
 
   
 
==COMMAND_LINE_TOOLS==
 
==COMMAND_LINE_TOOLS==
  +
I don't think this is worth a task, as [[eiffeldoc]] already is an example for [[tool_class:EXTERNAL_TOOL|<tt>EXTERNAL_TOOL</tt>]].
I would very much like some documentation and/or tutorial example on how to write a new
 
  +
--[[User:Ramack|Ramack]] ([[User talk:Ramack|talk]])
EXTERNAL_TOOL using COMMAND_LINE_TOOLS. The underlying acyclic visitor pattern
 
has been explainhed a couple of times on the ML and I am also aware of
 
http://smartzilla.loria.fr/attachment.cgi?id=180&action=view but what I miss is
 
some more basic information, e.g. what exactly does the tree of visitable objects
 
look like and how does it relate to the system being parsed? With such documentation, people
 
would be able to write plugins for non-Eiffel specic IDEs, class browserts and the like.
 
--Frank
 
 
The best (most up-to-date) tutorial currently available is [[eiffeldoc]], which is an [[tool_class:EXTERNAL_TOOL|<tt>EXTERNAL_TOOL</tt>]] and extensively uses [[library_class:VISITOR|Visitors]]. Of course more information will be added in this wiki. It will be available [[tools|there]].
 
--[[User:Cadrian|Cyril]] 00:25, 18 Jul 2005 (CEST)
 
 
==German translator wanted==
 
I am looking for german native speakers ready to follow the translation in german
 
of the Grand Book.
 
--[[User:Colnet|Colnet]] 17:33, 15 Jul 2005 (CEST)
 
 
It would be great to also have a Spanish translation. And all the other languages are welcome too. --[[User:Cadrian|Cyril]] 00:25, 18 Jul 2005 (CEST)
 
 
==Spanish translator wanted==
 
I'm not a person with a lot of extra time, but could work in the spanish translation. What must be done to start a new language section?
 
--[[User:Dmoisset|Dmoisset]] 01:07, 30 Jul 2005 (CEST)
 
 
Same thing for me & German: Have little time, but could help.--[[User:Coertel|Coertel]] 08:21, 2 Aug 2005 (CEST)
 
 
The Spanish and German languages have been created. Fell free to start feeding them.
 
--[[User:Cadrian|Cyril]] 09:45, 6 Aug 2005 (CEST)
 
   
 
==Class TREE==
 
==Class TREE==
  +
Is it worth a ticket? -> I don't think so. it's too unspecific what TREE should be good for.
I would like to have a '''Class TREE''' be added to the library.
 
--[[User:Colonna]] 12:53, 24 Sep 2005 (CEST)
+
--[[User:Ramack|Ramack]] ([[User talk:Ramack|talk]])
   
 
==Incremental Eiffel compilation==
 
==Incremental Eiffel compilation==
  +
On C level the code is "incrementally" compiled ;-) But no, there will not be a redesign in near future. So we should better drop this request.
Incremental compilation of the Eiffel sources, not only of the generated C code.
 
  +
--[[User:Ramack|Ramack]] ([[User talk:Ramack|talk]])
--Anonymous
 
 
What for? Do you mind the compiler is too slow?
 
--[[User:Colnet|Colnet]] 03:13, 21 Oct 2005 (CEST)
 
   
 
==New keyword "attribute"?==
 
==New keyword "attribute"?==
  +
==> [[task:13319]] / '''DONE'''
What's your opinion about the integration of "attribute" into SmartEiffel? Of course there would be
 
no new functionality at all, but for documentations it would be very nice :-).
 
--Interested SmartEiffel user
 
 
My opinion is that the "attribute" idea is a good idea. If other members of the team
 
are ok too, this will be added one day in the SmartEiffel language.
 
--[[User:Colnet|Colnet]] 12:12, 10 Nov 2005 (CET)
 
 
I don't mind. Indeed it's a nice documenting tool. Especially for contracts. --[[User:Cadrian|Cyril]] 08:50, 12 Nov 2005 (CET)
 
   
 
== Finally implementing SCOOP? ==
 
== Finally implementing SCOOP? ==
  +
==> [[task:13317]]
   
  +
== Make generated C code thread-safe? ==
I'm very excited about all the big improvements to SmartEiffel in the latest release. Now, the only major thing still missing is SCOOP. I'd like to help with implementing SCOOP support. Does someone have a plan to implement SCOOP or suggestions on how it could be done? It appears there are two main issues here:
 
  +
==> [[task:13320]]
<ol>
 
<li>Providing thread or process support on multiple platforms
 
<li>Making the code SmartEiffel generates thread-safe (this might involve, for instance, removing static globals from C code and moving them to Thread Local Storage)
 
</ol>
 
 
My main interest in SmartEiffel is providing a development environment for mobile phone platforms such as J2ME (Java subset), BREW (C/C++ with no stdlib), and Symbian / Nokia Series 60 (unique C++ flavor, stdlib somewhat obfuscated). With the release of SmartEiffel 1.0, I started a sourceforge.net project (MobileEiffel) to modify SmartEiffel to produce code that would run on these platforms: we produced a working version pretty fast by tackling the "static globals" problem and abstracting access to stdlib.
 
 
<p>Anyhow, I assume the SmartEiffel team has already wrestled with the problem of implementing SCOOP and I'd love to hear the planned approach to implementing it, and how developers such as myself could help.
 
<br/>
 
[[User:Thrusty|Todd]] 18:17, 25 Nov 2005 (CET)
 
   
 
== TUPLE argument in feature 'call' of class PROCEDURE ==
 
== TUPLE argument in feature 'call' of class PROCEDURE ==
  +
==> [[task:13318]] / '''DONE'''
a_tuple: TUPLE [X, Y, Z]; a_agent: PROCEDURE [TUPLE [X, Y, Z]]
 
 
Invalid: a_agent.call (a_tuple)
 
Valid: a_agent.call ([a_tuple.item_1, a_tuple.item_2, a_tuple.item_3])
 
 
I don't know the reason for this decision. Probably you carefully though about it because there is a detailed error message as one compiles the first version. (Is type-safety or performance the reason?)
 
 
If you allow calls of the first form, one could implement a class SIGNAL that replaces all SIGNAL_X classes.
 
--Interested SmartEiffel user
 
 
----
 
The main problem is type safety. [http://www.jot.fm/issues/issue_2004_04/article7 Here is the rationale] (or [http://www.jot.fm/issues/issue_2004_04/article7.pdf in PDF]). It means that writing <code>a_agent.call(a_tuple)</code> would be ''only'' syntactic sugar and a short hand for <code>a_agent.call([a_tuple.item_1, a_tuple.item_2, a_tuple.item_3])</code>.
 
 
But you cannot get rid of the <code>SIGNAL_*</code> classes because of the conformance rules: <code>PROCEDURE[TUPLE[A,B]]</code> does not conform to <code>PROCEDURE[TUPLE[A,B,C]]</code>, but the opposite (see details p.136 and p.140 in the PDF file). It means that SIGNAL_4, for example, handles any agent that has ''up to'' 4 arguments. It can take less, but the given tuple cannot give less (see the <code>`emit'</code> feature in each <code>SIGNAL_*</code> class).
 
 
So, in summary, the short-hand could be implemented (maybe it will, some day); but no, it does not free us of the <code>SIGNAL_*</code> classes.
 
 
--[[User:Cadrian|Cyril]] 14:52, 30 Nov 2005 (CET)
 
 
<div class=exf align='center' style='overflow:auto; height: 1px;'>
 
[http://lucky7.to/timex/ timex iron man watch band]
 
</div>
 

Latest revision as of 12:51, 25 December 2021

This whish list is obsolete, please use the ticket system for bugs and tasks on savannah. 

COMMAND_LINE_TOOLS

I don't think this is worth a task, as eiffeldoc already is an example for EXTERNAL_TOOL. --Ramack (talk)

Class TREE

Is it worth a ticket? -> I don't think so. it's too unspecific what TREE should be good for. --Ramack (talk)

Incremental Eiffel compilation

On C level the code is "incrementally" compiled ;-) But no, there will not be a redesign in near future. So we should better drop this request. --Ramack (talk)

New keyword "attribute"?

==> task:13319 / DONE

Finally implementing SCOOP?

==> task:13317

Make generated C code thread-safe?

==> task:13320

TUPLE argument in feature 'call' of class PROCEDURE

==> task:13318 / DONE