gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] Suggestion for getest

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

Eric,

Would it make sense to add a command line option to getest to just execute
the "Preparing Test Cases" step rather than all of the steps at once? In
fact, an option to run each of the steps selectively would be useful.

This would make is easier to develop test harnesses using an IDE, such as
EiffelBench. I could then develop the test harness code in the IDE, generate
the test harnesses using getest and execute the test harness in the IDE.

Glenn.

[gobo-eiffel-develop] geant integrated in gobo

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

geant (a.k.a ant4e) is now integrated in GOBO.
If you want to try it you can find it in GOBO's cvs
under gobo/src/geant.

- Sven


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Der Aktien-Service, der f=FCr Sie aktiv ist! Automatische Berechnungen,=20
Mail-Benachrichtigung. F=FCr Ihre Bed=FCrfnisse!  http://boerse.web.de/

[gobo-eiffel-develop] Re: gobo-eiffel-develop digest, Vol 1 #28 - 7 msgs

[Greg C <gm...@ya...>]

> From: Einar Karttunen <eka...@cs...>
> To: <gob...@li...>
> Subject: [gobo-eiffel-develop] Adding tree support to gobo
> Reply-To: gob...@li...
> 
> Hello
> 
> I am/will be coding a small tree library using eiffel. As other parts of
> my software use gobo I am trying to create it to be complicant with gobo
> classes and if you want we can add it to the official distribution. At
> the moment I plan to include binary search trees, splay trees and red
> black trees.
> 
> - Einar Karttunen
> 

The Kedsal library contains a binary tree implementation.
http://www.eiffel-forum.org/archive/kedsal/index.htm

There may be other classes worth integrating into Gobo as well.

Greg


=====
http://www.geocities.com/gmc444/gregs.html
Apologies for the stupid Yahoo ad below.

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: [gobo-eiffel-develop] Adding tree support to gobo

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

Einar Karttunen wrote:
>=20
> I think of inheriting from DS_CONTAINER=2E DS_TRAVERSABLE presents
> problems as trees can be traversed in many orders=2E I plan to include
> pre-, post-, inorder and Lindst=F6m-traversing=2E

You could arbitrarily choose one of them to implement
the routines from DS_TRAVERSABLE and provide other
external cursors for the other kind of traversals=2E
For example:

  new_cursor: DS_TREE_CURSOR [G] is
        -- New external cursor for traversal
        -- (Use preorder traversal by default=2E)
     do
        Result :=3D new_preorder_cursor
     end

  new_preorder_cursor: DS_PREORDER_TREE_CURSOR [G] is
        -- New external cursor for preorder traversal
    do
        !! Result=2Emake (Current)
    ensure
        =2E=2E=2E
    end

  new_postorder_cursor: DS_POSTORDER_TREE_CURSOR [G] is
        -- New external cursor for postorder traversal
    do
        !! Result=2Emake (Current)
    ensure
        =2E=2E=2E
    end

  =2E=2E=2E

--=20
Eric Bezault
mailto:ericb@gobosoft=2Ecom
http://www=2Egobosoft=2Ecom

Re: [gobo-eiffel-develop] Adding tree support to gobo

[Alexander K. <kw...@ah...>]

Eric Bezault wrote:

> BTW, I think that someone already wrote a red black tree
> in Eiffel, so perhaps you can borrow some ideas or chunks
> of code. I don't remember the name of the author nor the
> URL (it was part of a sound library if I recall correctly),
> but I'm sure that Geoff Eldridge can give us a pointer since
> it was reported in his excellent ELJ daily news (although
> it was a long time ago).

One implementation that uses red-black trees was

http://www.eiffel-forum.org/archive/objtools/containe.htm

which worked with Eiffel/S 1.3 and ISE Eiffel 3. Later the
library was ported to Visual Eiffel and is included in the standard
VE setup. I can send the latest version of the library as a separate
ZIP file if required (there were some fixes since the first release).

Regards,
Alexander Kogtenkov
Object Tools, Moscow

Re: [gobo-eiffel-develop] Adding tree support to gobo

[Einar K. <eka...@cs...>]

On 27 Jun 2001, Andreas Leitner wrote:

> On 27 Jun 2001 16:55:12 +0200, Eric Bezault wrote:
>>>...
> > That would be great. If you can manage to integrate them
> > with the other classes of the Gobo Eiffel Structure Library
> > such as DS_CONTAINER, DS_TRAVERSABLE or DS_CURSOR, it would
> > be even better.
I think of inheriting from DS_CONTAINER. DS_TRAVERSABLE presents
problems as trees can be traversed in many orders. I plan to include
pre-, post-, inorder and Lindst=F6m-traversing. If someone has suggestion=
s
on any other containers to inherit please send a message. I will
provide external iterators. If there would be internal iterators that
would mean four iterators per tree or functions that set/get the iterator
type. I think this is not very wise but if most people want it I can
include it too.

> >
> > BTW, I think that someone already wrote a red black tree
> > in Eiffel, so perhaps you can borrow some ideas or chunks
> > of code. I don't remember the name of the author nor the
> > URL (it was part of a sound library if I recall correctly),
> > but I'm sure that Geoff Eldridge can give us a pointer since
> > it was reported in his excellent ELJ daily news (although
> > it was a long time ago).
>
>
> Do you mean this library, Eric?
> http://www.eiffel-forum.org/archive/durian/red_black_tree.htm
I will check it out. Thanks for the pointer.


> Btw, Einar: Are you going to write a Tree Library as in a container tha=
t
> holds an abitrarily nested (but non recursive) item structure, or a set
> of classes (like the RB-Tree) that implement a sorted list with a
> certain tree structure?
Currently I am only going to implement binary trees. I know other kinds o=
f
trees are important too, but I think getting the binary trees in the lib
first should be important. If someone wants to implement e.g. B-trees or
tries they are welcome to, but I don't currently have time for that.

- Einar Karttunen

Re: [gobo-eiffel-develop] Adding tree support to gobo

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

Andreas Leitner wrote:
> 
> Do you mean this library, Eric?
> http://www.eiffel-forum.org/archive/durian/red_black_tree.htm

Yes.

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

Re: [gobo-eiffel-develop] Adding tree support to gobo

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

On 27 Jun 2001 16:55:12 +0200, Eric Bezault wrote:
> Einar Karttunen wrote:
> >  
> > I am/will be coding a small tree library using eiffel. As other parts of
> > my software use gobo I am trying to create it to be complicant with gobo
> > classes and if you want we can add it to the official distribution. At
> > the moment I plan to include binary search trees, splay trees and red
> > black trees.
> 
> That would be great. If you can manage to integrate them
> with the other classes of the Gobo Eiffel Structure Library
> such as DS_CONTAINER, DS_TRAVERSABLE or DS_CURSOR, it would
> be even better.
> 
> BTW, I think that someone already wrote a red black tree
> in Eiffel, so perhaps you can borrow some ideas or chunks
> of code. I don't remember the name of the author nor the
> URL (it was part of a sound library if I recall correctly),
> but I'm sure that Geoff Eldridge can give us a pointer since
> it was reported in his excellent ELJ daily news (although
> it was a long time ago).


Do you mean this library, Eric?
http://www.eiffel-forum.org/archive/durian/red_black_tree.htm

Btw, Einar: Are you going to write a Tree Library as in a container that
holds an abitrarily nested (but non recursive) item structure, or a set
of classes (like the RB-Tree) that implement a sorted list with a
certain tree structure?

I think there is a major difference between those areas. Although we
probably need both (;

Andreas

Re: [gobo-eiffel-develop] Adding tree support to gobo

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

Einar Karttunen wrote:
>  
> I am/will be coding a small tree library using eiffel. As other parts of
> my software use gobo I am trying to create it to be complicant with gobo
> classes and if you want we can add it to the official distribution. At
> the moment I plan to include binary search trees, splay trees and red
> black trees.

That would be great. If you can manage to integrate them
with the other classes of the Gobo Eiffel Structure Library
such as DS_CONTAINER, DS_TRAVERSABLE or DS_CURSOR, it would
be even better.

BTW, I think that someone already wrote a red black tree
in Eiffel, so perhaps you can borrow some ideas or chunks
of code. I don't remember the name of the author nor the
URL (it was part of a sound library if I recall correctly),
but I'm sure that Geoff Eldridge can give us a pointer since
it was reported in his excellent ELJ daily news (although
it was a long time ago).

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

[gobo-eiffel-develop] Adding tree support to gobo

[Einar K. <eka...@cs...>]

Hello

I am/will be coding a small tree library using eiffel. As other parts of
my software use gobo I am trying to create it to be complicant with gobo
classes and if you want we can add it to the official distribution. At
the moment I plan to include binary search trees, splay trees and red
black trees.

- Einar Karttunen

Re: [gobo-eiffel-develop] memory strategy

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

fr...@ne... (Franck Arnaud) writes:

> > like this waste lots of memory (50%), because resizing is done by a
> > factor of 2 when necessary.
> 
> This memory may have (close to) zero cost on typical modern 
> operating systems (if you let the OS handle initialisation to zero, 
> I guess you just allocate address space but not real memory 
> until you actually write to it).

Not really. As soon as you allocate something and write your first
character, all other space is wasted. If you expand using realloc, you
just waste 50% (with the usual times 2 expansion), because the memory
will be written.

And this is proved by experience by the familiar SmallEiffel string
example that compes up every so often.

Groetjes,

Berend. (-:

[gobo-eiffel-develop] memory strategy

[<fr...@ne...>]

Berend:

> like this waste lots of memory (50%), because resizing is done by a
> factor of 2 when necessary.

This memory may have (close to) zero cost on typical modern 
operating systems (if you let the OS handle initialisation to zero, 
I guess you just allocate address space but not real memory 
until you actually write to it).

--
fr...@ne...

[gobo-eiffel-develop] alexandria apache-documentation-project

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

The Apache Jarkarta people have an interesting project that is meat to simplify the generation and maintainance of source code documentation. here is a link to the projects homepage:
http://jakarta.apache.org/alexandria/index.html

I don't know if this is exaclty what we want, but maybe they have some ideas we could steal for GOBO (;


Andreas

Re: [gobo-eiffel-develop] Re: [exml] References: url and pipework

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

Andreas Leitner wrote:

> ...
>>All these stuff can be done as augmentation to
>>GOBO project, but my feeling is that it is better
>>suited for the standard Eiffel.
>>
> 
> I`d be happier if NICE can revamp ARRAY and STRING is a reasonable amount
> of time and shortly after all Eiffel compilers adopt the new
> standard. Looking at the past this task is not to be underestimated - It's
> just with the GOBO effort: I'd like to see NICE succeed with a small job
> rather than fail with a big one.
> 
> regards,
> Andreas
> 
> 
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> http://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 
> 

Yes.  Standards work best when they are a recognition of existing good 
practices.  My favored structure has several levels of standard, ranging 
from "somebody's interesting proposal" through "recommended practices" 
up to "required to pass acceptance tests".  But they don't all need to 
be run by Nice.  I see
Required for acceptance tests :: the compiler vendors/distributors
Recommended practices         :: Nice
Proposed Standard             :: Nice
Shared library                :: Gobo
Work in Progress              :: Gobo beta, other public betas
Interesting proposal          :: Mailing lists, newsgroups

N.B.:  I said public betas.  I mean at minimum Open Source(tm) software, 
and prefer Free Software (FSF).  Proprietary libraries/code is not 
suitable for a public standard.  It can become so at the cost of 
releasing it under an OSF or FSF license.  But code that says "This 
routine may only be used in conjucntion with..." or "You do not have 
permission to modify and redistribute this code" is essentially unuseable.

Now one could easily agrue over the details, and they don't matter much. 
  What matters is that proposals move up during a process of refinement 
and debugging.  So by the time they get to the top they are well tested, 
and reasonably efficient.

One defect of this proposed organization is that it doesn't have any 
place for "large jumps".  But in most cases that is at least as much of 
an advantage as it is a weakness.

Another defect is that it doesn't have much room for the compiler 
vendors to have their custom classes to be considered a part of the 
standard.  And I think that that's also nearly as much of an advantage 
as a defect.  Proposals handed down from on high all too often overlook 
necessary features.  And if they are proprietary, things are even worse. 
  Proprietary libraries are divisive, resist improvement, and can't be 
incorporated into a good standard.  And if there are only a couple of 
good ways to do things, they can cause the public standard to be clumsy 
and inefficient (to avoid legal problems).
-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

[gobo-eiffel-develop] Re: [exml] References: url and pipework

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

Posting crosspostend to gobo-eiffel-develop.

On Fri, 22 Jun 2001, Alexander Kogtenkov wrote:

> The recent discussions in this and other mailing lists
> and comp.lang.eiffel showed an interest in basic
> and extended I/O facilities abstracted to streams/
> readers and alike. While extended facilities might
> be pretty advanced and are subject to long-term
> development, the basic things should be available
> in every Eiffel implementation.
> 
> At the moment the implementations differ mostly
> in some minor points, namely class and feature
> names. And sometimes the classes are overloaded
> with too much functionality (e.g., ELKS class FILE
> represents both file system descriptor and file handle).
> 
> I suggest to work out the proposal of the NICE
> library standard that covers
>    Input streams:
>       General
>       System (stdin, file, pipe)
>       Data (read_integer, etc.)
>       Proxy (works through other input stream)
>    Output streams - almost the same structure

Personally I am totaly happy if NICE is going to rework ELKS as planned. I
fear if we ask them to decide on a general io framework it would slow down
the proccess currently in the works as well.

Why not try to implement it in GOBO first and when we feel it is stable
and usefull submit it to NICE. This has IMO 2 advantages:

1) The users get what they need sooner
2) Nice gets a well thought out and well tested proposal

ISE is working on fixed sized integers in their new release. If other
vendors support it, we (GOBO-team) are fine, I think.

> As all the classes are tightly related, I think it's
> better to consider them as a whole and not on
> class-by-class basis for consistency reasons.

I am not so sure. The most important thing IMO is the abstract IO API,
which is totaly unlrelated to the other things. Various implementation may
be releated, but implementations can come and go. Important is the
interface.

> All these stuff can be done as augmentation to
> GOBO project, but my feeling is that it is better
> suited for the standard Eiffel.

I`d be happier if NICE can revamp ARRAY and STRING is a reasonable amount
of time and shortly after all Eiffel compilers adopt the new
standard. Looking at the past this task is not to be underestimated - It's
just with the GOBO effort: I'd like to see NICE succeed with a small job
rather than fail with a big one.

regards,
Andreas

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

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

[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] UCSTRING integrated to cvs

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

Great! I was away for a few days, going to look into it ASAP. This is
excellent news for eXML - or the future GOBO-XML (;


Andreas

Re: [gobo-eiffel-develop] UCSTRING integrated to cvs

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

Hi all,

majkel kretschmar wrote:

> the ucstring library is now fully integrated into the gobo cvs. you can
> find it under
> library/kernel/unicode.
>

Excellent! I will try it out as soon as I get time.

/Paul

--
Paul Cohen                      Tel: +46 8 50 714 366
Software consultant             Vx:  +46 8 50 714 000
Enea Business Software AB       Fax:  +46 8 65 857 90
Hornsgatan 166
117 28 Stockholm                          www.enea.se

Re: [gobo-eiffel-develop] UCSTRING integrated to cvs

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

majkel kretschmar wrote:
> 
> the ucstring library is now fully integrated into the gobo cvs.

Great.

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

[gobo-eiffel-develop] UCSTRING integrated to cvs

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

the ucstring library is now fully integrated into the gobo cvs. you can
find it under
library/kernel/unicode.

it is mostly identically to the version found on sourceforge.net under
project ucstring with some exceptions:
- all headers (indexing) rewritten
- compiler specific behaviour is now handled by gobo
- renamed UC_STRING.*_ucchar to UC_STRING.*_uc_character,
UC_STRING.*_ucstring to
  UC_STRING.*_uc_string, old feature names marked as obsolete

things to come:
- remove self written features and replace it by gobo-equivalent ones (i
think   there is one for converting integer to hexstring etc.)
- write a todo-list
- write the documentation (at the moment you have to live with the
feature doc)
- release the my little test tool
- update the unicode database to the last actual one (currently, i am
not sure
  which one i am using; i think it's v2 with v3 names); realease the
tools for
  generating it.
- a class for converting streams in one encoding to another one

hope you'll enjoy it.
 
--
maj...@ep...

Re: [gobo-eiffel-develop] integrating UCSTRING to gobo-eiffel

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

Hi all,

majkel kretschmar wrote:

>
> i think it is getting time to integrate the ucstring-cvs-repository into
> the gobo-eiffel-cvs. in the current state it is relative stable, nearly
> only minor
> beautifications must be done (eg "indexing"). a lot of people are
> waiting for it, so we should integrate it. the necessary modifications
> can be done if i have a little more time and cvs-access.
>

Mmm. Nice! No pun intended ;-).

/Paul

Re: [gobo-eiffel-develop] integrating UCSTRING to gobo-eiffel

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

Majkel,

> i think it is getting time to integrate the ucstring-cvs-repository into
> the gobo-eiffel-cvs.

Great. Do you want to give me your SourgeForge username so that
I can add write-access for you in the gobo-eiffel CVS repository?

> in the current state it is relative stable, nearly only minor
> beautifications must be done (eg "indexing"). a lot of people are
> waiting for it, so we should integrate it. the necessary modifications
> can be done if i have a little more time and cvs-access.

Yes, that's what I said in a previous message: as long as
the classes are committed with their proper names in
the proper directories, then we can take care of cosmetics
later on when time permits. Actually if you don't have
time to do it now I can take charge of it if you want.

> who will import the stuff into cvs and 

You or me. If you don't have time to do it I can do it
for you if you want. That way I could take care of the
cosmetics at the same time. Just let me know.

> whereto?

I suggest that we put it as part of the Gobo Kernel library
in cluster gobo/library/kernel/unicode:

  gobo/library/kernel/unicode/uc_string.e
  gobo/library/kernel/unicode/uc_character.e 
  ...

I noticed that you were using a class UC_SPECIFIC in
clusters spec/[ise|se|ve] with the routine: 

 code_to_character (i: INTEGER): CHARACTER

I suggest that we don't commit this class to gobo-eiffel
CVS repository and use KL_INTEGER_ROUTINES.to_character
instead. This is actually the advantage of merging several
packages into Gobo: we can now share classes instead of
duplicating these functionalities in every package. If
I'm the one who commits your unicode classes to gobo-eiffel
I'll take care of changing the code as well so that it
calls KL_INTEGER_ROUTINES.to_character instead of
UC_SPECIFIC.code_to_character.

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