gobo-eiffel-develop

[gobo-eiffel-develop] DocBook & XML

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

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

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

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

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


--
Frieder Monninger
Object Tools GmbH

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

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

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

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

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

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

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

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

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

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

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

If I understand correctly, you just want to 
mount:

foo/interfaces
foo/impl/${PLATFORM}

instead of:

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

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

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

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

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

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

  mount foo
     exclude
        impl/unix

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

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

[gobo-eiffel-develop] HATs: Hashed Array Trees

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

Hai Eric,

The latest DDJ (#326) has a nice article about fast and small
resizable arrays. Something for Gobo? 

(or is it already there and I don't know it :-) )

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] HATs: Hashed Array Trees

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

Berend de Boer wrote:
> 
> The latest DDJ (#326) has a nice article about fast and small
> resizable arrays. Something for Gobo?
> 
> (or is it already there and I don't know it :-) )

No, it's not in Gobo yet. Do you know if this article
is (or will be) on-line?

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

Re: [gobo-eiffel-develop] HATs: Hashed Array Trees

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

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

> No, it's not in Gobo yet. Do you know if this article
> is (or will be) on-line?

Not sure. I'll mail you a copy. I think it's an interesting container
to have for strings, especially UCSTRINGS. Most of the time containers
like this waste lots of memory (50%), because resizing is done by a
factor of 2 when necessary. Simple and fail proof. But HATs solve both
the waste of memory and the time to expand it and make it O(Vn) [V =
root, not sure if there is an ascii symbol for it??].

Cost of access is one indirection.

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] HATs: Hashed Array Trees

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

Eric Bezault wrote:
> 
> Berend de Boer wrote:
> >
> > The latest DDJ (#326) has a nice article about fast and small
> > resizable arrays. Something for Gobo?
> >
> > (or is it already there and I don't know it :-) )
> 
> No, it's not in Gobo yet. Do you know if this article
> is (or will be) on-line?

I just read the article and a similar mechanism, although
not as sophisticated (e.g. no power of two), is already
used in the class DS_MULTIARRAYED_HASH_TABLE. It is
implemented using arrays of arrays, arrays on the second
level  being created only when first accessed. I used
this class to hold over 17 million objects and it worked
quite well. As I said it's not as sophisticated as the
algorithm described in the article, but it was good enough
for my needs. I was also planning to implement a class
DS_MULTIARRAYED_STACK, but I didn't have time to implement
it in Gobo 2.0.

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

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

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

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

Even better:

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

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

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

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

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

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

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

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

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

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

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

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

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


Andreas 

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

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

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

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

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

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

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

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