Difference between revisions of "Wish list"
Jump to navigation
Jump to search
(update link to issue tracker) |
(move wishes into tasks) |
||
| Line 1: | Line 1: | ||
| − | [[Category:Smarteiffel]] |
||
| − | Note |
||
| − | This is the imported page from SmartEiffelWiki. For Liberty we should get rid of this page by moving the requests into [https://savannah.gnu.org/bugs/?func=additem&group=liberty-eiffel bugs] or [https://savannah.gnu.org/task/?func=additem&group=liberty-eiffel tasks] on [https://savannah.gnu.org/projects/liberty-eiffel/ savannah]. |
||
| − | |||
[[Category:Community]] |
[[Category:Community]] |
||
==Exception handling== |
==Exception handling== |
||
| + | ==> [[task:13316]] |
||
| − | 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://websympa.loria.fr/wwsympa/arc/smarteiffel/2001-03/msg00105.html as] |
||
| − | [http://websympa.loria.fr/wwsympa/arc/smarteiffel/2003-09/msg00000.html has] |
||
| − | [http://websympa.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://websympa.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) |
||
| − | |||
| − | ''This is not a high priority request for me anymore. I've worked around it by removing all rescue clauses from my application'' [[User:Eiffel|Roger Browne]] 14:57, 23 Dec 2005 (CET) |
||
| − | |||
| − | I've got a "rescue" clause in my application again, so this problem is biting me again. [[User:Eiffel|Roger Browne]] 21:11, 13 Sep 2006 (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) |
||
| − | |||
| − | |||
==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:Ramack|Ramack]] ([[User talk:Ramack|talk]]) |
||
| − | --[[User:Colonna]] 12:53, 24 Sep 2005 (CEST) |
||
| − | |||
| − | |||
==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]] |
||
| − | 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) |
||
| − | |||
| − | Where should this keyword be used? - I don't see the point, sorry --[[User:Ramack|Ramack]] 16:36, 15 Jan 2006 (CET) |
||
== Finally implementing SCOOP? == |
== Finally implementing SCOOP? == |
||
| + | ==> [[task:13317]] |
||
| − | |||
| − | 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: |
||
| − | <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) |
||
=== Make generated C code thread-safe? === |
=== Make generated C code thread-safe? === |
||
| + | ==> [[task:13320]] |
||
| − | As a starting point, how about just making the generated C code thread-safe? Right now the use of global static variables makes the generated C code unsafe. |
||
| − | |||
| − | But as soon as you say Thread, it is unsafe :-) [[User:Colnet|Colnet]] 17:06, 19 Dec 2005 (CET) |
||
| − | |||
| − | So basically it sounds like there is no plan for implementing SCOOP in a cross-platform-compatible way-- is that correct? |
||
| − | |||
| − | It is. SCOOP is fairly complex (conceptually), hence it is rather complex (to implement), therefore it is quite complex (to use). We are not sure about implementing SCOOP. But maybe thread safety can be achieved. There are not a lot of global variables and they are almost useless (I think in particular of <tt>se_dst</tt>). It means that |
||
| − | # even if we don't implement SCOOP, someone else would be able to; |
||
| − | # we won't provide a THREAD class, but a third party could do so once the code is thread safe (probably using [[Plugins]]); |
||
| − | # there is already some multi-tasking possibilities in SmartEiffel: cooperative multi-tasking implemented by the <tt>lib/sequencer</tt> cluster, with examples both in the tutorial and [http://shootout.alioth.debian.org/ The Computer Language Shootout Benchmarks] (look at the [http://shootout.alioth.debian.org/benchmark.php?test=message&lang=se cheap concurrency] and [http://shootout.alioth.debian.org/benchmark.php?test=chameneos&lang=se&id=0 chameneos] benchmarks); |
||
| − | # we'd rather implement communication between process: watch the <tt>lib/net</tt> cluster, it should evolve in the following months. |
||
| − | --[[User:Cadrian|Cyril]] 09:43, 21 Dec 2005 (CET) |
||
| − | |||
| − | |||
== TUPLE argument in feature 'call' of class PROCEDURE == |
== TUPLE argument in feature 'call' of class PROCEDURE == |
||
| + | ==> [[task:13318]] |
||
| − | 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) |
||
| − | |||
| − | Sorry, I don't think so. For me, <code>PROCEDURE[TUPLE[A,B]]</code> '''does''' conform to <code>PROCEDURE[TUPLE[A,B,C]]</code>. -- Philippe Ribet |
||
| − | |||
| − | What did I miss? Philippe, please fix my argument. Maybe I'm wrong. You know the topic better than me. --[[User:Cadrian|Cyril]] 11:34, 21 Dec 2005 (CET) |
||
| − | |||
| − | Well, <code>TUPLE[A,B,C]</code> conforms to <code>TUPLE[A,B]</code> (no special rule here), |
||
| − | so <code>PROCEDURE[TUPLE[A,B]]</code> conforms to <code>PROCEDURE[TUPLE[A,B,C]]</code> (because of the reversal you mentionned). A procedure can discard extra-arguments, but you have to give it enough arguments so it can do its work.--[[User:FM|FM]] 17:26, 17 Jan 2006 (CET) |
||
| − | |||
| − | --- |
||
| − | |||
| − | I would like such agent calls: It would be possible to have a type-safe class <code>SIGNAL[E_ -> TUPLE]</code>. The callback would look like this <code>callback: PROCEDURE[E_]</code> (I don't use an array of callbacks here because of readability). This is type-safe for any actual generic. A <code>set_callback (a_callback: like callback)</code> feature would be safe as well... And the important point, the emit feature that is currently not valid: |
||
| − | |||
| − | emit (argument: E_) is |
||
| − | do |
||
| − | callback.call(argument) |
||
| − | end |
||
| − | |||
| − | This kind of agent call is '''not''' syntactic sugar. It is impossible to write such a class without it. The number of arguments is the only information one has, and this of course only at run-time. The types of the arguments are not known and thus it is impossible to implement such a class from my point of view. |
||
| − | |||
| − | With such an implementation the following is possible: |
||
| − | If a class contains a <code>SIGNAL_2[INTEGER, STRING]</code> it could be replaced by <code>SIGNAL[TUPLE[INTEGER, STRING]]</code>.--Andy |
||
| − | |||
| − | == embed external c structs into (expanded) classes == |
||
| − | |||
| − | I'd like to embed a field of some external c type in the generated struct for a |
||
| − | class. Here is an example as explanation: |
||
| − | |||
| − | my_struct.h: |
||
| − | typedef struct |
||
| − | { |
||
| − | double x; |
||
| − | int c; |
||
| − | } |
||
| − | my_struct; |
||
| − | void ext_use(my_struct* c); |
||
| − | |||
| − | x.e: |
||
| − | class X |
||
| − | feature |
||
| − | use is |
||
| − | do |
||
| − | ext_use($ext) |
||
| − | end |
||
| − | feature |
||
| − | ext is |
||
| − | external "C use my_struct.h" |
||
| − | embedded_type "my_struct" |
||
| − | end |
||
| − | ext_use(POINTER: ptr) is |
||
| − | external "C" |
||
| − | end |
||
| − | end |
||
| − | |||
| − | (There might be better syntax for this.) |
||
| − | |||
| − | The following c code should be generated for class X (assume X to have id |
||
| − | 25): |
||
| − | struct S25{Tid id; my_struct x;}; |
||
| − | |||
| − | Why all this? First, I'd like my_struct to react expanded for an expanded class(allocation on the stack, call-by-value semantics), the second point is, that I want to |
||
| − | handle the struct with many external c functions and do not like one additional level of indirection. |
||
| − | |||
| − | I sent this already to the mailing list, but none commented on it. - I'm a bit disappointed about that, because this is just unfair and don't improve the ambience in a community - exactly that what is missing for eiffel. |
||
| − | |||
| − | It is planned to integrate this in some way into the next release. See [[External_types]] for details. |
||
| − | |||
| − | [[User:Ramack|Ramack]] 21:20, 2 May 2006 (CEST) |
||
| − | |||
| − | ==Library class links need updating== |
||
| − | In the index, links to classes are represented as <tt>library_class:''CLASSNAME''</tt> which translates to |
||
| − | <tt>libraries/''CLASSNAME''.ANY.html</tt>. This should now translate to <tt>libraries/''CLASSNAME''at.ANY.html</tt>. |
||
| − | |||
| − | [[User:Oliver|Oliver]] 11:14, 15 May 2006 (CEST) |
||
| − | |||
| − | ''The links generated by eiffeldoc were changed back to a more normal scheme ([http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/tools/generation/eiffeldoc/?rev=7297&root=smarteiffel svn revision 7297]). The library should be generated again.'' |
||
| − | --[[User:Cadrian|Cyril]] 15:42, 15 May 2006 (CEST) |
||
Revision as of 22:04, 10 September 2014
Exception handling
==> task:13316
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
Finally implementing SCOOP?
==> task:13317
Make generated C code thread-safe?
==> task:13320
TUPLE argument in feature 'call' of class PROCEDURE
==> task:13318