gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] integrating UCSTRING to gobo-eiffel

[majkel k. <maj...@ep...>]

hello eric,

i think it is getting time to integrate the ucstring-cvs-repository into
the gobo-eiffel-cvs. in the current state it is relative stable, nearly
only minor
beautifications must be done (eg "indexing"). a lot of people are
waiting for it, so we should integrate it. the necessary modifications
can be done if i have a little more time and cvs-access.

who will import the stuff into cvs and whereto?


--
maj...@ep...

Re: [gobo-eiffel-develop] build tools

[Andreas L. <no...@sb...>]

And once again I was trapped by reply-to... Sorry the last mail was only
ment for Berend.

sorry for the confusion,
Andreas

[gobo-eiffel-develop] build tools

[Andreas L. <no...@sb...>]

Hi Berend,

have you heard about Sven Ehrke's effort to develop a "ant" like tool
for Eiffel. IIRC you also showed interest in developing a similar tool.
I think it would be a good idea to coordinate our efforts to avoid
duplicated work (;


Andreas

[gobo-eiffel-develop] Re: ant4e

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

Sven Ehrke wrote (in http://groups.yahoo.com/group/elj-win32-dev/):
> 
> Hi everyone,
> 
> I am back from my holidays and just had to do it:
> under the tools/ant4e directory of bonbon you can find a first version
> of an eiffel build tool based on the concepts of Jakarta's Ant
> tool for Java.
> All you have to do is to create a file called ebuild.xml
> (take the one which is there as a template).
> Currently only two tasks are supported:
> 
>   - the SmallEiffel compile task
>   - a general exec task
> 
> this is enough to get a project compiled, cleaned etc., so we
> could get rid of the elj.bat files.
> Look in the small Readme.txt in tools/ant4e if you're interested.
> 
> one extension I plan to include is the cluster list of system
> into the ebuild.xml. That information then could be used to
> generate to loadpath.se file and files needed for Visual Eiffel
> and ISE Eiffel.
> 
> BTW: mexp is required.
> 
> Let me know what you think.
> 
> - Sven

This is just to let people on the elj-win32-dev mailing list
know that Andreas Leitner is currently developing a similar
tool called xace (this name might change when the tool gets
part of the Gobo distribution) as part of the Gobo project.
It would be nice if the ELJ and Gobo teams could join their
efforts and build a unique tool. You can check what Andreas
has already done in the eXML mailing list archive:

  http://groups.yahoo.com/group/exml/messages

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

Re: [gobo-eiffel-develop] cluster structure of bridge pattern

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

Andreas Leitner wrote:
> 
> This is modelled after your second sugesstion, but I like the first one
> better.

In your case yes. But if you have something like that:

  foo/...
  foo/impl/a
  foo/impl/b
  foo/impl/c
  foo/impl/d
  foo/impl/e
  foo/impl/f
  foo/impl/g

then the second solution is better when you want to include
only one implementation (if a, b, c, ... are platforms for 
example):

<mount location="${FOO}/library/foo.xace">
    <exclude cluster="foo.impl"/>
</mount>
<mount location="${FOOL}/library/foo.xace" cluster="foo.impl.f"/>

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

Re: [gobo-eiffel-develop] cluster structure of bridge pattern

[Andreas L. <no...@sb...>]

On 07 Jun 2001 10:20:46 +0200, Eric Bezault wrote:
> Eric Bezault wrote:
> > 
> >   mount foo
> >      exclude
> >         impl/unix
> 
> Even better:
> 
>   mount foo exclude impl
>   mount foo/impl/${PLATFORM}

Ok, you convinced me. This is my current XACE file for the xace-tool. 

--
<?xml version="1.0"?>
<system name="xace">
	<root class="XACE" creation="make" />
	<cluster>
		<options classes="default" >
			<require enable="False" />
			<ensure enable="False" />
			<invariant enable="False" />
			<loop enable="False" />
			<optimize enable="True" />
		</options>

		<cluster name="xace" location="${EXML}/src/xace/" />

		<mount location="${EXML}/library/exml.xace" >
			<exclude cluster="exml.impl.no_eiffel" />
			<exclude cluster="exml.impl.no_tree_on_event" />
			<exclude cluster="exml.impl.expat" />
		</mount>

		<mount location="${EXML}/library/gobo.xace" />
		<mount location="${EXML}/library/ucstring.xace" />
		<mount location="${EXML}/library/kernel.xace" />
	</cluster>
</system>
--

Which means that the Eiffel and Tree on Event implementations are
included and Expat is left out. Note: Due to the factory pattern in eXML
I have to include a "no_...." cluster for each implementation left out. 

The eXML mount could be rewritten like this also:
--
		<mount location="${EXML}/library/exml.xace" >
			<exclude cluster="exml.impl" />
		</mount>
<mount location="${EXML}/library/exml.xace" 
      cluster="exml.impl.interface" />
<mount location="${EXML}/library/exml.xace" 
      cluster="exml.impl.eiffel" />
<mount location="${EXML}/library/exml.xace" 
      cluster="exml.impl.tree_on_event" />
<mount location="${EXML}/library/exml.xace" 
      cluster="exml.impl.no_expat" />
/>
--

This is modelled after your second sugesstion, but I like the first one
better. Making "exlcude" an attribute is not such a good idea IMO,
because it prehibits multiple excludes.


Andreas 

Re: [gobo-eiffel-develop] cluster structure of bridge pattern

[Alexander K. <kw...@ah...>]

Eric Bezault wrote:

> It's not that easy because in the case of the xml library
> for example, two (or more) different implementations for
> the XML parser may be compiled into the program. So the
> user needs to choose which implementations of the parser
> he wants to have in his program. In that case having a
> single point of entry for each implementation in the
> impl directory seems better in my opinion:
> 
>   xml/impl/expat
>   xml/impl/eiffel

You are right, it depends on the situation. I mean that the
details, like PLATFORM and COMPILER, should be
hidden for the user by default. E.g., it _could_ be that we
have 2 expat implementations:

   xml/impl/expat/win32
   xml/impl/expat/unix

No need to bother user with platform details in this case.

Regards,
Alexander Kogtenkov
Object Tools, Moscow

Re: [gobo-eiffel-develop] cluster structure of bridge pattern

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

Alexander Kogtenkov wrote:
>  
> I would also move PLATFORM/COMPILER-dependent
> directories down the hierarchy:
> 
>  foo/impl/foo/win32
>  foo/impl/foo/unix
>  foo/impl/foobar/win32
>  foo/impl/foobar/unix
> 
> and hide the platform dependencies in the descriptions
> of the clusters  foo/impl/foo and  foo/impl/foobar so that
> the client should not worry about implementation issues
> at all. The user just mounts
> 
>  foo/impl
> 
> or more selectively
> 
>  foo/impl/foo

It's not that easy because in the case of the xml library
for example, two (or more) different implementations for
the XML parser may be compiled into the program. So the
user needs to choose which implementations of the parser
he wants to have in his program. In that case having a
single point of entry for each implementation in the
impl directory seems better in my opinion:

  xml/impl/expat
  xml/impl/eiffel

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

Re: [gobo-eiffel-develop] cluster structure of bridge pattern

[Alexander K. <kw...@ah...>]

Andreas Leitner wrote:

> foo ... main cluster of GOBO-sub-library "foo"
> foo/bar ... "bar" is a (interface-)subcluster
> foo/foobar ..."foobar" is another (interface-)subcluster
> foo/impl ... "impl" contains all bridge-implementations
> foo/impl/win32 ... contains the win32 implementation
> foo/impl/win32/bar ... implements the "bar" interfaces for win32
> foo/impl/win32/foobar ... implements the "foobar" interfaces for win32
> foo/impl/unix/ ... contains the unix implementation
> foo/impl/unix/bar ... implements the "bar" interfaces for unix
> foo/impl/unix/foobar ... implements the "foobar" interfaces for unix

> For several reasons (some implementations might be mutaly exclusive or
> depend on external references you cannot satisfy) it must be easily
> possible to select an arbitray number of implementations. This means
> that if the above foo example is in a XACE file called foo.xace, you may
> not want mount the whole cluster, as this would automatically mount all
> implementations.
> 
> This is easily _not_ possible with the above cluster structure for
> "foo". It is possible with the original cluster structure of eXML
> thought. Here is the same library "foo" with the eXML (or Vision2 - to
> be exact) cluster structure:
> 
> foo ... main cluster of GOBO-sub-library "foo"
> foo/interfaces ... all interfaces subclusters go in here
> foo/interfaces/bar ... bar is an interface-subcluster
> foo/interface/foobar ... foobar is an interface-subcluster
> foo/impl  ... all implementations go in here
> foo/impl/win32 ... the win32 impl
> foo/impl/win32/foo .. the "foo" impl for win32
> foo/impl/win32/foobar .. the "foobar" impl for win32
> foo/impl/unix/foo ... the "foo" impl for unix
> foo/impl/unix/foobar ... the "foobar" impl for unix 
> 
> Here the user mounts (remember a mount, also mounts the sublcusters)
> 
> foo/interfaces
> foo/impl/${PLATFORM}

Like Eric I see an additional level "interfaces" as artificial.
In fact, if the cluster description file is designed correctly,
every implementation cluster will refer to the corresponding
interface cluster, so

 foo/impl/win32/foo mounts foo/foo
 foo/impl/win32/foobar mounts foo/foobar
 foo/impl/unix/foo mounts foo/foo
 foo/impl/unix/foobar mounts foo/foobar

So, it would be enough for the user to mount only one
cluster, namely

 foo/impl/${PLATFORM}

All the interfaces will be mounted automatically.

I would also move PLATFORM/COMPILER-dependent
directories down the hierarchy:

 foo/impl/foo/win32
 foo/impl/foo/unix
 foo/impl/foobar/win32
 foo/impl/foobar/unix

and hide the platform dependencies in the descriptions
of the clusters  foo/impl/foo and  foo/impl/foobar so that
the client should not worry about implementation issues
at all. The user just mounts

 foo/impl

or more selectively

 foo/impl/foo

Regards,
Alexander Kogtenkov
Object Tools, Moscow

Re: [gobo-eiffel-develop] cluster structure of bridge pattern

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

Eric Bezault wrote:
> 
>   mount foo
>      exclude
>         impl/unix

Even better:

  mount foo exclude impl
  mount foo/impl/${PLATFORM}

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

Re: [gobo-eiffel-develop] cluster structure of bridge pattern

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

Andreas Leitner wrote:
> 
> foo ... main cluster of GOBO-sub-library "foo"
> foo/interfaces ... all interfaces subclusters go in here
> foo/interfaces/bar ... bar is an interface-subcluster
> foo/interface/foobar ... foobar is an interface-subcluster
> foo/impl  ... all implementations go in here
> foo/impl/win32 ... the win32 impl
> foo/impl/win32/foo .. the "foo" impl for win32
> foo/impl/win32/foobar .. the "foobar" impl for win32
> foo/impl/unix/foo ... the "foo" impl for unix
> foo/impl/unix/foobar ... the "foobar" impl for unix
> 
> Here the user mounts (remember a mount, also mounts the sublcusters)
> 
> foo/interfaces
> foo/impl/${PLATFORM}
> 
> Q.E.D.
> 
> What do you think?

I think something is missing in your bridge pattern.
What interface are you talking about in foo/interfaces
(BTW, I would prefer foo/interface (singular)): user-
interface or the deferred classes parents of the
classes in foo/impl/${PLATFORM}/*?

If I understand correctly, you just want to 
mount:

foo/interfaces
foo/impl/${PLATFORM}

instead of:

foo/bar
foo/foobar
foo/impl/${PLATFORM}

Personally I have the feeling that this extra directory
'interface' is artificial. If you consider XM_PARSER to
be part of the "interface" of the xml library, then
DS_LINKED_LIST is part of the "interface" of the
container library as well, and as such we should also
add this dummy directory to the container library:

structure/interface/list
structure/interface/set
structure/interface/table
...

So it looks like the only reason why you want to add this
extra directory is to save typing characters in the XACE
file rather than to get a better directory structure. Is
it really a good reason?

> Here the user mounts (remember a mount, also mounts the sublcusters)

Could you have an option in XACE which excludes some
specified clusters from a library? This looks like
a better solution to me if you want to save typing
characters:

  mount foo
     exclude
        impl/unix

I'll let you find an XML syntax for that, but I hope
you got the idea.

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

Re: [gobo-eiffel-develop] Gobo project and source codeformatting

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

Andreas Leitner wrote:
> 
> If I understand the situation correctly, we could now run the CVS
> version of UCSTRING through Fresco and start integrating it into GOBO,
> right? Or are there further steps neccessary before we can do so?

Actually now that Majkel has changed the name of his classes
(and their filenames as well), he could commit ucstring now
into the Gobo CVS repository and take care of the cosmetics
a little bit later. I didn't suggested that to Majkel yet 
because I thought I understood that he wanted to make an
official release of ucstring before integrating it into
Gobo. Otherwise I would be happy for Majkel to commit his
classes into Gobo CVS. What would have been more heavyweight
would have been to commit the classes with their old names
and then 'cvs remove' them to commit them again with their
new names.

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

Re: [gobo-eiffel-develop] DocBook & XML

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

Frieder Monninger wrote:
> 
> I am repeating myself .. but it seems to be necessary:
> 
> DocBook is just a syntax in order to express a document.
> What happens with this document afterwards is something
> different - usually it is transformed to lets say HTML or PDF -
> but maybe to something totally different.
> 
> If there is a buggy transformation available - lets say to HTML,
> then this transformation should be fixed. Note: The transformation
> (usually in XSL - and in source :-) is buggy, not DocBook.
> 
> And if you don't like the transformation - change it. Thats all.

Yes, I think that we understood what you were saying
in your previous messages. I'm currently reading
some tutorials about XSL and it looks very powerful
indeed. Nobody volunteered yet to convert one of the
existing chapters of the Gobo doc to DocBook (or XML
in general), so I will give it a try this weekend after
I finish reading the XSL tutorials.

Thank you for your suggestion about using XSL. I'll
let you know when I will have made progress converting
a chapter of the doc to DocBook and show you what it
looks like.

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

Re: [gobo-eiffel-develop] [Fwd: Gobo project and source code formatting]

[Andreas L. <no...@sb...>]

On 06 Jun 2001 18:26:37 +0100, Ian Elliott wrote:
> In message <3B1...@go...>, Eric Bezault
> <er...@go...> writes
> >Berend de Boer wrote:
> >> 
> >> I'm a bit short on time, so I didn't read the stuff carefully, but I
> >> like to get a copy to try it out on my sources. Does it compile with
> >> SmallEiffel or ISE?
> >
> >Unfortunately I don't think so. Ian said that it compiles
> >only with Visual Eiffel and is only available under
> >Windows.
> >
> This is the case. I can understand the wish to try out Fresco before
> making any kind of decision. I estimate it shall be ready for beta
> testing within a couple of weeks or so. In the meantime the offer to
> format sources under the goboesque style spec still stands,

While I am not for making a non-free tool mandatory for the GOBO
development, I am all for using a closed source tool optionally -
especially if it speeds up development.

Thank you Ian for your offer. I for one would, when time is ready,
surely want to make use of your tool to bring eXML into shape.

If I understand the situation correctly, we could now run the CVS
version of UCSTRING through Fresco and start integrating it into GOBO,
right? Or are there further steps neccessary before we can do so?


Andreas

[gobo-eiffel-develop] DocBook & XML

[Frieder M. <fm...@ob...>]

I am repeating myself .. but it seems to be necessary:

DocBook is just a syntax in order to express a document.
What happens with this document afterwards is something
different - usually it is transformed to lets say HTML or PDF -
but maybe to something totally different.

If there is a buggy transformation available - lets say to HTML,
then this transformation should be fixed. Note: The transformation
(usually in XSL - and in source :-) is buggy, not DocBook.

And if you don't like the transformation - change it. Thats all.


--
Frieder Monninger
Object Tools GmbH

fm...@ob...  ---  http://www.object-tools.com
Nordstr. 5 - D 35619 Braunfels - fon +49 6472 911 030 fax 031

Re: [gobo-eiffel-develop] [Fwd: Gobo project and source code formatting]

[Ian E. <ia...@no...>]

In message <3B1...@go...>, Eric Bezault
<er...@go...> writes
>Berend de Boer wrote:
>> 
>> I'm a bit short on time, so I didn't read the stuff carefully, but I
>> like to get a copy to try it out on my sources. Does it compile with
>> SmallEiffel or ISE?
>
>Unfortunately I don't think so. Ian said that it compiles
>only with Visual Eiffel and is only available under
>Windows.
>
This is the case. I can understand the wish to try out Fresco before
making any kind of decision. I estimate it shall be ready for beta
testing within a couple of weeks or so. In the meantime the offer to
format sources under the goboesque style spec still stands,

Ian Elliott

Re: [gobo-eiffel-develop] [Fwd: Gobo project and source code formatting]

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

Berend de Boer wrote:
> 
> I'm a bit short on time, so I didn't read the stuff carefully, but I
> like to get a copy to try it out on my sources. Does it compile with
> SmallEiffel or ISE?

Unfortunately I don't think so. Ian said that it compiles
only with Visual Eiffel and is only available under
Windows.

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

[gobo-eiffel-develop] Re: DocBook

[Joseph R. K. <ki...@ac...>]

--"Alexander Kogtenkov" <kw...@ah...> wrote:

> DocBook is mostly developed to write texts rather than
> code. There are some constructs that allow to write
> class/feature declarations but not implementations. These
> constructs are potentialy language-independent, but the
> real tools support only C, C++, Java and, maybe, few
> others - not Eiffel. If we talk about Norman Walsh XSLTs
> it's possible to provide Eiffel rendering and ask him to
> include it to the distribution.

Norm is an old friend of mine from graduate school (the first go 'round), 
so we won't have any trouble with interactions there.

I agree with Alexander's DocBook comments, but I'd like to add one thing. 
It is possible to do (X)HTML in such a way that is standards-compliant, 
consistent, looks great, and is browser-independent.  We use such 
techniques for the new NICE web site.  It isn't easy, but once you know the 
standards inside and out and know the capabilities of all browsers 
(including such things as OmniWeb, W3-mode, lynx, etc.) you can do a very 
good job.  I'd be happy to provide assistance on this front wrt HTML 
generation.

Joe
--
Joseph R. Kiniry                    http://www.cs.caltech.edu/~kiniry/
California Institute of Technology        ID 78860581      ICQ 4344804

Re: [gobo-eiffel-develop] [Fwd: Gobo project and source code formatting]

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> Comments welcome.

I'm a bit short on time, so I didn't read the stuff carefully, but I
like to get a copy to try it out on my sources. Does it compile with
SmallEiffel or ISE?

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] fresco tool

[Charles H. <cha...@ea...>]

Roger Browne wrote:

>>>Also Ian Elliott (ia...@no...) has written a tool called
>>>fresco which formats Eiffel source code in user-defined ways to let
>>>people use it for free (it runs only on MS-Windows, though).
>>>
> 
> Eric Bezault wrote:
> 
>>contrary to what Roger said, this tool is not free.
>>
> 
...
> Regards,
> Roger
> 
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> http://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 
> 

Perhaps a more significan restriction (I don't know the price) is that 
it's Windows only.  This imposes significant restrictions.  One of my 
main interests in Eiffel/Gobo is as a cross-platform tool, and I have 
been intentionally avoiding (attempting to avoid, sometimes) tools and 
techniques that are limited to one particular platform.


-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

[gobo-eiffel-develop] fresco tool

[Roger B. <ro...@ei...>]

> > Also Ian Elliott (ia...@no...) has written a tool called
> > fresco which formats Eiffel source code in user-defined ways to let
> > people use it for free (it runs only on MS-Windows, though).

Eric Bezault wrote:
> contrary to what Roger said, this tool is not free.

Sorry for the confusion. I first wrote something like "and Ian might be
persuaded to let people use it for free on the Gobo project". Then I
decided this was too presumptuous and decided to take it out - but due to
a cut-and-paste error some of the text remained.

Regards,
Roger

Re: [gobo-eiffel-develop] DocBook

[Alexander K. <kw...@ah...>]

Eric Bezault wrote:

> Does anyone in this list have some experience using
> DocBook to write documentation? I suggested using
> DocBook to write the documentation of Gobo and I
> would like to know your opinion about that.

I  have some experience with DocBook and some other
issues discussed here last few days. Here are my comments:

1. DocBook

1.1. Writing

It seems to be the real way to write the documentation.
I cannot say that many products support this XML out
of the box, but there is enough tools to make the things
rolling. Even WYSIWYG can be approached to some
extent (I written a CSS that styles the DocBook document
under XMetal - XML editor).

1.2. Program code

DocBook is mostly developed to write texts rather than
code. There are some constructs that allow to write
class/feature declarations but not implementations. These
constructs are potentialy language-independent, but the
real tools support only C, C++, Java and, maybe, few
others - not Eiffel. If we talk about Norman Walsh XSLTs
it's possible to provide Eiffel rendering and ask him to
include it to the distribution.

1.3. Modularity

When I started to use XML DocBook (after using SGML
version), I tried to minimize elements/attributes I would use.
This is possible due to modular structure of the DocBook DTD.
However, that did not work. Day after day I included back
tables, cross-references, index terms, glossary elements,
footnotes, ... - almost everything DocBook gives.

The story is a little bit different with attributes. There are many
of them that I did not use. So, to simplify writing, a half of them
was excluded.

DocBook DTD allows to add elements and attributes that are not
the standard part of it. It might be possible to add Eiffel-specific
markup, but I have no actual experiance with it.

1.4. Colors

All output I've seen for DocBook documents is black-white.
I do not know whether multicolored schemes can be used for the
output.

2. HTML formatting

2.1. Problem with automatically generated HTML

The reasons of bad-looking HTML mostly deal with the
browser. The same HTML  looks very differently under
different browsers. Some of  them seem to expect
hand-written HTML. Reformating HTML to the "expected"
form improves the results. Examples of the formating
that tricks the browsers are: spaces around some elements,
elements not starting from the new line, new line inside the
element tag, "unexpected" combination of nested elements.
Fortunately, w3c provides a tool (tidy) that modifies HTML
to be in the most "expected" form. Other appoaches
like SED/AWK can be also used.

2.2. Styles

HTML can look much more attractive if it uses CSS.
The HTML output for DocBook document can include
classes for the elements, so customization via CSS becomes
a lot easier. Unfortunately, not all browsers support CSS
properly.

3. PDF output

Simple markup usually can be converted to PDF without
problems and the resulting PDF can look pretty good. When
the layout becomes complex, especially when complex tables
are used, the PDF is just unacceptable (I tried both free FOP
and commercial renderx).

Regards,
Alexander Kogtenkov
Object Tools, Moscow

[gobo-eiffel-develop] [Fwd: Gobo project and source code formatting]

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

Here is Ian's second message.

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

[gobo-eiffel-develop] [Fwd: Gobo project and source code formatting]

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

Ian Elliott allowed me to forward this message to the list.
As Roger already mentioned, Ian is the author of a new
formatting tool called Fresco Formatter written in Eiffel.
Unfortunately, it is still under development and not available
yet, it will work only on Windows, and contrary to what Roger
said, this tool is not free. But nevertheless Ian offers to
give a free license of Fresco to the members of the Gobo
development team when it will be released for beta-testing,
as it may help converting existing classes to a consistent
Gobo-nized layout.

Here is Ian's message, followed by two others forwarded
messages (one from me and another one from Ian).

Comments welcome.

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

[gobo-eiffel-develop] [Fwd: Gobo project and source code formatting]

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

This is my reply to Ian's original message.

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