guide (previously: edp)Description
'guide' is an IDE for Eiffel, currently in pre-alpha, based on the Gobo package, and using a pure Eiffel GUI based on a translation and adaptation of the Fox toolkit.
While it has reached the stage of being of some use to its author as a code browser, it is not yet a substitute for any other tool. Its principal advantage, as with other tools based on the Gobo libraries, is speed and adaptability of the codebase.
As with Gobo in general, it is intended that guide will be able to compile EiffelStudio compatible projects, eventually ...
Primary development of guide is with guide itself on Linux, with C compilation using gcc. The Win32 code is compilable but the current type-set analysis has limitations (read bugs ...) in conjunction with external C code.
Current work is aimed at providing a precise per-thread GC and associated thread library support, both to support threading within guide for separation of GUI interaction from compilation, and to enable generation of robust GC enabled multi-threaded cross-platform applications using guide.
As of August 2010, the GC has reached stability for the current, single threaded, usage and testing to date. Work continues (slowly ...), on extending the runtime for multi-thread GC and inter-thread messaging.
It is also intended to adapt the Eiffel GUI code to using the Vision2 interface to be compatible with other Eiffel projects using Eiffel Studio.
Comments
Progress Report on GC
My GC (Garbage Collector !) work on gec is nearing a working version with, I think (!), only expanded classes containing embedded references to deal with, of which TYPED_POINTER[ANY] I know is outstanding.
With GC collection disabled, the allocator is working fine [i.e. the compiler works], and the GC testing built in to the C implementation works OK, so in theory a working implementation is not far off.
With GC collection enabled, some objects are being collected that the crash stack trace show as being part part of the set of reachable objects, so marking is as yet incomplete, either from the stack or between objects.
The current code is a precise GC, with no provision as yet for moving objects, or returning memory to the OS, although the latter is essentially trivial for pages that are detected as not in use.
I have only worked on Linux so far, but the code to adapt to Win32 is only one routine that calls the mmap() system call, and that should be fairly easy to adapt to a Win32 version.
Other commitments are looming, so development may slow down for a while ...
Multi-core scalability and messaging, and multi-thread GC
I have recently come across the 0MQ messaging library [www.zeromq.org] , and am working on adapting my codebase to use it for all inter-thread messaging.
The associated web pages discussing the practical basis for using messaging are illuminating, and well worth a read by anyone interested in both dependable and scalable programming for a multi-threaded environment, likely to become more common with today's multi-core processors.
To extend the GC capability of Guide to multi threading, I will retain the existing GC code for all allocations for which references only exist within the allocating thread, and for all other allocations there will be a GC co-ordination thread that will receive appropriate messages about the continuing liveness of shared objects.
As I envisage the need to scale to at least 100 concurrent threads for a project to re-implement a current system implemented in C, I do not think that a GC that requires stop-the-world operation to perform marking will be appropriate for that.
As mentioned in 0MQ's white papers, I conclude that only immutable objects should be shared between threads, and therefore all objects passing between threads must do so via an implementation aware message passing interface that, in the act of passing a message, both ensures that all memory barrier instructions that are needed to ensure consistency are executed, and also ensures that GC related implementation details are maintained.
As ever, the ideas come faster than the code, but progress is still being made ... !
Incremental C Compilation for Guide
Hi,
I have been working on a selective re-compilation process for the C code generation for 'guide', my adaptation of the Gobo Eiffel Compiler.
Essentially, C code is generated per routine, and is then hashed [SHA1] and the hash code looked up in previously generated compilations, with the C code only being emitted to file if this does not match previously compiled code.
In theory, of the current 8 minutes that it takes my laptop to compile guide, I should be able to lop off around 6 minutes for small changes to the Eiffel source code.
There are some issues yet to address, especially dependence on changes in class attributes and consequent C struct changes.
Progress is being made ... [Currently on holiday in Crete ... !]
Howard