gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] The Docbook Book

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

Paul Cohen wrote:
> 
> Am I the only one getting multiple copies of single
> postings to gob...@li...?
> 
> I have got duplicate (and even triple copy) mails
> from Eric, Frieder, Roger and Berend begining
> this Saturday.
> 
> Anyone know what's going on?

I don't have this problem. Did you try to unsubscribe
and then subscribe again?

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

Re: [gobo-eiffel-develop] The Docbook Book

[Paul C. <pa...@en...>]

Hi all,

Am I the only one getting multiple copies of single
postings to gob...@li...?

I have got duplicate (and even triple copy) mails
from Eric, Frieder, Roger and Berend begining
this Saturday.

Anyone know what's going on?

/Paul

[gobo-eiffel-develop] Generating DocBook from Eiffel short forms

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

Andreas wrote:
> ... Perhaps it's easy to adapt my Eiffel mode to generate
> Eric's makeup, I haven't looked into detail if that is possible.

The ebench output filter mechanism is quite powerful; it should be
possible to configure it to format short forms for DocBook. I haven't
tried it, though.

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).

Regards,
Roger
-- 
Roger Browne - ro...@ei... - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428

[gobo-eiffel-develop] The Docbook Book

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

seems even to be available on-line: http://www.docbook.org/tdg/html/


--
Frieder Monninger
Object Tools GmbH

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

[gobo-eiffel-develop] DocBook

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

1. There is a book available at O'Reilley ..

2. As a nice example one can do with PDF - have a look at 
http://www.renderx.com/Tests/hammer/hammer.fo.html in special,
and  http://www.renderx.com in general :-)

3. Again: Do it in XML - no other format. What scheme/dtd is
used does not matter so much. Unfortunately there is no need to
use eiffel for transformations - XSL is something like a functional
programming language to transfor XML into nearly everything ...




--
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] DocBook

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

Andreas Leitner <no...@sb...> writes:

> Don't remember the exact tag names, but they have something like:
> <listing name="C++">
>     void main () {...}
> </listing>

I think pdf doc generation shouldn't be a problem. Take a look at
eposix-manual.pdf to see what's possible. My ConTeXt Eiffel mode
generates OOSC2 Eiffel formatting.

So DocBook to pdf through ConTeXt will just run fine, I'll will make
sure of that. You can get any layout you wish.

Generating HTML like Eric does might be harder, I don't know. Perhaps
it's easy to adapt my Eiffel mode to generate Eric's makeup, I haven't
looked into detail if that is possible.

Straight from DocBook to HTML and getting a decent markup is
hard, I suppose. As there are also jadetex -> latex -> latex2html
possiblities, I think we don't limit ourselves in anyway. But certain
output might take some work, but is never impossible.

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] DocBook

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

Roger Browne wrote:
>  
> Perhaps someone with existing DocBook experience will volunteer to
> convert one of Eric's chapters so that he can get an idea of the usual
> DocBook idioms. 

Yes, good idea! That way it will make it easier for me to learn
DocBook and convert the other chapters at the same time using
this example as a starting point. Any volunteers who already
know the DocBook idioms? I don't ask to convert everything: just
one chapter would be enough (hopefully) to get an idea.

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

[gobo-eiffel-develop] DocBook, LaTeX

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

I wrote:
> > LaTeX ... An example of the problems: Eiffel identifiers
> > use lots of underscores, and in some places (e.g. headers) you must
> > escape these with a backslash, but in other places you do not need to...

Berend replied:
> And even the underscore problem is easy to fix with just this
> definition:
> 
>         \catcode`\_=12

Yeah, LaTeX is like emacs. _ANYTHING_ is possible, but it is a hassle.
One after another, we were "fixing" problems like this. There was always
a solution or a patch or a macro, but finding and applying the fixes was
getting in the way of writing documentation.

I wrote:
> > ... I wanted to be proud of the documentation that we were
> > producing, and DocBook just wasn't good enough.

Eric asked: 
> Do you mean for flatshort forms or for the overall documentation
> in general?

The problems were with the layout in general. I can't remember the
details now, but it was cosmetic things like uneven vertical spacing
around certain combinations of headings, paragraphs and program listings.

Andreas wrote:
> ... IMO it should not be a big deal to write our own DocBook->HTML
> tool that generates HTML the way we want it. This will be even easier if
> we only settle for a subset of DocBook 
> ... I believe that the best way would be to start with
> DocBook imediatly. Even if we don't get perfect results now, we will
> have a smooth upgarde path (once we write our own tools).

That sounds good. I suggest to start with a small subset of DocBook. That
way, "our own tools" will be easier to write and won't take too much
energy away from writing software. The subset of DocBook can just be the
tags that Eric needs to convert his existing documentation.

Perhaps someone with existing DocBook experience will volunteer to
convert one of Eric's chapters so that he can get an idea of the usual
DocBook idioms. (Sorry, I'm not in a position to donate the time to do
that myself right now.)

Regards,
Roger
-- 
Roger Browne - ro...@ei... - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428

Re: [gobo-eiffel-develop] DocBook

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

On 02 Jun 2001 12:31:45 +0200, Eric Bezault wrote:
> Andreas Leitner wrote:
> > 
> > I never wrote anything with DocBook. I just looked up the specs
> > recently. IMO it should not be a big deal to write our own DocBook->HTML
> > tool that generates HTML the way we want it. This will be even easier if
> > we only settle for a subset of DocBook (we surely don't need some of
> > it's features - they seem to have special tags for special domains alot)
> 
> But on the other hand they don't have special tags for Eiffel ;-(
> If we add these tags for Eiffel, it will not be DocBook anymore
> and we won't be able to use tools supporting the DocBook format.
> Is that correct? Or can we hijack some tags and use them to specify
> Eiffel specific entities? To what extent is the DocBook format
> flexible (or is it not flexible at all)?

Don't remember the exact tag names, but they have something like:
<listing name="C++">
    void main () {...}
</listing>

So we can use that. I believe that the best way would be to start with
DocBook imediatly. Even if we don't get perfect results now, we will
have a smooth upgarde path (once we write our own tools). And even if we
at some point decide that DocBook is to limiting, a tool to convert it
to any other format will be easy to do, because we have all the meta
information and can parse it very very easily.

I am totaly for DocBook. Also I belive that with the current tools you
can supply your own style sheets. Maybe that helps us in the short term
to get better HTML results.

Andreas

Re: [gobo-eiffel-develop] DocBook

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

Andreas Leitner wrote:
> 
> I never wrote anything with DocBook. I just looked up the specs
> recently. IMO it should not be a big deal to write our own DocBook->HTML
> tool that generates HTML the way we want it. This will be even easier if
> we only settle for a subset of DocBook (we surely don't need some of
> it's features - they seem to have special tags for special domains alot)

But on the other hand they don't have special tags for Eiffel ;-(
If we add these tags for Eiffel, it will not be DocBook anymore
and we won't be able to use tools supporting the DocBook format.
Is that correct? Or can we hijack some tags and use them to specify
Eiffel specific entities? To what extent is the DocBook format
flexible (or is it not flexible at all)?

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

Re: [gobo-eiffel-develop] DocBook

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

Berend de Boer wrote:
> 
> I would rather have everyone use ConTeXt :-)

I don't know ConTeXt, but from its name I guess that it is
a TeX based tool/format.

I'm not sure that everyone wants to use TeX based formats.
The advantage of XML based formats is that it's fun. But don't
get me wrong: it's not fun because it's any better than TeX
or other formatting languages. It's fun in the sense that 
more and more people are using it, more and more tools are
supporting it, and finally it's fun because it's related to
the internet. This is a questionable definition of what
fun means, but I guess that it is questionable as well to
see people using Java instead of Eiffel ;-)

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

Re: [gobo-eiffel-develop] DocBook

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

Roger Browne wrote:
> 
> So we moved to DocBook. It's a very pleasant markup to write in. The DTD
> is clean, readable, easy-to-learn and well-suited to software
> documentation. But we never produced HTML that looked really good. It was
> OK, but there were too many quirks in the spacing, and a small number of
> other irritating quirks such as character set incompatibilities. It just
> didn't look good enough that I could be proud of it. Don't get me wrong
> ... it's quite usable, but the HTML tools don't produce output that looks
> as good as Eric's. I wanted to be proud of the documentation that we were
> producing, and DocBook just wasn't good enough.

That's something that worried me as well: I never saw on the
Web HTML pages generated from DocBook that looked really good.
That's why I asked Andreas if it was possible to write a translator
DocBook -> HTML using his Eiffel XML library. Or at least with
a subset of DocBook. I see no reason indeed why it wouldn't
be possible to generate HTML which looks like the current Gobo
documentation from an XML file written with the DocBook standard.
The advantage of using (a subset of) DocBook if Andreas (or
someone else) can write our own customized DocBook -> HTML
converter is that we would benefit from the already existing
tools (and the ones to come) supporting the DocBook standard,
get access to pdf, postscript and other formats for free, and
surf the XML wave which is getting bigger and bigger.
 
> Now I know that good documentation can be produced for software, because
> I have seen it. For a long time, I have been meaning to ask Eric what
> tools he used to achieve his clean, consistent appearance. I was
> disappointed when, a few days ago, Eric posted that he did them "by
> hand". Oh well.

Do you mean for flatshort forms or for the overall documentation
in general? One of my problems is that I'm too perfectionist. It
can be seen as a quality (the appearance of doc and software looks
consistent, assertions are well defined, etc.), but it can be
seen as a fault as well: no tool is good enough for my needs and
I end up doing a lot of things "by hand". This is the case for 
example for the flatshort forms which appear in the Gobo
documentation. I didn't find a tool yet which does what I want.
So I ended up being my own tool ;-) But more seriously one day
I will have to write such tool which formats the flatshort forms
the way I want, especially because I don't think it is reasonable
to ask the new contributors to the Gobo project to do their own
doc by hand as well. I guess I'm the only one to be that masochist ;-)
As for the doc other than flatshort, I guess that its formatting is
consistent as well, but it's not that much of a problem to write
it by hand since the most difficult part is writing the doc, not
formatting it. And I didn't find a tool which can write the doc 
for me yet!

> I think an HTML-only solution should be quite acceptable. Those who want
> to download the whole document for offline browsing can download a
> tarball of all the pages. And composing HTML is something that is easily
> available to most people (Netscape Composer or FrontPage).

So, would you suggest that we keep HTML to write Gobo documentation
until Andreas (or someone else) comes up with a customized DocBook
to HTML converter which generates nice looking Web pages, and then
try to switch progressively to DocBook using this new tool?

> If PostScript is really needed, 

I only got one request so far from a user wanting to print the
documentation of Gobo in pdf or postscript format. But the
advantage of DocBook (provided that we can generate nice looking
HTML) is that we get this for free.

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

[gobo-eiffel-develop] DocBook

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

We used it internally at OT .. Alexander <kw...@ah...> knows a lot about 
it. I personally
like another approach: I defined a small subset as DTD which (in my eyes)
is more suited for daily work. Translating these XML files into docBook is 
then trivial.
(the same applies for any "short" form .. if its in XML, then you have 
Docbook already -
just apply some small XSL transformations :-)

So, there should be no discussion about: Should we XML for documentation. 
If the answer
is "yes", then the final format is only a minor question.


--
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] DocBook

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

Roger Browne <ro...@ei...> writes:

> For the first few months, we used LaTeX. This was a real backwards step
> for me. I have no problem with using command-line tools, but this one
> just was too inconsistent. An example of the problems: Eiffel identifiers
> use lots of underscores, and in some places (e.g. headers) you must
> escape these with a backslash, but in other places you do not need to (or
> must not) escape them. Therefore, search-and-replace becomes a real pain
> because you need to use regular expressions even to find occurrences of
> identifiers. But from a single source we could get beautiful PostScript
> output and passable HTML output.

And even the underscore problem is easy to fix with just this
definition:

        \catcode`\_=12

With DocBook it seems I can still compile the output to pdf using the
tex formatting engine. So I like this choice a lot.

And I think generating HTML should also be possible, either converting
the XML to HTML or else converting to ConTeXt (macro package similar
to latex but more powerful) and converting that to
HTML.

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] DocBook

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

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

> 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 would rather have everyone use ConTeXt :-)

But I'm quite happy with this choice. I can perfectly handle XML with
ConTeXt so I can still influence the layout at will.


Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] DocBook

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

On 01 Jun 2001 22:09:16 +0100, Roger Browne wrote:
 
> So we moved to DocBook. It's a very pleasant markup to write in. The DTD
> is clean, readable, easy-to-learn and well-suited to software
> documentation. But we never produced HTML that looked really good. It was
> OK, but there were too many quirks in the spacing, and a small number of
> other irritating quirks such as character set incompatibilities. It just
> didn't look good enough that I could be proud of it. Don't get me wrong
> ... it's quite usable, but the HTML tools don't produce output that looks
> as good as Eric's. I wanted to be proud of the documentation that we were
> producing, and DocBook just wasn't good enough.

I never wrote anything with DocBook. I just looked up the specs
recently. IMO it should not be a big deal to write our own DocBook->HTML
tool that generates HTML the way we want it. This will be even easier if
we only settle for a subset of DocBook (we surely don't need some of
it's features - they seem to have special tags for special domains alot)

regards,
Andreas

Re: [gobo-eiffel-develop] DocBook

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

Roger Browne wrote:

> Eric 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 think an HTML-only solution should be quite acceptable. Those who want
> to download the whole document for offline browsing can download a
> tarball of all the pages. And composing HTML is something that is easily
> available to most people (Netscape Composer or FrontPage).
> 
> If PostScript is really needed, it can be produced by just "printing to
> file" from a web browser, and there are open-source tools that can
> concatenate PostScript files to join all the stuff together into a
> "book".
> 
> ...
> Regards,
> Roger
> 

The trouble with using HTML tools, is that text documentation needs 
features that HTML does quite poorly.  Indexes and Paginated Tables of 
Contents come to mind as good examples.  If you go with HTML, you are OH 
BUT DEFINITELY making print documentation a second class choice.  The 
importance of proper pagination in print documents is hard to 
overstress.  A Table of Contents is important, but for reference work a 
good index is even more important.

P.S.:  This is also something that a great many HTML sites do quite 
poorly.  OTOH, some do it rather well.  It depends largely (though not 
entirely) on whether or not they include a good search engine for 
perusing the documents.  And just downloading an HTML file won't 
automatically supply one with this capacity.  If docbook enables good 
text document generation, then please consider how much post-processing 
would be needed to polish the HTML (and whether or not a script could do 
it).

-- 
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] DocBook

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

Eric 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.

We really struggled to find a good documentation tool to use for my
current project.

For the first few months, we used LaTeX. This was a real backwards step
for me. I have no problem with using command-line tools, but this one
just was too inconsistent. An example of the problems: Eiffel identifiers
use lots of underscores, and in some places (e.g. headers) you must
escape these with a backslash, but in other places you do not need to (or
must not) escape them. Therefore, search-and-replace becomes a real pain
because you need to use regular expressions even to find occurrences of
identifiers. But from a single source we could get beautiful PostScript
output and passable HTML output.

Then, Adobe released a beta version of FrameMaker for Linux. I'd not used
FrameMaker before, but I had used Ventura Publisher which is a similar
long-document-oriented desktop publishing application. (Sadly, Ventura
has been badly bugridden ever since Corel bought it from Xerox).
FrameMaker worked really well. It did exactly what we needed for
technical documentation. Unfortunately, after a year the beta expired and
Adobe decided that there wasn't a commercial reason to release FrameMaker
for Linux.

So we moved to DocBook. It's a very pleasant markup to write in. The DTD
is clean, readable, easy-to-learn and well-suited to software
documentation. But we never produced HTML that looked really good. It was
OK, but there were too many quirks in the spacing, and a small number of
other irritating quirks such as character set incompatibilities. It just
didn't look good enough that I could be proud of it. Don't get me wrong
... it's quite usable, but the HTML tools don't produce output that looks
as good as Eric's. I wanted to be proud of the documentation that we were
producing, and DocBook just wasn't good enough.

Since then we've played with StarOffice. You can generate beautiful
PostScript output, but again the HTML is not perfect.

Maybe I'm being too fussy, but I think there really is a problem getting
good PostScript and good HTML from the same source document. It seems
there must be some compromises along the way.

Now I know that good documentation can be produced for software, because
I have seen it. For a long time, I have been meaning to ask Eric what
tools he used to achieve his clean, consistent appearance. I was
disappointed when, a few days ago, Eric posted that he did them "by
hand". Oh well.

I think an HTML-only solution should be quite acceptable. Those who want
to download the whole document for offline browsing can download a
tarball of all the pages. And composing HTML is something that is easily
available to most people (Netscape Composer or FrontPage).

If PostScript is really needed, it can be produced by just "printing to
file" from a web browser, and there are open-source tools that can
concatenate PostScript files to join all the stuff together into a
"book".

Finally, PDF should never be a problem: the Linux tool "ps2pdf" turns
PostScript into very nice PDF.

If you want to look beyond this, the Ruby documentation tools use a
clean, simple wiki-like markup. I don't know if they do PS/PDF, but the
HTML output looks good. I've not tried these tools myself though.

Regards,
Roger
-- 
Roger Browne - ro...@ei... - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428

[gobo-eiffel-develop] Re: DocBook experiences.

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

Eric 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've used the sgml-tools (DocBook) stuff for probably a total of a dozen or 
so hours.  One of my companies used it for internal documentation.  I've 
also contributed fixes, rewrites, and sections to several Linux HOWTOs.

I like the toolsuite and the docbook standard.  It is simple, to the point, 
multi-platform, and Just Works.  Its nice when all of that falls together.

Complaints?

Some of my developers didn't like the fact that there wasn't a fancy GUI 
front-end.  They were the folks that are used to Word and hadn't ever seen 
something like TeXInfo or (La)TeX.  They also didn't like the lack of 
"fine-tuned" layout capabilities (e.g. \vspace and similar).

Some of the cross-referencing facilities were inadequate for our tastes. 
We wanted things like lists of tables (for the table of contents) and 
support for an index.  These features did not exist when we used the tools. 
I do not know if they have been added.

Output quality - we wanted a more direct to PDF translation scheme rather 
than the multi-step that existed.  Such would (hopefully) let us use our 
own fonts and similar.  We ended up hacking this with a sed script that was 
inserted into the document compile sequence and it worked ok.


The only other real option is writing/translating documentation directly in 
TeXInfo.  This is what the OCaml community has decided to do with their CDK 
release.  I believe they made this decision because this gave them somewhat 
more expressiveness at little complexity cost and they have significant 
experience with TeX/Info and had never used SGML.

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

Re: [gobo-eiffel-develop] progress in "goboization" of UCSTRING

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

On 01 Jun 2001 09:57:03 +0200, majkel kretschmar wrote:
> i am modifying UCSTRING to be integrated into gobo. at first, all
> classes start now with the prefix UC_. further modifications will be
> done later (identation, feature groupation, etc.).
> 
> the classes needed by other projects (UC_STRING, UC_CHARACTER,
> UC_CHARACTER_REF) are similar to the ELKS 1995 classes (STRING,
> CHARACTER, CHARACTER_REF) and their features should be regared as
> stable. the other classes within the cluster are used by the three
> classes itself only.
> 
> Andreas, now you can start to modify eXML.


Great, thanks for you work.

> this version is only available as latest version from CVS. it is
> available at http://sourceforge.net/projects/ucstring/.
> if it will fit the gobo developer guidelines in a reasonable way, i will
> release it as a beta.

Cool, I am eagerly awating such a release. Because of XACE I plan to
make regular eXML prereleases as well and I'd like to base them on
UCSTRING release/beta as well instead of depending on CVS. This way
installation is easier and thus we will have a wider audience of testers
which will in turn benefit the project (;


regards,
Andreas

[gobo-eiffel-develop] progress in "goboization" of UCSTRING

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

i am modifying UCSTRING to be integrated into gobo. at first, all
classes start now with the prefix UC_. further modifications will be
done later (identation, feature groupation, etc.).

the classes needed by other projects (UC_STRING, UC_CHARACTER,
UC_CHARACTER_REF) are similar to the ELKS 1995 classes (STRING,
CHARACTER, CHARACTER_REF) and their features should be regared as
stable. the other classes within the cluster are used by the three
classes itself only.

Andreas, now you can start to modify eXML.

this version is only available as latest version from CVS. it is
available at http://sourceforge.net/projects/ucstring/.
if it will fit the gobo developer guidelines in a reasonable way, i will
release it as a beta.

have fun,

--
maj...@ep...

[gobo-eiffel-develop] DocBook

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

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.

PS: If you don't know what DocBook is, it's an XML
format to write technical documentations. It is used
to write Linux's documentation, and as a consequence
there are already many tools supporting it. From a
DocBook file, we can then use one of these tools to
generate an HTML file, or pdf, Postscipt, etc. Here
are some URLs:

  http://www.DocBook.org/
  http://www.oasis-open.org/docbook/
  http://www.nwalsh.com/docbook/index.html
 
http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro/docbook-intro.html
  http://www.amazon.co.uk/exec/obidos/ASIN/1565925807/

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

Re: [eposix] Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

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

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

> Berend, what's your opinion about this design? At least
> it has the advantage of providing both programming
> styles to the clients of this library. I didn't look
> at the implementation of your library so I don't know
> whether this may cause implementation problems or
> involve too much work for you to modify your classes.

The latter. I currently cannot afford the time to do this. I'll start
making the latest errno available per object and not crash on failure,
but rewriting everything is too much.

I'm thinking about this solution and when I like it I can use it for
the socket/ftp/http stuff I'm working on, but it looks to me like lots
of work with not so much real value, but I'll ponder over it a while
and do some experiments.

Also: you have to invent another prefix to make the distinction clear.

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] cluster images tool

[Peter H. <pe...@de...>]

Andreas Leitner wrote:
> 
> I have found a tool that will be able to draw cluster charts for the big
> number of classes gobo will contain in the future. I even found a
> screenshot of how such an image could look like:
> 
> http://dept-info.labri.fr/~auber/projects/tulip/screenshots/genome1.jpg

:-)

Actually, I don't want such information presented in that form. It's
overwhelming. But if the tool can work interactively, then one can
select a class and its environment, ignoring and hiding more distant
classes. This would be much more useful.
-- 
Peter Horan                     School of Computing and Mathematics
pe...@de...             Deakin University
+61-3-5227 1234 (Voice)         Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX)           http://www.cm.deakin.edu.au/~peter

-- The Eiffel guarantee: From specification to implementation 
-- (http://www.cetus-links.org/oo_eiffel.html)

[gobo-eiffel-develop] cluster images tool

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

I have found a tool that will be able to draw cluster charts for the big
number of classes gobo will contain in the future. I even found a
screenshot of how such an image could look like:

http://dept-info.labri.fr/~auber/projects/tulip/screenshots/genome1.jpg

scnr,
Andreas