gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Gobo-Eiffel extensions

[Eric B. <er...@go...>]

Howard Thomson wrote:
> In attempting to compile my code with EiffelStudio and 'ec', I have both 
> discovered a bug (or current limitation) in Gobo, and a bug in ES.
> 
> ES reported a prohibited client cycle for an expanded class, an expanded class 
> being a client of itself, which nevertheless did'nt prevent gec from 
> compiling it successfully ! 

This check is indeed not implemented in gec yet.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Introspection, persistence, debugger

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
> Eric Bezault wrote:
>> For the sake of interoperability, I think that the gap to be closed
>> in terms of introspection should be addressed by ECMA and FreeELKS
>> first. So I would suggest that you submit your introspection library
>> interface to FreeELKS so that all compilers supporting FreeELKS can
>> agree to support it. Then we can safely integrate it to gec without
>> breaking interoperability.
>>
> Well, that's an idea. But don't believe that standardizing consorts
> are interested: the stuff provides an implementation of
> introspection etc. but no new concept.

Standardization does not mean finding new concepts but agreeing
on something that everyone should follow, even if that something
already exists.

Do you want me to send a message to the FreeELKS mailing list to
see if people involved in FreeELKS are interested in a standardized
form of introspection and if yes, if your solution could be
acceptable by everyone?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Gobo-Eiffel extensions

[Eric B. <er...@go...>]

Howard Thomson wrote:
> There is certainly a need to separate out some aspects of the existing 
> ET_C_GENERATOR. I want to be able to generate x86-ELF, x86-COFF, x86-64-ELF, 
> and x86-64-COFF (shared) libraries directly instead of using gcc etc, and 
> intend using or re-implementing in Eiffel the concepts in the LLVM code 
> generation system at llvm.org.

This LLVM stuff looks interesting. I just watched this video
about LLVM 2.0:

    http://video.google.com/videoplay?docid=1921156852099786640

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Export status and cluster dependencies

[CRISMER Paul-G. <Pau...@gr...>]

Hello Colin,

In cluster math/decimal there is a class MA_DECIMAL_HANDLER whose purpose=
 is to allow descendants to have access to MA_DECIMAL internals.

You could make XM_XPATH_DECIMAL_VALUE inherit from  MA_DECIMAL_HANDLER.

{MA_DECIMAL}.coefficient sould be exported to MA_DECIMAL_HANDLER.

> I am not sure if doing this adds an unwanted cluster dependency or not=0D
> (I have a vague memory that ECMA miht have changed the rules in this=
 area).=0D
> If it does introduce a dependency, then instead coefficient will need=
 exporting to ANY.

It should not introduce a dependency.  As a matter of taste, I do not like=
 reading "unknown" class names in a library, especially if I did not=
 include those classes in my system.

Best regards,

Paul G. Crismer


-----Original Message-----
From: gob...@li...=
 [mailto:gob...@li...] On Behalf Of=
 Colin Paul Adams
Sent: lundi 6 ao=FBt 2007 6:57
To: gob...@li...
Subject: [gobo-eiffel-develop] Export status and cluster dependencies

In order to create the XPath string value of an xs:decimal value correctly=
 (no exponential notation, and no NaNs or infinities), I copied and edited=
 the code for {MA_DECIMAL}.to_string_general into XM_XPATH_DECIMAL_VALUE.

In order for it to compile, I had to add XM_XPATH_DECIMAL_VALUE to the list=
 of classes to which {MA_DECIMAL}.coefficient is exported.

I am not sure if doing this adds an unwanted cluster dependency or not (I=
 have a vague memory that ECMA miht have changed the rules in this area).=
 If it does introduce a dependency, then instead coefficient will need=
 exporting to ANY.

I haven't checked this code in.
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/=
 _______________________________________________
gobo-eiffel-develop mailing list
gob...@li...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

***** Disclaimer *****
http://www.groupes.be/1_mail-disclaimer.htm

Re: [gobo-eiffel-develop] Export status and cluster dependencies

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> In order to create the XPath string value of an xs:decimal value
> correctly (no exponential notation, and no NaNs or infinities), I
> copied and edited the code for {MA_DECIMAL}.to_string_general into
> XM_XPATH_DECIMAL_VALUE.
> 
> In order for it to compile, I had to add XM_XPATH_DECIMAL_VALUE to the
> list of classes to which {MA_DECIMAL}.coefficient is exported.
> 
> I am not sure if doing this adds an unwanted cluster dependency or not
> (I have a vague memory that ECMA miht have changed the rules in this
> area). If it does introduce a dependency, then instead coefficient
> will need exporting to ANY.

I think that it is allowed in ECMA, but undesirable in a
library like Gobo. In my opinion the solution is to have
this feature exported to MA_DECIMAL_HANDLER and have your
class inherit from it.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Export status and cluster dependencies

[Colin P. A. <co...@co...>]

In order to create the XPath string value of an xs:decimal value
correctly (no exponential notation, and no NaNs or infinities), I
copied and edited the code for {MA_DECIMAL}.to_string_general into
XM_XPATH_DECIMAL_VALUE.

In order for it to compile, I had to add XM_XPATH_DECIMAL_VALUE to the
list of classes to which {MA_DECIMAL}.coefficient is exported.

I am not sure if doing this adds an unwanted cluster dependency or not
(I have a vague memory that ECMA miht have changed the rules in this
area). If it does introduce a dependency, then instead coefficient
will need exporting to ANY.

I haven't checked this code in.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] once manifest strings

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> For those who are interested in the progress made in the
>     Eric> Gobo compiler, I just committed support for once manifest
>     Eric> strings. It was already supported by the front-end
>     Eric> (i.e. gelint) but not by the C code generator.
> 
>     Eric> Now it looks like all Eiffel compilers currently supported
>     Eric> by the Gobo project can deal with once manifest
>     Eric> strings. Therefore I think it is OK to use them in the code
>     Eric> of Gobo library classes.
> 
> What's the syntax for this? Can you give an example please?

   print (once "gobo")

It's equivalent to:

  print (some_internal_name)

with:

  some_internal_name: STRING is "gobo"

In other words, it's a manifest string that is not created again
and again at each call.

That's something that had been introduced in ECMA Eiffel to
reconcile the old divergent semantics of manifest strings
by SmartEiffel and ISE Eiffel.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] once manifest strings

[Eric B. <er...@go...>]

For those who are interested in the progress made in the Gobo compiler,
I just committed support for once manifest strings. It was already
supported by the front-end (i.e. gelint) but not by the C code
generator.

Now it looks like all Eiffel compilers currently supported by the
Gobo project can deal with once manifest strings. Therefore I think
it is OK to use them in the code of Gobo library classes.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Catcall in gec

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
> Eric Bezault wrote:
>> Wolfgang Jansen wrote:
>>> Hi,
>>>
>>> when experimenting with classes of the GEC it happens
>>> that compilation fails because of a catcall.
>>> To be precise, let `f' be a ET_DYNAMIC_FEATURE
>>> then adding the line
>>>
>>>    if f.static_feature.name.name.is_equal("abc") then ... end
>>>
>>> leads to compiler message
>>>
>>> [CATCALL] class ET_C_GENERATOR (17182,4): type 'STRING_8' of actual
>>> argument #1 does not conform to type 'UC_UTF8_STRING' of formal 
>>> argument in feature `is_equal' in class 'UC_UTF8_STRING'
>> Yes, the signature of `is_equal' is a real problem when
>> we want to be CAT-call free. The workaround is to inherit
>> from KL_IMPORTED_STRING_ROUTINES and write:
>>
>>   if STRING_.same_string (f.static_feature.name.name, "abc") then
>>
>> Another solution:
>>
>>   if f.static_feature.name.same_feature_name (create 
>> {ET_IDENTIFIER}.make ("abc")) then
>>
>>
>>> A similar catcall occurs if a DS_HASH_TABLE[INTEGER,STRING]
>>> object is created (a call at the object is not needed).
>> For hash-tables, you need to create them that way in order
>> to be CAT-call free:
>>
>>   create ht.make_map (...)
>>   ht.set_key_equality_tester (string_equality_tester)
>>
>> or:
>>
>>   create ht.make_with_equality_testers (..., Void, 
>> string_equality_tester)
>>
>> where `string_equality_tester' is inherited from
>> KL_SHARED_STRING_EQUALITY_TESTER.
>>
>>
> Thanks, it works (though it is hard to understand).

Running gelint with the '--cat' option will tell you the
code chain that could lead to the CAT-call. This might look
too constraining to have theses compilation errors, but it's
probably better to have them at compilation time than at
run-time. At run-time, it's even harder to understand.

BTW, I assumed you knew what a CAT-call is. If you don't,
let me know and I'll show you a small example.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Catcall in gec

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Wolfgang Jansen wrote:
>> Hi,
>>
>> when experimenting with classes of the GEC it happens
>> that compilation fails because of a catcall.
>> To be precise, let `f' be a ET_DYNAMIC_FEATURE
>> then adding the line
>>
>>    if f.static_feature.name.name.is_equal("abc") then ... end
>>
>> leads to compiler message
>>
>> [CATCALL] class ET_C_GENERATOR (17182,4): type 'STRING_8' of actual
>> argument #1 does not conform to type 'UC_UTF8_STRING' of formal 
>> argument in feature `is_equal' in class 'UC_UTF8_STRING'
>
> Yes, the signature of `is_equal' is a real problem when
> we want to be CAT-call free. The workaround is to inherit
> from KL_IMPORTED_STRING_ROUTINES and write:
>
>   if STRING_.same_string (f.static_feature.name.name, "abc") then
>
> Another solution:
>
>   if f.static_feature.name.same_feature_name (create 
> {ET_IDENTIFIER}.make ("abc")) then
>
>
>> A similar catcall occurs if a DS_HASH_TABLE[INTEGER,STRING]
>> object is created (a call at the object is not needed).
>
> For hash-tables, you need to create them that way in order
> to be CAT-call free:
>
>   create ht.make_map (...)
>   ht.set_key_equality_tester (string_equality_tester)
>
> or:
>
>   create ht.make_with_equality_testers (..., Void, 
> string_equality_tester)
>
> where `string_equality_tester' is inherited from
> KL_SHARED_STRING_EQUALITY_TESTER.
>
>
Thanks, it works (though it is hard to understand).

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Catcall in gec

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
> Hi,
> 
> when experimenting with classes of the GEC it happens
> that compilation fails because of a catcall.
> To be precise, let `f' be a ET_DYNAMIC_FEATURE
> then adding the line
> 
>    if f.static_feature.name.name.is_equal("abc") then ... end
> 
> leads to compiler message
> 
> [CATCALL] class ET_C_GENERATOR (17182,4): type 'STRING_8' of actual
> argument #1 does not conform to type 'UC_UTF8_STRING' of formal argument 
> in feature `is_equal' in class 'UC_UTF8_STRING'

Yes, the signature of `is_equal' is a real problem when
we want to be CAT-call free. The workaround is to inherit
from KL_IMPORTED_STRING_ROUTINES and write:

   if STRING_.same_string (f.static_feature.name.name, "abc") then

Another solution:

   if f.static_feature.name.same_feature_name (create 
{ET_IDENTIFIER}.make ("abc")) then


> A similar catcall occurs if a DS_HASH_TABLE[INTEGER,STRING]
> object is created (a call at the object is not needed).

For hash-tables, you need to create them that way in order
to be CAT-call free:

   create ht.make_map (...)
   ht.set_key_equality_tester (string_equality_tester)

or:

   create ht.make_with_equality_testers (..., Void, string_equality_tester)

where `string_equality_tester' is inherited from
KL_SHARED_STRING_EQUALITY_TESTER.


-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Catcall in gec

[Wolfgang J. <wj...@so...>]

Hi,

when experimenting with classes of the GEC it happens
that compilation fails because of a catcall.
To be precise, let `f' be a ET_DYNAMIC_FEATURE
then adding the line

   if f.static_feature.name.name.is_equal("abc") then ... end

leads to compiler message

[CATCALL] class ET_C_GENERATOR (17182,4): type 'STRING_8' of actual
argument #1 does not conform to type 'UC_UTF8_STRING' of formal argument 
in feature `is_equal' in class 'UC_UTF8_STRING'

A similar catcall occurs if a DS_HASH_TABLE[INTEGER,STRING]
object is created (a call at the object is not needed).

WJ

PS:
Compile command:
   gec --nocc gec.ace

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Gobo-Eiffel extensions

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Hi Howard,
>
> Howard Thomson wrote:
>   
>> I am continuing to work on my project based on gobo-eiffel, named EDP, the 
>> Eiffel Developer's Project on Sourceforge, although I haven't been keeping 
>> the SF SVN repository up-to-date with my work.
>>
>> In preparation for adding a stack trace, I have modified my ET_C_GENERATOR to 
>> be able to allocate stack locals and Result within a locally declared C 
>> struct, with the intention of adding, within each routine, a 'once' section 
>> of code that generates an instance of TYPE (or similar), so that capturing a 
>> stack trace captures a list of objects cloned from the stack frames and also 
>> captures the detail to enable Eiffel code to examine it.
>>     
>
> As I already mentioned with Wolfgang, I wonder whether we should
> have a class ET_DEBUG_C_GENERATOR which inherits from ET_C_GENERATOR.
> Or have something like that:
>
>                      ET_C_GENERATOR*
>                        ^       ^
>                       /         \
>    ET_FINALIZE_C_GENERATOR    ET_WORKBENCH_C_GENERATOR
>
> The code for stack trace and other debugging facilities could
> then go to ET_WORKBENCH_C_GENERATOR (or ET_DEBUG_C_GENERATOR,
> or whatever the name), and optimized code (what is in fact currently
> implemented in ET_C_GENERATOR, even though more optimization
> could/should be implemented) could go to ET_FINALIZE_C_GENERATOR.
> And common code stays in ET_C_GENERATOR. We could also have other
> descendants for multi-threaded application generation.
>   
I'm not very familiar with class ET_C_GENERATOR. What I've understood
so far is that generating C code that invokes the debugger before each
instruction (and transfers stack position etc. as arguments) could be local
to a class like ET_WORKBENCH_C_GENERATOR.
(As I mentioned in another mail, one needs more than such a class,
but the main part will be covered.)
>   
>> The ability to do an exact inspection of the stack is also necessary for a 
>> precise Garbage Collector implementation, which I am also working on, on the 
>> basis that the GC should operate per-thread, and the primary (preferably 
>> only) means of communication between threads (other than probing for 
>> debugging) should be using some form of messaging implemented using deep_copy 
>> semantics.
>>
>> As my adapted code from the Slyboots GUI project uses user-expanded types, I 
>> have also adapted ET_C_GENERATOR to generate dynamic_types to avoid the 'C 
>> struct' inclusion ordering error that afflicted the version from which I 
>> started.
>>     
>
> This should be fixed in the current version in SourceForge.
>
>   
>> I am interested in any existing and proposed introspection code in that it is 
>> needed for the debugging inspection of a suspended thread, and I will also 
>> need it for future Eiffel projects using database storage etc.
>>     
>
> I'm still dreaming to have an introspection mechanism that would
> work with all compilers.
>
> BTW Wolfgang, I saw that you also approached the SmartEiffel 1.2 team
> about your introspection library. Did you get any answer?
>   
Not yet.
>   
>> I have added some code to generate tracing information, currently only routine 
>> entry/exit with a stack depth counter, which I have needed to discover some 
>> (rare !) faults in the tools library, although I have not yet added the code 
>> to select the option from the command line, necessitating recompiling the 
>> compiler to change settings ..... !
>>
>> On the performance front, I think that some level of routine inlining is 
>> fairly urgent; doing a C routine call to evaluate INTEGER_32.infix ">=, and 
>> similarly with ">", "|", "|<<", "|>>", INTEGER_8.to_integer_32 etc is 
>> somewhat performance limiting ....
>>     
>
> I'll see what I can do.
> Do you have any benchmarks showing how bad performance is?
>
>   
>> I have modified the report_giaaa calls to be of the form:
>> 	error_handler.report_giaaa ("__CLASS__", "__LINE__")
>> where ET_C_GENERATOR substitutes the above strings for the appropriate strings 
>> for the textual location of the report_giaaa call. Although the code from 
>> where I tracked down a call to this routine has since been modified, I think 
>> the facility could be useful in future.
>>     
>
> This really looks like a hack. When I have internal errors, I run
> gec in EiffelStudio and I put some break-points on that routine.
> That way I get even more information from EiffelStudio's debugger
> about the context of the internal error.
>
>   
>> For the longer term, I am still interested in the problems and potential 
>> solutions needed to be able to dynamically add one or more class libraries 
>> into a running system, as one can do (carefully !) with Java. The added 
>> classes would have to have been compiled against the same kernel/base classes 
>> as the running system, or at least have no incompatibilities with them. 
>>
>> Firstly, for performance reasons I want to be able to separately compile the 
>> classes that are changing rapidly from those that are unchanging when 
>> developing a project.
>>
>> And secondly I think that one of the aspects of Eiffel that is holding back 
>> some commercial acceptance is that to compile a system, or any variant of any 
>> system, one currently needs a complete set of source code to all classes in 
>> the system for the compiler to work.
>>
>> It should be possible for the IDE/compiler to dynamically load a pre-compiled 
>> library (.so or .dll), inspect it to retrieve the same required information 
>> that one would derive from compiling the sources, and generate new 
>> clients/descendants that can be based on the loaded library. 
>>
>> I have been looking at ET_C_GENERATOR.print_polymorphic_xxx_calls and thinking 
>> about how one would dynamically allocate and register type_ids and data 
>> structures to lookup routine addresses and attribute offsets etc.
>>     
>
> One thing that should be considered when implementing dynamic
> class loading is that gec currently relies on the dynamic
> type set mechanism in order to determine which calls are polymorphic
> or not, what are the possible types at run-time for a given entity,
> etc. This is both convenient (because the dynamic type set mechanism
> was implemented before the C code generation) and allows more
> optimizations (less code needs to be compiled, reduce the number
> of polymorphic calls).
>
> An alternative mechanism would need to be put in place in
> order to take into account the fact that an entity can actually
> have other types at run-time.
>
>   
>> I went to a couple of workshops at the ECOOP '07 conference in Berlin at the 
>> weekend, and picked up some useful information and contacts relevant to this 
>> area of interest.
>>
>> In applications, I am working on a comparison program for Eiffel texts to 
>> compare classes, selectively excluding things like indexing clauses, 
>> comments, assertions etc, which I will also be integrating into the IDE.
>>     
>
> I started to work on a similar tool at work as well.
> The way I do it is to have a canonical pretty printer that
> does not display comments and other information I'm not
> interested in for the diff, print features in alphabetical
> order (each in its own feature clause with the clients
> it is exported to), feature names in alphabetical order in
> Redefine, Undefine, Create, ... clauses, etc. Then I can compare
> (in a graphical diff tool) too versions of the same class
> using their canonical pretty-printed versions. This is still
> a work in progress, and I have nothing to show yet.
>
>   
>> I am interested in working with others on what I am doing, and welcome 
>> feedback on ideas and from potential users of EDP, which is approaching (for 
>> me at any rate!) being useable as a substitute for my existing editing system 
>> (Code Crusader) and is already my only Eiffel compilation system in 
>> conjunction with the (modified) GEC command line equivalent.
>>
>> My immediate priorities are GC and threads, but the earlier I am able to 
>> cooperate with others in what is being designed and coded, the faster we will 
>> all achieve results.
>>     
>
> For the GC, last week I successfully plugged the Boehm GC:
>
>     http://en.wikipedia.org/wiki/Boehm_GC
>     http://www.hpl.hp.com/personal/Hans_Boehm/gc/
>
> to an application at work compiled with gec. Of course it is
> not as optimal as a GC decicated to gec could be. But this is
> encouraging.
>
> As for multi-threading, one thing that would need to be done
> (if you haven't done that yet) is to determine in the C code
> currently generated by gec what are the global variables, what
> are the non-thread-safe function calls, etc. I know for sure
> that the current implementation of once-functions is not
> thread-safe.
>
>   


-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Gobo-Eiffel extensions

[Howard T. <how...@di...>]

Hi Eric,

On Friday 03 August 2007 11:30, you wrote:
> Howard Thomson wrote:
> > The advantage of having the option to retain the existing 'C' routines
> > for such simple operations is the ability to report assertion failures
> > and to provide precise details about the feature where an assertion
> > fails, but for production code having a (frozen) routine generated to
> > execute a single instruction is less than ideal.
>
> Instead of having special treatment for those features in
> basic types, I wanted to have them handled by a more general
> "inlining" mechanism that would work for other user-written
> classes containing small and easily inlinable routines as well.
> But I didn't have time implement such mechanism yet.

I agree that this is the way to go, to inline where:

	The called feature is statically known, as for a frozen or expanded target 
class, or the dynamic type set count is one and dynamic class loading etc is 
prohibited.

The recursively totalled count of Instructions does not exceed some 
specifiable limit.

Either there are no assertions, assertions are not enabled for the inlined 
code, or possibly assertions are inlined as well with restricted reporting of 
the assertion information.

I may have a go at it sometime, once I fully understand how the code 
generation system works with regard to passing arguments to routines and 
consequently how to adapt generated references to routine arguments to the 
arguments being supplied to inlined code.

> > Is there yet an agreed basis for the semantics of 'once' functions in a
> > multi-threaded environment ? Where and how does one specifiy the variety
> > of once semantics that applies to a given feature ?
>
> This is specified in the ECMA Eiffel standard document.
> Did you download it already?

I have previously downloaded it, and had forgotten that it is now specified 
therein. Thanks !

I must re-subscribe to the gobo-eiffel-develop list ...

Regards,

Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] Introspection, persistence, debugger

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Sorry for not answering earlier. I was busy with day-time work.
>
> Wolfgang Jansen wrote:
>> Eric Bezault wrote:
>>> Hi Wolfgang,
>>>
>>> The first rule to follow in the Gobo team is to reply
>>> to the mailing-list. Can you please make sure to do that
>>> in the future? Thank you.
>> Sorry, not sending to that list is the result of the first mail
>> in this thread that was too large. Then all other mails followed
>> the same address: just yours.
>
> I don't understand. I keep adding the address of the mailing list
> each time I reply to your messages, and my reply goes to the mailing
> list. How come this wouldn't work for you.
Maybe, I was not enough diligent.
>
>> So I may ask, can you make sure that one can send also larger
>> attachments to the GOBO's mailing list?
>
> Done.
>
>>>
>>> Wolfgang Jansen wrote:
>>>> Eric Bezault wrote:
>>>>> Wolfgang Jansen wrote:
>>>>>> Eric Bezault wrote:
>>>>>>> Wolfgang Jansen wrote:
>>>>>>>> Eric Bezault wrote:
>>>>>>>>> Hi Wolfgang,
>>>>>>>>>
>>>>>>>>> Wolfgang Jansen wrote:
>>>>>>>>>> I would like to contribute the following
>>>>>>>>>> features/parts to the GEC compiler:
>>>>>>>>>> - introspection (in particular, class INTERNAL)
>>>>>>>>>>  and persistence closure (in particular, class STORABLE),
>>>>>>>>>>  see persist.pdf
>>>>>>>>>> - debugger, see debug.pdf
>>>>>>>>>>
>>>>>>>>>> In the course of recent years I implemented those parts
>>>>>>>>>> for the SE-1.* compiler (not integrated into the
>>>>>>>>>> official release), and the last version is almost
>>>>>>>>>> completely written in Eiffel. Thus, it should be
>>>>>>>>>> possible to integrate the stuff into the GEC as well.
>>>>>>>>>> The integration of introspection and persistence closure
>>>>>>>>>> (at least the core parts) seems to be straight forward
>>>>>>>>>> whereas integrating the debugger is much more involved.
>>>>>>>>>>
>>>>>>>>>> Most of the development still to be done will be my work
>>>>>>>>>> (help about the meaning of existing compiler classes
>>>>>>>>>> and their features may be necessary from time to time).
>>>>>>>>>> Moreover, the development is rather separated from
>>>>>>>>>> the main lines of the development of the compiler,
>>>>>>>>>> therefore, conflicts should be rare. On the other hand,
>>>>>>>>>> things may take some time since it's not my main work.
>>>>>>>>>>
>>>>>>>>>> What do you think about the topic?
>>>>>>>>>
>>>>>>>>> I just finished reading your documents, and here are my
>>>>>>>>> remarks:
>>>>>>>>>
>>>>>>>> The PDF description was rather a user's guide, not a 
>>>>>>>> developer's guide.
>>>>>>>> To answer your remarks it will be wise to sketch the 
>>>>>>>> implementation.
>>>>>>>>>
>>>>>>>>> INTERNAL
>>>>>>>>> --------
>>>>>>>>>
>>>>>>>>> In order to take full advantage of the dynamic type set
>>>>>>>>> mechanism implemented in gec, my plan was to implement
>>>>>>>>> class TYPE first (introduced in ECMA), and then add to
>>>>>>>>> class TYPE the features currently available in INTERNAL.
>>>>>>>>> The features of INTERNAL could be implemented using those
>>>>>>>>> from TYPE in order to allow backward compatibility for
>>>>>>>>> applications currently compiled with ISE. Let's consider
>>>>>>>>> that we have in ANY:
>>>>>>>>>
>>>>>>>>>    generating_type: TYPE [like Current]
>>>>>>>>>
>>>>>>>>> and in class TYPE:
>>>>>>>>>
>>>>>>>>>    attribute_count: INTEGER
>>>>>>>>>         external
>>>>>>>>>              "built_in"
>>>>>>>>>
>>>>>>>>> we could implement `field_count' in INTERNAL as follows:
>>>>>>>>>
>>>>>>>>>    Result := object.generating_type.attribute_count
>>>>>>>>>
>>>>>>>>> and likewise for the other features in INTERNAL. In your
>>>>>>>>> document you mentioned a class INTRO_TYPES. Is it similar
>>>>>>>>> to class TYPE above? In the generated C code there is
>>>>>>>>> already an array 'getypes' whose purpose will be to return
>>>>>>>>> a TYPE object indexed by type-id.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> As mentioned in the description, class INTERNALS is just a 
>>>>>>>> wrapper class.
>>>>>>>> The heart of introspection is a couple of classes INTRO_TYPE,
>>>>>>>> INTRO_FIELD etc. which mirror information contained in compiler 
>>>>>>>> classes
>>>>>>>> (RUN_CLASS, ... in case of SE, possibly ET_DYNAMIC_TYPE, ...
>>>>>>>> in case of GEC) as far as needed during runtime. Moreover, the 
>>>>>>>> classes
>>>>>>>> have features needed during runtime only (e.g. creating an object
>>>>>>>> of the type in question). The compiler's part is to strip the 
>>>>>>>> appropriate
>>>>>>>> information from RUN_CLASS, ... objects to make INTRO_TYPE, ...
>>>>>>>> objects and to write the result to C code.
>>>>>>>>
>>>>>>>> The approach should be open to implement class TYPE by means
>>>>>>>> of class INTRO_TYPE.
>>>>>>>
>>>>>>> Does that mean that interoperability with ISE will be broken?
>>>>>> I don't know, my knowledge of ISE is rather poor.
>>>>>>> Currently class TYPE is in FreeELKS, and the idea is that both
>>>>>>> ISE and Gobo use the same class for interoperability. The trick
>>>>>>> is to use 'external "built_in"' to let the each compiler plug
>>>>>>> its own runtime. My feeling if we want interoperability with ISE
>>>>>>> is that all features needed to implement introspection need to
>>>>>>> be in FreeELKS. This mean that either everything needed is in
>>>>>>> class TYPE (or INTERNAL) and your classes INTRO_TYPE/INTRO_FIELD
>>>>>>> are based on that. Or your classes INTRO_TYPE/INTRO_FIELD
>>>>>> Is it a joke? Do you really want to base elementary classes
>>>>>> on complex ones?
>>>>>
>>>>> Well, I know nothing about your classes except that you
>>>>> want to use them to implement other parts of your contribution.
>>>> The appendix contains the short form (still SE generated) of the 
>>>> classes.
>>>
>>> I cannot see it in the document you sent me.
>> Sorry once again, I simply forgot the attachment.
>> The outline of the class hierarchy is as follows:
>>
>> INTRO_SYSTEM provides the top object containing
>>  arrays of type, agent, and class descriptions.
>> INTRO_TYPE describes one type
>>  (e.g. base class, attributes, routines)
>> INTRO_AGENT describes one agent definition
>>  (e.g. routine, closed arguments)
>> INTRO_EFFECTIVE describes one effective routine
>>  (e.g. name, arguments, local variables)
>> INTRO_FIELD describes one attribute, argument,
>>  local variable, or closed argument (e.g. name)
>> INTRO_ONCE_VALUE is a heir of INTRO_FIELD
>>  (has additionally the locations of value and flag)
>>
>> The next classes are primarily used by the debugger:
>> INTRO_CLASS describes one class text
>>  (e.g. name, features)
>> INTRO_FEATURE describes a feature within INTRO_CLASS
>>  (e.g. name, line number)
>> INTRO_CONST, INTRO_ROUTINE are heirs of INTRO_FEATURE
>
> There is something I'm not sure to understand. Your classes
> seems to be mutable. There are some setters, etc. So, how does
> it work? Does the compiler generate some C code that can then
> be accessed from these classes. Or does the compiler generate
> Eiffel code to create and populate the introspection classes.
> The latter seems more likely to me, otherwise why have these
> setters (unless you want to be able to modify your program
> while executing it). In that case, does that mean that the
> compiler has to compile the code it just generated?
Yes, the objects are mutable. The reason is as follows.
When retrieving an object's persistence closure generated
by a system different from the current one then type descriptions
occurring in the store file may have no (or not exact) counter part
in the running system. Therefore, during retrieval new INTRO_TYPE
etc. objects are created describing the data in the store file.
These new objects are filled step by step by the setter routines.
(After finishing such a new object it is associated to an existing
INTRO_TYPE, ... object the "best possible" way.)
On the other hand, the INTRO_TYPE, ... objects describing
the running system exist exactly once. They are created by
the compiler and written to C code as initialized global variables.
These objects are not visible by programmer's Eiffel code.

OK, one can imagine a type hierarchy where each class INTRO_TYPE, ...
is replaced by two: an immutable base class and a mutable heir class.
>
>>>
>>>>> I don't even know what might be the difference between TYPE
>>>>> and INTRO_TYPE. So it's hard to say why one is more complex
>>>>> than the other. I can see that one might be more object-oriented,
>>>>> but more basic/complex? The only thing that I know is that
>>>>> if we want to have some interoperability with ISE, either
>>>>> we add what is needed in class TYPE because it seems to be
>>>>> the chosen mechanism by ECMA to have an embryo of introspection.
>>>>> Or we decide that your approach is better/more elegant/more
>>>>> object-oriented and we discuss with ISE and ECMA to replace
>>>>> TYPE by your solution.
>>>>>
>>>> My solution is more elementary since class INTRO_TYPE
>>>> is not generic. 
>>>
>>> I don't see why not being generic makes it more elementary.
>>> The advantage of having TYPE generic is that we can have
>>> `new_instance' which returns an object whose type is known
>>> at compilation time. Apart from that, why is the fact that
>>> INTRO_TYPE is not generic making it more elementary?
>> Maybe, that we have different opinions of the term "elementary".
>>>
>>>> It is more object-orientated since it provides
>>>> different classes, including inheritance if appropriate, for
>>>> different abstractions. It is less elegant, at least less programmer
>>>> friendly (the generic parameter of class TYPE lets the programmer
>>>> express the type of interest). It is more flexible since it is
>>>> our decision which features to add, remove, or modify.
>>>
>>> If these features require some compiler support, then it means
>>> that we gain flexibility but lose interoperability with other
>>> Eiffel compilers.
>> Of course.
>>>
>>>> Is it better? I don't know, too many criteria are to be considered.
>>>>
>>>> I'm more and more convinced that class TYPE may be
>>>> implemented on base of class INTRO_TYPE.
>>>> For example:
>>>>
>>>>   class TYPE[G]
>>>>
>>>>   create set_internal
>>>>
>>>>   feature {NONE} -- Initialization
>>>>
>>>>      set_internal(i: like internal) is
>>>>         do
>>>>            internal := i
>>>>         end
>>>>
>>>>   feature
>>>>
>>>>      name: STRING is
>>>>         do
>>>>            Result := internal.base_class.name
>>>>         end
>>>>
>>>>      -- other features
>>>>
>>>>   feature {NONE} -- Implementation
>>>>
>>>>      internal: INTRO_TYPE
>>>>
>>>>   end
>>>
>>> But the reverse could also be true. I don't see why we could
>>> not implement INTRO_TYPE with features of TYPE. Why couldn't
>>> TYPE be equipped with features that would provide information
>>> about its base class, about its attributes, ...
>> Besides the different opinions about "more elementary",
>> we should not do so since INTRO_TYPE is essentially ready
>> whereas TYPE is merely a concept. We cannot implement
>> INTRO_TYPE on base of TYPE because this does not exist.
>>
>> My idea was not to force GEC to integrate my stuff,
>> the idea was to help closing some gaps. I see, this was a bad idea.
>
> For the sake of interoperability, I think that the gap to be closed
> in terms of introspection should be addressed by ECMA and FreeELKS
> first. So I would suggest that you submit your introspection library
> interface to FreeELKS so that all compilers supporting FreeELKS can
> agree to support it. Then we can safely integrate it to gec without
> breaking interoperability.
>
>
Well, that's an idea. But don't believe that standardizing consorts
are interested: the stuff provides an implementation of
introspection etc. but no new concept.
>>>
>>>
>>>> One point is, when to generate an object of, say, TYPE[STRING].
>>>> Will be there exactly one object for each type occurring in the 
>>>> system,
>>>
>>> Yes.
>>>
>>>> possibly from the program's startup? Having more objects per
>>>> generic parameter is meaningless since each describes the same thing.
>>>> Another point is, having an object of TYPE[STRING] then
>>>> also TYPE[STRING] is an alive type and we need type
>>>> TYPE[TYPE[STRING]] either. You see, we immediately
>>>> enter an infinite recursion.
>>>
>>> The infinite recursion only occurs when you want to introspect
>>> on objects of type TYPE.
>> Why not? And by Murphy's law, someone will do that sometime.
>
> One solution could be to have a class META_TYPE (non-generic descendant
> of TYPE) in that case. But there are other solutions which would
> require compiler support.
>
>>>
>>>> To the first point: my solution provides one type, namely
>>>> INTRO_TYPE, and exactly one object of that type for each
>>>> type in the system. Well, there is also an object for INTRO_TYPE
>>>> itself, but this does not cause infinite recursion.
>>>> If based on this solution then it should be possible to implement
>>>> class TYPE such that exactly one object exists for each necessary
>>>> generic parameter value, simply by mapping the objects of
>>>> INTRO_TYPE to those of TYPE[G]. The advantage of is
>>>> that classes INTRO_TYPE etc. already exist.
>>>> What remains to do is to create objects of these types by extracting
>>>> information from objects of ET_DYNAMIC_TYPE etc.,
>>>> and then, when this works, to implement class TYPE.
>>>>
>>>> To the second point: Of course, class TYPE needs a special
>>>> treatment to avoid the infinite recursion. Here, the approach
>>>> to implement TYPE on top of INTRO_TYPE does not help.
>>>
>>> The recursive recursion is something that has already been
>>> discussed at ECMA and is being addressed. I don't think that
>>> this is a show-stopper, knowing class TYPE is known by the
>>> compiler.
>>>
>>>> There is no question whether to follow ECMA or not, and it is
>>>> no question that class TYPE should _not_ be replaced by classes
>>>> INTRO_TYPE etc. 
>>>
>>> Well, the question is about interoperability. And this is where
>>> ECMA, ISE and FreeELKS are concerned. I don't think it is good
>>> for Eiffel to have libraries which only work with SmartEiffel
>>> or only work with ISE. Let's try not to repeat these mistakes
>> I fully agree.
>>> in Gobo. I keep coming back to class TYPE because that's the
>>> only entry point that we currently have for interoperability
>>> in the introspection world. Here I speak about TYPE as a basic
>>> class (equipped with 'external "built_in"' features), not as
>>> something based on even more basic classes. As I already said,
>> Does "built_in" mean that it should be implemented in C?
>> If so then you can immediately forget my contribution.
>
> Currently gec only supports "built_in" implemented in C.
> But I know that in EiffelStudio, their "built_in" are
> implemented by substituting some Eiffel code.
I thought about the point once again and I don't think anymore
that "built_in" in C is really an obstacle: let the C code call
the Eiffel code of the INTRO_TYPE, ... classes (some sort
of "light weight cecil"). In fact, I used that approach already
to invoke the debugger (SE version).
One problem is the maintenance if the interface from
C to Eiffel is very rich (in case of the debugger I could reduce
the interface to just one routine making the approach acceptable).

>
>>> if you think that your classes are/should be more basic that TYPE
>> I think that they _are_ more basic (OK, that's nothing new).
>>> (or that TYPE cannot achieve the kind of introspection that you
>> Yes, for debugging I need, e.g., the line numbers of features etc. 
>> which,
>> to my knowledge, TYPE will not provide.
>>> have in mind), then we should discuss that with ECMA/ISE/FreeELKS
>>> at all means rather than introducing interoperability issues.
>>>
>>>> The question is, whether to use these classes
>>>> as a basis of the implementation of the former one.
>>>> And the question is, whether to use these classes directly
>>>> to implement the persistence closure or indirectly via class TYPE.
>>>> I think that the direct use is more efficient.
>>>> If class TYPE is implemented on the base of class INTRO_TYPE
>>>> then the final question is, whether this should be a solution
>>>> for eternity or merely a temporary solution for now.
>>>>>> What makes sense is to implement class TYPE
>>>>>> on base of classes INTRO_TYPE etc. Where to locate the classes,
>>>>>> together with class TYPE in FreeEKLS or in a more hidden cluster,
>>>>>> is a secondary question.
>>>>>>> (by the way, I'm not a big fan of these class names) should be
>>>>>> By the way, INTRO_TYPE etc. are the _current_ class names.
>>>>>> Changing them is no problem and will be done for the GEC version.
>>>>>> Please, do not misunderstand the final state for SE to be also
>>>>>> the final state for GEC.
>>>>>>> added to FreeELKS with the proper 'external "built_in"' routines
>>>>>>> to let other compilers like ISE be able to plug their 
>>>>>>> implementation.
>>>>>>> In either case, I think that it is better to discuss with ISE
>>>>>>> about what we could do with FreeELKS in order to make available
>>>>>>> in an interoperable way the features that you need to implement
>>>>>>> introspection.
>>>>>>>
>>>>>>>>> STORABLE
>>>>>>>>> --------
>>>>>>>>>
>>>>>>>>> It would indeed be interesting to plug your implementation
>>>>>>>>> of STORABLE in gec. I have two concerns though. First, are
>>>>>>>>> you aware that ISE also implemented a version of Storable
>>>>>>>>> in Eiffel:
>>>>>>>>>
>>>>>>>>> http://dev.eiffel.com/cgi-bin/viewvc.cgi/trunk/Src/library/base/ise/serialization/ 
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I knew only older variants (it's at least three years ago that 
>>>>>>>> I played with ISE),
>>>>>>>> and I played also with serialization but did not analyze it.
>>>>>>>>> As far as I understood, they only use INTERNAL. So I wonder
>>>>>>>>> whether you should try to use the experience you gained when
>>>>>>>>> developing your Storable for SmartEiffel and try to improve
>>>>>>>>> ISE's SED library rather than providing a competing library.
>>>>>>>>>
>>>>>>>> I developed the stuff from scratch (I started in 2001 or 02  when
>>>>>>>> ISE was not yet open). What I've just read, so has ISE's approach
>>>>>>>> a similar class hierarchy but the underlying implementation
>>>>>>>> seems to be quite different.
>>>>>>>> In any case, my approach is bases on classes INTRO_TYPE, etc.
>>>>>>>> not on class INTERNALS.
>>>>>>>>> The other concern that I have is interoperability. It would
>>>>>>>>> be nice if gec could at least have a way to read and write
>>>>>>>>> the file formats produced by the old ISE's STORABLE mechanism
>>>>>>>>> (at least independent_store). And why not also the file format
>>>>>>>>> produced by SE 2.*, although I'm less interested in this one ;-)
>>>>>>>>> It may be sound odd to try to be interoperable with ISE's old
>>>>>>>>> STORABLE, but that's something I will need at work (we have a
>>>>>>>>> lot of Storable files like that). And probably others currently
>>>>>>>>> using ISE Eiffel will have the same need. So this will have
>>>>>>>>> to be implemented at some stage.
>>>>>>>>>
>>>>>>>> Yes, I understand. The point was that I did not know ISE's
>>>>>>>> store format. (The appendix of file "persist.pdf" contains the BNF
>>>>>>>> of the store format I use. Are you aware of an analog description
>>>>>>>> of ISE's store format? Knowing this would be a great help.)
>>>>>>>
>>>>>>> Each time I asked ISE I was told that I should read the source
>>>>>>> code.
>>>>>>>
>>>>>> I downloaded the stuff yesterday. Maybe that I have time to study it
>>>>>> on weekend. It will be rather hard to understand it.
>>>>>>>> On the other hand, I know the store format of SE. In fact,
>>>>>>>> it is possible to store in that format, but not to read from.
>>>>>>>>
>>>>>>>> The implementation is based on a class PERSISTENCE_CLOSURE
>>>>>>>> managing the traversal through the persistence closure and
>>>>>>>> on deferred classes PERSISTENCE_SOURCE and
>>>>>>>> PERSISTENCE_TARGET for handling elementary data.
>>>>>>>> Effective descendants of the latter two are combined
>>>>>>>> with the first to get the desired effect. As sources exist
>>>>>>>> reading from memory and from a file written by the corresponding
>>>>>>>> target class. The question whether ISE's store format will
>>>>>>>> be readable is the question whether it will be possible
>>>>>>>> to implement a new source class while keeping class
>>>>>>>> PERSISTENCE_CLOSURE as it is.
>>>>>>>> On the other hand, there are much more effective target
>>>>>>>> classes,in particular those which generate output that is
>>>>>>>> not devoted to be re-read by PERSISTENCE_CLOSURE.
>>>>>>>> Among those target classes is one that generates SE's
>>>>>>>> store format and one that writes, at the end of compilation,
>>>>>>>> the INTRO_TYPE, ... objects to C code. As for ISE,
>>>>>>>> the question whether the SE store format can be read
>>>>>>>> is the question whether an appropriate heir of class
>>>>>>>> PERSISTENCE_SOURCE can be implemented.
>>>>>>>> And here I know the answer: it is not possible.
>>>>>>>>
>>>>>>>> I final remark: classes SERIALIZER and SERIALIZE
>>>>>>>> mentioned in the description are merely wrapper classes
>>>>>>>> to make programmer's life easier.
>>>>>>>>> deep_twin
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>> You didn't mention it in your message, but it is mentioned
>>>>>>>>> in your document. None of the deep features are implemented
>>>>>>>>> yet in gec. Even though I don't like to use deep_twin myself
>>>>>>>>> (I prefer to control the level of duplication I want by
>>>>>>>>> redefining `copy'), one of the programs I currently try to
>>>>>>>>> compile with gec at work uses it. So it will need to be
>>>>>>>>> implemented soon.
>>>>>>>>>
>>>>>>>> In fact, I didn't try it so far, but I'm sure it will work.
>>>>>>>> The only bad thing is that the general approach causes overhead
>>>>>>>> in space and time slowing down the `deep_twin' by some factor.
>>>>>>>> Of the other routines, `deep_copy' will be quite similar to
>>>>>>>> `deep_twin' whereas `deep_is_equal' is different:
>>>>>>>> we have two sources and no target. Maybe that one can
>>>>>>>> misuse the target as one another source.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Debugger
>>>>>>>>> --------
>>>>>>>>>
>>>>>>>>> This topic is something that I'm not very good at. So I really 
>>>>>>>>> need
>>>>>>>>> to rely on others to implement a good debugging mechanism for 
>>>>>>>>> gec.
>>>>>>>>> I have not really thought about it. My only requirement is that
>>>>>>>>> it should be user-friendly and should do what people expect from
>>>>>>>>> a debugger. So people who want to contribute in this area will
>>>>>>>>> be free to do pretty much what they want, also I will be 
>>>>>>>>> interested
>>>>>>>>> in following their progress.
>>>>>>>>>
>>>>>>>>> But gec is not as advanced as SmartEiffel with respect to
>>>>>>>>> debugging. There is currently only one compilation mode, with
>>>>>>>>> no stack trace, no assertion monitoring, no exception. So
>>>>>>>>> everything needs to be done in this area. If this is not
>>>>>>>>> frightening you, then that would be great.
>>>>>>>>>
>>>>>>>> The debugger started as a by-product of introspection/persistence
>>>>>>>> closure: to implement an "evaluate" (or "print") command
>>>>>>>> one needs introspection. Since the SE debugger did that time
>>>>>>>> (yes, it is long ago) not support evaluation even of the most
>>>>>>>> simple expressions, I added such a command to the debugger.
>>>>>>>> And since I'm a friend of debuggers, I continued the work
>>>>>>>> to make the debugger more user friendly, finally,  to implement
>>>>>>>> it in Eiffel.
>>>>>>>>
>>>>>>>> Expression evaluation of the debugger is based on the
>>>>>>>> introspection discussed above (whether INTRO_TYPE
>>>>>>>> directly or indirectly via TYPE is of minor concern).
>>>>>>>> Well, expression evaluation is just a part of debugging,
>>>>>>>> but an inevitable part. Thus, whether I can add the debugger
>>>>>>>> to GEC is also the question whether my approach of
>>>>>>>> introspection will been added.
>>>>>>>>
>>>>>>>> In any case, adding the debugger (probably any debugger)
>>>>>>>> to GEC will have much more impact on the compiler and
>>>>>>>> the generated C code than introspection. This will cause
>>>>>>>> more discussion and negotiation.
>>>>>>>
>>>>>>> But since the compilation mode for debugging does not exist
>>>>>>> yet (only the equivalent of SE's boost mode is implemented),
>>>>>>> I think that it should be less controversial than if such
>>>>>>> compilation mode already existed and needed to be adapted.
>>>>>>> Here I wonder if we could simply have a class ET_DEBUG_C_GENERATOR
>>>>>>> which inherits from ET_C_GENERATOR. Or have something like
>>>>>>> that:
>>>>>>>
>>>>>>>                    ET_C_GENERATOR*
>>>>>>>                      ^       ^
>>>>>>>                     /         \
>>>>>>> ET_FINALIZE_C_GENERATOR    ET_WORKBENCH_C_GENERATOR
>>>>>> Yes, it was my idea, too, to put much of the work into code 
>>>>>> generation
>>>>>> (and in case of GEC, in contrast to SE, it is well concentrated).
>>>>>> Nevertheless, a class ET_WORKBENCH_C_GENERATOR
>>>>>> will be not sufficient.
>>>>>> First of all, the debugger is written in Eiffel but the user written
>>>>>> program does not contain an object of class DEBUGGER
>>>>>> (or which class name you like). Thus, the class will normally not
>>>>>> be compiled and the executable will not have debugging facility.
>>>>>> What's needed is to compile class DEBUGGER additionally to
>>>>>> the user's system as a second root class and to create an object
>>>>>> of that class during runtime as a second root object.
>>>>>> Second, during compilation one has to decide what to do with
>>>>>> classes and features that occur twice: generating them twice
>>>>>> and giving them different C names, or reusing in the debugger
>>>>>> class what has been generated outside of them (causing that
>>>>>> the debugger will debug itself, possibly an infinite recursion).
>>>>>> The duplication of the root and possibly other code is
>>>>>> what I mean by large impact onto the compiler.
>>>>>>>
>>>>>>>>>
>>>>>>>>> You spoke about your availability to work on this project.
>>>>>>>>> INTERNAL/TYPE and deep_twin are something that I will need
>>>>>>>>> relatively soon. So I guess I should start implementing
>>>>>>>>> them myself. Of course it does not mean that you cannot
>>>>>>>>> help or that I won't need your help. For STORABLE,
>>>>>>>>> what I will need will be something similar to ISE's
>>>>>>>>> independent store. I don't think that any of us can
>>>>>>>>> implement that in short amount of time. I guess that
>>>>>>>>> you would prefer to work on your own Storable format (which
>>>>>>>>> looks interesting just by reading you document), although it
>>>>>>>>> would be nice if you could have a look at ISE's SED and see
>>>>>>>>> if/how it could be improved. The part of your contribution
>>>>>>>>> offer that I would be the most interested in, considering
>>>>>>>>> my need and your availability, would be the debugger part.
>>>>>>>>> Indeed, this is not something that I need in the short term,
>>>>>>>>> so you have plenty of time to work on it without too much
>>>>>>>>> constraints. There is not that much conflicting parts with
>>>>>>>>> what I currently work on in the compiler. And this is something
>>>>>>>>> that I don't think I will be able to implement myself anyway.
>>>>>>>>> And everything needs to be done from scratch. So if you are
>>>>>>>>> not frightened by that, this could be an interesting experience.
>>>>>>>>>
>>>>>>>> As already mentioned, the core part of introspection/persistence
>>>>>>>> (i.e introspection of types and attributes, not routines
>>>>>>>> and local variables, not class TYPE; persistence without
>>>>>>>> class ACTIONABLE, not ISE's format) should be not very
>>>>>>>> difficult. Besides the general task to replace SE specific classes
>>>>>>>> and features by GOBO specific ones, there remains only
>>>>>>>> the extraction of relevant information from classes
>>>>>>>> ET_DYNAMIC_TYPE etc.
>>>>>>>> I think that I can tell you tomorrow evening
>>>>>>>> how much time will be needed.
>>>>>>>>> Now I should mention that people contributing to the Gobo
>>>>>>>>> project need to follow some programming rules. It is difficult
>>>>>>>>> to follow them at first because most of them are not explicitly
>>>>>>>>> stated. Some are here:
>>>>>>>>>
>>>>>>>>>    http://www.gobosoft.com/eiffel/gobo/guidelines/
>>>>>>>>>
>>>>>>>>> Some are just implicit (just look at how the other classes
>>>>>>>>> in Gobo look like). The idea is to have a Gobo package where
>>>>>>>>> all classes follow the same programming style so that we have
>>>>>>>>> some sort of uniformity, instead of being a set of independently
>>>>>>>>> developed parts.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>


-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Gobo-Eiffel extensions

[Eric B. <er...@go...>]

Howard Thomson wrote:
> The advantage of having the option to retain the existing 'C' routines for 
> such simple operations is the ability to report assertion failures and to 
> provide precise details about the feature where an assertion fails, but for 
> production code having a (frozen) routine generated to execute a single 
> instruction is less than ideal.

Instead of having special treatment for those features in
basic types, I wanted to have them handled by a more general
"inlining" mechanism that would work for other user-written
classes containing small and easily inlinable routines as well.
But I didn't have time implement such mechanism yet.

> Is there yet an agreed basis for the semantics of 'once' functions in a 
> multi-threaded environment ? Where and how does one specifiy the variety of 
> once semantics that applies to a given feature ?

This is specified in the ECMA Eiffel standard document.
Did you download it already?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Gobo-Eiffel extensions

[Howard T. <how...@di...>]

Hi Eric,

On Thursday 02 August 2007 19:53, you wrote:
> Hi Howard,
>
> Howard Thomson wrote:
> > I am continuing to work on my project based on gobo-eiffel, named EDP,
> > the Eiffel Developer's Project on Sourceforge, although I haven't been
> > keeping the SF SVN repository up-to-date with my work.
> >
> > In preparation for adding a stack trace, I have modified my
> > ET_C_GENERATOR to be able to allocate stack locals and Result within a
> > locally declared C struct, with the intention of adding, within each
> > routine, a 'once' section of code that generates an instance of TYPE (or
> > similar), so that capturing a stack trace captures a list of objects
> > cloned from the stack frames and also captures the detail to enable
> > Eiffel code to examine it.
>
> As I already mentioned with Wolfgang, I wonder whether we should
> have a class ET_DEBUG_C_GENERATOR which inherits from ET_C_GENERATOR.
> Or have something like that:
>
>                      ET_C_GENERATOR*
>                        ^       ^
>                       /         \
>    ET_FINALIZE_C_GENERATOR    ET_WORKBENCH_C_GENERATOR
>
> The code for stack trace and other debugging facilities could
> then go to ET_WORKBENCH_C_GENERATOR (or ET_DEBUG_C_GENERATOR,
> or whatever the name), and optimized code (what is in fact currently
> implemented in ET_C_GENERATOR, even though more optimization
> could/should be implemented) could go to ET_FINALIZE_C_GENERATOR.
> And common code stays in ET_C_GENERATOR. We could also have other
> descendants for multi-threaded application generation.

There is certainly a need to separate out some aspects of the existing 
ET_C_GENERATOR. I want to be able to generate x86-ELF, x86-COFF, x86-64-ELF, 
and x86-64-COFF (shared) libraries directly instead of using gcc etc, and 
intend using or re-implementing in Eiffel the concepts in the LLVM code 
generation system at llvm.org.

>
> > The ability to do an exact inspection of the stack is also necessary for
> > a precise Garbage Collector implementation, which I am also working on,
> > on the basis that the GC should operate per-thread, and the primary
> > (preferably only) means of communication between threads (other than
> > probing for debugging) should be using some form of messaging implemented
> > using deep_copy semantics.
> >
> > As my adapted code from the Slyboots GUI project uses user-expanded
> > types, I have also adapted ET_C_GENERATOR to generate dynamic_types to
> > avoid the 'C struct' inclusion ordering error that afflicted the version
> > from which I started.
>
> This should be fixed in the current version in SourceForge.
>
> > I am interested in any existing and proposed introspection code in that
> > it is needed for the debugging inspection of a suspended thread, and I
> > will also need it for future Eiffel projects using database storage etc.
>
> I'm still dreaming to have an introspection mechanism that would
> work with all compilers.
>
> BTW Wolfgang, I saw that you also approached the SmartEiffel 1.2 team
> about your introspection library. Did you get any answer?
>
> > I have added some code to generate tracing information, currently only
> > routine entry/exit with a stack depth counter, which I have needed to
> > discover some (rare !) faults in the tools library, although I have not
> > yet added the code to select the option from the command line,
> > necessitating recompiling the compiler to change settings ..... !
> >
> > On the performance front, I think that some level of routine inlining is
> > fairly urgent; doing a C routine call to evaluate INTEGER_32.infix ">=,
> > and similarly with ">", "|", "|<<", "|>>", INTEGER_8.to_integer_32 etc is
> > somewhat performance limiting ....
>
> I'll see what I can do.
> Do you have any benchmarks showing how bad performance is?

Well it is most noticeable in my GUI code that has, re-coded in Eiffel, 
routines to process icon images etc for the screen dialogs, and it is very 
apparent that the original C++ code in the Fox library is MUCH faster. There 
is a quite noticeable delay in opening a dialog with several icons the first 
time, whereas for other aspects of Gobo compiled code the performance hit is 
more diffuse.

The advantage of having the option to retain the existing 'C' routines for 
such simple operations is the ability to report assertion failures and to 
provide precise details about the feature where an assertion fails, but for 
production code having a (frozen) routine generated to execute a single 
instruction is less than ideal.

> > I have modified the report_giaaa calls to be of the form:
> > 	error_handler.report_giaaa ("__CLASS__", "__LINE__")
> > where ET_C_GENERATOR substitutes the above strings for the appropriate
> > strings for the textual location of the report_giaaa call. Although the
> > code from where I tracked down a call to this routine has since been
> > modified, I think the facility could be useful in future.
>
> This really looks like a hack. When I have internal errors, I run
> gec in EiffelStudio and I put some break-points on that routine.
> That way I get even more information from EiffelStudio's debugger
> about the context of the internal error.

It IS a hack (of course), only made necessary by the current lack of stack 
trace information and assertion checking.

I intend that for 'debug' generated code, that there would be a separate GUI 
capable initial thread that would be capable of suspending, reacting to 
suspensions of, and probing other threads in the debug executable, with some 
needed wrapping of system calls to avoid unwanted interactions between the 
debug thread and the rest of the system. Whereas ES (I think) uses 
instruction modification to do breakpoints, I envisage using (slower) trace 
capable code and flag checks.

First I need to move to two threads .....

>
> > For the longer term, I am still interested in the problems and potential
> > solutions needed to be able to dynamically add one or more class
> > libraries into a running system, as one can do (carefully !) with Java.
> > The added classes would have to have been compiled against the same
> > kernel/base classes as the running system, or at least have no
> > incompatibilities with them.
> >
> > Firstly, for performance reasons I want to be able to separately compile
> > the classes that are changing rapidly from those that are unchanging when
> > developing a project.
> >
> > And secondly I think that one of the aspects of Eiffel that is holding
> > back some commercial acceptance is that to compile a system, or any
> > variant of any system, one currently needs a complete set of source code
> > to all classes in the system for the compiler to work.
> >
> > It should be possible for the IDE/compiler to dynamically load a
> > pre-compiled library (.so or .dll), inspect it to retrieve the same
> > required information that one would derive from compiling the sources,
> > and generate new clients/descendants that can be based on the loaded
> > library.
> >
> > I have been looking at ET_C_GENERATOR.print_polymorphic_xxx_calls and
> > thinking about how one would dynamically allocate and register type_ids
> > and data structures to lookup routine addresses and attribute offsets
> > etc.
>
> One thing that should be considered when implementing dynamic
> class loading is that gec currently relies on the dynamic
> type set mechanism in order to determine which calls are polymorphic
> or not, what are the possible types at run-time for a given entity,
> etc. This is both convenient (because the dynamic type set mechanism
> was implemented before the C code generation) and allows more
> optimizations (less code needs to be compiled, reduce the number
> of polymorphic calls).
>
> An alternative mechanism would need to be put in place in
> order to take into account the fact that an entity can actually
> have other types at run-time.

Yes, absolutely. Either there would have to be some type-set analysis at 
dynamic-load time, or polymorphic calls would have to be more inclusive.

>
> > I went to a couple of workshops at the ECOOP '07 conference in Berlin at
> > the weekend, and picked up some useful information and contacts relevant
> > to this area of interest.
> >
> > In applications, I am working on a comparison program for Eiffel texts to
> > compare classes, selectively excluding things like indexing clauses,
> > comments, assertions etc, which I will also be integrating into the IDE.
>
> I started to work on a similar tool at work as well.
> The way I do it is to have a canonical pretty printer that
> does not display comments and other information I'm not
> interested in for the diff, print features in alphabetical
> order (each in its own feature clause with the clients
> it is exported to), feature names in alphabetical order in
> Redefine, Undefine, Create, ... clauses, etc. Then I can compare
> (in a graphical diff tool) two versions of the same class
> using their canonical pretty-printed versions. This is still
> a work in progress, and I have nothing to show yet.

Yes, re-ordering of features in texts is a difficulty that needs solutions. I 
want to be able to show the sources side-by-side with the differences 
highlighted on a symbol by symbol basis.
>
> > I am interested in working with others on what I am doing, and welcome
> > feedback on ideas and from potential users of EDP, which is approaching
> > (for me at any rate!) being useable as a substitute for my existing
> > editing system (Code Crusader) and is already my only Eiffel compilation
> > system in conjunction with the (modified) GEC command line equivalent.
> >
> > My immediate priorities are GC and threads, but the earlier I am able to
> > cooperate with others in what is being designed and coded, the faster we
> > will all achieve results.
>
> For the GC, last week I successfully plugged the Boehm GC:
>
>     http://en.wikipedia.org/wiki/Boehm_GC
>     http://www.hpl.hp.com/personal/Hans_Boehm/gc/
>
> to an application at work compiled with gec. Of course it is
> not as optimal as a GC decicated to gec could be. But this is
> encouraging.
>
> As for multi-threading, one thing that would need to be done
> (if you haven't done that yet) is to determine in the C code
> currently generated by gec what are the global variables, what
> are the non-thread-safe function calls, etc. I know for sure
> that the current implementation of once-functions is not
> thread-safe.

Agreed.

Is there yet an agreed basis for the semantics of 'once' functions in a 
multi-threaded environment ? Where and how does one specifiy the variety of 
once semantics that applies to a given feature ?

I used the Boehm-GC before when I was developing with SmartEiffel, and for a 
single threaded application it worked fine, at least more reliably than the 
SE GC. I feel the need for the code that I am working on to be lucid and 
complete, and the Boehm-GC doesn't meet my longer-term criteria.

Regards,

Howard

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] Gobo-Eiffel extensions

[Eric B. <er...@go...>]

Hi Howard,

Howard Thomson wrote:
> I am continuing to work on my project based on gobo-eiffel, named EDP, the 
> Eiffel Developer's Project on Sourceforge, although I haven't been keeping 
> the SF SVN repository up-to-date with my work.
> 
> In preparation for adding a stack trace, I have modified my ET_C_GENERATOR to 
> be able to allocate stack locals and Result within a locally declared C 
> struct, with the intention of adding, within each routine, a 'once' section 
> of code that generates an instance of TYPE (or similar), so that capturing a 
> stack trace captures a list of objects cloned from the stack frames and also 
> captures the detail to enable Eiffel code to examine it.

As I already mentioned with Wolfgang, I wonder whether we should
have a class ET_DEBUG_C_GENERATOR which inherits from ET_C_GENERATOR.
Or have something like that:

                     ET_C_GENERATOR*
                       ^       ^
                      /         \
   ET_FINALIZE_C_GENERATOR    ET_WORKBENCH_C_GENERATOR

The code for stack trace and other debugging facilities could
then go to ET_WORKBENCH_C_GENERATOR (or ET_DEBUG_C_GENERATOR,
or whatever the name), and optimized code (what is in fact currently
implemented in ET_C_GENERATOR, even though more optimization
could/should be implemented) could go to ET_FINALIZE_C_GENERATOR.
And common code stays in ET_C_GENERATOR. We could also have other
descendants for multi-threaded application generation.

> The ability to do an exact inspection of the stack is also necessary for a 
> precise Garbage Collector implementation, which I am also working on, on the 
> basis that the GC should operate per-thread, and the primary (preferably 
> only) means of communication between threads (other than probing for 
> debugging) should be using some form of messaging implemented using deep_copy 
> semantics.
> 
> As my adapted code from the Slyboots GUI project uses user-expanded types, I 
> have also adapted ET_C_GENERATOR to generate dynamic_types to avoid the 'C 
> struct' inclusion ordering error that afflicted the version from which I 
> started.

This should be fixed in the current version in SourceForge.

> I am interested in any existing and proposed introspection code in that it is 
> needed for the debugging inspection of a suspended thread, and I will also 
> need it for future Eiffel projects using database storage etc.

I'm still dreaming to have an introspection mechanism that would
work with all compilers.

BTW Wolfgang, I saw that you also approached the SmartEiffel 1.2 team
about your introspection library. Did you get any answer?

> I have added some code to generate tracing information, currently only routine 
> entry/exit with a stack depth counter, which I have needed to discover some 
> (rare !) faults in the tools library, although I have not yet added the code 
> to select the option from the command line, necessitating recompiling the 
> compiler to change settings ..... !
> 
> On the performance front, I think that some level of routine inlining is 
> fairly urgent; doing a C routine call to evaluate INTEGER_32.infix ">=, and 
> similarly with ">", "|", "|<<", "|>>", INTEGER_8.to_integer_32 etc is 
> somewhat performance limiting ....

I'll see what I can do.
Do you have any benchmarks showing how bad performance is?

> I have modified the report_giaaa calls to be of the form:
> 	error_handler.report_giaaa ("__CLASS__", "__LINE__")
> where ET_C_GENERATOR substitutes the above strings for the appropriate strings 
> for the textual location of the report_giaaa call. Although the code from 
> where I tracked down a call to this routine has since been modified, I think 
> the facility could be useful in future.

This really looks like a hack. When I have internal errors, I run
gec in EiffelStudio and I put some break-points on that routine.
That way I get even more information from EiffelStudio's debugger
about the context of the internal error.

> For the longer term, I am still interested in the problems and potential 
> solutions needed to be able to dynamically add one or more class libraries 
> into a running system, as one can do (carefully !) with Java. The added 
> classes would have to have been compiled against the same kernel/base classes 
> as the running system, or at least have no incompatibilities with them. 
> 
> Firstly, for performance reasons I want to be able to separately compile the 
> classes that are changing rapidly from those that are unchanging when 
> developing a project.
> 
> And secondly I think that one of the aspects of Eiffel that is holding back 
> some commercial acceptance is that to compile a system, or any variant of any 
> system, one currently needs a complete set of source code to all classes in 
> the system for the compiler to work.
> 
> It should be possible for the IDE/compiler to dynamically load a pre-compiled 
> library (.so or .dll), inspect it to retrieve the same required information 
> that one would derive from compiling the sources, and generate new 
> clients/descendants that can be based on the loaded library. 
> 
> I have been looking at ET_C_GENERATOR.print_polymorphic_xxx_calls and thinking 
> about how one would dynamically allocate and register type_ids and data 
> structures to lookup routine addresses and attribute offsets etc.

One thing that should be considered when implementing dynamic
class loading is that gec currently relies on the dynamic
type set mechanism in order to determine which calls are polymorphic
or not, what are the possible types at run-time for a given entity,
etc. This is both convenient (because the dynamic type set mechanism
was implemented before the C code generation) and allows more
optimizations (less code needs to be compiled, reduce the number
of polymorphic calls).

An alternative mechanism would need to be put in place in
order to take into account the fact that an entity can actually
have other types at run-time.

> I went to a couple of workshops at the ECOOP '07 conference in Berlin at the 
> weekend, and picked up some useful information and contacts relevant to this 
> area of interest.
> 
> In applications, I am working on a comparison program for Eiffel texts to 
> compare classes, selectively excluding things like indexing clauses, 
> comments, assertions etc, which I will also be integrating into the IDE.

I started to work on a similar tool at work as well.
The way I do it is to have a canonical pretty printer that
does not display comments and other information I'm not
interested in for the diff, print features in alphabetical
order (each in its own feature clause with the clients
it is exported to), feature names in alphabetical order in
Redefine, Undefine, Create, ... clauses, etc. Then I can compare
(in a graphical diff tool) too versions of the same class
using their canonical pretty-printed versions. This is still
a work in progress, and I have nothing to show yet.

> I am interested in working with others on what I am doing, and welcome 
> feedback on ideas and from potential users of EDP, which is approaching (for 
> me at any rate!) being useable as a substitute for my existing editing system 
> (Code Crusader) and is already my only Eiffel compilation system in 
> conjunction with the (modified) GEC command line equivalent.
> 
> My immediate priorities are GC and threads, but the earlier I am able to 
> cooperate with others in what is being designed and coded, the faster we will 
> all achieve results.

For the GC, last week I successfully plugged the Boehm GC:

    http://en.wikipedia.org/wiki/Boehm_GC
    http://www.hpl.hp.com/personal/Hans_Boehm/gc/

to an application at work compiled with gec. Of course it is
not as optimal as a GC decicated to gec could be. But this is
encouraging.

As for multi-threading, one thing that would need to be done
(if you haven't done that yet) is to determine in the C code
currently generated by gec what are the global variables, what
are the non-thread-safe function calls, etc. I know for sure
that the current implementation of once-functions is not
thread-safe.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Introspection, persistence, debugger

[Eric B. <er...@go...>]

Sorry for not answering earlier. I was busy with day-time work.

Wolfgang Jansen wrote:
> Eric Bezault wrote:
>> Hi Wolfgang,
>>
>> The first rule to follow in the Gobo team is to reply
>> to the mailing-list. Can you please make sure to do that
>> in the future? Thank you.
> Sorry, not sending to that list is the result of the first mail
> in this thread that was too large. Then all other mails followed
> the same address: just yours.

I don't understand. I keep adding the address of the mailing list
each time I reply to your messages, and my reply goes to the mailing
list. How come this wouldn't work for you.

> So I may ask, can you make sure that one can send also larger
> attachments to the GOBO's mailing list?

Done.

>>
>> Wolfgang Jansen wrote:
>>> Eric Bezault wrote:
>>>> Wolfgang Jansen wrote:
>>>>> Eric Bezault wrote:
>>>>>> Wolfgang Jansen wrote:
>>>>>>> Eric Bezault wrote:
>>>>>>>> Hi Wolfgang,
>>>>>>>>
>>>>>>>> Wolfgang Jansen wrote:
>>>>>>>>> I would like to contribute the following
>>>>>>>>> features/parts to the GEC compiler:
>>>>>>>>> - introspection (in particular, class INTERNAL)
>>>>>>>>>  and persistence closure (in particular, class STORABLE),
>>>>>>>>>  see persist.pdf
>>>>>>>>> - debugger, see debug.pdf
>>>>>>>>>
>>>>>>>>> In the course of recent years I implemented those parts
>>>>>>>>> for the SE-1.* compiler (not integrated into the
>>>>>>>>> official release), and the last version is almost
>>>>>>>>> completely written in Eiffel. Thus, it should be
>>>>>>>>> possible to integrate the stuff into the GEC as well.
>>>>>>>>> The integration of introspection and persistence closure
>>>>>>>>> (at least the core parts) seems to be straight forward
>>>>>>>>> whereas integrating the debugger is much more involved.
>>>>>>>>>
>>>>>>>>> Most of the development still to be done will be my work
>>>>>>>>> (help about the meaning of existing compiler classes
>>>>>>>>> and their features may be necessary from time to time).
>>>>>>>>> Moreover, the development is rather separated from
>>>>>>>>> the main lines of the development of the compiler,
>>>>>>>>> therefore, conflicts should be rare. On the other hand,
>>>>>>>>> things may take some time since it's not my main work.
>>>>>>>>>
>>>>>>>>> What do you think about the topic?
>>>>>>>>
>>>>>>>> I just finished reading your documents, and here are my
>>>>>>>> remarks:
>>>>>>>>
>>>>>>> The PDF description was rather a user's guide, not a developer's 
>>>>>>> guide.
>>>>>>> To answer your remarks it will be wise to sketch the implementation.
>>>>>>>>
>>>>>>>> INTERNAL
>>>>>>>> --------
>>>>>>>>
>>>>>>>> In order to take full advantage of the dynamic type set
>>>>>>>> mechanism implemented in gec, my plan was to implement
>>>>>>>> class TYPE first (introduced in ECMA), and then add to
>>>>>>>> class TYPE the features currently available in INTERNAL.
>>>>>>>> The features of INTERNAL could be implemented using those
>>>>>>>> from TYPE in order to allow backward compatibility for
>>>>>>>> applications currently compiled with ISE. Let's consider
>>>>>>>> that we have in ANY:
>>>>>>>>
>>>>>>>>    generating_type: TYPE [like Current]
>>>>>>>>
>>>>>>>> and in class TYPE:
>>>>>>>>
>>>>>>>>    attribute_count: INTEGER
>>>>>>>>         external
>>>>>>>>              "built_in"
>>>>>>>>
>>>>>>>> we could implement `field_count' in INTERNAL as follows:
>>>>>>>>
>>>>>>>>    Result := object.generating_type.attribute_count
>>>>>>>>
>>>>>>>> and likewise for the other features in INTERNAL. In your
>>>>>>>> document you mentioned a class INTRO_TYPES. Is it similar
>>>>>>>> to class TYPE above? In the generated C code there is
>>>>>>>> already an array 'getypes' whose purpose will be to return
>>>>>>>> a TYPE object indexed by type-id.
>>>>>>>>
>>>>>>>>
>>>>>>> As mentioned in the description, class INTERNALS is just a 
>>>>>>> wrapper class.
>>>>>>> The heart of introspection is a couple of classes INTRO_TYPE,
>>>>>>> INTRO_FIELD etc. which mirror information contained in compiler 
>>>>>>> classes
>>>>>>> (RUN_CLASS, ... in case of SE, possibly ET_DYNAMIC_TYPE, ...
>>>>>>> in case of GEC) as far as needed during runtime. Moreover, the 
>>>>>>> classes
>>>>>>> have features needed during runtime only (e.g. creating an object
>>>>>>> of the type in question). The compiler's part is to strip the 
>>>>>>> appropriate
>>>>>>> information from RUN_CLASS, ... objects to make INTRO_TYPE, ...
>>>>>>> objects and to write the result to C code.
>>>>>>>
>>>>>>> The approach should be open to implement class TYPE by means
>>>>>>> of class INTRO_TYPE.
>>>>>>
>>>>>> Does that mean that interoperability with ISE will be broken?
>>>>> I don't know, my knowledge of ISE is rather poor.
>>>>>> Currently class TYPE is in FreeELKS, and the idea is that both
>>>>>> ISE and Gobo use the same class for interoperability. The trick
>>>>>> is to use 'external "built_in"' to let the each compiler plug
>>>>>> its own runtime. My feeling if we want interoperability with ISE
>>>>>> is that all features needed to implement introspection need to
>>>>>> be in FreeELKS. This mean that either everything needed is in
>>>>>> class TYPE (or INTERNAL) and your classes INTRO_TYPE/INTRO_FIELD
>>>>>> are based on that. Or your classes INTRO_TYPE/INTRO_FIELD
>>>>> Is it a joke? Do you really want to base elementary classes
>>>>> on complex ones?
>>>>
>>>> Well, I know nothing about your classes except that you
>>>> want to use them to implement other parts of your contribution.
>>> The appendix contains the short form (still SE generated) of the 
>>> classes.
>>
>> I cannot see it in the document you sent me.
> Sorry once again, I simply forgot the attachment.
> The outline of the class hierarchy is as follows:
> 
> INTRO_SYSTEM provides the top object containing
>  arrays of type, agent, and class descriptions.
> INTRO_TYPE describes one type
>  (e.g. base class, attributes, routines)
> INTRO_AGENT describes one agent definition
>  (e.g. routine, closed arguments)
> INTRO_EFFECTIVE describes one effective routine
>  (e.g. name, arguments, local variables)
> INTRO_FIELD describes one attribute, argument,
>  local variable, or closed argument (e.g. name)
> INTRO_ONCE_VALUE is a heir of INTRO_FIELD
>  (has additionally the locations of value and flag)
> 
> The next classes are primarily used by the debugger:
> INTRO_CLASS describes one class text
>  (e.g. name, features)
> INTRO_FEATURE describes a feature within INTRO_CLASS
>  (e.g. name, line number)
> INTRO_CONST, INTRO_ROUTINE are heirs of INTRO_FEATURE

There is something I'm not sure to understand. Your classes
seems to be mutable. There are some setters, etc. So, how does
it work? Does the compiler generate some C code that can then
be accessed from these classes. Or does the compiler generate
Eiffel code to create and populate the introspection classes.
The latter seems more likely to me, otherwise why have these
setters (unless you want to be able to modify your program
while executing it). In that case, does that mean that the
compiler has to compile the code it just generated?

>>
>>>> I don't even know what might be the difference between TYPE
>>>> and INTRO_TYPE. So it's hard to say why one is more complex
>>>> than the other. I can see that one might be more object-oriented,
>>>> but more basic/complex? The only thing that I know is that
>>>> if we want to have some interoperability with ISE, either
>>>> we add what is needed in class TYPE because it seems to be
>>>> the chosen mechanism by ECMA to have an embryo of introspection.
>>>> Or we decide that your approach is better/more elegant/more
>>>> object-oriented and we discuss with ISE and ECMA to replace
>>>> TYPE by your solution.
>>>>
>>> My solution is more elementary since class INTRO_TYPE
>>> is not generic. 
>>
>> I don't see why not being generic makes it more elementary.
>> The advantage of having TYPE generic is that we can have
>> `new_instance' which returns an object whose type is known
>> at compilation time. Apart from that, why is the fact that
>> INTRO_TYPE is not generic making it more elementary?
> Maybe, that we have different opinions of the term "elementary".
>>
>>> It is more object-orientated since it provides
>>> different classes, including inheritance if appropriate, for
>>> different abstractions. It is less elegant, at least less programmer
>>> friendly (the generic parameter of class TYPE lets the programmer
>>> express the type of interest). It is more flexible since it is
>>> our decision which features to add, remove, or modify.
>>
>> If these features require some compiler support, then it means
>> that we gain flexibility but lose interoperability with other
>> Eiffel compilers.
> Of course.
>>
>>> Is it better? I don't know, too many criteria are to be considered.
>>>
>>> I'm more and more convinced that class TYPE may be
>>> implemented on base of class INTRO_TYPE.
>>> For example:
>>>
>>>   class TYPE[G]
>>>
>>>   create set_internal
>>>
>>>   feature {NONE} -- Initialization
>>>
>>>      set_internal(i: like internal) is
>>>         do
>>>            internal := i
>>>         end
>>>
>>>   feature
>>>
>>>      name: STRING is
>>>         do
>>>            Result := internal.base_class.name
>>>         end
>>>
>>>      -- other features
>>>
>>>   feature {NONE} -- Implementation
>>>
>>>      internal: INTRO_TYPE
>>>
>>>   end
>>
>> But the reverse could also be true. I don't see why we could
>> not implement INTRO_TYPE with features of TYPE. Why couldn't
>> TYPE be equipped with features that would provide information
>> about its base class, about its attributes, ...
> Besides the different opinions about "more elementary",
> we should not do so since INTRO_TYPE is essentially ready
> whereas TYPE is merely a concept. We cannot implement
> INTRO_TYPE on base of TYPE because this does not exist.
> 
> My idea was not to force GEC to integrate my stuff,
> the idea was to help closing some gaps. I see, this was a bad idea.

For the sake of interoperability, I think that the gap to be closed
in terms of introspection should be addressed by ECMA and FreeELKS
first. So I would suggest that you submit your introspection library
interface to FreeELKS so that all compilers supporting FreeELKS can
agree to support it. Then we can safely integrate it to gec without
breaking interoperability.


>>
>>
>>> One point is, when to generate an object of, say, TYPE[STRING].
>>> Will be there exactly one object for each type occurring in the system,
>>
>> Yes.
>>
>>> possibly from the program's startup? Having more objects per
>>> generic parameter is meaningless since each describes the same thing.
>>> Another point is, having an object of TYPE[STRING] then
>>> also TYPE[STRING] is an alive type and we need type
>>> TYPE[TYPE[STRING]] either. You see, we immediately
>>> enter an infinite recursion.
>>
>> The infinite recursion only occurs when you want to introspect
>> on objects of type TYPE.
> Why not? And by Murphy's law, someone will do that sometime.

One solution could be to have a class META_TYPE (non-generic descendant
of TYPE) in that case. But there are other solutions which would
require compiler support.

>>
>>> To the first point: my solution provides one type, namely
>>> INTRO_TYPE, and exactly one object of that type for each
>>> type in the system. Well, there is also an object for INTRO_TYPE
>>> itself, but this does not cause infinite recursion.
>>> If based on this solution then it should be possible to implement
>>> class TYPE such that exactly one object exists for each necessary
>>> generic parameter value, simply by mapping the objects of
>>> INTRO_TYPE to those of TYPE[G]. The advantage of is
>>> that classes INTRO_TYPE etc. already exist.
>>> What remains to do is to create objects of these types by extracting
>>> information from objects of ET_DYNAMIC_TYPE etc.,
>>> and then, when this works, to implement class TYPE.
>>>
>>> To the second point: Of course, class TYPE needs a special
>>> treatment to avoid the infinite recursion. Here, the approach
>>> to implement TYPE on top of INTRO_TYPE does not help.
>>
>> The recursive recursion is something that has already been
>> discussed at ECMA and is being addressed. I don't think that
>> this is a show-stopper, knowing class TYPE is known by the
>> compiler.
>>
>>> There is no question whether to follow ECMA or not, and it is
>>> no question that class TYPE should _not_ be replaced by classes
>>> INTRO_TYPE etc. 
>>
>> Well, the question is about interoperability. And this is where
>> ECMA, ISE and FreeELKS are concerned. I don't think it is good
>> for Eiffel to have libraries which only work with SmartEiffel
>> or only work with ISE. Let's try not to repeat these mistakes
> I fully agree.
>> in Gobo. I keep coming back to class TYPE because that's the
>> only entry point that we currently have for interoperability
>> in the introspection world. Here I speak about TYPE as a basic
>> class (equipped with 'external "built_in"' features), not as
>> something based on even more basic classes. As I already said,
> Does "built_in" mean that it should be implemented in C?
> If so then you can immediately forget my contribution.

Currently gec only supports "built_in" implemented in C.
But I know that in EiffelStudio, their "built_in" are
implemented by substituting some Eiffel code.

>> if you think that your classes are/should be more basic that TYPE
> I think that they _are_ more basic (OK, that's nothing new).
>> (or that TYPE cannot achieve the kind of introspection that you
> Yes, for debugging I need, e.g., the line numbers of features etc. which,
> to my knowledge, TYPE will not provide.
>> have in mind), then we should discuss that with ECMA/ISE/FreeELKS
>> at all means rather than introducing interoperability issues.
>>
>>> The question is, whether to use these classes
>>> as a basis of the implementation of the former one.
>>> And the question is, whether to use these classes directly
>>> to implement the persistence closure or indirectly via class TYPE.
>>> I think that the direct use is more efficient.
>>> If class TYPE is implemented on the base of class INTRO_TYPE
>>> then the final question is, whether this should be a solution
>>> for eternity or merely a temporary solution for now.
>>>>> What makes sense is to implement class TYPE
>>>>> on base of classes INTRO_TYPE etc. Where to locate the classes,
>>>>> together with class TYPE in FreeEKLS or in a more hidden cluster,
>>>>> is a secondary question.
>>>>>> (by the way, I'm not a big fan of these class names) should be
>>>>> By the way, INTRO_TYPE etc. are the _current_ class names.
>>>>> Changing them is no problem and will be done for the GEC version.
>>>>> Please, do not misunderstand the final state for SE to be also
>>>>> the final state for GEC.
>>>>>> added to FreeELKS with the proper 'external "built_in"' routines
>>>>>> to let other compilers like ISE be able to plug their implementation.
>>>>>> In either case, I think that it is better to discuss with ISE
>>>>>> about what we could do with FreeELKS in order to make available
>>>>>> in an interoperable way the features that you need to implement
>>>>>> introspection.
>>>>>>
>>>>>>>> STORABLE
>>>>>>>> --------
>>>>>>>>
>>>>>>>> It would indeed be interesting to plug your implementation
>>>>>>>> of STORABLE in gec. I have two concerns though. First, are
>>>>>>>> you aware that ISE also implemented a version of Storable
>>>>>>>> in Eiffel:
>>>>>>>>
>>>>>>>> http://dev.eiffel.com/cgi-bin/viewvc.cgi/trunk/Src/library/base/ise/serialization/ 
>>>>>>>>
>>>>>>>>
>>>>>>> I knew only older variants (it's at least three years ago that I 
>>>>>>> played with ISE),
>>>>>>> and I played also with serialization but did not analyze it.
>>>>>>>> As far as I understood, they only use INTERNAL. So I wonder
>>>>>>>> whether you should try to use the experience you gained when
>>>>>>>> developing your Storable for SmartEiffel and try to improve
>>>>>>>> ISE's SED library rather than providing a competing library.
>>>>>>>>
>>>>>>> I developed the stuff from scratch (I started in 2001 or 02  when
>>>>>>> ISE was not yet open). What I've just read, so has ISE's approach
>>>>>>> a similar class hierarchy but the underlying implementation
>>>>>>> seems to be quite different.
>>>>>>> In any case, my approach is bases on classes INTRO_TYPE, etc.
>>>>>>> not on class INTERNALS.
>>>>>>>> The other concern that I have is interoperability. It would
>>>>>>>> be nice if gec could at least have a way to read and write
>>>>>>>> the file formats produced by the old ISE's STORABLE mechanism
>>>>>>>> (at least independent_store). And why not also the file format
>>>>>>>> produced by SE 2.*, although I'm less interested in this one ;-)
>>>>>>>> It may be sound odd to try to be interoperable with ISE's old
>>>>>>>> STORABLE, but that's something I will need at work (we have a
>>>>>>>> lot of Storable files like that). And probably others currently
>>>>>>>> using ISE Eiffel will have the same need. So this will have
>>>>>>>> to be implemented at some stage.
>>>>>>>>
>>>>>>> Yes, I understand. The point was that I did not know ISE's
>>>>>>> store format. (The appendix of file "persist.pdf" contains the BNF
>>>>>>> of the store format I use. Are you aware of an analog description
>>>>>>> of ISE's store format? Knowing this would be a great help.)
>>>>>>
>>>>>> Each time I asked ISE I was told that I should read the source
>>>>>> code.
>>>>>>
>>>>> I downloaded the stuff yesterday. Maybe that I have time to study it
>>>>> on weekend. It will be rather hard to understand it.
>>>>>>> On the other hand, I know the store format of SE. In fact,
>>>>>>> it is possible to store in that format, but not to read from.
>>>>>>>
>>>>>>> The implementation is based on a class PERSISTENCE_CLOSURE
>>>>>>> managing the traversal through the persistence closure and
>>>>>>> on deferred classes PERSISTENCE_SOURCE and
>>>>>>> PERSISTENCE_TARGET for handling elementary data.
>>>>>>> Effective descendants of the latter two are combined
>>>>>>> with the first to get the desired effect. As sources exist
>>>>>>> reading from memory and from a file written by the corresponding
>>>>>>> target class. The question whether ISE's store format will
>>>>>>> be readable is the question whether it will be possible
>>>>>>> to implement a new source class while keeping class
>>>>>>> PERSISTENCE_CLOSURE as it is.
>>>>>>> On the other hand, there are much more effective target
>>>>>>> classes,in particular those which generate output that is
>>>>>>> not devoted to be re-read by PERSISTENCE_CLOSURE.
>>>>>>> Among those target classes is one that generates SE's
>>>>>>> store format and one that writes, at the end of compilation,
>>>>>>> the INTRO_TYPE, ... objects to C code. As for ISE,
>>>>>>> the question whether the SE store format can be read
>>>>>>> is the question whether an appropriate heir of class
>>>>>>> PERSISTENCE_SOURCE can be implemented.
>>>>>>> And here I know the answer: it is not possible.
>>>>>>>
>>>>>>> I final remark: classes SERIALIZER and SERIALIZE
>>>>>>> mentioned in the description are merely wrapper classes
>>>>>>> to make programmer's life easier.
>>>>>>>> deep_twin
>>>>>>>> ---------
>>>>>>>>
>>>>>>>> You didn't mention it in your message, but it is mentioned
>>>>>>>> in your document. None of the deep features are implemented
>>>>>>>> yet in gec. Even though I don't like to use deep_twin myself
>>>>>>>> (I prefer to control the level of duplication I want by
>>>>>>>> redefining `copy'), one of the programs I currently try to
>>>>>>>> compile with gec at work uses it. So it will need to be
>>>>>>>> implemented soon.
>>>>>>>>
>>>>>>> In fact, I didn't try it so far, but I'm sure it will work.
>>>>>>> The only bad thing is that the general approach causes overhead
>>>>>>> in space and time slowing down the `deep_twin' by some factor.
>>>>>>> Of the other routines, `deep_copy' will be quite similar to
>>>>>>> `deep_twin' whereas `deep_is_equal' is different:
>>>>>>> we have two sources and no target. Maybe that one can
>>>>>>> misuse the target as one another source.
>>>>>>>
>>>>>>>>
>>>>>>>> Debugger
>>>>>>>> --------
>>>>>>>>
>>>>>>>> This topic is something that I'm not very good at. So I really need
>>>>>>>> to rely on others to implement a good debugging mechanism for gec.
>>>>>>>> I have not really thought about it. My only requirement is that
>>>>>>>> it should be user-friendly and should do what people expect from
>>>>>>>> a debugger. So people who want to contribute in this area will
>>>>>>>> be free to do pretty much what they want, also I will be interested
>>>>>>>> in following their progress.
>>>>>>>>
>>>>>>>> But gec is not as advanced as SmartEiffel with respect to
>>>>>>>> debugging. There is currently only one compilation mode, with
>>>>>>>> no stack trace, no assertion monitoring, no exception. So
>>>>>>>> everything needs to be done in this area. If this is not
>>>>>>>> frightening you, then that would be great.
>>>>>>>>
>>>>>>> The debugger started as a by-product of introspection/persistence
>>>>>>> closure: to implement an "evaluate" (or "print") command
>>>>>>> one needs introspection. Since the SE debugger did that time
>>>>>>> (yes, it is long ago) not support evaluation even of the most
>>>>>>> simple expressions, I added such a command to the debugger.
>>>>>>> And since I'm a friend of debuggers, I continued the work
>>>>>>> to make the debugger more user friendly, finally,  to implement
>>>>>>> it in Eiffel.
>>>>>>>
>>>>>>> Expression evaluation of the debugger is based on the
>>>>>>> introspection discussed above (whether INTRO_TYPE
>>>>>>> directly or indirectly via TYPE is of minor concern).
>>>>>>> Well, expression evaluation is just a part of debugging,
>>>>>>> but an inevitable part. Thus, whether I can add the debugger
>>>>>>> to GEC is also the question whether my approach of
>>>>>>> introspection will been added.
>>>>>>>
>>>>>>> In any case, adding the debugger (probably any debugger)
>>>>>>> to GEC will have much more impact on the compiler and
>>>>>>> the generated C code than introspection. This will cause
>>>>>>> more discussion and negotiation.
>>>>>>
>>>>>> But since the compilation mode for debugging does not exist
>>>>>> yet (only the equivalent of SE's boost mode is implemented),
>>>>>> I think that it should be less controversial than if such
>>>>>> compilation mode already existed and needed to be adapted.
>>>>>> Here I wonder if we could simply have a class ET_DEBUG_C_GENERATOR
>>>>>> which inherits from ET_C_GENERATOR. Or have something like
>>>>>> that:
>>>>>>
>>>>>>                    ET_C_GENERATOR*
>>>>>>                      ^       ^
>>>>>>                     /         \
>>>>>> ET_FINALIZE_C_GENERATOR    ET_WORKBENCH_C_GENERATOR
>>>>> Yes, it was my idea, too, to put much of the work into code generation
>>>>> (and in case of GEC, in contrast to SE, it is well concentrated).
>>>>> Nevertheless, a class ET_WORKBENCH_C_GENERATOR
>>>>> will be not sufficient.
>>>>> First of all, the debugger is written in Eiffel but the user written
>>>>> program does not contain an object of class DEBUGGER
>>>>> (or which class name you like). Thus, the class will normally not
>>>>> be compiled and the executable will not have debugging facility.
>>>>> What's needed is to compile class DEBUGGER additionally to
>>>>> the user's system as a second root class and to create an object
>>>>> of that class during runtime as a second root object.
>>>>> Second, during compilation one has to decide what to do with
>>>>> classes and features that occur twice: generating them twice
>>>>> and giving them different C names, or reusing in the debugger
>>>>> class what has been generated outside of them (causing that
>>>>> the debugger will debug itself, possibly an infinite recursion).
>>>>> The duplication of the root and possibly other code is
>>>>> what I mean by large impact onto the compiler.
>>>>>>
>>>>>>>>
>>>>>>>> You spoke about your availability to work on this project.
>>>>>>>> INTERNAL/TYPE and deep_twin are something that I will need
>>>>>>>> relatively soon. So I guess I should start implementing
>>>>>>>> them myself. Of course it does not mean that you cannot
>>>>>>>> help or that I won't need your help. For STORABLE,
>>>>>>>> what I will need will be something similar to ISE's
>>>>>>>> independent store. I don't think that any of us can
>>>>>>>> implement that in short amount of time. I guess that
>>>>>>>> you would prefer to work on your own Storable format (which
>>>>>>>> looks interesting just by reading you document), although it
>>>>>>>> would be nice if you could have a look at ISE's SED and see
>>>>>>>> if/how it could be improved. The part of your contribution
>>>>>>>> offer that I would be the most interested in, considering
>>>>>>>> my need and your availability, would be the debugger part.
>>>>>>>> Indeed, this is not something that I need in the short term,
>>>>>>>> so you have plenty of time to work on it without too much
>>>>>>>> constraints. There is not that much conflicting parts with
>>>>>>>> what I currently work on in the compiler. And this is something
>>>>>>>> that I don't think I will be able to implement myself anyway.
>>>>>>>> And everything needs to be done from scratch. So if you are
>>>>>>>> not frightened by that, this could be an interesting experience.
>>>>>>>>
>>>>>>> As already mentioned, the core part of introspection/persistence
>>>>>>> (i.e introspection of types and attributes, not routines
>>>>>>> and local variables, not class TYPE; persistence without
>>>>>>> class ACTIONABLE, not ISE's format) should be not very
>>>>>>> difficult. Besides the general task to replace SE specific classes
>>>>>>> and features by GOBO specific ones, there remains only
>>>>>>> the extraction of relevant information from classes
>>>>>>> ET_DYNAMIC_TYPE etc.
>>>>>>> I think that I can tell you tomorrow evening
>>>>>>> how much time will be needed.
>>>>>>>> Now I should mention that people contributing to the Gobo
>>>>>>>> project need to follow some programming rules. It is difficult
>>>>>>>> to follow them at first because most of them are not explicitly
>>>>>>>> stated. Some are here:
>>>>>>>>
>>>>>>>>    http://www.gobosoft.com/eiffel/gobo/guidelines/
>>>>>>>>
>>>>>>>> Some are just implicit (just look at how the other classes
>>>>>>>> in Gobo look like). The idea is to have a Gobo package where
>>>>>>>> all classes follow the same programming style so that we have
>>>>>>>> some sort of uniformity, instead of being a set of independently
>>>>>>>> developed parts.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 


-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Gobo-Eiffel extensions

[Howard T. <how...@di...>]

Hi Eric and Wolfgang,

I am continuing to work on my project based on gobo-eiffel, named EDP, the 
Eiffel Developer's Project on Sourceforge, although I haven't been keeping 
the SF SVN repository up-to-date with my work.

In preparation for adding a stack trace, I have modified my ET_C_GENERATOR to 
be able to allocate stack locals and Result within a locally declared C 
struct, with the intention of adding, within each routine, a 'once' section 
of code that generates an instance of TYPE (or similar), so that capturing a 
stack trace captures a list of objects cloned from the stack frames and also 
captures the detail to enable Eiffel code to examine it.

The ability to do an exact inspection of the stack is also necessary for a 
precise Garbage Collector implementation, which I am also working on, on the 
basis that the GC should operate per-thread, and the primary (preferably 
only) means of communication between threads (other than probing for 
debugging) should be using some form of messaging implemented using deep_copy 
semantics.

As my adapted code from the Slyboots GUI project uses user-expanded types, I 
have also adapted ET_C_GENERATOR to generate dynamic_types to avoid the 'C 
struct' inclusion ordering error that afflicted the version from which I 
started.

I am interested in any existing and proposed introspection code in that it is 
needed for the debugging inspection of a suspended thread, and I will also 
need it for future Eiffel projects using database storage etc.

I have added some code to generate tracing information, currently only routine 
entry/exit with a stack depth counter, which I have needed to discover some 
(rare !) faults in the tools library, although I have not yet added the code 
to select the option from the command line, necessitating recompiling the 
compiler to change settings ..... !

On the performance front, I think that some level of routine inlining is 
fairly urgent; doing a C routine call to evaluate INTEGER_32.infix ">=, and 
similarly with ">", "|", "|<<", "|>>", INTEGER_8.to_integer_32 etc is 
somewhat performance limiting ....

I have modified the report_giaaa calls to be of the form:
	error_handler.report_giaaa ("__CLASS__", "__LINE__")
where ET_C_GENERATOR substitutes the above strings for the appropriate strings 
for the textual location of the report_giaaa call. Although the code from 
where I tracked down a call to this routine has since been modified, I think 
the facility could be useful in future.

For the longer term, I am still interested in the problems and potential 
solutions needed to be able to dynamically add one or more class libraries 
into a running system, as one can do (carefully !) with Java. The added 
classes would have to have been compiled against the same kernel/base classes 
as the running system, or at least have no incompatibilities with them. 

Firstly, for performance reasons I want to be able to separately compile the 
classes that are changing rapidly from those that are unchanging when 
developing a project.

And secondly I think that one of the aspects of Eiffel that is holding back 
some commercial acceptance is that to compile a system, or any variant of any 
system, one currently needs a complete set of source code to all classes in 
the system for the compiler to work.

It should be possible for the IDE/compiler to dynamically load a pre-compiled 
library (.so or .dll), inspect it to retrieve the same required information 
that one would derive from compiling the sources, and generate new 
clients/descendants that can be based on the loaded library. 

I have been looking at ET_C_GENERATOR.print_polymorphic_xxx_calls and thinking 
about how one would dynamically allocate and register type_ids and data 
structures to lookup routine addresses and attribute offsets etc.

I went to a couple of workshops at the ECOOP '07 conference in Berlin at the 
weekend, and picked up some useful information and contacts relevant to this 
area of interest.

In applications, I am working on a comparison program for Eiffel texts to 
compare classes, selectively excluding things like indexing clauses, 
comments, assertions etc, which I will also be integrating into the IDE.

I am interested in working with others on what I am doing, and welcome 
feedback on ideas and from potential users of EDP, which is approaching (for 
me at any rate!) being useable as a substitute for my existing editing system 
(Code Crusader) and is already my only Eiffel compilation system in 
conjunction with the (modified) GEC command line equivalent.

My immediate priorities are GC and threads, but the earlier I am able to 
cooperate with others in what is being designed and coded, the faster we will 
all achieve results.

Regards to all,

Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] Problems when installing GEC

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Wolfgang Jansen wrote:
>> Hi Eric,
>>
>> some minutes ago I downloaded revision 6029 of 
>> /gobo/trunk/library/tools/eiffel
>> and tried to re-stall "gec". Up to one mistake things are fine.
>
> [...]
>
>> The remaining problem is C compilation. There are many errors of the 
>> form
>>   cc: Error: test.h, line 257: Missing ";". (nosemi)
>>
>> Line 257 is
>>   extern T0* geboxed1(T1 a1);
>> and T0 in turn is defined in line 235 by
>>   #define T0 EIF_ANY
>> but EIF_ANY is not defined. 
>
> It should be defined. I guess it's because you didn't
> checkout the files which are in:
>
>    /gobo/trunk/tool
>
Thanks, this was the point.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Problems when installing GEC

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
> Hi Eric,
> 
> some minutes ago I downloaded revision 6029 of 
> /gobo/trunk/library/tools/eiffel
> and tried to re-stall "gec". Up to one mistake things are fine.

[...]

> The remaining problem is C compilation. There are many errors of the form
>   cc: Error: test.h, line 257: Missing ";". (nosemi)
> 
> Line 257 is
>   extern T0* geboxed1(T1 a1);
> and T0 in turn is defined in line 235 by
>   #define T0 EIF_ANY
> but EIF_ANY is not defined. 

It should be defined. I guess it's because you didn't
checkout the files which are in:

    /gobo/trunk/tool

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Problems when installing GEC

[Wolfgang J. <wj...@so...>]

Hi Eric,

some minutes ago I downloaded revision 6029 of 
/gobo/trunk/library/tools/eiffel
and tried to re-stall "gec". Up to one mistake things are fine.

Eric Bezault wrote:
> Hi Wolfgang,
>
> Wolfgang Jansen wrote:
>> When trying the same with "gcc" then many warnings like the following
>> were issued:
>>
>>   gec.c: In function `T202f63':
>>   gec.c:82734: warning: cast to pointer from integer of different size
>>
>> Line 82734 in C code reads
>>
>>   t2 = ((T0*)gevoid(((T202*)(C))->a20, l2));
>>
>> whereas "gevoid" is declared as
>>
>>   extern int gevoid(T0* C, ...);
>>
>> Thus, the bad cast is from "int" to "T0*", i.e. from 4 to 8 bytes
>> on a Tru64 platform (as I'm working on). I think, the solution is
>> to redefine "gevoid" like "T0* gevoid(T0* C, ...)".
>
> I think that this problem should be solved now. gec now generates
> a different "gevoid" function for each possible return type.
> So, no bad type cast should occur anymore.
>
Yes, this works very well.
>> After the warnings an error message follows:
>>
>>   as1: Error: /usr/tmp/cciOAHCE.s, line 5: gp-relative segments 
>> together exceed 64k bytes
>>
>> Probably, the generated object file is too large.
>> (I had the same effect also earlier when bootstrapping the SE compiler
>> from a single C file instead from a split one.)
>
> gec is now able to split the generated C code over several files.
> I didn't change the bootstrap to use this new functionality yet.
Yes, this works very well either.
>
>>   cc: Warning: gec.c, line 479288: Non-void function "gevoid" does 
>> not contain a return statement. (missingreturn)
>>   int gevoid(T0* C, ...)
>
> This should be solved as well.
>
Yes, it is.

The remaining problem is C compilation. There are many errors of the form
  cc: Error: test.h, line 257: Missing ";". (nosemi)

Line 257 is
  extern T0* geboxed1(T1 a1);
and T0 in turn is defined in line 235 by
  #define T0 EIF_ANY
but EIF_ANY is not defined. Replacing the last definition
manually by
  #define T0 EIF_OBJECT
makes the C compiler happy.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] GEC bootstrap

[Franck A. <fr...@ne...>]

> I think that the shell script is invoked by using C's 'system'.
> Something like:
> 
>     system("/path/to/gec.sh")
> 
> So, do you think that calling:
> 
>     system("sh /path/to_gec.sh")
> 
> would work? Or should I write:
> 
>     system("/bin/sh /path/to_gec.sh")
> 
> (in case 'sh' was not the in the path, or aliased to something else)?

      system (". /path/to_gec.sh")

might be a neater and more portable variant. and I guess system() is
always supposed to operate in a sh-compatible shell, so '.' is going to
be the right shell and not the user's current shell with a different
syntax.

Re: [gobo-eiffel-develop] GEC bootstrap

[Eric B. <er...@go...>]

Cheng-Chang Wu wrote:
> Hi,
> 
> After reading ET_C_GENERATOR :
> 
>  if not operating_system.is_windows then
>                                         create
> l_command.make ("chmod a+x " + l_filename)
>                                        
> l_command.execute
>                                 end
> 
> But l_filename is set to gec11.c a few lines before.

Thank you for pointing that out.
It should be fixed now.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com