Menu
▾
▴
gobo-eiffel-develop
|
From: Eric B. <er...@go...> - 2001-05-25 14:13:28
|
OK, it seems that we are all subscribed now. 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. In the meantime feel free to post to this mailing list if you want to start the discussion. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Berend de B. <be...@po...> - 2001-05-25 18:40:17
|
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. (-: |
|
From: Eric B. <er...@go...> - 2001-05-25 19:06:55
|
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 |
|
From: Eric B. <er...@go...> - 2001-05-25 19:29:14
|
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
|
|
From: Andreas L. <no...@sb...> - 2001-05-25 20:39:55
|
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 |
|
From: Eric B. <er...@go...> - 2001-05-25 21:26:47
|
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 |
|
From: Andreas L. <no...@sb...> - 2001-05-25 21:31:48
|
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 |
|
From: Andreas L. <no...@sb...> - 2001-05-26 12:59:15
|
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 |
|
From: Eric B. <er...@go...> - 2001-05-26 14:04:51
|
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 |
|
From: Andreas L. <no...@sb...> - 2001-05-27 02:16:18
|
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 |
|
From: Berend de B. <be...@po...> - 2001-05-28 08:39:50
|
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. (-: |
|
From: Eric B. <er...@go...> - 2001-05-27 09:30:07
|
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
|
|
From: Andreas L. <no...@sb...> - 2001-05-27 11:31:59
|
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
|
|
From: Andreas L. <no...@sb...> - 2001-05-27 18:06:28
|
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
|
|
From: Berend de B. <be...@po...> - 2001-05-28 06:09:44
|
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. (-: |
|
From: Berend de B. <be...@po...> - 2001-05-28 08:39:52
|
Eric Bezault <er...@go...> writes: > 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'). I think #ifdefs are an absolutely bad way to manage code. Perhaps in a few low level classes I can live with them, but generally they generate a mess of used on a larger scale. So lets avoid them at all costs. Perhaps put this in the guidelines as well: 1. gepp only to be used for ise/se/ve/hact distinctions. 2. deferred classes are a much better choice. gepp is completely orthogonal to oo programming in almost any case. If you use it, there is something wrong. For example, if a new Eiffel compiler pops up (Eiffel .NET comes to mind), you have to scrawl all over your code to fix the #ifdefs and not forget anything. Deferred classes with a proper implementation work just as good and give you a nice warning if you forgot to implement a method. Groetjes, Berend. (-: |
|
From: Eric B. <er...@go...> - 2001-05-27 19:05:33
Attachments:
guidelines.txt
|
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 |
|
From: Andreas L. <no...@sb...> - 2001-05-27 19:43:50
|
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. |
|
From: Eric B. <er...@go...> - 2001-05-27 21:24:06
|
> > 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 |
|
From: Andreas L. <no...@sb...> - 2001-05-27 21:51:20
|
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 |
|
From: Berend de B. <be...@po...> - 2001-05-28 06:39:41
|
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. (-: |
|
From: Berend de B. <be...@po...> - 2001-05-28 06:32:45
|
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. |
|
From: Eric B. <er...@go...> - 2001-05-28 09:34:44
|
Berend de Boer wrote: > > What about the create construct? It is not supported by Visual Eiffel yet. > Forbid tabs. Everybody uses a different tab width Yes, and that exactly why we should use tabs. With spaces we cannot set the size of indentations to personal preferences. > and sources with tabs looks really ugly on my system for example. What do you mean by ugly? > Your code with tabs looks ugly on any editor with tabs set to > something different than 8 spaces ro whatever you have. I'm sorry but I don't agree. I set the tab width to different sizes and the code is still indented properly and still looks fine to me. (BTW, I usually use a size of 4). > Tabs are bad. This is your opinion. On the other hand I think that spaces 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. I differ from OOSC2 because all the Eiffel code that I wrote or saw in the projects I work on during the past 10 years or more (even when I was at ISE) put the class name on the same line as the 'class' keyword. That's all. > 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. I think that it is bad pratice to raise exceptions in Eiffel. But at least we should know when such exceptions may occur. I don't think this is superfluous. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Berend de B. <be...@po...> - 2001-05-28 10:57:25
|
Eric Bezault <er...@go...> writes: > Yes, and that exactly why we should use tabs. With spaces > we cannot set the size of indentations to personal preferences. With Emacs you can tabify sources when you load them and untabify when saved. If you can do this with vim you can have tabs the way you want. So it all boils down to the choice of the proper editor :-)) > > and sources with tabs looks really ugly on my system for example. > > What do you mean by ugly? If people cut and paste code from other editors, html browsers, whatever you end up with a mix. And that looks ugly. And emacs is customizable so you can press tab and have spaces inserted (what many people use), you can set this with vim too, but few people seem to customize vim. > > Your code with tabs looks ugly on any editor with tabs set to > > something different than 8 spaces ro whatever you have. > > I'm sorry but I don't agree. I set the tab width to different > sizes and the code is still indented properly and still looks > fine to me. (BTW, I usually use a size of 4). I was wrong here, sorry. At least I couldn't find any of your code that uses spaces AND tabs for indenting :-) > > Tabs are bad. > > This is your opinion. On the other hand I think that spaces > are bad. With only spaces: 1. your layout is never destroyed 2. looks the same on any viewer, even those that do not handle tabs properly as the original vi. > > > (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. > > I differ from OOSC2 because all the Eiffel code that I wrote > or saw in the projects I work on during the past 10 years or > more (even when I was at ISE) put the class name on the same > line as the 'class' keyword. That's all. You can make this optional. eposix uses the OOSC2 almost excusively. For examples (better formatting results) I use your approach. > > 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. > > I think that it is bad pratice to raise exceptions in Eiffel. > But at least we should know when such exceptions may occur. > I don't think this is superfluous. Raising exceptions is a core feature of eposix: if you ask to create a directory, it is created or you get an exception. Every failure gives you can exception so you don't continue in case of failure. I don't think I use exceptions where it is not clear from the ensure clause (which I admit is not always there )-: ). Can you agree that when the ensure clause exists, the comment is superfluous? There should be exceptions when the contract cannot be fullfilled, so it should be in the contract. If it is not in the contract, perhaps you shouldn't generate exceptions (so a comment is an indication that something is wrong). Groetjes, Berend. (-: |
|
From: Eric B. <er...@go...> - 2001-05-28 09:34:46
|
Berend de Boer wrote: > > Please no editor war, If we cannot fight on that, what should we do? Fight on semicolons ;-) > Just not true, please read the url. I read it, but since it is inexact wrt Vim I didn't take it for granted. > Because the problem is not Eamcs, but tabs and of course this is all > settable, please read the url. An editor which saves on disk something different from what I typed, who's the problem so? -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X