<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>https://dev.eiffel.com/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Gmc444</id>
		<title>EiffelStudio: an EiffelSoftware project - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="https://dev.eiffel.com/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Gmc444"/>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/Special:Contributions/Gmc444"/>
		<updated>2026-04-04T11:16:17Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.24.1</generator>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=Talk:ProposalLibraryDependencies&amp;diff=7287</id>
		<title>Talk:ProposalLibraryDependencies</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=Talk:ProposalLibraryDependencies&amp;diff=7287"/>
				<updated>2007-01-30T07:32:04Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''--[[User:Paulb|Paulb]] 21:23, 14 November 2006 (CET)'''&lt;br /&gt;
&lt;br /&gt;
I don't know if the Examples are going to turn into anything concrete. I don't like a useless &amp;quot;'''com.'''&amp;quot; prefix. &amp;quot;'''eiffel.'''&amp;quot; is useless also because it's an Eiffel library. I'm assuming you meant &amp;quot;'''eiffelsoftware.'''&amp;quot;&lt;br /&gt;
&lt;br /&gt;
My suggestions for naming conventions should be:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;company&amp;gt;.&amp;lt;type&amp;gt;.&amp;lt;name&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*For EiffelBase: '''eiffelsoftware.library.base'''&lt;br /&gt;
*For a utility framework: '''eiffelsoftware.framework.utilities'''&lt;br /&gt;
*For the Eiffel parser: '''eiffelsoftware.eiffel.parser'''&lt;br /&gt;
*For the Eiffel compiler: '''eiffelsoftware.eiffel.compiler'''&lt;br /&gt;
&lt;br /&gt;
'''--[[User:Patrickr|Patrickr]] 22:37, 14 November 2006 (CET)'''&lt;br /&gt;
&lt;br /&gt;
My idea was to use the url of the &amp;quot;company&amp;quot; producing the library to be sure that the name is unique, from most general to more specific. So for base from eiffel.com the idea was com.eiffel.base, gobo could then for example be net.sourceforge.gobo.base (basically the same schema that is used in the java world).&lt;br /&gt;
I would not put the type into the name, as there are no clear borders between a framework and a library and it's possible that a library can later turn into a framework.&lt;br /&gt;
&lt;br /&gt;
'''--[[User:Paulb|Paulb]] 22:55, 14 November 2006 (CET)'''&lt;br /&gt;
&lt;br /&gt;
I suppose it would make sense to use a URL namespace given that it would be the source, I just don't like it and there is an increasing number of people being turned off Java. Imagine a Gobo Eiffel compiler parser library - ''net.sourceforge.gobo.eiffel.compiler.parser'' - That's a little too long for my liking. But it's whatever the majority vote calls for. Whatever we have it better than a path.&lt;br /&gt;
&lt;br /&gt;
It's not a solid argument that a library can turn into a framework. If it does, it's no longer a library and no longer usable in the way someone consuming the library had based their implementation on. By the by, it doesn't matter. It was a distinction about where it came from and what purpose the library served; ''library'' meant it came from our library repository, ''eiffel'' is related to the Eiffel language, and so on. &lt;br /&gt;
&lt;br /&gt;
My idea was also based on the default namespaces that are assigned to libraries for use with .NET. We already have products out there that use namespaces like ''EiffelSoftware.Library.Base'' and ''EiffelSoftware.Library.Vision2''. It's going to be confusing for those .NET users that see a namespace for a library yet the library name is very different. It's too late to change namespaces now because of user that use Eiffel for .NET assemblies from other languages, it would break a lot of code. Basing a namespace system of a language that we don't even support fully and have no user base for might not be the best idea. Using URL is a sound convention but not if it leads to confusion. Eiffel for .NET has been out there for the last six years, why not base it on something established and used. We have a solid source, a company name. It's been working for billions of lines of code so far...&lt;br /&gt;
&lt;br /&gt;
That's my two + two cents.&lt;br /&gt;
&lt;br /&gt;
'''--[[User:Manus|manus]] 07:41, 16 November 2006 (CET)'''&lt;br /&gt;
The good thing with URL is that they cannot be 2 entities using the same url, however you can have 2 companies called EiffelSoftware. Using the url we would be safer. Note that the url is just used in libraries, it is not like in java where it appears in the source code.&lt;br /&gt;
&lt;br /&gt;
'''--[[User:Paulb|Paulb]] 17:21, 16 November 2006 (CET)'''&lt;br /&gt;
My concern was for EiffelEnvision users that use libraries but I guess this really doesn't matter because Eiffel for .NET doesn't use namespaces and C#, ..., users don't use Eiffel libraries.&lt;br /&gt;
&lt;br /&gt;
'''--[[User:Gmc444|Greg C]] 11:17 PM 29 January 2007(PST)'''&lt;br /&gt;
Does it make sense to allow two versions of the same library to be accessed from one application?  For example, I don't think it would be sensible or possible for an app to use two versions of Vision2 at the same time. If libraries are assumed to always be exclusive, then does this simplify the problem?&lt;br /&gt;
&lt;br /&gt;
How large is the user base for Eiffel .Net? If a breaking change would have a long-term advantage for all Eiffel users, then perhaps the Eiffel .Net users would be willing to suffer through the change for the greater good. In fact, Eiffel .Net users might welcome a significant change, or for direct support of namespaces within the language, since it seems there's a lot of confusion and frustration with the way things sort-of-work now, with prefixes that come and go that may or may not be meaningful, etc.&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=ConfigurationComparison&amp;diff=7187</id>
		<title>ConfigurationComparison</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=ConfigurationComparison&amp;diff=7187"/>
				<updated>2007-01-27T00:54:07Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:Configuration]]&lt;br /&gt;
The purpose of this page is to compare existing configuration solutions. This would help to see if we can merge existing solutions into just one, thus avoiding duplication of effort. At the moment we are only going to compare `ace', `ecf' and `xace'.&lt;br /&gt;
&lt;br /&gt;
In the table below, we have 4 possible answers:&lt;br /&gt;
* '''{{Green|Yes}}''': Feature is present&lt;br /&gt;
* '''{{Red|No}}''': Feature was deliberately not supported&lt;br /&gt;
* '''N/A''': Unlike '''{{Red|No}}''' it is not present but not deliberately&lt;br /&gt;
* '''DNK''': Do Not Know, that is to say if you know the answer, feel free to update the DNK entry.&lt;br /&gt;
&lt;br /&gt;
Feel free to update this page if you feel there is a missing feature, that we have an accurate comparisons.&lt;br /&gt;
&lt;br /&gt;
{| border=&amp;quot;1&amp;quot; cellspacing=&amp;quot;0&amp;quot; cellpadding=&amp;quot;5&amp;quot; align=&amp;quot;top&amp;quot;&lt;br /&gt;
! Feature&lt;br /&gt;
! ace&lt;br /&gt;
! ecf&lt;br /&gt;
! xace&lt;br /&gt;
|-&lt;br /&gt;
| colspan=&amp;quot;4&amp;quot; | '''Cluster management'''&lt;br /&gt;
|-&lt;br /&gt;
| Notion of cluster&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
|-&lt;br /&gt;
| Recursive cluster&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
|-&lt;br /&gt;
| Notion of override cluster&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| Allow multiple override cluster&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| colspan=&amp;quot;4&amp;quot; | '''Grouping'''&lt;br /&gt;
|-&lt;br /&gt;
| Notion of group (Cluster, Library, Assembly, Override)&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| Support for group dependencies&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| Notion of library&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| colspan=&amp;quot;4&amp;quot; | '''Class names'''&lt;br /&gt;
|-&lt;br /&gt;
| Enable some sort of class renaming&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| Class prefixing (renaming of all classes of a group)&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| Allow for same class name in a recursive cluster in different subdirectories&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| colspan=&amp;quot;4&amp;quot; | '''Project management'''&lt;br /&gt;
|-&lt;br /&gt;
| Optional specification (i.e. option being platform, build, or user defined)&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| Multiple targets (i.e. more than one system in a configuration file)&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| colspan=&amp;quot;4&amp;quot; | '''Access style'''&lt;br /&gt;
|-&lt;br /&gt;
| Reading/editing configuration file as a library&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| Graphical front end for reading/editing configuration file&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| colspan=&amp;quot;4&amp;quot; | '''Interfacing to external software'''&lt;br /&gt;
|-&lt;br /&gt;
| Support .NET assembly&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| DNK&lt;br /&gt;
|-&lt;br /&gt;
| Specification of includes for C/C++ externals&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
|-&lt;br /&gt;
| Specification of object files for C/C++ externals&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
| {{Green|Yes}}&lt;br /&gt;
|- &lt;br /&gt;
| Specification of C/C++ compiler options&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| {{Red|No}}&lt;br /&gt;
| DNK&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=Talk:ConfigurationFileFormat&amp;diff=7041</id>
		<title>Talk:ConfigurationFileFormat</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=Talk:ConfigurationFileFormat&amp;diff=7041"/>
				<updated>2007-01-24T19:16:41Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Gmc44==&lt;br /&gt;
This proposal for a configuration file format looks similar to what was done with geant and gexace.&lt;br /&gt;
&lt;br /&gt;
Personally, I think XML is an inappropriate format for this job. It might be a good idea to talk to Gobo (Eric Bezault) about his experience with those tools.&lt;br /&gt;
&lt;br /&gt;
Among the problems:&lt;br /&gt;
&lt;br /&gt;
XML is very verbose, and while it can be read by a human, it's not very easy to read. In this respect it's much worse than Ace files.&lt;br /&gt;
&lt;br /&gt;
To solve configuration problems, you need all the basics of a programming language: input, output, state, conditionals, and iteration. Using XML to represent these often becomes kludgy. Look at the effort that goes into solving what should be fairly simple if conditions.&lt;br /&gt;
&lt;br /&gt;
I think it would be far better to evolve the Ace file specification, perhaps into a subset of Eiffel that allows us to write a clear, declarative specification of a system without a lot of &amp;lt;tag&amp;gt;s and &amp;lt;/tags&amp;gt; and obtuse rules.&lt;br /&gt;
&lt;br /&gt;
==Manus==&lt;br /&gt;
The format is just an internal mean and it is only in XML format to make it easy to store in source control management system. We will go towards the edition through a hopefully nice graphical interface, we have the experience of what currently exists in EiffelStudio to make something much easier to use.&lt;br /&gt;
&lt;br /&gt;
==Gmc444==&lt;br /&gt;
After writing my initial post, I did get to see a demo of how the new file format works, and how it's represented in an Eiffel-like format for users. It surprises me a little that the Eiffel-like presentation would be considered harder to work with in source control than XML. Oh well, as long as I don't have to worry about hand-editing XML I can live with it =)&lt;br /&gt;
&lt;br /&gt;
after giving this more consideration, I've come to two conclusions:&lt;br /&gt;
&lt;br /&gt;
First, I still don't like XML. It's a marginal language for simple constructs, unreadable for complex constructs, and truly horrid for trying to use as a programming language.&lt;br /&gt;
&lt;br /&gt;
A build specification language has to be a programming language, of that I'm convinced. You need variables (state), conditional statements (flow of control), input and output. I don't know of any really successful attempts to build a programming language using XML syntax.&lt;br /&gt;
&lt;br /&gt;
One problem with Lace is that it's a declarative language that looks like Eiffel, an imperative language. I think this leads to problems in expressing programming notions that might otherwise be easy to express.&lt;br /&gt;
&lt;br /&gt;
I think extending a declarative language like Lace will be problematic for people used to imperative programming. &lt;br /&gt;
&lt;br /&gt;
Rebuilding that declarative language in XML will only lead to similar problems, but they'll just be harder to read.&lt;br /&gt;
&lt;br /&gt;
What I would like to see is a set of specialized Eiffel classes that would be used to describe the system being built. I'll try to sketch out what this would look like, and if it looks viable, I'll put it forward.&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=Eiffel_Glossary&amp;diff=6275</id>
		<title>Eiffel Glossary</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=Eiffel_Glossary&amp;diff=6275"/>
				<updated>2006-11-19T21:27:31Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category: General]]&lt;br /&gt;
Eiffel uses a precisely defined terminology. That terminology sometimes sounds strange to programmers used to other languages, but it's only because (1) there has been a systematic effort to classify object-oriented concepts in a logical way; (2) some of the terms predate terminology that is used in other languages. You will see, however, that behind every choice of term there is a carefully devised rationale.&lt;br /&gt;
&lt;br /&gt;
Please try to keep the list sorted alphabetically.&lt;br /&gt;
&lt;br /&gt;
; Attribute : A property of a class that denotes a field present in each instance of the class.&lt;br /&gt;
; Cluster : A group of logically related classes that have something in common. The corresponding class texts are generally stored in files of a single directory.&lt;br /&gt;
; Feature : An operation (command or query) applicable to all instances of the class, and specified in the class text. Routines and attributes are examples of features.&lt;br /&gt;
; Function : In a class, a feature with an associated algorithm that returns a result. A pure function or query does not affect the state of its object.&lt;br /&gt;
; Library : A group of related classes, devised to cover all the facilities needed in a certain application areas. A library is made of a number of clusters. For example a math library may be composed of clusters devoted to random number generation, linear algebra, integration, etc.&lt;br /&gt;
; Routine : In a class, a feature with an associated algorithm, so that calling the feature executes that algorithm. a Routine takes zero or more arguments. It does not return a result directly but often changes the state of the object associated with the Routine feature.&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=User:Zoran&amp;diff=5015</id>
		<title>User:Zoran</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=User:Zoran&amp;diff=5015"/>
				<updated>2006-10-06T21:44:11Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Hi Zoran!&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=Reducing_Eifgen_Size&amp;diff=4821</id>
		<title>Reducing Eifgen Size</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=Reducing_Eifgen_Size&amp;diff=4821"/>
				<updated>2006-09-29T23:53:52Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: /* Technical Overview */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:Compiler]]&lt;br /&gt;
[[Category:Projects]]&lt;br /&gt;
&lt;br /&gt;
== Objective ==&lt;br /&gt;
&lt;br /&gt;
To reduce the size of EIFGENs to 10% of their levels as of version 5.7.62110&lt;br /&gt;
&lt;br /&gt;
== Motivation for reducing the size of EIFGENs ==&lt;br /&gt;
&lt;br /&gt;
I recently benchmarked a &amp;quot;Hello World&amp;quot; project at taking over 40 Mb of storage (with both workbench and finalized version compiled). Many of my production applications consume hundreds of megabytes, or even more than 1 Gb. This high level of consumption has several negative effects. It puts off potential customers when they see the high costs of storage and time involved in using the compiler, and it inhibits automated compilation and testing of a large number of Eiffel applications.&lt;br /&gt;
&lt;br /&gt;
Reducing the size of Eifgens could have numerous benefits. Significantly reducing the size could be reflected by a corresponding improvement in performance. It would make the compiler more competitive and more attractive to cost-conscious potential customers. &lt;br /&gt;
 &lt;br /&gt;
Manus told me that recently the size of the EIFGEN that's generated when compiling the compiler has gone from 1.8 Gb to 1 Gb. This is good, but I would like to set the goal of reducing EIFGENs by another 90%.&lt;br /&gt;
&lt;br /&gt;
== Technical Overview ==&lt;br /&gt;
&lt;br /&gt;
In a recent posting on comp.lang.eiffel, Manus explained the bulky content of the EIFGEN directory as follows:&lt;br /&gt;
&lt;br /&gt;
# The COMP directory contains &lt;br /&gt;
## one representation of the Abstract Syntax Tree of the source code in a format that's larger than the original source. &lt;br /&gt;
## a modifed second copy for code generation. &lt;br /&gt;
## A description of the classes in a compact format&lt;br /&gt;
## Dependencies for incremental recompilation&lt;br /&gt;
# The F_CODE directory contains &lt;br /&gt;
## C code for the finalized mode&lt;br /&gt;
## The C compiler output (Object files, static libraries, shared libraries, assemblies and executables.)&lt;br /&gt;
# The W_CODE directory contains&lt;br /&gt;
## C code for the Workbench mode&lt;br /&gt;
## The C compiler output (Object files, static libraries, shared libraries, assemblies and executables.&lt;br /&gt;
## Debug files from the C compiler (at least for MSC)&lt;br /&gt;
&lt;br /&gt;
I also found a PARTIALS directory, but it was empty.&lt;br /&gt;
&lt;br /&gt;
Right away, several ideas occur to me for reducing the size of the EIFGEN. First, there is almost certainly a HUGE amount of replication from project to project. Unless someone is radically modifying ANY, the majority of the code generated by one project is going to be identical to another project that's referencing the same libraries (or universe). With the current implementation, applications pay an enormous penalty for having to recompile all their libraries. A partial solution already exists with precompiled libraries, but historically these have been a pain to set up, and in my experience they can be difficult to port from one machine to another (especially for Eiffel .Net). There's also a major drawback to precompiles: your project can only reference one. So either you can reference a relatively small commmon subset, or you can reference a larger set that tries to engulf everything outside of your application. Neither solution is optimal. A better approach would allow precompiles to work more like traditional libraries, and for applications to be able to reference multiple precompiled libraries.&lt;br /&gt;
&lt;br /&gt;
Second, if I understand what's going on there can be five separate representations for each class in the EIFGEN (three representations in the COMP directory and a C representation in both the F_CODE and W_CODE directories). I'm not counting the additional representations that are the C compiler's binary output. &lt;br /&gt;
This sounds excessive on the surface of it, and there may be opportunities for combining some of these representations. For example, what if only one C code representation was generated, and C macros or ifdefs were used to control which type of binary was produced? Or could a single version of the AST serve all purposes?&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=Reducing_Eifgen_Size&amp;diff=4120</id>
		<title>Reducing Eifgen Size</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=Reducing_Eifgen_Size&amp;diff=4120"/>
				<updated>2006-08-05T01:13:00Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:Compiler]]&lt;br /&gt;
[[Category:Projects]]&lt;br /&gt;
&lt;br /&gt;
== Objective ==&lt;br /&gt;
&lt;br /&gt;
To reduce the size of EIFGENs to 10% of their levels as of version 5.7.62110&lt;br /&gt;
&lt;br /&gt;
== Motivation for reducing the size of EIFGENs ==&lt;br /&gt;
&lt;br /&gt;
I recently benchmarked a &amp;quot;Hello World&amp;quot; project at taking over 40 Mb of storage (with both workbench and finalized version compiled). Many of my production applications consume hundreds of megabytes, or even more than 1 Gb. This high level of consumption has several negative effects. It puts off potential customers when they see the high costs of storage and time involved in using the compiler, and it inhibits automated compilation and testing of a large number of Eiffel applications.&lt;br /&gt;
&lt;br /&gt;
Reducing the size of Eifgens could have numerous benefits. Significantly reducing the size could be reflected by a corresponding improvement in performance. It would make the compiler more competitive and more attractive to cost-conscious potential customers. &lt;br /&gt;
 &lt;br /&gt;
Manus told me that recently the size of the EIFGEN that's generated when compiling the compiler has gone from 1.8 Gb to 1 Gb. This is good, but I would like to set the goal of reducing EIFGENs by another 90%.&lt;br /&gt;
&lt;br /&gt;
== Technical Overview ==&lt;br /&gt;
&lt;br /&gt;
In a recent posting on comp.lang.eiffel, Manus explained the bulky content of the EIFGEN directory as follows:&lt;br /&gt;
&lt;br /&gt;
# The COMP directory contains &lt;br /&gt;
## one representation of the Abstract Syntax Tree of the source code in a format that's larger than the original source. &lt;br /&gt;
## a modifed second copy for code generation. &lt;br /&gt;
## A description of the classes in a compact format&lt;br /&gt;
## Dependencies for incremental recompilation&lt;br /&gt;
# The F_CODE directory contains &lt;br /&gt;
## C code for the finalized mode&lt;br /&gt;
## The C compiler output (Object files, static libraries, shared libraries, assemblies and executables.)&lt;br /&gt;
# The W_CODE directory contains&lt;br /&gt;
## C code for the Workbench mode&lt;br /&gt;
## The C compiler output (Object files, static libraries, shared libraries, assemblies and executables.&lt;br /&gt;
## Debug files from the C compiler (at least for MSC)&lt;br /&gt;
&lt;br /&gt;
I also found an empty PARTIALS directory, but it was empty.&lt;br /&gt;
&lt;br /&gt;
Right away, several ideas occur to me for reducing the size of the EIFGEN. First, there is almost certainly a HUGE amount of replication from project to project. Unless someone is radically modifying ANY, the majority of the code generated by one project is going to be identical to another project that's referencing the same libraries (or universe). With the current implementation, applications pay an enormous penalty for having to recompile all their libraries. A partial solution along these lines already exists with precompiled libraries, but historically these have been a pain to set up, and in my experience they can be difficult to port from one machine to another (especially for Eiffel .Net). There's also a major drawback to precompiles: your project can only reference one. So either you can reference a relatively small commmon subset, or you can reference a larger set that tries to engulf everything outside of your application. Neither solution is optimal. A better approach would allow precompiles to work more like traditional libraries, and for applications to be able to reference multiple precompiled libraries.&lt;br /&gt;
&lt;br /&gt;
Second, if I understand what's going on there can be five separate representations for each class in the EIFGEN (three representations in the COMP directory and a C representation in both the F_CODE and W_CODE directories). I'm not counting the additional representations that are the C compiler's binary output.&lt;br /&gt;
This sounds excessive on the surface of it, and there may be opportunities for combining some of these representations. For example, what if only one C code representation was generated, and C macros were used to control which type of binary was produced? Or could a single version of the AST serve both purposes?&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=User:Gmc444&amp;diff=4118</id>
		<title>User:Gmc444</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=User:Gmc444&amp;diff=4118"/>
				<updated>2006-08-05T00:16:52Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Greg began experimenting with Eiffel after reading about it in the mid '90s, and began seriously working with it a few years later.&lt;br /&gt;
&lt;br /&gt;
Blogs: [http://greg-c.blogspot.com/ Greg C] and [http://teameiffel.blogspot.com/ Team Eiffel]&lt;br /&gt;
&lt;br /&gt;
[[Reducing Eifgen Size]]&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=Talk:ConfigurationFileFormat&amp;diff=3035</id>
		<title>Talk:ConfigurationFileFormat</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=Talk:ConfigurationFileFormat&amp;diff=3035"/>
				<updated>2006-05-24T21:31:54Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Gmc44==&lt;br /&gt;
This proposal for a configuration file format looks similar to what was done with geant and gexace.&lt;br /&gt;
&lt;br /&gt;
Personally, I think XML is an inappropriate format for this job. It might be a good idea to talk to Gobo (Eric Bezault) about his experience with those tools.&lt;br /&gt;
&lt;br /&gt;
Among the problems:&lt;br /&gt;
&lt;br /&gt;
XML is very verbose, and while it can be read by a human, it's not very easy to read. In this respect it's much worse than Ace files.&lt;br /&gt;
&lt;br /&gt;
To solve configuration problems, you need all the basics of a programming language: input, output, state, conditionals, and iteration. Using XML to represent these often becomes kludgy. Look at the effort that goes into solving what should be fairly simple if conditions.&lt;br /&gt;
&lt;br /&gt;
I think it would be far better to evolve the Ace file specification, perhaps into a subset of Eiffel that allows us to write a clear, declarative specification of a system without a lot of &amp;lt;tag&amp;gt;s and &amp;lt;/tags&amp;gt; and obtuse rules.&lt;br /&gt;
&lt;br /&gt;
==Manus==&lt;br /&gt;
The format is just an internal mean and it is only in XML format to make it easy to store in source control management system. We will go towards the edition through a hopefully nice graphical interface, we have the experience of what currently exists in EiffelStudio to make something much easier to use.&lt;br /&gt;
&lt;br /&gt;
==Gmc444==&lt;br /&gt;
After writing my initial post, I did get to see a demo of how the new file format works, and how it's represented in an Eiffel-like format for users. It surprises me a little that the Eiffel-like presentation would be considered harder to work with in source control than XML. Oh well, as long as I don't have to worry about hand-editing XML I can live with it =)&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=User:Gmc444&amp;diff=3034</id>
		<title>User:Gmc444</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=User:Gmc444&amp;diff=3034"/>
				<updated>2006-05-24T21:20:48Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Greg began experimenting with Eiffel after reading about it in the mid '90s, and began seriously working with it a few years later.&lt;br /&gt;
&lt;br /&gt;
Blogs: [http://greg-c.blogspot.com/ Greg C] and [http://teameiffel.blogspot.com/ Team Eiffel]&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=User:Gmc444&amp;diff=3029</id>
		<title>User:Gmc444</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=User:Gmc444&amp;diff=3029"/>
				<updated>2006-05-24T20:03:51Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Greg began experimenting with Eiffel after reading a few articles about it in the mid '90s, and began seriously working with it a few years later.&lt;br /&gt;
&lt;br /&gt;
Blogs: [http://greg-c.blogspot.com/ Greg C] and [http://teameiffel.blogspot.com/ Team Eiffel]&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=Talk:ConfigurationFileFormat&amp;diff=1919</id>
		<title>Talk:ConfigurationFileFormat</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=Talk:ConfigurationFileFormat&amp;diff=1919"/>
				<updated>2006-04-18T05:12:20Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: XML is not a good way to go.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This proposal for a configuration file format looks similar to what was done with geant and gexace.&lt;br /&gt;
&lt;br /&gt;
Personally, I think XML is an inappropriate format for this job. It might be a good idea to talk to Gobo (Eric Bezault) about his experience with those tools.&lt;br /&gt;
&lt;br /&gt;
Among the problems:&lt;br /&gt;
&lt;br /&gt;
XML is very verbose, and while it can be read by a human, it's not very easy to read. In this respect it's much worse than Ace files.&lt;br /&gt;
&lt;br /&gt;
To solve configuration problems, you need all the basics of a programming language: input, output, state, conditionals, and iteration. Using XML to represent these often becomes kludgy. Look at the effort that goes into solving what should be fairly simple if conditions.&lt;br /&gt;
&lt;br /&gt;
I think it would be far better to evolve the Ace file specification, perhaps into a subset of Eiffel that allows us to write a clear, declarative specification of a system without a lot of &amp;lt;tag&amp;gt;s and &amp;lt;/tags&amp;gt; and obtuse rules.&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=Component_standards&amp;diff=1909</id>
		<title>Component standards</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=Component_standards&amp;diff=1909"/>
				<updated>2006-04-16T16:32:35Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Standards and Tools for Eiffel-based Components'''&lt;br /&gt;
&lt;br /&gt;
While Eiffel appears to be an ideal language for building libraries, it has not caught on. Today, the most common way of distributing Eiffel libraries is as source code, for Eiffel compilers.&lt;br /&gt;
&lt;br /&gt;
At the same time, other languages heavily leverage the distribution of binary components. This is true for both open source and proprietary software. &lt;br /&gt;
&lt;br /&gt;
I'd like to see some emphasis placed on standards and tools to make it easier to distribute binary components written in Eiffel. Among the problems that need to be addressed are issues of data interchange, what to do with MI, exception handling, and multithreading.&lt;br /&gt;
&lt;br /&gt;
One possible starting place: for binary Eiffel library, designate for the compiler an &amp;quot;export&amp;quot; cluster. This cluster contains the root classes for the library. Constraints may be placed on these classes to ease integration with other languages. For example, members of the cluster may not be implemented with MI. The public interface for the classes may only reference other classes within the cluster, or primitive data types.&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	<entry>
		<id>https://dev.eiffel.com/index.php?title=Category:Projects&amp;diff=1908</id>
		<title>Category:Projects</title>
		<link rel="alternate" type="text/html" href="https://dev.eiffel.com/index.php?title=Category:Projects&amp;diff=1908"/>
				<updated>2006-04-16T16:25:08Z</updated>
		
		<summary type="html">&lt;p&gt;Gmc444: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Projects and project suggestions.&lt;br /&gt;
&lt;br /&gt;
* Build infrastructure&lt;br /&gt;
**[[Build_tool | Build tool]]&amp;lt;br&amp;gt;&lt;br /&gt;
**[[Debian_packages | Debian packages]]&amp;lt;br&amp;gt;&lt;br /&gt;
**[[OSX_release_infrastructure|OSX release infrastructure]]&lt;br /&gt;
**[[Component_standards| Standards and tools for Eiffel based components]]&lt;br /&gt;
&lt;br /&gt;
* UI&lt;br /&gt;
**[[Vision2_Accelerator|Vision2 Accelerator]]&amp;lt;br&amp;gt;&lt;br /&gt;
**[[Editor|Editor]]&amp;lt;br&amp;gt;&lt;br /&gt;
**[[EiffelBuild_Integration|EiffelBuild Integration]]&amp;lt;br&amp;gt;&lt;br /&gt;
**[[Cocoa_for_EiffelVision2|Cocoa for EiffelVision2]]&lt;br /&gt;
&lt;br /&gt;
* Library&lt;br /&gt;
**[[Scintilla_component| Multiplatform editor component: Scintilla]]&amp;lt;br&amp;gt;&lt;br /&gt;
**[[Gecko_component| Multiplatform layout engine component: Mozilla/Gecko]]&amp;lt;br&amp;gt;&lt;/div&gt;</summary>
		<author><name>Gmc444</name></author>	</entry>

	</feed>