gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] GOBO and eXML

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

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

> Now how can
> I do that? With Makefiles of course, but they do not work on Windows

For eposix I'm working on a Makefile generator that will make the
libeposix.lib on Windows. Can be used by expat as well to generate the
correct Windows Makefile.

Groetjes,

Berend. (-:

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

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

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

> I don't understand why people think Emacs is so great
> and on the other hand it is not able to properly handle
> indentation.

Please no editor war, this has nothing to do with Emacs.


> And then someone else will modify your code and put tabs
> (because everyone, except people using Emacs, uses tabs)
> and then we get ugly layout again.

Just not true, please read the url.


> Furthermore the advantage of tabs is that each user
> can set them to their favorite size. With spaces you
> can't.

Every editor??? A problem for tabs again if not so.


> Or better, Emacs is open source, right? So why this problem
> has not been fixed over the years? 

Because the problem is not Eamcs, but tabs and of course this is all
settable, please read the url.


Groetjes,

Berend. (-:

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

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

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

> On the contrary, constructs which have not been officially adopted
> by NICE yet but which are already supported by all Eiffel compilers
> can be used in Gobo Eiffel. 

What about the create construct?


> Indentations from the left margin should be made up of tabs.

Forbid tabs. Everybody uses a different tab width and sources with
tabs looks really ugly on my system for example.

Your code with tabs looks ugly on any editor with tabs set to
something different than 8 spaces ro whatever you have. Tabs are bad.


> (Borrow the guidelines from OOSC2 section 26.5 page 891.
> Note that contrary to the guidelines in OOSC2, the
> recommended layout for Gobo Eiffel classes in to put
> the class name on the same line as the 'class' keyword
> -- see class BAR above.)

Why differ from OOSC2? I see absolutely no need for this. Just follow
OOSC2 and you're almost guaranteed that acceptible libraries for Gobo
are formatted correctly.


> Routines which may raise exceptions should make it clear
> in their header comment. (There is no need to report the
> fact that a No_more_memory exception can be raised in each
> routine creating objects though ;-))

That's almost any routine in eposix. Hard to specify I think. The
ensure clause should be enough to see that an exception
follows. Putting it again in the header comment seems superfluous to
me.


> 
> Graphviz could probably be used to generate class inheritance
> graphs. Graphiz is an open source graph drawing software.

I use metapost, my code is something like:


\beginfig (13) ;
path stdcbase, posixbase, abstractfd, windowsbase, windowsfd ;
path factory ;

stdcbase := deferredclass (btex \it STDC\_BASE etex, 6cm, 9cm) ;

posixbase := deferredclass (btex \it POSIX\_BASE etex, 1cm, 5cm) ;
abstractfd := deferredclass (btex \it ABSTRACT\_FD etex, 6cm, 5cm) ;
windowsbase := deferredclass (btex \it WINDOWS\_BASE etex, 11cm, 5cm) ;

posixfd := effectiveclass (btex \it POSIX\_FD etex, 1cm, 1cm) ;
factory := effectiveclass (btex \it EPX\_FACTORY etex, 6cm, 1cm) ;
windowsfd := effectiveclass (btex \it WINDOWS\_FD etex, 11cm, 1cm) ;

isa (windowsbase, stdcbase) ;
isa (abstractfd, stdcbase) ;
isa (posixbase, stdcbase) ;
isa (posixfd, posixbase) ;
isa (posixfd, abstractfd) ;
isa (windowsfd, windowsbase) ;
isa (windowsfd, abstractfd) ;
hasa (factory, posixfd) ;
hasa (factory, windowsfd) ;
hasa (factory, abstractfd) ;

endfig ;


Best to leave this open, only specify output as .png.



> Have a loo at:
> 
>   http://www.research.att.com/sw/tools/graphviz/ 
> 
> For example, with the following 'list.dot' file:
> 
> digraph G {
> 	edge [dir=back, color=maroon];
> 	node [height=0.35, fontsize=8, style=filled, color=paleturquoise3];
> 
> 	ds_list [label="DS_LIST*"];
> 	ds_linked_list [label="DS_LINKED_LIST"];
> 	ds_bilinked_list [label="DS_BILINKED_LIST"];
> 	ds_arrayed_list [label="DS_ARRAYED_LIST"];
> 
> 	ds_list -> ds_linked_list -> ds_bilinked_list;
> 	ds_list -> ds_arrayed_list;
> }
> 
> I managed to generate a 'list.gif' file similar to
> those used in the existing Gobo Eiffel documentation
> with the command-line:
> 
>   dot -Tgif -o list.gif list.dot
> 
> I don't know yet how to simulate the client relationship
> double-arrow with graphviz though.
> 
> (Thank you to Franck Arnaud for letting me know about this
> graphviz tool.)
> 
> 
> EXAMPLES
> 
> Eiffel libraries or tools may be provided with a set of
> examples. These examples should be put in $GOBO/example/
> <library-or-tool-name>.
> 
> 
> TEST SUITE
> 
> Each Eiffel library should come with a test suite runnable
> with 'getest'. The test case classes should be placed in
> $GOBO/test/<library-name> along with the Ace files, loadpath
> files, ESD files and the 'getest' configuration files to run
> the tests.
> 
> The purpose of these tests is to make sure that the library
> classes work as expected (i.e. as specified by the assertions)
> and also to make sure that they compile correctly with compilers
> such as SmallEiffel which compiles only alive code.
> 
> These tests are also useful for library maintainers who have
> not access to all supported Eiffel compilers or to some
> operating systems. That way the maintainers can ask others
> from the Gobo development team to run the tests on other
> platforms or with other compilers for them.
> 
> Finally the $GOBO/test/<library-name> directory is used as
> regression test to make sure that no new bugs have been
> introduced between two releases.
> 
> Note: 'getest' is based on Jim Weirich's 'eunit' tool but
> has the advantage to work with all Eiffel compilers supported
> by the Gobo Eiffel project.
> 
> 
> CVS REPOSITORY
> 
> The CVS repository should not include generated files. These
> files should be generated either when building the package
> or when running the installation procedure.
> 
> 
> INSTALLATION PROCEDURE
> 
> A Gobo Eiffel Make tool?
> Something similar to Java's Ant?
> Andreas' XACE?
> ...
> 
> 
> LICENSE
> 
> The files in the Gobo Eiffel package are released under
> the Eiffel Forum Freeware License.

Re: [gobo-eiffel-develop] GOBO and eXML

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

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

>          -- does this work with a moving gc??
> 
> the answer is no: it is not safe when using a moving GC and
> you might get weird behaviors. The only safe way to pass
> pointers to Eiffel objects to C code is to use directly the
> $ construct in the arguments of the external routines. So
> I would suggest that you put all your external routines in
> a class *_EXTERNALS along with routines without POINTERs
> as arguments or results, and that you put this class in
> clusters spec/[ise|se|ve|hact] (you can possibly use 'gepp').

Another option is to have a few caches in string helper where you can
copy the data to, so it's save against the moving gc. For eposix this
seems to be a much better solution than having another layer.

Groetjes,

Berend. (-:

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

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

Andreas Leitner wrote:
> 
> Good choice. Btw, whats that Eiffel thing ppl. here on the list keep
> talking about?

I think it's a iron tower in Paris :-)

> Maybe if we restrict ourselfe to write free comments in a certain
> fashion this problem can be overcome.

So, it's not really free comments anymore ;-)

> Btw, it looks like there is a new SE beta out with preliminart ACE
> support.

Yes, I saw your message in comp.lang.eiffel today.

> They do follow the ISE conventions quite closely,

Sounds great.

> but for now they do not support the external clause.

Perhaps in future releases...

> Ad graphviz: I tried several versions including rolling my own from
> source they always run endlessly and consume more and more RAM every
> second. What version are you using?

I'm using version 1.7 under Windows.
I know that Franck Arnaud uses it under Linux, so it
should work. I'll ask him what version he is using on
Linux.

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

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

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

On 28 May 2001 00:19:39 +0200, Eric Bezault wrote:
> Andreas Leitner wrote:
> OK, I'll try to put together such little scripts
> and let you know when they are ready. I'll try to
> make them configurable so that we can specify the
> size of the tabs, and have two modes to convert
> tabs back and forth. Hmmm, we need something 
> OS-independent to write these scripts. I think the
> best choice for platform independent language in
> the context of the development of Gobo Eiffel
> package is ... Eiffel. What do you think?

Good choice. Btw, whats that Eiffel thing ppl. here on the list keep
talking about? 

> 
> > In the long term, I think your gelint effort could be used as a basis
> > for a GOBO style pretty printer.
> 
> Yes, a pretty-printer can be written re-using the
> same code as 'gelint'. The only problem with
> pretty-printers is that they usually do not handle
> free comments properly in a nice way.

Maybe if we restrict ourselfe to write free comments in a certain
fashion this problem can be overcome. Dunno, have not thought about this
yet (;

> > Then before a checkin I run the pretty
> > printer and before opening a file, I run the Emacs indentation command
> > to get my preferred indentation.
> 
> I think we will already be able to do that with the
> little scripts described above.

Great. Meanwhile I will look into XML Schemas and try to cut out a first
draft of XACE (I have several new ideas since the last version :). Maybe
I can get a minimal (but functional enough - for our purposes) done in a
reasonable time.

Btw, it looks like there is a new SE beta out with preliminart ACE
support. They do follow the ISE conventions quite closely, but for now
they do not support the external clause.

Ad graphviz: I tried several versions including rolling my own from
source they always run endlessly and consume more and more RAM every
second. What version are you using?

regards,
Andreas 

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

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

Andreas Leitner wrote:
>  
> The same argument can be made for spaces only.

Except that only people using Emacs put spaces instead of tabs.
So I think this is a problem with people using Emacs, not people
using the others text editors.

> What are you using?

CodeWright and Vim.

> That was actually a point I forgot to mention. We _should_ come up with
> a standard (and be it spaces only) and we _should_ come up with tools
> (as part of GOBO) that automate as much of the bookkeeping work as
> possible. Indentation can be done completly automatic and we should
> strive for this goal. We may not archive this in the short term, but we
> can start with little scripts as yours.

OK, I'll try to put together such little scripts
and let you know when they are ready. I'll try to
make them configurable so that we can specify the
size of the tabs, and have two modes to convert
tabs back and forth. Hmmm, we need something 
OS-independent to write these scripts. I think the
best choice for platform independent language in
the context of the development of Gobo Eiffel
package is ... Eiffel. What do you think?

> In the long term, I think your gelint effort could be used as a basis
> for a GOBO style pretty printer.

Yes, a pretty-printer can be written re-using the
same code as 'gelint'. The only problem with
pretty-printers is that they usually do not handle
free comments properly in a nice way.

> Then before a checkin I run the pretty
> printer and before opening a file, I run the Emacs indentation command
> to get my preferred indentation.

I think we will already be able to do that with the
little scripts described above.

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

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

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

On 27 May 2001 23:21:16 +0200, Eric Bezault wrote:
> > > Indentations from the left margin should be made up of tabs.
> > 
> > Are you sure? 
> 
> Yes. That's what tabs are for.
> 
> > I use Emacs and it's automatic indentation works great.
> 
> I don't think so. Emacs spoils indentation. Is that what you
> call "works great"? It's the only text editor that I have heard
> of that produces such crap with indentation generating files
> with a mixing of spaces and tabs.

The big advantage with Emacs is it's support. You can get a mode for
just anything. I don't need to learn new key bindings just because I
need to do a SML assignement. The inital learning curve is steep, but it
pays IMO. But let's not get into some religious editor war here. We have
better to do (;

> > I have been asking around how to solve the issue and Berend finally gave
> > me the best advice: Don't use tabs.
> 
> And then someone else will modify your code and put tabs
> (because everyone, except people using Emacs, uses tabs)
> and then we get ugly layout again.

The same argument can be made for spaces only.

> And the editors that I use works fine with autoindenting
> with tabs, but not with spaces. This is normal since
> tabs of for indentation, not spaces.

What are you using?

 
> Isn't it possible to do a global search/replace of
> spaces to tabs before you save your file or before
> you commit it to CVS? Something like that:
> 
>   sed -e 's/    /\t/g' file > file

That was actually a point I forgot to mention. We _should_ come up with
a standard (and be it spaces only) and we _should_ come up with tools
(as part of GOBO) that automate as much of the bookkeeping work as
possible. Indentation can be done completly automatic and we should
strive for this goal. We may not archive this in the short term, but we
can start with little scripts as yours.

In the long term, I think your gelint effort could be used as a basis
for a GOBO style pretty printer. Then before a checkin I run the pretty
printer and before opening a file, I run the Emacs indentation command
to get my preferred indentation.
 
> Or better, Emacs is open source, right? So why this problem
> has not been fixed over the years? It's not the first time
> that I heard about this problem with Emacs, and only with
> Emacs! So, even if Emacs users like the current behavior,
> there should be a configurable way to switch it off and use
> real tabs instead. That's the least I would expect from a 
> text editor: that it saves to disk what I typed. So if I
> type a tab and don't want spaces to appear instead in my
> file.

Yeah, and it is possible. I once started to do it. All I have to do
(IIRC) is to modify the Eiffel mode to just use multiples of TAB for
intending. I don't know Lisp to well, so I stopped - maybe I find some
time for this again someday... (;

> > Please also have a look at: http://www.jwz.org/doc/tabs-vs-spaces.html
> 
> It just says that Emacs is crap and that you should
> switch to Vim ;-)

No comment (;

regards,
Andreas

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

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

> > Indentations from the left margin should be made up of tabs.
> 
> Are you sure? 

Yes. That's what tabs are for.

> I use Emacs and it's automatic indentation works great.

I don't think so. Emacs spoils indentation. Is that what you
call "works great"? It's the only text editor that I have heard
of that produces such crap with indentation generating files
with a mixing of spaces and tabs.

> I had always problems with people using different tab stop settings.

Yes, that's exactly the problem. Your classes have
tabs and spaces and the indentation is screwed up.

I don't understand why people think Emacs is so great
and on the other hand it is not able to properly handle
indentation.

> I have been asking around how to solve the issue and Berend finally gave
> me the best advice: Don't use tabs.

And then someone else will modify your code and put tabs
(because everyone, except people using Emacs, uses tabs)
and then we get ugly layout again.

Furthermore the advantage of tabs is that each user
can set them to their favorite size. With spaces you
can't.

And the editors that I use works fine with autoindenting
with tabs, but not with spaces. This is normal since
tabs of for indentation, not spaces.

Isn't it possible to do a global search/replace of
spaces to tabs before you save your file or before
you commit it to CVS? Something like that:

  sed -e 's/    /\t/g' file > file

Or better, Emacs is open source, right? So why this problem
has not been fixed over the years? It's not the first time
that I heard about this problem with Emacs, and only with
Emacs! So, even if Emacs users like the current behavior,
there should be a configurable way to switch it off and use
real tabs instead. That's the least I would expect from a 
text editor: that it saves to disk what I typed. So if I
type a tab and don't want spaces to appear instead in my
file.

> Please also have a look at: http://www.jwz.org/doc/tabs-vs-spaces.html

It just says that Emacs is crap and that you should
switch to Vim ;-)

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

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

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

On 27 May 2001 21:02:39 +0200, Eric Bezault wrote:

> As promised here is a first draft of the developer guidelines.
> Of course I didn't have that much time to work on it, so it
> is far from complete. More sections should be added and 
> some existing sections need some more work. But there are
> already enough material for you to review.

Good work, Eric!
 

> CLASS LAYOUT
> 
> Indentations
> 
> Indentations from the left margin should be made up of tabs.

Are you sure? I would much prefere if we disallowed spaces. I use Emacs
and it's automatic indentation works great. There is no way I move away
from this editor any time soon.

I had always problems with people using different tab stop settings. I
have been asking around how to solve the issue and Berend finally gave
me the best advice: Don't use tabs. I can configure Emacs to not write
the tabs onto harddisk, which is what I do at the moment.

Please also have a look at: http://www.jwz.org/doc/tabs-vs-spaces.html


regards,
Andreas
PS: I have the C_STRING_HELPER class ready for SE and ISE. I'd like to
give it some more thought (name etc.) before I submit it.

Re: [gobo-eiffel-develop] GOBO and eXML

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

Andreas Leitner wrote:
> 
> I will remove the make_pointer_ features from C_STRING_HELPER, rename
> make_ to new_ and unify the class using GEPP as you suggested. I think
> the class needs a better name. Do you have an idea? 

Not yet. I have to think about it.
Finding good names requires as much effort (or even more)
than actually writing the class library itself...

> When I am ready, I
> can post it here, so you can include it into GOBO as soon as UCSTRING
> gets merged into GOBO. Is that ok with you?

OK. Or you can send it directly to me if you don't want
to bother others in this mailing list with class texts.

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

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

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

Eric Bezault wrote:
> 
> What I suggest is that I start writing a first draft of
> the developer guidelines this weekend and then make it
> available to this mailing list as a starting point for
> discussion.

As promised here is a first draft of the developer guidelines.
Of course I didn't have that much time to work on it, so it
is far from complete. More sections should be added and 
some existing sections need some more work. But there are
already enough material for you to review.

Note that I wrote it in ASCII form since it is better to 
quote it in e-mail messages and I didn't have time to
experiement with DocBook yet.

PS: Unfortunately the mailing list archive still doesn't
work. I hope it will be fixed early next week when the folks
from SourceForge come back from the weekend.

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

Re: [gobo-eiffel-develop] GOBO and eXML

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

I will remove the make_pointer_ features from C_STRING_HELPER, rename
make_ to new_ and unify the class using GEPP as you suggested. I think
the class needs a better name. Do you have an idea? When I am ready, I
can post it here, so you can include it into GOBO as soon as UCSTRING
gets merged into GOBO. Is that ok with you?


On 27 May 2001 11:27:16 +0200, Eric Bezault wrote:
> Andreas Leitner wrote:
[snip]
> In the version of C_STRING_HELPER_NP for ISE Eiffel you
> wrote:
> 
>    make_pointer_from_string (s: STRING): POINTER is
>          -- returns the pointer to the data of a specific string
>          -- does this work with a moving gc??
> 
>    make_pointer_from_string_buffer (data: SPECIAL [CHARACTER]): POINTER
> is
>          -- returns the pointer to the data of a specific string
>          -- does this work with a moving gc??
> 
> the answer is no: it is not safe when using a moving GC and
> you might get weird behaviors. The only safe way to pass
> pointers to Eiffel objects to C code is to use directly the
> $ construct in the arguments of the external routines. So
> I would suggest that you put all your external routines in
> a class *_EXTERNALS along with routines without POINTERs
> as arguments or results, and that you put this class in
> clusters spec/[ise|se|ve|hact] (you can possibly use 'gepp').
> For example if you have an external C routine such as:
> 
>   char *foo (char *str) {}
> 
> I would suggest that you have the following routines in your
> *_EXTERNALS class:
> 
> feature -- Something here
> 
>    foo (str: STRING): STRING is
>         -- ...
>      require
>         str_not_void: str /= Void
>      local
>         c_str: ANY
>      do
>         !! Result.make (0)
>         c_str := str.to_c
>         Result.from_c (c_foo ($c_str))
>      ensure
>         foo_not_void: Result /= Void
>      end
> 
> feature {NONE} -- Externals
> 
>    c_foo (str: POINTER): POINTER is
>          -- ...
>       require
>          str_not_null: str /= default_pointer
>       external
>          "C"
>       alias
>          "...."
>       ensure
>          c_foo_not_null: Result /= default_pointer
>       end
> 
> and provide different implementations for the different Eiffel
> compilers. This is in my opinion the only safe way with respect
> to moving GC to implement calls to C functions with pointers
> to Eiffel objects.
> 
> It may look cumbersome at first, but it is actually cleaner
> because the public interface of this class does not involve
> POINTER, only pure Eiffel types. So if one day expat is
> ported to .Net or JVM you will have less work to do since
> the only class aware of the C language will be this class.

Removing all POINTERS does not make sense, because sometimes (for expat
actually most of the time) POINTER is not a C string, but some other
pointer. It may be a pointer to a structure, but it may also be just a
void* (that in C-library intern may very well a pointer to a struct
again) but the user cannot and should not know. For the user it is just
a handle (like the handle to the expat parser, or the handle to a window
in a GUI toolkit).

I will remove all pointers which are in fact some sort of char* in the
feature arguments and provide three features instead:

ext_foo (s: POINTER) is
    external ...
foo_string (s: STRING) is
    do ...
foo_string_buffer (s: like STRING_BUFFER_TYPE) is
    do ...

I can totaly leave the POINTERs in the function results, because on the
C side there is no moving GC and in case the POINTER really is a char* I
can use new_string_from_c_zero_terminted_string. 

regards,
Andreas

Re: [gobo-eiffel-develop] GOBO and eXML

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

On 27 May 2001 11:27:16 +0200, Eric Bezault wrote:
> Andreas Leitner wrote:
> > 
> > ad 7)
> > External C dependencies make life really really hard... I have my
> > examples all setup very general. Due to the factory class they check
> > what back end parsers are compiled in and you can choose your favoriteat
> > runtime via a command line argument. This brings in some trouble at
> > build time though: I want to provide a simple way for the user to choose
> > at build time what backends he wants to have compiled in. This is
> > important because not everybody wants to go through the hassel and
> > install expat on his system. Also a possible compile_to_jvm is not
> > possible with expat dependencies in the build configuration. Now how can
> > I do that? With Makefiles of course, but they do not work on Windows ):
> > 
> > Do you have any idea on how I can solve that issue?
> 
> I thought that having expat/no_expat would solve the problem.
> One has just to choose one or the other in the Ace file at
> build-time. Did I miss something?

Additionally to the optional clusters you have optional C libraries. You
need to link to libraries specify include directories, give cecil files
etc. All this must be done _only_ if a user wants to compile the
correspoding implementation in. That's why I came up with XACE. It's
structure allows to specify all those things in subclusters. The tool
merges the dependencies of the total ACE file and generates the usual
build files. And simple EXPRESSIONS (like those in GEPP - EXPAT||EIFFEL)
allow for selecting and deselecting various clusters. Only that I don't
need "#ifdefs", but can use attributes in XML to do the job.


> BTW, I was surprised by your directory structure:
> 
>    impl/expat/expat/ep_event_parser_factory.e
>    impl/expat/expat/...
>    impl/expat/no_expat/ep_event_parser_factory.e
> 
> I thought you would have done something like that:
> 
>    impl/expat/factory/ep_event_parser_factory.e
>    impl/expat/...
>    impl/no_expat/factory/ep_event_parser_factory.e
> 
> I'm not saying that one is better than the other, but it
> seems more natural to me to choose whether I want to
> compile with expat or not at the impl level. Then you
> could have a loadpath.se, ise.ace, etc. in the directories:
> 
>   impl/expat
>   impl/no_expat
> 
> and include one or the other in your application loadpath
> or Ace file depending on whether you want to include
> expat or not.

Yes, that is on my list. I must give this some more thought though.
Initially I wanted to put all factory classes into the factory cluster,
but that's not a good choice, because Then factory would include both
event and tree specific classes. That means that if you decide to
include cluster factory you need to include both tree and event as well.
So I probably go for s.th. like this:

Event impls have:
expat/event/ep_event_parser_factory.e
no_expat/event/ep_event_parser_factory.e
and Tree impls have:
eiffel/tree/ef_tree_parser_factory.e
no_eiffel/tree/ef_tree_parser_factory.e



> > ad 8)
> > In order to get actual data from expat I need to convert all kinds of C
> > strings (fixed length, zero terminated, ...) into Eiffel Strings (or
> > UCSTRINGs) C_STRING_HELPER is what I built to do that, but it is
> > compiler dependent of course. I think this is a good candidate for GOBO
> > itself (outside of the proper eXML clusters) - maybe with a few
> > modifications.
> 
> Yes, it is clear that many libraries currently have their 
> own string handling clusters, and one of the advantage of
> merging everything into Gobo is that we will be able to
> do some refactoring with all these classes, and possibly
> share them between libraries.
> 
> You were suggesting putting these classes into the 'utility'
> library. Wouldn't all these string handling classes deserve
> a library on their own? Something like $GOBO/library/string?
> Then we could have:
> 
>    library/string/c_string
>                  /formatter
>                  /input
>                  /output
>                  /...
> 
> The cluster c_string would be where to put your class since
> it is dependent on C (even though they don't have external
> routines) and applications compiled on .Net or JVM would not
> include this cluster.
> 
> In the version of C_STRING_HELPER_NP for ISE Eiffel you
> wrote:
> 
>    make_pointer_from_string (s: STRING): POINTER is
>          -- returns the pointer to the data of a specific string
>          -- does this work with a moving gc??
> 
>    make_pointer_from_string_buffer (data: SPECIAL [CHARACTER]): POINTER
> is
>          -- returns the pointer to the data of a specific string
>          -- does this work with a moving gc??
> 
> the answer is no: it is not safe when using a moving GC and
> you might get weird behaviors. The only safe way to pass
> pointers to Eiffel objects to C code is to use directly the
> $ construct in the arguments of the external routines. So
> I would suggest that you put all your external routines in
> a class *_EXTERNALS along with routines without POINTERs
> as arguments or results, and that you put this class in
> clusters spec/[ise|se|ve|hact] (you can possibly use 'gepp').
> For example if you have an external C routine such as:
> 
>   char *foo (char *str) {}
> 
> I would suggest that you have the following routines in your
> *_EXTERNALS class:
> 
> feature -- Something here
> 
>    foo (str: STRING): STRING is
>         -- ...
>      require
>         str_not_void: str /= Void
>      local
>         c_str: ANY
>      do
>         !! Result.make (0)
>         c_str := str.to_c
>         Result.from_c (c_foo ($c_str))
>      ensure
>         foo_not_void: Result /= Void
>      end
> 
> feature {NONE} -- Externals
> 
>    c_foo (str: POINTER): POINTER is
>          -- ...
>       require
>          str_not_null: str /= default_pointer
>       external
>          "C"
>       alias
>          "...."
>       ensure
>          c_foo_not_null: Result /= default_pointer
>       end
> 
> and provide different implementations for the different Eiffel
> compilers. This is in my opinion the only safe way with respect
> to moving GC to implement calls to C functions with pointers
> to Eiffel objects.
> 
> It may look cumbersome at first, but it is actually cleaner
> because the public interface of this class does not involve
> POINTER, only pure Eiffel types. So if one day expat is
> ported to .Net or JVM you will have less work to do since
> the only class aware of the C language will be this class.
> 
> Furthermore having this class *_EXTERNAL duplicated over
> the spec/[ise|se|ve|hact] clusters (once again yo can
> use 'gepp' to make its implementation and maintenance
> easier) has the other advantage of allowing you to use
> the different external C syntax enhancements provided
> by the different Eiffel compilers. We all know that they
> are not portable and we are stuck with the:
> 
>   external "C"
> 
> syntax in order to have something portable, but since
> we already have the spec/[ise|se|ve|hact] clusters
> we can now take advantage of non-portable syntax.
> 
> BTW, the routines above are functions, not procedures.
> So I suggest to name them `new_...' instead of `make_...'.

Thanks I look into that.


thanks for reviewing the code,
Andreas

Re: [gobo-eiffel-develop] GOBO and eXML

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

Andreas Leitner wrote:
> 
> ad 7)
> External C dependencies make life really really hard... I have my
> examples all setup very general. Due to the factory class they check
> what back end parsers are compiled in and you can choose your favoriteat
> runtime via a command line argument. This brings in some trouble at
> build time though: I want to provide a simple way for the user to choose
> at build time what backends he wants to have compiled in. This is
> important because not everybody wants to go through the hassel and
> install expat on his system. Also a possible compile_to_jvm is not
> possible with expat dependencies in the build configuration. Now how can
> I do that? With Makefiles of course, but they do not work on Windows ):
> 
> Do you have any idea on how I can solve that issue?

I thought that having expat/no_expat would solve the problem.
One has just to choose one or the other in the Ace file at
build-time. Did I miss something?

BTW, I was surprised by your directory structure:

   impl/expat/expat/ep_event_parser_factory.e
   impl/expat/expat/...
   impl/expat/no_expat/ep_event_parser_factory.e

I thought you would have done something like that:

   impl/expat/factory/ep_event_parser_factory.e
   impl/expat/...
   impl/no_expat/factory/ep_event_parser_factory.e

I'm not saying that one is better than the other, but it
seems more natural to me to choose whether I want to
compile with expat or not at the impl level. Then you
could have a loadpath.se, ise.ace, etc. in the directories:

  impl/expat
  impl/no_expat

and include one or the other in your application loadpath
or Ace file depending on whether you want to include
expat or not.

> ad 8)
> In order to get actual data from expat I need to convert all kinds of C
> strings (fixed length, zero terminated, ...) into Eiffel Strings (or
> UCSTRINGs) C_STRING_HELPER is what I built to do that, but it is
> compiler dependent of course. I think this is a good candidate for GOBO
> itself (outside of the proper eXML clusters) - maybe with a few
> modifications.

Yes, it is clear that many libraries currently have their 
own string handling clusters, and one of the advantage of
merging everything into Gobo is that we will be able to
do some refactoring with all these classes, and possibly
share them between libraries.

You were suggesting putting these classes into the 'utility'
library. Wouldn't all these string handling classes deserve
a library on their own? Something like $GOBO/library/string?
Then we could have:

   library/string/c_string
                 /formatter
                 /input
                 /output
                 /...

The cluster c_string would be where to put your class since
it is dependent on C (even though they don't have external
routines) and applications compiled on .Net or JVM would not
include this cluster.

In the version of C_STRING_HELPER_NP for ISE Eiffel you
wrote:

   make_pointer_from_string (s: STRING): POINTER is
         -- returns the pointer to the data of a specific string
         -- does this work with a moving gc??

   make_pointer_from_string_buffer (data: SPECIAL [CHARACTER]): POINTER
is
         -- returns the pointer to the data of a specific string
         -- does this work with a moving gc??

the answer is no: it is not safe when using a moving GC and
you might get weird behaviors. The only safe way to pass
pointers to Eiffel objects to C code is to use directly the
$ construct in the arguments of the external routines. So
I would suggest that you put all your external routines in
a class *_EXTERNALS along with routines without POINTERs
as arguments or results, and that you put this class in
clusters spec/[ise|se|ve|hact] (you can possibly use 'gepp').
For example if you have an external C routine such as:

  char *foo (char *str) {}

I would suggest that you have the following routines in your
*_EXTERNALS class:

feature -- Something here

   foo (str: STRING): STRING is
        -- ...
     require
        str_not_void: str /= Void
     local
        c_str: ANY
     do
        !! Result.make (0)
        c_str := str.to_c
        Result.from_c (c_foo ($c_str))
     ensure
        foo_not_void: Result /= Void
     end

feature {NONE} -- Externals

   c_foo (str: POINTER): POINTER is
         -- ...
      require
         str_not_null: str /= default_pointer
      external
         "C"
      alias
         "...."
      ensure
         c_foo_not_null: Result /= default_pointer
      end

and provide different implementations for the different Eiffel
compilers. This is in my opinion the only safe way with respect
to moving GC to implement calls to C functions with pointers
to Eiffel objects.

It may look cumbersome at first, but it is actually cleaner
because the public interface of this class does not involve
POINTER, only pure Eiffel types. So if one day expat is
ported to .Net or JVM you will have less work to do since
the only class aware of the C language will be this class.

Furthermore having this class *_EXTERNAL duplicated over
the spec/[ise|se|ve|hact] clusters (once again yo can
use 'gepp' to make its implementation and maintenance
easier) has the other advantage of allowing you to use
the different external C syntax enhancements provided
by the different Eiffel compilers. We all know that they
are not portable and we are stuck with the:

  external "C"

syntax in order to have something portable, but since
we already have the spec/[ise|se|ve|hact] clusters
we can now take advantage of non-portable syntax.

BTW, the routines above are functions, not procedures.
So I suggest to name them `new_...' instead of `make_...'.

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

[gobo-eiffel-develop] GOBO and eXML

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

I just released a new version of eXML (http://www.sourceforge.net/projects/exml).

This version includes a lot of the changes we were discussing the past
couple of days, though not all of them yet (;

Here is my TODO-list:
1) Wait for GOBO-nized UCSTRING
2) remove eXML comments at the end of each class
3) add/replace GOBO std indexing clauses
4) clean up examples (make parser choice in ebook)
5) documentation (use docbook?)
6) find better name (XM_) for DEFAULT_POSITION and DEFAULT_SOURCE
7) build system 
	*)make .mk makefiles in parser backends real stand alone Makefiles
	  don't forget to update the global makefiles
 *) somehow merge build system with GOBO's build system
8) C_STRING_HELPER
 *) should go into a general Eiffel<->Cluster in GOBO (utility?)
9) expat support for Visual Eiffel and general HACT support 

ad 7)
External C dependencies make life really really hard... I have my
examples all setup very general. Due to the factory class they check
what back end parsers are compiled in and you can choose your favoriteat
runtime via a command line argument. This brings in some trouble at
build time though: I want to provide a simple way for the user to choose
at build time what backends he wants to have compiled in. This is
important because not everybody wants to go through the hassel and
install expat on his system. Also a possible compile_to_jvm is not
possible with expat dependencies in the build configuration. Now how can
I do that? With Makefiles of course, but they do not work on Windows ):

Do you have any idea on how I can solve that issue?

ad 8)
In order to get actual data from expat I need to convert all kinds of C
strings (fixed length, zero terminated, ...) into Eiffel Strings (or
UCSTRINGs) C_STRING_HELPER is what I built to do that, but it is
compiler dependent of course. I think this is a good candidate for GOBO
itself (outside of the proper eXML clusters) - maybe with a few
modifications.

What do you think? If we make (a modified variant of) C_STRING_HELPER a
part of GOBO, I think we should do so before the actual eXML merger. It
is a smaller cut and thus takes less time. Once it is in GOBO (CVS is
sufficient) I can adjust eXML to work with the new GOBO (which then
includes C_STRING_HELPER). This in turn will make the eXML meger smaller
and thus easier. I believe that cutting up the big job into several
smaller jobs will have several benefits. There will be visible progress,
regressions won't hit us so badly and thus we will save time.

Andreas

Re: [gobo-eiffel-develop] DocBook

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

Andreas Leitner wrote:
> 
> I had a quick look into DocBook, and I think it is a good idea to use it.
> Here is a tutorial for anybody who is interested:
> http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro/docbook-intro.html

I didn't know about this URL. Personally I bought this book
from O'Reilly:

 
http://www.amazon.co.uk/exec/obidos/ASIN/1565925807/qid=990884726/sr=1-1/202-2240368-1643821

Here are other interesting links:

  http://www.DocBook.org/
  http://www.oasis-open.org/docbook/
  http://www.nwalsh.com/docbook/index.html

It has been a long time since I had look at DocBook, so I
would probably have to visit these Web sites again.

> On Linux you can use jade or openjade to convert DocBook into HTML/ps/dvi/...
> Dunno where the RPMS are, since I had it installed already.
> 
> A eXML implementation should be possible - and will probably be usefull as well,
> because we can extend it to pretty print Eiffel source code (the hooks are there).
> 
> For the beginning I think it is safe if we start writing (or converting) our docs into DocBook.
> We can use the standard tools (jade) to convert the xml to html. Later we can start a Eiffel DocBook tool
> (,that initially supports only the subset of the standard that we need).

Yes, it is indeed the advantage of using DocBook: there are
already plenty of tools supporting this standard. So we can
already use these tools while waiting for our own converter
with some Gobo-personalized output.

Note that DocBook supports SGML and XML as input formats. I think
we will all agree that we should choose XML rather than SGML.
Hopefully jade (or whatever) supports it.

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

[gobo-eiffel-develop] Mailing list administration

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

We have problem with the archiving of this mailing list.
The only configuration difference I could see with the
other mailing list (gobo-eiffel-commits) that I created
yesterday is that the Reply-to: of the messages from
gobo-eiffel-develop was set to the mailing list itself.
I removed this setting in order to see if it made any 
difference (apparently not). In the meantime make sure
to press "Reply All" and not just "Reply" when you want
to reply to a message from this mailing list. Sorry for
this temporary inconvenience.

PS: I have sent a support request to the people at
SourceForge in order to find out why the archiving is
not working for this list.

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

[gobo-eiffel-develop] DocBook

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

I had a quick look into DocBook, and I think it is a good idea to use it.
Here is a tutorial for anybody who is interested:
http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro/docbook-intro.html

On Linux you can use jade or openjade to convert DocBook into HTML/ps/dvi/...
Dunno where the RPMS are, since I had it installed already.

A eXML implementation should be possible - and will probably be usefull as well, 
because we can extend it to pretty print Eiffel source code (the hooks are there).

For the beginning I think it is safe if we start writing (or converting) our docs into DocBook.
We can use the standard tools (jade) to convert the xml to html. Later we can start a Eiffel DocBook tool
(,that initially supports only the subset of the standard that we need).


regards,
Andreas

Re: [gobo-eiffel-develop] Hello

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

On 25 May 2001 23:24:10 +0200, Eric Bezault wrote:
> Andreas Leitner wrote:
> > 
> > Btw, in eXML I now use XM_ as a prefix, but the bridge implementations
> > use TOE_, EXPAT_, and EIFFEL_. I have not thought about renaming them
> > yet, because I think of them as non user visible. What is your position
> > on this Eric?
> 
> There are not visible by the users but there are visible
> by the compiler. So I think that the class name prefix
> rule should apply to all classes since its goal is to
> avoid class name clashes.

Ok. No problem.

> > Another question, do you use any tools to write the docs?
> 
> My docs is currently written in HTML and I use Microsoft
> Frontpage (yes I know, shame on me ;-)). It has been two
> years now since I seriously considered using the XML
> DocBook format to write my docs. But I never found time
> to actually do it. Do you think DocBook would be a good
> choice to write the docs? It has the advantage of being
> XML, used in the Linux community for writing docs and
> hence there exist several tools to convert it to many
> other formats such as HTML, pdf, Postscript, etc. Do you
> think it would be possible to write such a tool with
> eXML to convert a DocBook XML doc into HTML for example?
> That way using the DocBook standard we would be able
> to generate our home-brewed HTML format to be used on
> the Gobo project Web page.

Sure, why not. Have not looked into DocBook yet, but I think it should
be doable. Don't know how much work it will be though. Gotta check the
DocBook specs sometime...

> 
> PS: I created two mailing lists in the gobo-eiffel sourceforge
> web page today, but the archive for the gobo-eiffel-develop
> returns an error whereas the one for gobo-eiffel-commits
> seems to work. Do you have any clue what's going wrong?

Yeah, saw this problem too. Maybe some cron job needs to go over the
mailing lists first... Dunno


Andreas

Re: [gobo-eiffel-develop] Hello

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

Andreas Leitner wrote:
> 
> Btw, in eXML I now use XM_ as a prefix, but the bridge implementations
> use TOE_, EXPAT_, and EIFFEL_. I have not thought about renaming them
> yet, because I think of them as non user visible. What is your position
> on this Eric?

There are not visible by the users but there are visible
by the compiler. So I think that the class name prefix
rule should apply to all classes since its goal is to
avoid class name clashes.

> Btw, Eric, where does the name GOBO come from?

It was my nickname when I was at school more than 10 years
ago. At that time there was a French TV show for the kids
and the antihero was called Gobo.

> Another question, do you use any tools to write the docs?

My docs is currently written in HTML and I use Microsoft
Frontpage (yes I know, shame on me ;-)). It has been two
years now since I seriously considered using the XML
DocBook format to write my docs. But I never found time
to actually do it. Do you think DocBook would be a good
choice to write the docs? It has the advantage of being
XML, used in the Linux community for writing docs and
hence there exist several tools to convert it to many
other formats such as HTML, pdf, Postscript, etc. Do you
think it would be possible to write such a tool with
eXML to convert a DocBook XML doc into HTML for example?
That way using the DocBook standard we would be able
to generate our home-brewed HTML format to be used on
the Gobo project Web page.

PS: I created two mailing lists in the gobo-eiffel sourceforge
web page today, but the archive for the gobo-eiffel-develop
returns an error whereas the one for gobo-eiffel-commits
seems to work. Do you have any clue what's going wrong?

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

Re: [gobo-eiffel-develop] Hello

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

On 25 May 2001 21:03:38 +0200, Eric Bezault wrote:
> Berend de Boer wrote:
> > 
> > A few things:
> > 
> > 1. I think ECLI is also a good candidate (odbc access).
> 
> Yes, and there are probably many others as well.
> But we have to start somewhere ;-)

Right, I have a never ending list of additions for GOBO. But if we can
get UCSTRING ePosix and eXML merged into GOBO in a reasonable time we
will have archived so much. This is land no Eiffelist has touched ever
before (;

> > 3. For the guideline: note that eposix also has several layers like a
> >    Standard C, POSIX, Single Unix Specification and an abstract layer
> >    (common subset of POSIX and  Win32). With single prefixes like PX
> >    or so I don't get that far in communication the structure. Perhaps
> >    you can give this some thoughts.
> 
> Yes, I thought about that two days ago as well. What about
> possibly allowing several prefixes for some libraries. It
> is actually already the case for the Lexical library with
> LX_ and YY_ (for skeleton classes) and for the Parse library
> with PR_ and YY_ (again for skeleton classes). And if we
> integrate the Unicode cluster into the Kernel library we
> would also have KL_ and UC_ for this library. So provided
> that these prefixes are well documented (i.e. have a page
> listing all the libraries with their prefixes used) so that
> we can avoid clashes, I don't think that there is any problem.
> So what about SC_, PX_, SU_, etc. for the different layers?
> Of course you (and any other developer) are free to choose
> the prefixes you want provided that there are not used yet.


Btw, in eXML I now use XM_ as a prefix, but the bridge implementations
use TOE_, EXPAT_, and EIFFEL_. I have not thought about renaming them
yet, because I think of them as non user visible. What is your position
on this Eric?

> > 5. The name: I think the Gobo name is quite usefull as it is
> >    well-known. But what about a somewhat more catchy name like Unified
> >    Gobo? "The Unified Open Source Eiffel Library" is to formal, but
> >    Unified Gobo sounds as somewhat more important for this large
> >    undertaking.
> >    But I'm also just fine with Gobo.
> 
> I would say the shorter the better. For example the full
> name is actually Gobo Eiffel, but everybody just calls it
> Gobo because it's shorter. So I would rather stick to
> Gobo as a name, even if the documentation will clearly
> state that it's a multi-developer multi-library project.

Btw, Eric, where does the name GOBO come from?

Another question, do you use any tools to write the docs?


regards,
Andreas

Re: [gobo-eiffel-develop] Hello

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

Eric Bezault wrote:
> 
> CVS is not perfect but it has been good enough for me so far and
> it has the advantage of being wildly used I think.
                                ^^^^^^
I meant "widely" of course :-)

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

Re: [gobo-eiffel-develop] Hello

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

Berend de Boer wrote:
> 
> A few things:
> 
> 1. I think ECLI is also a good candidate (odbc access).

Yes, and there are probably many others as well.
But we have to start somewhere ;-)

> 2. Does anyone know Perforce? (http://www.perforce.com). I like its
>    version control system much more than CVS, its available for free
>    for Open Source projects.
>    However, CVS and SourceForge are already setup and available, but I
>    just wanted to know if more people know and like Perforce.

I never used Perforce. I use CVS at work (I used it in my previous
work as well and when I was at ISE also) and for Gobo locally on my
PC before I moved it to Sourceforge. CVS is not perfect but it has
been good enough for me so far and it has the advantage of being wildly
used I think. And as you said it's already there for us on SourceForge.

> 3. For the guideline: note that eposix also has several layers like a
>    Standard C, POSIX, Single Unix Specification and an abstract layer
>    (common subset of POSIX and  Win32). With single prefixes like PX
>    or so I don't get that far in communication the structure. Perhaps
>    you can give this some thoughts.

Yes, I thought about that two days ago as well. What about
possibly allowing several prefixes for some libraries. It
is actually already the case for the Lexical library with
LX_ and YY_ (for skeleton classes) and for the Parse library
with PR_ and YY_ (again for skeleton classes). And if we
integrate the Unicode cluster into the Kernel library we
would also have KL_ and UC_ for this library. So provided
that these prefixes are well documented (i.e. have a page
listing all the libraries with their prefixes used) so that
we can avoid clashes, I don't think that there is any problem.
So what about SC_, PX_, SU_, etc. for the different layers?
Of course you (and any other developer) are free to choose
the prefixes you want provided that there are not used yet.

> 4. It's great to see UCSTRING become part of the lib.

Agreed.

> 5. The name: I think the Gobo name is quite usefull as it is
>    well-known. But what about a somewhat more catchy name like Unified
>    Gobo? "The Unified Open Source Eiffel Library" is to formal, but
>    Unified Gobo sounds as somewhat more important for this large
>    undertaking.
>    But I'm also just fine with Gobo.

I would say the shorter the better. For example the full
name is actually Gobo Eiffel, but everybody just calls it
Gobo because it's shorter. So I would rather stick to
Gobo as a name, even if the documentation will clearly
state that it's a multi-developer multi-library project.

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

Re: [gobo-eiffel-develop] Hello

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

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

> What I suggest is that I start writing a first draft of
> the developer guidelines this weekend and then make it
> available to this mailing list as a starting point for
> discussion. As soon as I have a first draft I will also
> announce the existence of this mailing list publicly so
> that others can join the discussion if they are interested.

Good idea.


> In the meantime feel free to post to this mailing list
> if you want to start the discussion.

A few things:

1. I think ECLI is also a good candidate (odbc access).

2. Does anyone know Perforce? (http://www.perforce.com). I like its
   version control system much more than CVS, its available for free
   for Open Source projects.
   However, CVS and SourceForge are already setup and available, but I
   just wanted to know if more people know and like Perforce.

3. For the guideline: note that eposix also has several layers like a
   Standard C, POSIX, Single Unix Specification and an abstract layer
   (common subset of POSIX and  Win32). With single prefixes like PX
   or so I don't get that far in communication the structure. Perhaps
   you can give this some thoughts.

4. It's great to see UCSTRING become part of the lib.

5. The name: I think the Gobo name is quite usefull as it is
   well-known. But what about a somewhat more catchy name like Unified
   Gobo? "The Unified Open Source Eiffel Library" is to formal, but
   Unified Gobo sounds as somewhat more important for this large
   undertaking.
   But I'm also just fine with Gobo.


Groetjes,

Berend. (-: