gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Trouble with IO

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

Uwe Sander wrote:
> 
> Compiler is SE, the following lines are code snippets
> 
>   local
>    stream: INPUT_STREAM
>    file: KL_TEXT_INPUT_FILE
>   do
>    !!file.make ("test1.c")
>    file.open_read
> 
>    stream := file

KL_TEXT_INPUT_FILE indirectly inherits from INPUT_STREAM
using implementation inheritance (export {NONE} all), therefore
even though no Eiffel compiler forbids the above assignment
it is theoritically invalid. At least that's the way I consider
it when I write Eiffel code.

>    stream.read_line

Here you have a CAT-call: the entity `stream' is attached to
an instance of KL_TEXT_INPUT_FILE, and the version of
INPUT_STREAM.read_file is exported to NONE in KL_TEXT_INPUT_FILE.

Either you use the Gobo IO classes, or you use SmallEiffel's,
but don't mix and match them. This is likely not to work.

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

Re: [gobo-eiffel-develop] geant and file sets

[Sven E. <sve...@we...>]

*********** REPLY SEPARATOR  ***********

On 20/10/2001 at 1:09 AM Andreas Leitner wrote:

>Sven,
>
>I just experimented with geant and found out that
><delete file=3D"*.obj"/>
>does not work as expected. This comes to no suprise as there is no shell 
>to expand the '*'. IIRC in ant there is a notion of filesets to overcome 
>this and similar problems. Given that you have more experience with ant 
>then me, do you think such a notion would make sense for geant as well?
>

Currently work is in progress for a <fileset> element similar to the one
in jakarta ant. When this element is available the <del> task (and many=
 others)
could use it as a subelement.
The interface specification of <fileset> is not finished yet but a possible
usage pattern could be:

<del>
  <fileset>
    <inlude>*.obj</include>
  </fileset>
</del>

or for nested files:

<del>
  <fileset>
    <inlude>**/*.obj</include>
  </fileset>
</del>

- Sven

Re: [gobo-eiffel-develop] bridge pattern and feature comments

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

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

> On a slightly different note, I am not totally convinced anymore
> that the bridge pattern is the best solution for GOBO XML. The
> factory plus implementation plus implementations approach is simpler
> and gives you the same results with one layer of duplication less
> (the implementation interface) (If my talking was to confusing I
> mean the approach taken by eposix and the new kernel io clustern in
> gobo (et all).

On a related note: eposix will do away with the factory or phase it
out or so. This is I want to give users the ability to inherit from a
file system. This is not possible with a factory.

So you get this tree in eposix:

ABSTRACT_FILE_SYSTEM
EPX_FILE_SYSTEM (one class per windows/posix/whatever)
WINDOWS_FILE_SYSTEM/POSIX_FILE_SYSTEM/WHATEVER_FILE_SYSTEM

-- 
Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] bridge pattern and feature comments

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

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

> The brige pattern introduces for almost all interfaces 2 + n classes
> (one class for the user interface, one class for the implementation
> interface and one class for each implementation). The classes
> usually are very very similar, meaning that feature comments are
> mostly identical as well.

And especially if you start to introduce things like my validating
parser that has to work with any implementation and seems to need two
sides: implementation and interface.


> If the kernel io approach is indeed better, I am not sure if we
> should convert GOBO XML. If the amount of work neccessary to be done
> is worth it. IMO GOBO would look a bit more homogenous if GOBO XML
> would not use the bridge pattern.

Important things, IMO, to take into account are:

1. Do we want to switch, on the fly, in the same program, between
   different XML parsers? My answer would be NO (at least not out of
   the box, there are work-arounds of course).
   If no, this means particular parsers can live in different directories,
   have the *same* name, and by choosing a particular directory you
   are working with that parser.

2. Do we want to have the ability to inherit from a given
   implementation? My answer would be YES.

3. Do we want layers, i.e. have a validating parser using any
   particular implementation? YES of course. The DOM generator is also
   a layer upon a parser IMO.
   But how? Having the validating parser inherit or use a parser? The
   validating parser looks like any simple non-validating parser, so
   itself either inherits from some base parser class or from the
   particular implementation.
   I favor the first approach (as it is now more or less): the
   validating parser inherits from a base parser class and uses a
   particular parser.

   Three is about the ability to move code that is common accross all
   implementations into a separate class, a layer you can insert
   before the calls finally reach the user program.

   I don't favor using a single inheritance tree. A validating parser
   can inherit from a particular implementation and this would
   work. But:
   1. the client interface depends on the particular implementation
      choosen at a time.
   2. It's easier to make the fault of writing something that depends
      on a particular implementation, instead of being
      portable. Because you inherit from a particular implementation, you
      have features you in other situations don't have.
   3. A validating parser isn't a particular implementation nor
      dependent on it. So this modeling is wrong.

4. Another thing I would like is to have several base layers:
   a. A very simple layer only having start/stop tag and data.
   b. The full-blown expat thing.

   This way it's easier for people to make a particular implementation
   and it's easier to check at compile that an implementation doesn't
   have implemented everything.

From this requirements it seems the current approach isn't too bad. It
can do these things (almost). In particular, I don't see how we can do
3 without agents. If we can decide to use agents, a different design
can be done.

-- 
Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

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

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

> I think ideally we should replace the Makefile.* mess in
> /library/xml/impl/expat/spec/c with only one maintainable geant
> file. This should already be possible with OS-specific tasks and the
> exec command. But I have that feeling in my stomach that such a
> geant file won't be that clean and maintainable either. Maybe we can
> come up with some reusable geant tasks for c compilation and
> linkage. Such commands will be usefull for other C dependent parts
> as well (think eposix).

For eposix I've written a Makefile generator that works quite well
from the reports I've received. It generates Makefile's for Borland,
Microsoft and lcc. It just needs a simple config file.

I think it would be a good thing to move this into geant. It's
dependent on eposix. This might make bootstrap a bit more difficult,
but we can provide a makelib binary for every architecture if
necessary.

> The trivial abstraction level would be to create a a compile and
> create archive command for each c-compiler (and OS combination?) and
> then use conditionals in the geant files. Can we do better? Maybe we
> can use a combination of geant commands and geant inheritance (that
> feature rules :)?

I suggest we create Makefile as Makefiles include certain system
and compiler specific knowledge. Users can have tweaked there Makefile
configurations for example. If you generate a Makefile you can take
advantage of these things.

Here is the makelib (the name of my program) configuration file that
would be more or less ok:

----------------
GOBO
libexpat
library\xml\impl\expat\spec\c
----------------

not tested, but it's not more difficult than this. The first thing is
the enivronment variable, that should contain the start directory. The
second line is the target makefile. The eiffel compiler and c compiler
are attached to that name so you get something like:

        libexpat-ise-msc

The third and next lines contain the C files. As the EXML C files are
written exactly like eposix this works. makelib just finds all .c
files and includes them in the generated Makefile.

-- 
Groetjes,

Berend. (-:

[gobo-eiffel-develop] Trouble with IO

[Uwe S. <us...@on...>]

Hi GOBO team,

if this is the wrong list, please accept my apologizes and point me to the
right one ...

Please consider the following situation:

Compiler is SE, the following lines are code snippets

  local
   stream: INPUT_STREAM
   file: KL_TEXT_INPUT_FILE
  do
   !!file.make ("test1.c")
   file.open_read

   stream := file

   stream.read_line

The last line results in a feature applied to Void reference problem,
because it calls 'old_read_line' from KL_TEXT_INPUT_FILE, which calls in
turn 'last_string' which is Void. Wouldn't it be better to redefine
'last_string' in a way that it is not an attribute but a function which
returns an internal attribute (simulating once-per-object)? Other
suggestions?

The problem occured while converting ELJ to make use of GOBO io classes.


Best Regards

Uwe

[gobo-eiffel-develop] geant and file sets

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

Sven,

I just experimented with geant and found out that
<delete file="*.obj"/>
does not work as expected. This comes to no suprise as there is no shell 
to expand the '*'. IIRC in ant there is a notion of filesets to overcome 
this and similar problems. Given that you have more experience with ant 
then me, do you think such a notion would make sense for geant as well?

Andreas

[gobo-eiffel-develop] bridge pattern and feature comments

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

Hi,

I am about to revamp the inline documentation of GOBO XML.
Now, in the last 2 days I have tried to bring the feature comments in the user interface layer and the implementation interface layer in sync. (Some spots still need work, though). 

The brige pattern introduces for almost all interfaces 2 + n classes (one class for the user interface, one class for the implementation interface and one class for each implementation). The classes usually are very very similar, meaning that feature comments are mostly identical as well.

Now I wanted to start working on the documentation of the various implementations. But I remember the in the book "The Pragmatic Programmer" they talk about too much documentation, documentation that is redundant that is. They argue that such documentation is likely to get out of sync and thus it is better to not introduce redundant documentation in the first place.

What is your (the list, or better Eric :) opinion on that?

On a slightly different note, I am not totally convinced anymore that the bridge pattern is the best solution for GOBO XML. The factory plus implementation plus implementations approach is simpler and gives you the same results with one layer of duplication less (the implementation interface) (If my talking was to confusing I mean the approach taken by eposix and the new kernel io clustern in gobo (et all).
 
If the kernel io approach is indeed better, I am not sure if we should convert GOBO XML. If the amount of work neccessary to be done is worth it. IMO GOBO would look a bit more homogenous if GOBO XML would not use the bridge pattern.
 
Andreas

 

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

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

On Fri, Oct 19, 2001 at 03:45:56PM +0200, Eric Bezault wrote:
> Glenn Maughan wrote:
> 
> I have taken all your remarks above into account I have patched
> the files so that they can now be compiled with ISE Eiffel under
> Windows NT with MSVC++ 6.0. I didn't look at the code for other
> platforms or other compilers though. I tried to compile the new
> code in CVS with expat_win32bin_1_95_2.exe downloaded from the
> SourceForge Expat project and everything seems to compile OK on
> my laptop under Windows NT 4.0 with ISE Eiffel 5.0.34. As usual
> (hmmm, shame one me ;-)) I didn't try to execute these modifications,
> so I'll let experiement with it.


I think ideally we should replace the Makefile.* mess in /library/xml/impl/expat/spec/c with only one maintainable geant file. This should already be possible with OS-specific tasks and the exec command. But I have that feeling in my stomach that such a geant file won't be that clean and maintainable either. Maybe we can come up with some reusable geant tasks for c compilation and linkage. Such commands will be usefull for other C dependent parts as well (think eposix).

OK, I'll try to do some brainstorming. What do we need to do:
*) We need to compile 2 c files, make sure they have certain include dirs set and ideally create a static library from the resulting object files. 

What are the difficulties to overcome:
*) Different OSes
*) Different Eiffel compilers
*) Different C compilers

Some random thought:
*) On some OSes the include paths are a non issue (on my debian box the headers should be in a directory that is accessible by the c compiler already).

What would be the best abstraction level for geant commands? Or should we go for plain execs?

The trivial abstraction level would be to create a a compile and create archive command for each c-compiler (and OS combination?) and then use conditionals in the geant files. Can we do better? Maybe we can use a combination of geant commands and geant inheritance (that feature rules :)?


Andreas

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

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

Glenn Maughan wrote:
> 
> On the expat side, I found that Makefile.win.msc does not compile correctly
> using VC++ 6.0. I think it is because the eiffel.h header is expecting the
> symbol 'ise' to be defined but 'ISE' is defined instead. Must be
> case-sensitive in nmake.
> 
> Also the makefile builds the file 'libexml.lib' rather than the
> 'libexml-expat-${GOBO_EIFFEL}.a' as defined in the library/xml/cluster.xace
> file.
> 
> Finally, the <external> element in library/xml/cluster.xace uses braces '{}'
> rather than parenthesis '()' to surround environment variables for the
> externals. It also defines '-lexpat' as a link library. nmake does not seem
> to like either of these.
> 
> Perhaps there needs to be a few conditional <external> elements that depend
> on the OS for the expat clusters. A bit messy!

I have taken all your remarks above into account I have patched
the files so that they can now be compiled with ISE Eiffel under
Windows NT with MSVC++ 6.0. I didn't look at the code for other
platforms or other compilers though. I tried to compile the new
code in CVS with expat_win32bin_1_95_2.exe downloaded from the
SourceForge Expat project and everything seems to compile OK on
my laptop under Windows NT 4.0 with ISE Eiffel 5.0.34. As usual
(hmmm, shame one me ;-)) I didn't try to execute these modifications,
so I'll let experiement with it.

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

Re: Re: [gobo-eiffel-develop] inheritance for geant

[Sven E. <sve...@we...>]

er...@go... schrieb am 19.10.01:
> Sven Ehrke wrote:
> > 
> > geant now supports a simple single inheritance mechanism:
> 
> This sounds great: it will allow me to remove all the duplicated
> code in the various Gobo build files.
> 

Yes, and I hope it proofs to be useful.

- Sven

_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: [gobo-eiffel-develop] inheritance for geant

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

Sven Ehrke wrote:
> 
> geant now supports a simple single inheritance mechanism:

This sounds great: it will allow me to remove all the duplicated
code in the various Gobo build files.

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

Re: Re: [gobo-eiffel-develop] inheritance for geant

[Sven E. <sve...@we...>]

Andreas Leitner <no...@sb...> schrieb am 19.10.01:
> On Thu, Oct 18, 2001 at 10:08:00PM +0200, Sven Ehrke wrote:
> > geant now supports a simple single inheritance mechanism:
> 
> Awesome! Am I correct that there is no such feature in the original ant?

Yes, there's no inheritance mechanism in the original ant. I browsed ant's discoussion list a bit
and it seems they are planning to support some subproject mechanism for version 2 which sounds
like another include mechanism to me.

> I used ant a bit during this summer and I was looking for a mechanism to build a standard set of rules that can be applied for >all projects in that company. I did not find anything usefull - but maybe I wasn't looking hard enought (;

It's been the first thing I was looking for as well when I started with ant. The only useful answer I got
from was to use xml entities for includes. But inheritance of course is much better than includes.

>If I understand the purpose of the geant inheritance correctly, such standard rules are a prime example, da?
Well all the advantages of inheritance are a prime example but yes, you're right.

- Sven

_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: [gobo-eiffel-develop] gexace nested cluster problem

[Glenn M. <gle...@ho...>]

>For now we are using environment variables, but maybe we can eventually 
>introduce a repository. Via geant a system or cluster could register itself 
>in a global repository with a key, which could then be used to mount a 
>cluster. But to get such a thing going needs quite a bit of thinking to get 
>all the details right. And I think we are better of using environment 
>variables for now, and eventually will introduce a repository (speaking for 
>myself here, not for the gobo-
>team as a whole - dunno what the others think about this).

I agree that environment variables are good for now. Passing the variables 
from geant to gexace would is good also.

Glenn.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

[Glenn M. <gle...@ho...>]

>No, you don't. But please be aware that the Eiffel parser is really >bare 
>bones at the moment. For example DTD Declarations do _not_ work >yet.

That's fine. I don't need them for what I'm doing.

Thanks.
Glenn.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: [gobo-eiffel-develop] inheritance for geant

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

On Thu, Oct 18, 2001 at 10:08:00PM +0200, Sven Ehrke wrote:
> geant now supports a simple single inheritance mechanism:

Awesome! Am I correct that there is no such feature in the original ant? I used ant a bit during this summer and I was looking for a mechanism to build a standard set of rules that can be applied for all projects in that company. I did not find anything usefull - but maybe I wasn't looking hard enought (; If I understand the purpose of the geant inheritance correctly, such standard rules are a prime example, da?

Andreas

[gobo-eiffel-develop] inheritance for geant

[Sven E. <sve...@we...>]

geant now supports a simple single inheritance mechanism:

A build file now can inherit the targets of another build
file by specifying the inherit attribute in the project element:

  <project name="B" inherit="a.eant">

build files which do not use the inherit attribute work like before.

You can find a demonstration of this new behaviour in

  $GOBO/example/geant/inherit

which contains the two build files 'a.eant' and 'b.eant':

a.eant:
_____________________________________________________________
<?xml version="1.0" ?>

<project name="A">
	
	<target name="f1">
		<echo message="A.f1"/>
		<set name="var1" value="default_value1"/>
	</target>

	<target name="f2" depend="f1">
		<echo message="A.f2"/>
		<echo message="var1: ${var1}"/>
	</target>

</project>
_____________________________________________________________


b.eant:
_____________________________________________________________
<?xml version="1.0" ?>

<project name="B" inherit="a.eant">
	
	<target name="f1-">
		<echo message="B.f1"/>
		<set name="var1" value="value1"/>
	</target>

	<target name="f2-" depend="f1">
		<echo message="B.f2"/>
	</target>

	<target name="f3">
		<echo message="B.f3"/>
	</target>

</project>
_____________________________________________________________

If you invoke

  geant -v -b b.eant f3

you get the following output (almost like before):

_____________________________________________________________
  Loading Project's configuration from b.eant
  Loading Project's configuration from a.eant
  Building Project

  B.f3:

    [echo] B.f3
_____________________________________________________________

If you invoke

  geant -v -b b.eant f1

you get the following output:
_____________________________________________________________
  Loading Project's configuration from b.eant
  Loading Project's configuration from a.eant
  Building Project

  A.f1:

    [echo] A.f1
    [set] var1=default_value1
_____________________________________________________________

which demonstrates some inheritance behaviour.

Then

  geant -v -b b.eant f2

produces the following output:
_____________________________________________________________
  Loading Project's configuration from b.eant
  Loading Project's configuration from a.eant
  Building Project

  A.f1:

    [echo] A.f1
    [set] var1=default_value1

  A.f2:

    [echo] A.f2
    [echo] var1: default_value1
_____________________________________________________________


Now rename target 'f1-' in 'b.eant' to 'f1' and invoke

  geant -v -b b.eant f1

output:
_____________________________________________________________
  Loading Project's configuration from b.eant
  Loading Project's configuration from a.eant
  Building Project

  B.f1:

    [echo] B.f1
    [set] var1=value1
_____________________________________________________________

Invoke

  geant -v -b b.eant f2

output:
_____________________________________________________________
  Loading Project's configuration from b.eant
  Loading Project's configuration from a.eant
  Building Project

  B.f1:

    [echo] B.f1
    [set] var1=value1

  A.f2:

    [echo] A.f2
    [echo] var1: value1
_____________________________________________________________


Now rename target 'f1' in 'b.eant' back to 'f1-',
rename  'f2-' in 'b.eant' to 'f2', and invoke

  geant -v -b b.eant f2

output:
_____________________________________________________________
  Loading Project's configuration from b.eant
  Loading Project's configuration from a.eant
  Building Project

  A.f1:

    [echo] A.f1
    [set] var1=default_value1

  B.f2:

    [echo] B.f2
_____________________________________________________________

Maybe one day geant supports multiple inheritance and 'rename' and
'redefine' clauses like we are used to in Eiffel. Then the
'inherit' attribute will become a subelement of the project rather
than an attribute. The <precursor> task might be the next item on the
todo list.

- Sven

Re: [gobo-eiffel-develop] Indexing clauses in XML library

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

On Thu, Oct 18, 2001 at 04:11:45PM +0200, Eric Bezault wrote:
> Andreas,
> 
> In the indexing clauses that you recently modified in
> library/xml, you put:
> 
>   library: "Gobo Eiffel Kernel Library"
> 
> instead of:
> 
>   library: "Gobo Eiffel XML Library"

Oooops, thanks for the notice. I have just checked in the corrections.


Andreas

[gobo-eiffel-develop] Re: another point regarding FILE_SET

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

Sven Ehrke wrote:
> 
> Hello Eric,
> 
> so far the FILE_SET class has several queries for the included files, the excluded files, and many others
> which more or less have to do with set operations. This is due to the fact that I would like to make file sets
> available for geant.
> This morning I had the idea the the FILE_SET class should only support one set of files so that there would
> be only one query instead of all those it supports now. Then there could be commands like `subtract', `add'
> `intersect' and so on. The <fileset> task/command internally would use two FILE_SETS internally: one for
> the things to include and one for the things to exclude. I am quite sure that I can reuse a lot from DS_SET.
> This would make FILE_SET much smaller and more flexible.

I promise that as soon as I come back home this weekend
I'll stop working on other things and review your file-set
implementation. But in the meantime your idea above seems
interesting indeed.

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

[gobo-eiffel-develop] Indexing clauses in XML library

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

Andreas,

In the indexing clauses that you recently modified in
library/xml, you put:

  library: "Gobo Eiffel Kernel Library"

instead of:

  library: "Gobo Eiffel XML Library"

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

Re: [gobo-eiffel-develop] outofdate

[Sven E. <sve...@we...>]

er...@go... schrieb am 18.10.01:
> Sven,
> 
> So far we had class names of the form GEANT_<taskname>_COMMAND
> and GEANT_<taskname>_TASK, where <taskname> is the name of
> the corresponding task as it appears in the build files. So
> although it doesn't follow exactly the Eiffel style, I would
> personally have named the classes for <outofdate>
> GEANT_OUTOFDATE_COMMAND and GEANT_OUTOFDATE_TASK instead
> of GEANT_OUT_OF_DATE_COMMAND and GEANT_OUT_OF_DATE_TASK.
> What is your point of view about the GEANT_<taskname>_COMMAND
> and GEANT_<taskname>_TASK naming convention?

same as your's. I just did not pay attention and will fix it as soon as possible.

- Sven


_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

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

On Thu, Oct 18, 2001 at 12:43:47PM +1000, Glenn Maughan wrote:
> >The idea is that the eiffel parser and the expat parser behave exactly >the 
> >
> >same
> >(except for bugs and unimplemented features). It is even possible to 
> >>switch from
> >one implmentation to the other at runtime. Namespace handling is done >in 
> >the
> >tree parser and thus is supported by both the eiffel and expat backend >if 
> >used
> >via the tree interface.
> >
> >Andreas
> 
> Great. I'll give it a try.
> 
> When using expat I had to manually register for certain events to be sent 
> using code like:
> 
>     -- register callback handlers
>     exml_register_XML_SetElementDeclHandler (item)
>     exml_register_XML_SetAttlistDeclHandler (item)
>     exml_register_XML_SetXmlDeclHandler (item)
>     exml_register_XML_SetEntityDeclHandler (item)
>     exml_register_XML_SetElementHandler (item)
>     exml_register_XML_SetCharacterDataHandler (item)
> 
> Do I still need to do something like this?

No, you don't. But please be aware that the Eiffel parser is really bare bones at the moment. For example DTD Declarations do _not_ work yet.

regards,
Andreas

Re: [gobo-eiffel-develop] gexace nested cluster problem

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

On Thu, Oct 18, 2001 at 12:34:41PM +1000, Glenn Maughan wrote:
> >With the way it is implemented now, as soon as you
> >have the attribute 'location', it is meant to be
> >a full pathname and not a relative pathname to the
> >parent directory. That's why you got the above behavior.
> >
> 
> This is fine as long as it doesn't require absolute paths. I'd like to be 
> able to move clusters around without having to recode the xace file. Relying 
> 
> on environment variables to specify the root of a path is ok but not perfect 
> 
> because it is another thing a user has to set to get a library working.
> 
> Ant is traditionally used by executing from the directory where the .ant 
> file resides. Therefore every path can be relative. The geant files I have 
> seen so far (from GOBO) seem to rely more on absolute paths with an 
> environment variable specifying the root.


Well, but using the current directory has it's drawbacks as well. First, what if you _want_ to call a given XACE file from somewhere else? This makes sense whenever you want the output files not in the same directory as the input files. But the really nasty things come up once you mount clusters. What does "current directory" mean in a cluster.xace file? Does it mean the directory of the cluster file or the directory of the system file? How is the semantic with recursive mounts?

But you are right that env. vars are not the right solution either. The user has to set them up himself, and there is no clean way to automate this process as one cannot know where to store the env. var. permanently. 

For now we are using environment variables, but maybe we can eventually introduce a repository. Via geant a system or cluster could register itself in a global repository with a key, which could then be used to mount a cluster. But to get such a thing going needs quite a bit of thinking to get all the details right. And I think we are better of using environment variables for now, and eventually will introduce a repository (speaking for myself here, not for the gobo-team as a whole - dunno what the others think about this).


regards,
Andreas

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

[Glenn M. <gle...@ho...>]

>The idea is that the eiffel parser and the expat parser behave exactly >the 
>same
>(except for bugs and unimplemented features). It is even possible to 
> >switch from
>one implmentation to the other at runtime. Namespace handling is done >in 
>the
>tree parser and thus is supported by both the eiffel and expat backend >if 
>used
>via the tree interface.
>
>Andreas

Great. I'll give it a try.

When using expat I had to manually register for certain events to be sent 
using code like:

     -- register callback handlers
     exml_register_XML_SetElementDeclHandler (item)
     exml_register_XML_SetAttlistDeclHandler (item)
     exml_register_XML_SetXmlDeclHandler (item)
     exml_register_XML_SetEntityDeclHandler (item)
     exml_register_XML_SetElementHandler (item)
     exml_register_XML_SetCharacterDataHandler (item)

Do I still need to do something like this?

Thanks.
Glenn.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: [gobo-eiffel-develop] Eiffel XML parser 'parse_from_string' implementation

[Glenn M. <gle...@ho...>]

>I just implemented it and committed to CVS. However no testing
>has been done at all (apart from checking that it compiles
>with ISE Eiffel). So it's up to you to try it if you want.

Excellent! And for the ISE Ace file generation.

I'll try them both out tonight and let you know how they go.

Glenn.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp