gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] ma_decimal update

[itt <itt...@us...>]

Hi list and especially Paul,

I am going to update the MA_DECIMAL to the latest IEEE-SA 754r spec. I
will work with Eric to get the updates committed to SVN.

Cheers,
Ivan

Re: [gobo-eiffel-develop] Bug in gec ?

[Howard T. <how...@di...>]

Thanks Eric for the fix as below.

I am continuing to develop my custom Garbage Collector for gec, with
four outstanding routines needed before stress testing.

1/ mark the stack, and I have basically worked out how I am going to
accurately mark references values on the stack [subject to testing ! ]

2/ make available to the GC a reference to the root object

3/ dispatch routine to call dynamic-type mark routine per id field

4/ [less urgent] work for expanded class attribute(s) that recursively
contain reference containing expanded class attribute(s)

Stress testing of the core C routines for memory allocation, random de-reference,
mark, scan and free is now working reliably with about 50/55 percent bytes-requested
vs bytes-allocated [I think from memory]. It is currently Linux specific, but with only
one smallish routine being platform specific [mmap dependent code].

I am also working on a class ET_ELF_X86_64_CODE_GENERATOR to generate a
Linux ELF X86_64 file, using a set of classes based loosely on the concepts in the
LLVM project, but that has a long way to go.

Regards,

Howard

On Thursday 24 Jul 2008, you wrote:
> Eric Bezault wrote:
> > Howard Thomson wrote:
> >> Hi all,
> >>
> >> I managed to confuse myself, and the compiler, by trying to compile
> >> a class set, as below, which had non-corresponding class filenames
> >> vs the contained class names.
> >>
> >> Would someone care to compile the following (trivial) class set
> >> and see whether 'gec' compiles it [it shouldn't !] and whether you
> >> get any error messages that explain the problem ?
> > 
> > I think that gec detects a compilation error because
> > no C code is generated. However it fails to display
> > an error message. I'll fix that.
> 
> It's now fixed. gec displays this message:
> 
> ----
> [GVSCN-1] class CHILD (1,16): file '.\child.e' contains class PARENT 
> instead of the expected class CHILD.
> ----
> 



-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] Bug in gec ?

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

Eric Bezault wrote:
> Howard Thomson wrote:
>> Hi all,
>>
>> I managed to confuse myself, and the compiler, by trying to compile
>> a class set, as below, which had non-corresponding class filenames
>> vs the contained class names.
>>
>> Would someone care to compile the following (trivial) class set
>> and see whether 'gec' compiles it [it shouldn't !] and whether you
>> get any error messages that explain the problem ?
> 
> I think that gec detects a compilation error because
> no C code is generated. However it fails to display
> an error message. I'll fix that.

It's now fixed. gec displays this message:

----
[GVSCN-1] class CHILD (1,16): file '.\child.e' contains class PARENT 
instead of the expected class CHILD.
----

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

Re: [gobo-eiffel-develop] Binary search tree

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

Hi Daniel,

Your binary search tree classes are now committed to SVN in
the SourceForge Gobo project. As agreed, I made some name
changes and some header comments and reformatting to better
match Gobo's style guildelines. I also removed the unnecessary
`void_is_valid_key' and merged `equality_tester' with `comparator'.
I probably did some other minor changes, such as making sure
that "key" features are not exported in the set classes
(set classes don't have the notion of keys in their interface).

I didn't review the binary search tree algorithms. But I think
that some improvements can be made. For example, would it be
possible to redefine `cursor_search_forth' and `cursor_search_back'
in DS_BINARY_SEARCH_TREE_SET, to take advantage that the items
are sorted, and hence avoid linear traversal?

Also, I think that `internal_put' and `internal_put_new' deserve
some postconditions that should match those of DS_SET and DS_TABLE
so that when they are used to implement the corresponding features
in set and table variants the code is correct in terms of DbC.

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

Re: [gobo-eiffel-develop] Bug in gec ?

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

Howard Thomson wrote:
> Hi all,
> 
> I managed to confuse myself, and the compiler, by trying to compile
> a class set, as below, which had non-corresponding class filenames
> vs the contained class names.
> 
> Would someone care to compile the following (trivial) class set
> and see whether 'gec' compiles it [it shouldn't !] and whether you
> get any error messages that explain the problem ?

I think that gec detects a compilation error because
no C code is generated. However it fails to display
an error message. I'll fix that.

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

[gobo-eiffel-develop] Bug in gec ?

[Howard T. <how...@di...>]

Hi all,

I managed to confuse myself, and the compiler, by trying to compile
a class set, as below, which had non-corresponding class filenames
vs the contained class names.

Would someone care to compile the following (trivial) class set
and see whether 'gec' compiles it [it shouldn't !] and whether you
get any error messages that explain the problem ?

Howard Thomson
--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

==================================================

file main.e:

class MAIN

create
	make

feature

	parent: PARENT

	make is
		do
			create {CHILD} parent.make
		end

end
=======================

file: child.e:

deferred class PARENT

feature -- Creation

	make is
		do
		end

end
======================

file parent.e:

class CHILD

inherit
	PARENT

create

	make

feature -- Creation

	make_x is
		do
		end

end

Re: [gobo-eiffel-develop] Binary search tree

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

Daniel Tuser wrote:
> Eric Bezault wrote:
>> Hi Daniel,
>>
>> Is there a reason why `void_is_valid_key' is False
>> in DS_BINARY_SEARCH_TREE? For example in DS_HASH_TABLE
>> it is possible to have void keys. And the algorithms
>> seem to work with void anyway since `void_is_valid_key'
>> is True in DS_BINARY_SEARCH_TREE_SET. I think that it
>> would make the interface simplier if we could get rid
>> of this feature `void_is_valid_key'.
> I will have a closer look at it as I have more time next week. If it 
> works in the void case too, you probably found an artifact I missed.

I just wrote test cases and it works fine.

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

Re: [gobo-eiffel-develop] Binary search tree

[Daniel T. <dan...@gm...>]

Eric Bezault wrote:
> Hi Daniel,
>
> Is there a reason why `void_is_valid_key' is False
> in DS_BINARY_SEARCH_TREE? For example in DS_HASH_TABLE
> it is possible to have void keys. And the algorithms
> seem to work with void anyway since `void_is_valid_key'
> is True in DS_BINARY_SEARCH_TREE_SET. I think that it
> would make the interface simplier if we could get rid
> of this feature `void_is_valid_key'.
I will have a closer look at it as I have more time next week. If it 
works in the void case too, you probably found an artifact I missed.
> Apart from that, I still need to improve one thing and
> then it will be ready to be committed in SVN. The
> problem is with `equality_tester'. This is assumed to
> be used in many places. Just look at the header comments
> of `is_subset', `interset', etc. in DS_BINARY_SEARCH_TREE_SET.
> But in fact it uses KL_COMPARATOR.order_equal. I'm currently
> trying to use the KL_COMPARATOR as if it was a
> KL_EQUALITY_TESTER of `equality_tester' (in other words
> `comparator' and `equality_tester' would be the same
> object).
When the implementation started, it was actually just one object. I had 
to split it because some problems with void tests. It made the work 
easier. I didn't change it because it worked. But it is certainly 
cleaner, if there is just one such object.

Re: [gobo-eiffel-develop] Binary search tree

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

Hi Daniel,

Is there a reason why `void_is_valid_key' is False
in DS_BINARY_SEARCH_TREE? For example in DS_HASH_TABLE
it is possible to have void keys. And the algorithms
seem to work with void anyway since `void_is_valid_key'
is True in DS_BINARY_SEARCH_TREE_SET. I think that it
would make the interface simplier if we could get rid
of this feature `void_is_valid_key'.

Apart from that, I still need to improve one thing and
then it will be ready to be committed in SVN. The
problem is with `equality_tester'. This is assumed to
be used in many places. Just look at the header comments
of `is_subset', `interset', etc. in DS_BINARY_SEARCH_TREE_SET.
But in fact it uses KL_COMPARATOR.order_equal. I'm currently
trying to use the KL_COMPARATOR as if it was a
KL_EQUALITY_TESTER of `equality_tester' (in other words
`comparator' and `equality_tester' would be the same
object).

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

Re: [gobo-eiffel-develop] Bounded structures?

[Bernd S. <ber...@co...>]

On Wed, 09 Jul 2008 17:26:27 -0000, Eric Bezault <er...@go...>  
wrote:

> Bernd Schoeller wrote:
>> Perhaps I missed it, but are any of the structures available in GOBO   
>> bounded? Is there a concept of "bounded" in any abstraction?
>>  I would need some bounded structures (mostly ring buffer) for some  
>> stuff  that I am currently writing.
>
> No bounded containers available in Gobo, they can all be resized.

Ok, then I will cook up something myself. I need a fast ring-buffer  
implementation, based on an array and two indexes. I am not sure if it  
could be an addition to GOBO, as it would live outside of the general  
structure hierarchie, because of its bounded-ness.

Bernd

-- 
Bernd Schoeller, PhD, CTO
Comerge AG, Technoparkstrasse 1, CH-8005 Zurich, Switzerland

Re: [gobo-eiffel-develop] Bounded structures?

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

Bernd Schoeller wrote:
> Perhaps I missed it, but are any of the structures available in GOBO  
> bounded? Is there a concept of "bounded" in any abstraction?
> 
> I would need some bounded structures (mostly ring buffer) for some stuff  
> that I am currently writing.

No bounded containers available in Gobo, they can all be resized.

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

[gobo-eiffel-develop] Bounded structures?

[Bernd S. <ber...@co...>]

Dear List,

Perhaps I missed it, but are any of the structures available in GOBO  
bounded? Is there a concept of "bounded" in any abstraction?

I would need some bounded structures (mostly ring buffer) for some stuff  
that I am currently writing.

Regards,
   Bernd

-- 
Comerge AG, Technoparkstrasse 1, CH-8005 Zurich, Switzerland

Re: [gobo-eiffel-develop] XM_XSLT_TEST_STYLESHEET_BUILDER does not compile

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Hi Colin, In your check-in svn#6447, it looks like you
>     Eric> forgot to update class XM_XSLT_TEST_STYLESHEET_BUILDER:
> 
> You are right. Sorry.
> 
>     Eric> What should be the extra argument to be passed to
>     Eric> `new_transformer' in this test class? It seems safe to pass
>     Eric> Void. Can we just do that?
> 
> Not only can, but must.
> Can you fix it for me? 

Done.

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

[gobo-eiffel-develop] XM_XSLT_TEST_STYLESHEET_BUILDER does not compile

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

Hi Colin,

In your check-in svn#6447, it looks like you forgot to update
class XM_XSLT_TEST_STYLESHEET_BUILDER:

~~~~~~~~~~~~~~~~~~~~~~~
Error code: VUAR(1)
Error: wrong number of actual arguments in feature call.
What to do: make sure that number of actuals matches number of formals.

Class: XM_XSLT_TEST_STYLESHEET_BUILDER
Feature: test_simple
Called feature: new_transformer (a_factory: XM_XSLT_TRANSFORMER_FACTORY; 
a_timer: XM_XSLT_TIMING): XM_XSLT_TRANSFORMER from 
XM_XSLT_STYLESHEET_COMPILER

Number of actuals: 1 Number of formals: 2
Line: 286
         assert ("hr 3", l_literal_result /= Void and then 
STRING_.same_string (l_literal_result.node_name, "hr"))
->      l_transformer := l_stylesheet_compiler.new_transformer 
(l_transformer_factory)
         assert ("transformer", l_transformer /= Void)
~~~~~~~~~~~~~~~~~~~~~~~

What should be the extra argument to be passed to `new_transformer'
in this test class? It seems safe to pass Void. Can we just do that?

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

Re: [gobo-eiffel-develop] Binary search tree

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

Daniel Tuser wrote:
> My todo list for the binary search trees is now empty. From my point of 
> view it is ready to be released if no one finds weaknesses in the code. 

I'm currently looking at integrating your classes into
Gobo and I'm wondering whether I can make some modifications
first. For example, when I see the name of this class:
DS_ABSTRACT_COMMON_RED_BLACK_TREE, I said "Wow!". In Gobo
we try to avoid using "ABSTRACT" (all deferred classes
are abstract, so it does not give that much information
about the class). And "COMMON" does not give that much
help either. From what I can see, you have sets and tables
implemented with various binary search tree algorithms.
In Gobo we already have DS_SPARSE_CONTAINER with the
descendants DS_SPARSE_TABLE and DS_SPARSE_SET. I think
that's what you tried to do with your "COMMON" classes.
So instead of DS_COMMON_BINARY_SEARCH_TREE I suggest
DS_BINARY_SEARCH_TREE_CONTAINER, with the indexing
clause: "Containers using binary search tree algorithms".
Then you have two descendants: the set version
DS_BINARY_SEARCH_TREE_SET and the table version
DS_BINARY_SEARCH_TREE (for which we don't put the suffix
_TABLE because this container is commonly known without it).
And use the same naming convention for all binary search
tree algorithms. Now, trying to get rid of "ABSTRACT", I
wonder why we cannot have DS_LEFT_LEANING_RED_BLACK_TREE
that inherits from DS_RED_BLACK_TREE (instead of having
this "ABSTRACT" common ancestor). If this is OK, I can
do the renaming as well as making sure that the header
comments follow the Eiffel style guidelines while integrating
the classes in Gobo.

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

Re: [gobo-eiffel-develop] [gobo-eiffel] Re: Gobo Regexp and Unicode support.

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

Ted wrote:
> I could have a look if you don't mind how much time I would take.
> Because I am quite slow reading C code. And not too much free time
> left for this.

That would be great if you could have a look at that.

If you want I will send you the C package PCRE 3.9 which
I believe was originally used when developing the Eiffel
regexp library. That way you could make a diff with the
version 7.7 currently available in www.pcre.org and see
what they did to support unicode.

Note that this mailing list is for user questions. Can we
move the discussion to the SourceForge developer mailing
list:

https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

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

Re: [gobo-eiffel-develop] Gobo Regexp and Unicode support.

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

Eric Bezault wrote:
> However, in addition to Colin's remark about case-insensitivity, I also
> noticed that character classes (e.g. "[a-z]") will not work if they
> contain characters with code greater then 255.

I forgot to mention that the routine `optimize' builds its
own character set for internal purposes. This means that this
routine might corrupt the behavior of the regular expression
if it contains characters with code greater than 255.

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

Re: [gobo-eiffel-develop] [gobo-eiffel] Gobo Regexp and Unicode support.

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

Ted wrote:
> I read somewhere Gobo Regexp doesn't support Unicode yet.
> After some investigation. I found some minor changes would make it
> support Unicode (See following patch).
> 
> Can someone confirm? And merge it into the library if possible.

I just committed your modifications in SVN.

However, in addition to Colin's remark about case-insensitivity, I also
noticed that character classes (e.g. "[a-z]") will not work if they
contain characters with code greater then 255.

For your information, this regexp library in Gobo was born out of
a translation to Eiffel of the code of the PCRE C library. The version
of the C library was 3.9 if I remember correctly, and it was the
very early stage of its support for unicode. The version number today
is 7.7 and they claim to support unicode now, supposedly with a regexp
pattern syntax and behavior compatible with Perl's regexp. It might
be worth looking at the PCRE C library:

   http://www.pcre.org/

in order to implement unicode support in a way that does not depart
too much from the original PCRE library and at the same time preventing
us from having to reinvent the wheel.

I suggest that we move this discussion to the gobo-eiffel-develop
mailing list.

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

Re: [gobo-eiffel-develop] Gobo tools won't generate override cluster

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

 > From: Colin Adams
 > Sent: Wednesday, June 25, 2008 5:28 AM
 > To: Eric Bezault
 > Subject: Gobo tools won't generate override cluster
 >
 > I have the following lines in my system.xace:
 >
 > <option name="override_cluster" value="override_cluster"/>
 >
 > And
 >
 > <cluster name="override_cluster" location="${HOME}/es62_override">
 > 	  <option name="recursive" value="true"/>
 > 	</cluster>
 >
 >
 > But the getest command is generating the following in the ecf file:
 >
 > 	<cluster name="override_cluster"
 > location="${HOME}/es62_override" recursive="true">
 > 		</cluster>
 >
 >
 > So I don't get overrides - instead I get a clash.
 >
 > I am running on Linux using the latest SVN version of Gobo.

This should now be fixed in svn#6436.

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

Re: [gobo-eiffel-develop] Bug in XM_EXPAT_API

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

Paul Cohen wrote:
> The Result of type STRING is not created in the following feature in
> XM_EXPAT_API (see line 1426):
> 
>  1415 	new_string_from_c_zero_terminated_string (psz: POINTER): STRING is
>  1416 			-- Eiffel STRING object created from a zero terminated C
>  1417 			-- String located at `psz'.
>  1418 			-- The string is copied so the memory allocated at `psz' may be
>  1419 			-- freed without affecting the returned string.
>  1420 		require
>  1421 			psz_valid: psz /= default_pointer
>  1422 		do
>  1423 #ifdef SE
>  1424 			create Result.from_external_copy (psz)
>  1425 #else
>  1426 			Result.from_c (psz)
>  1427 #endif
>  1428 		ensure
>  1429 			string_not_void: Result /= Void
>  1430 		end
> 
> It should be:
> 
>  1426 			create Result.make_from_c (psz)
> 
> /Paul
> 

Thank you, it's now fixed in svn#6433.

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

[gobo-eiffel-develop] Bug in XM_EXPAT_API

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

Hi,

The Result of type STRING is not created in the following feature in
XM_EXPAT_API (see line 1426):

 1415 	new_string_from_c_zero_terminated_string (psz: POINTER): STRING is
 1416 			-- Eiffel STRING object created from a zero terminated C
 1417 			-- String located at `psz'.
 1418 			-- The string is copied so the memory allocated at `psz' may be
 1419 			-- freed without affecting the returned string.
 1420 		require
 1421 			psz_valid: psz /= default_pointer
 1422 		do
 1423 #ifdef SE
 1424 			create Result.from_external_copy (psz)
 1425 #else
 1426 			Result.from_c (psz)
 1427 #endif
 1428 		ensure
 1429 			string_not_void: Result /= Void
 1430 		end

It should be:

 1426 			create Result.make_from_c (psz)

/Paul

-- 
Paul Cohen
mobile: +46 730 787 035
e-mail: pau...@se...

Re: [gobo-eiffel-develop] [xsl] Printing CDATA from feed as HTML

[Colin P. A. <co...@co...>]

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

>>>>> "David" == David Carlisle <da...@na...> writes:
    >>> I think a parse() function almost made it into 2.0...

    David> it did.

    David> <xsl:function name="x:parse" as="document-node()">
    David> <xsl:param name="s" as="xs:string"/> <xsl:sequence
    David> select="doc(concat('data:text/xml,'$s))"/> </xsl:function>

    Colin> Almost.
    Colin> Your data URI needs the charset parameter.

Hm. Maybe not.

There is a portability problem here, in that there is a dependency
upon the Unicode encoding form used by the implementation. 

For instance, Gestalt currently uses UTF-8, so you need to specify:

data:application.xml; charset=UTF-8

but I am currently re-engineering it to use UTF-32 (amongst other
changes), and so there is a problem.

Now the implementation would be able to supply the actual encoding
using a higher level protocol (something internal to the
implementation of fn:doc()). You then have a clash between the
labelled encoding, and the encoding supplied by the higher level
protocol.

It is a TAG recommendation that the XML parser must not override the
encoding supplied by the higher level protocol in this case. So you
are just about OK. The normal thing for an XML parser to do would be
to report an error in this case, but that is not required by an spec.

-- 
Colin Adams
Picking nits off the nits
Preston Lancashire

Re: [gobo-eiffel-develop] Problem with DS_HASH_TABLE

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

>>>>> "Paul" == Paul G Crismer <pau...@sc...> writes:

    Paul> Hello, I have a problem with DS_HASH_TABLE.  A precondition
    Paul> violation in 'clashes_put'.

Hi Paul,

Maybe you have an issue where a STRING isn't cloned and overwritten
while adding things?

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Problem with DS_HASH_TABLE

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

Paul G. Crismer wrote:
> I have a problem with DS_HASH_TABLE.  A precondition violation in 
> 'clashes_put'.

Hi Paul,

Did you get a precondition violation on DS_HASH_TABLE.put after
following Ted's suggestion to enable Supplier Precondition in
the configuration?

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

Re: [gobo-eiffel-develop] Problem with DS_HASH_TABLE

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

Paul G. Crismer wrote:
> I have a problem with DS_HASH_TABLE.  A precondition violation in 
> 'clashes_put'.
> 
> Class / Object      Routine                Nature of exception           Effect
> -------------------------------------------------------------------------------
> DS_HASH_TABLE       clashes_put @12        index_small_enough:          
> <000000000B20FEF8>  (From DS_ARRAYED_SPARSE_TABLE)
>                                            Runtime check violated.       Fail
> -------------------------------------------------------------------------------
> DS_HASH_TABLE       clashes_put @3                                      
> <000000000B20FEF8>  (From DS_ARRAYED_SPARSE_TABLE)
>                                            Routine failure.              Fail
> -------------------------------------------------------------------------------
> DS_HASH_TABLE       put @12                                             
> <000000000B20FEF8>  (From DS_SPARSE_TABLE) Routine failure.              Fail
> -------------------------------------------------------------------------------
> 
> How does it come?  Before putting the new element we check the table is 
> not full.
> Is there a known problem with DS_HASH_TABLE?

There is no known problem.
Can you reproduce the bug on a small example?

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