gmane.comp.lang.eiffel.smalleiffel

Re: Reference classquery

Frederic Merizen — 2008-08-28T08:27:19

Philippe Ribet: My two cents: -Class names are generally nouns, so "REFERENCED" would be unorthodox. Of course, we could jump on the DSL bandwagon to make "REFERENCED" trendy. -In my opininion, for an expanded classes A, REFERENCE[A] really is a box (I believe the term "boxed integer" is reasonably standard). -Note that REFERENCE[A] is also useful if A is a reference classe (if you want to share a mutable reference between several objects). In this case, REFERENCE really is a reference. -There's also WEAK_REFERENCE[A], which is only useful if A is a reference class. I'm not sure I'd bother renaming the class.

Re: Reference classquery

Daniel F Moisset — 2008-08-28T12:59:42

On Thu, 2008-08-28 at 10:27 +0200, Frederic Merizen wrote: I wouldn't rename it, it has been enough time around... That said, I like to think them as "REFERENCEABLE" (that looks awful. "REFERABLE"? ) :) D.

Re: Reference classquery

Philippe Ribet — 2008-08-27T17:47:07

I'm not sure it's clearer. The integer you set is not referenced: a: INTEGER ra: REFERENCED[INTEGER] ra.set_item(a) a is not referenced by ra.

Re: Reference classquery

Paolo Redaelli — 2008-08-27T11:32:06

Il giorno Wed, 27 Aug 2008 08:28:30 +0200 Philippe Ribet worldonline.fr> ha scritto: I would rename the class. Perhaps REFERENCED[INTEGER] could be clearer to understand and nearer to its semantic. My 2Ec Paolo

Re: Reference classquery

Philippe Ribet — 2008-08-27T06:28:30

I have to be quick too... In other words: REFERENCE[INTEGER] does not mean "reference to integer" (as named variables in example code) but means "integer as reference object". Documentation improvement nedeed? (I do not have access to source code for now...) Best regards,

GetText tutorial

Guillaume Lemaître — 2008-08-27T05:25:36

Hello, I'm currently looking at the tutorial for the get_text wrapper, and in fact I do not understand how domain.pot is generated or updated. Does it mean that currently this file has to be managed manually, without using tools like xgettext and soon ? Guillaume

Re: Reference classquery

Dominique Colnet — 2008-08-26T14:31:13

Using other words, it means that there is only one passing parameter style in Eiffel! (And it is a good news!) Historically, this class was introduced to replace the old "reference" keyword. May be the REFERENCE class name is misleading... It does. -- -------------------------------------------------------------- Dominique.Colnet< at >loria.fr -- IUT (Nancy 2) -- INRIA Lorraine http://SmartEiffel.loria.fr -- The GNU Eiffel Compiler POST: Loria, B.P. 239,54506 Vandoeuvre les Nancy Cedex, FRANCE Voice:+33 0383913140 Mobile: +33 0665362381 Fax:+33 0383913201

Re: Reference classquery

Frederic Merizen — 2008-08-26T14:25:25

Hi, I have to be quick, please pardon the terse style: the REFERENCE class is meant to work the way it's working now. It does not allow you to reference an existing object, it just gives you a boxed copy (assuming the object was expanded) of the object which you can then reference. In other words, REFERENCE does not turn expanded objects into reference objects. It turns expanded classes into reference classes. I hope this helps. Best regards

Reference classquery

2008-08-26T13:11:04

The program below produces the subsequent output ========================================================================================= class TEST -- examining behaviour of REFERENCE[INTEGER] creation program feature program is do create reference_to_i.set_item(i); std_output.put_string("reference_to_i.item : " + reference_to_i.item.to_string); std_output.put_new_line; i := 1; j := 1; create reference_to_j.set_item(j); std_output.put_string("reference_to_i.item : " + reference_to_i.item.to_string); std_output.put_new_line; std_output.put_string("reference_to_j.item : " + reference_to_j.item.to_string); std_output.put_new_line; end i, j : INTEGER; reference_to_i, reference_to_j : REFERENCE[INTEGER]; end ========================================================================================= reference_to_i.item : 0 reference_to_i.item : 0 reference_to_j.item : 1 ====================

Re: invalid ::= assignment inside the compiler

Philippe Ribet — 2008-08-21T04:17:16

Very good! You have a workaround and you isolated the bug. I'll try to have a look today. Thanks,

Re: invalid ::= assignment inside the compiler

Cyril ADRIAN — 2008-08-20T20:45:31

Hi Philippe, On Wed, Aug 20, 2008 at 10:07 PM, Philippe Ribet worldonline.fr>wrote: In fact the bug happens when I try to compile yepp (an ESE tool). With your information, and thanks to the debug_string, it gives me more insight to what happened. In fact the bug is triggered, I think, by the agent being created inside a tuple creation: something([agent foo(some_param)]) It gives me yet another an excellent reason to get rid of a tuple and replace it by a real class... but it does not remove the problem ;-) Removing the tuple fixes the problem. I could reduce the example (see test_suite/language/agents/test_agent68.e) Thanks,

Re: invalid ::= assignment inside the compiler

Philippe Ribet — 2008-08-20T20:07:15

There is a bug, because specialize_2 may turn code into procedure_call. This mean, if specialize_2 is called after another specialize_2, you'll have such error. But, before calling this specialize_2, specialize_thru has been called and the error didn't show (there is the very same assignment in specialize_thru). The only exception I can see is your class is generic. This could be checked using the debug_string of the start_position ;-) With this information, I hope I can build a small example.

invalid ::= assignment inside the compiler

Cyril ADRIAN — 2008-08-20T13:18:17

It looks like there is a confusion between function and procedure call in agents... What can I do to help? *** Error at Run Time ***: Invalid ::= assignment (inserted type). sedb> . ---- Stack-frame: 26 ---- inside specialize_2 AGENT_CREATION Current = AGENT_CREATION#0x4d28c28 [ start_position = POSITION [ mangling = 538983828 ] original_function_call = #0x488b048 code = #0x4d28c08 open_operand_list = Void closed_operand_list = #0x488b1a8 resolved_memory = #0x4d28dd0 ] type = TYPE#0x488d3a0 [ item = #0x488d3a0 parents = #0x488ec80 children = #0x488ec98 parents_edge = #0x488ecb0 children_edge = #0x488ecc8 mark = False mark_score = 0 parents_edge_load = #0x488ec50 children_edge_load = #0x488ec68 default_rescue_compound = Void default_rescue_collected = False live_type = Void canonical_type_mark = #0x276

Re: Troubles getting reverse assignment right

Jörgen Tegnér — 2008-08-17T20:44:48

Yep! BLAS, LAPACK and some QUADPACK experiments. Coming from a Fortran 77 background so I'm learning by doing (mistakes). I ended up with something like that too. My first try above was not well thought through. Will try it. Now I simply echo an error message in case of troubles. Sure. Rigth now this was just for my own small summer project of refreshing some of the number-crunching classes from old. Thus it's not complete, it's buggy and ugly and nothing to publish.

Re: Troubles getting reverse assignment right

Jörgen Tegnér — 2008-08-17T20:26:28

Hi, thanks for the suggestion, didn't know that was possible. The simple solution I ended up with was to inherit and redefine just the fortran calling functions. Wroks fine. Thanks

Wrapping unions

Paolo Redaelli — 2008-08-12T07:41:30

Are unions accessible like structures using externals? For example: #include union unione { int intero; void *puntatore; }; union unione *get_unione () { return (union unione *) malloc(sizeof(union unione)); }; could be accessed with? intero (ptr: POINTER): INTEGER is external "[ C union unione get intero use "unione.h" ]" end puntatore (ptr: POINTER): POINTER is external "[ C union unione get puntatore use "unione.h" ]" end As far as I can say it is not possible. I know that I circumvent the problem writing come C macros or inline functions. Accessing unions is essential to provide access to real-time POSIX signals: sigqueue function requires a union argument. This issue is linked with the exteral type proposals. From my experiences wrapping libraries in EWLC I would say that having external types sitting on the edge of the type system, i.e. non-inheritable, providing access to "expanded" structures and union would not be a problem. In fact a REFERENCE [SIGVA

Re: Troubles getting reverse assignment right

Paolo Redaelli — 2008-08-11T09:36:09

Mhmmm... this smells to be as BLAS - Basic Linear Algebra Subprograms... Am I right? We have been trying to address a problem almost identical to yours in Eiffel Wrapper Libraries Collection, wrapping the GNU Scientific Library which does actually include BLAS. You could read more about it at https://gna.org/projects/eiffel-libraries more specifically looking at GSL_VECTOR_GENERAL, GSL_VECTOR_REAL_32 and GSL_VECTOR_REAL_64 at http://svn.gna.org/viewcvs/eiffel-libraries/trunk/eiffel-gsl/library/ . I don't see why you need to use such a non-object-oriented technique. As far as I can understand you need to invoke different (Fortran/C) functions depending on the generic type of the vector. At EWLC we solved the problem this way: ------------------------------------------------------------------------ deferred class GSL_VECTOR_GENERAL[TYPE_ -> NUMERIC] ... feature dot (other: like Current): TYPE_ is -- Current = (Current.transpoed) other -- scalar (inner) product require

Re: Troubles getting reverse assignment right

Philippe Ribet — 2008-08-11T05:47:33

I'm back from hollidays, I know it's quite old mail but still... The way would explore (I didn't test anything): item: E_ if {REAL_32} ?:= item then ... Hope it works! (in boost mode, the test will be statically removed). Please keep us informed!

Re: Result not assigned

Philippe Ribet — 2008-08-10T20:10:01

Yes, it is really common in Eiffel not to assign a value to Result because it is initialised with a default value as everything else. It has a sense to let the default value unchanged. May be some specific child will redefine this function and always set the Result to True. It is common in OO programming! The unsused local variable is very different case: as it is local, if it is unused it is useless (it can't be used elsewhere). One good practice in Eiffel could limit such errors: first write pre- and post-conditions. If you write your post-condition, probably you will specify some property of the result. It's just one more reason to write assertions. The more you use Eiffel, the more you understand how valuable the assertions are. Sorry for the late answer, it was hollidays time ;-)

Current Snapshot (18 July 2008) - Eiffeldoc - signal 11 failure

2008-08-08T13:09:54

If I'm telling you what you already know, please ignore this. The current snapshot's eiffeldoc fails with a signal 11 failure! It was compiled using gcc 4.1.2 without optimisation (-O0). Regards Frank Salter

Re: Troubles getting reverse assignment right

Frederic Merizen — 2008-07-28T11:54:40

Hi, You got you reverse assignment reversed ! ranchor: REFERENCE[E_] dummy_32:REFERENCE[REAL_32] ... if dummy_32 ?:= ranchor then I didn't test the snippet above so it might not work either, but it's not as hopeless as the other way round Cheers