Re: [gobo-eiffel-develop] Git development

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

Hi Howard,

Howard Thomson wrote:
>
> Hi Eric & Wolfgang,
>
> I would welcome a move to using Git as the SCM system for Gobo.
>
> I see that there is a useful page on wikipedia about git, with 
> reference to Windows implementations:
>
> http://en.wikipedia.org/wiki/Git_(software)#Implementation
>
> There is also an excellent website detailing how to use git ...
>
> http://progit.org/
>
> Regarding my own project:
>
> I have recently, I think [famous last words], reached stability with my
>
> GC when compiling with my modified 'gec', albeit that I have only so
>
> far tested it on Linux. A Win32 version should be a fairly trivial 
> adaptation,
>
> as it should be no more than adaptation of a single, smallish, routine.
>
> I am also thinking of renaming my project as 'guide',
>
> the Gobo-eiffel Users' Integrated Development Environment,
>
> from 'edp', the Eiffel Developers' Project. Although there a few
>
> classes [from other sources] that are LGPL, nearly all code that does
>
> not already derive from gobo, is EFFLv2 or MIT.
>
> I am very interested to hear about the introspection and debugger code, as
>
> I need such facilities for my intended future coding.
>
Description of introspection and debugger code may be really large.
Here, a short outline.
Descendant classes of ET_C_GENERATOR (extending the work of that class)
generate a description of the system to be compiled for use during runtime:
they extract information from objects of types
ET_DYNAMIC_SYSTEM, ET_DYNAMIC_TYPE etc. and puts
the information into objects of types ET_IN_SYSTEM, ET_IN_TYPE etc.
The resulting description is put onto C code (additional to the usual code)
using a special output mode of the persistence closure classes.
This code is C compiled, and the system description is available
during runtime (after a few adaptations at startup) as Eiffel objects.
More precisely, the root object of the description is provided by an 
external
routine that fetches the object's address from C code, the other objects
are then recursively available by Eiffel calls on the root object.
The attachment contains the interface of an example class
to show what kind of information is available during runtime.

Introspection for persistence closure and debugging differs in the amount
of information in the system description. For example, the debugger needs
information about routines but the persistence closure does not.
Moreover, in case of debugging many calls to the debugger have been 
inserted
into the "normal" code. The debugger then decides whether switching
into interactive mode (say a breakpoint has been reached)
or returning immediately to the caller.

Historically, the work started with the persistence closure.
I soon realized the introspection is a necessary prerequisite.
Then, having introspection, the idea was to utilize it also
for other purposes, e.g. for the "print" command of a debugger.
So, the debugger has been developed.

The approach to implement the persistence closure etc.
may be emphasized as follows:
The Eiffel compiler is written in Eiffel.
So, why not also implementing the Eiffel runtime system in Eiffel?  

BTW, does your GC mark/seep or move/compress? In the former case,
object marking may also be interesting when building the persistence 
closure.
Currently, the already seen objects are registered
in a DS_HASH_TABLE[INTEGER,POINTER]. This is inconvenient
because of the POINTER keys. Marking like the GC would be an
interesting alternative.

> One of the areas of the code generator that I intend to alter is the 
> polymorphic
>
> dispatch implementation, for two reasons:
>
> Firstly for rapid re-compilation, I want to be able to generate an 
> initial code package as
>
> an executable stub with dynamic library, where libraries register 
> their routine addresses
>
> with the runtime, with subsequent partial re-compilation code 
> generated as an additional
>
> dynamic library whose routines override the registered routines of the 
> initial library. This
>
> requires that routine dispatch be done using a tree data structure, of 
> some sort ...
>
> Secondly, I envisage that it should be possible, as with Java and 
> other languages [mostly interpreted ..],
>
> to dynamically add class libraries to an executable system, where such 
> libraries have been packaged,
>
> [compiled or otherwise verified against] to be compatible with classes 
> already in the current system.
>
> That would also require that the dispatch to reachable routines be 
> dynamically extendable.
>
This sounds very interesting. Extendibility of a program, dynamic 
linking etc. seems to be
necessary for contemporary software (otherwise, Eiffel will never have a 
chance).
>
> I am adapting my work on the Eiffel GUI toolkit derived from the 
> Fox-toolkit to use the Vision2 interface,
>
> providing an X11/Win32 all Eiffel GUI Toolkit, which has its 
> advantages ...
>
> I am working toward using LLVM as the basis for code generation for 
> native Eiffel routines, initially to emit
>
> LLVM assembler with llvm-as invocation, and with the possibility 
> [much] later of emitting machine code directly.
>
> I think using Git would assist in cooperation between myself and other 
> gobo-eiffel contributors and developers.
>
> Regards,
>
> Howard Thomson
>
> --
>
> "Only two things are infinite, the universe and human stupidity,
>
> and I'm not sure about the former." -- Albert Einstein
>


-- 
Dr. Wolfgang Jansen
University of Potsdam, Germany
Institute of Computer Science
Tel: +49 331 / 977 3047
mailto: wj...@so...