gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Postcondition failure in {DS_HASH_TABLE}.search_position

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

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

    Eric> There are two reasons why you could get a postcondition
    Eric> violation in this routine. Either this routine (or its
    Eric> postcondition) has a bug, or your hash table contains
    Eric> mutable keys whose comparison criterion or hash code has
    Eric> changed since it was first inserted.

I've thought of another possibility.
The items are datetimes in different time zones.
It may be that I have two items that compare equal, but their hash
codes are not equal.

I'll check on this tomorrow.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Postcondition failure in {DS_HASH_TABLE}.search_position

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

Colin Paul Adams wrote:
> While testing gexslt, I've come across a postcondition violation in
> this routine. I tried debugging it, but I couldn't work out why the
> problem was occurring.

There are two reasons why you could get a postcondition violation
in this routine. Either this routine (or its postcondition) has a
bug, or your hash table contains mutable keys whose comparison
criterion or hash code has changed since it was first inserted.

> So I've checked in the code, hoping that you can work out what is
> wrong.
> 
> The following command line will reproduce the problem:
> 
> gexslt group021.xsl group021.xml

OK, I will have a look.

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

[gobo-eiffel-develop] Postcondition failure in {DS_HASH_TABLE}.search_position

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

Hello Eric,

While testing gexslt, I've come across a postcondition violation in
this routine. I tried debugging it, but I couldn't work out why the
problem was occurring.

So I've checked in the code, hoping that you can work out what is
wrong.

The following command line will reproduce the problem:

gexslt group021.xsl group021.xml

I will send the two xml files needed for this to you by private email,
as they are from the W3C suite, and so I should not post them on a
public mailing list.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Undefined reference when compiling with gec

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

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

    Eric> Colin Paul Adams wrote:
    >> I'm doing a big re-factoring.
    >> 
    >> I ran the xpath test suite fine with ise and se, but with ge I
    >> get:
    >> 
    >> xpath.o: In function `T1021f1':xpath.c:(.text+0x226b8a):
    >> undefined reference to `is_dotnet' collect2: ld returned 1 exit
    >> status

    Eric> It's hard to tell what's wrong without having the code to
    Eric> reprodude this problem.

    Eric> Also, did you recompile gec recently? If not, you should try
    Eric> that first.

That does the trick.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Undefined reference when compiling with gec

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

Colin Paul Adams wrote:
> I'm doing a big re-factoring.
> 
> I ran the xpath test suite fine with ise and se, but with ge I get:
> 
> xpath.o: In function `T1021f1':xpath.c:(.text+0x226b8a): undefined reference to `is_dotnet'
> collect2: ld returned 1 exit status

It's hard to tell what's wrong without having the code
to reprodude this problem.

Also, did you recompile gec recently? If not, you should
try that first.

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

[gobo-eiffel-develop] Undefined reference when compiling with gec

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

I'm doing a big re-factoring.

I ran the xpath test suite fine with ise and se, but with ge I get:

xpath.o: In function `T1021f1':xpath.c:(.text+0x226b8a): undefined reference to `is_dotnet'
collect2: ld returned 1 exit status

-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Gobo binaries linked against glibc 2.4

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

Patrick Ruckstuhl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
>> I think there is very little use in providing pre-compiled binaries
>>  anyway, as the bootstrap procedure is so straight forward and
>> Linux libraries are ever-changing. ;-) Perhaps we should add some
>> hint on how to do it onto the project homepage.
> I think the files for the bootstrap are not even in the tar file, at
> least there's no work directory, so it would be good if this were in
> the releases.

They are not needed (if you are not using gec). You can just compile 
(using you favorite Eiffel compiler) each tool in the subdirectories
of $GOBO/src as indicated in the Readme.txt file. It's true that there
is no script yet to do that automatically.

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

Re: [gobo-eiffel-develop] Gobo binaries linked against glibc 2.4

[Patrick R. <pa...@ta...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
> I think there is very little use in providing pre-compiled binaries
>  anyway, as the bootstrap procedure is so straight forward and
> Linux libraries are ever-changing. ;-) Perhaps we should add some
> hint on how to do it onto the project homepage.
I think the files for the bootstrap are not even in the tar file, at
least there's no work directory, so it would be good if this were in
the releases.

Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGG+xtaA/ofYi4EMoRAv8HAKCZH4zlPYLmUbjpD1OXYG/NuyoSIgCfSSsx
7Gn82k/1UEuq6VEIeJC05x8=
=PVeY
-----END PGP SIGNATURE-----

Re: [gobo-eiffel-develop] Gobo binaries linked against glibc 2.4

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

On Tue, 10 Apr 2007 16:13:42 +0200, Patrick Ruckstuhl <pa...@ta...>  
wrote:

> Hi,
>
> in the Linux download of gobo, the binaries are linked against glibc
> 2.4, in a lot of distributions this is not yet available. Would it be
> possible to either compile the binaries statically or to link against an
> older version of the glibc?
>
> Thanks and regards,
> Patrick

I think there is very little use in providing pre-compiled binaries  
anyway, as the bootstrap procedure is so straight forward and Linux  
libraries are ever-changing. ;-) Perhaps we should add some hint on how to  
do it onto the project homepage.

Bernd

[gobo-eiffel-develop] Gobo binaries linked against glibc 2.4

[Patrick R. <pa...@ta...>]

Hi,

in the Linux download of gobo, the binaries are linked against glibc
2.4, in a lot of distributions this is not yet available. Would it be
possible to either compile the binaries statically or to link against an
older version of the glibc?

Thanks and regards,
Patrick

Re: [gobo-eiffel-develop] Precompiled geant.c in gobo-3.5 tag

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

Bernd Schoeller wrote:
> On Mon, 02 Apr 2007 18:06:26 +0200, Eric Bezault <er...@go...> 
> wrote:
> 
>> Bernd Schoeller wrote:
>>> would it be possible to update the precompiled geant.c file in the  
>>> 'tags/gobo-3.5' branch? It currently is still from gobo 3.4.
>>
>> I'm reluctant to do that because tags/gobo-3.5 is meant to be
>> a tag, not a branch.
> 
> Ok. Didn't know what the policy about tagging in GOBO was.

I'm just using Subversion's convension: "tags" means tags,
"branches" means branches ;-)

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

Re: [gobo-eiffel-develop] Precompiled geant.c in gobo-3.5 tag

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

On Mon, 02 Apr 2007 18:06:26 +0200, Eric Bezault <er...@go...>  
wrote:

> Bernd Schoeller wrote:
>> would it be possible to update the precompiled geant.c file in the   
>> 'tags/gobo-3.5' branch? It currently is still from gobo 3.4.
>
> I'm reluctant to do that because tags/gobo-3.5 is meant to be
> a tag, not a branch.

Ok. Didn't know what the policy about tagging in GOBO was.

>> This would making bootstrapping the automated build scripts for   
>> EiffelStudio easier, as some of them rely on geant features introduced  
>> by  gobo-3.5.
>
> Why don't you use tags/gobo-3.5/work/bootstrap/bootstrap.(sh|bat)
> to get the Gobo 3.5 binaries? geant.c and the other C files in
> there were never meant to be used other than through these bootstrap
> scripts.

Yes, in can understand your PoV. I was somehow expecting such an answer ;-)

I will try to find another way to do what I was planing to do. The current  
EiffelStudio tree does not require a proper bootstrap of GOBO, the  
'generated' stuff is checked in (not that I ever liked that ... *sigh*). I  
will probably still enforce proper bootstrapping of GOBO, though it takes  
a little longer, ignoring the pre-generated code.

Bernd

Re: [gobo-eiffel-develop] Precompiled geant.c in gobo-3.5 tag

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

Bernd Schoeller wrote:
> would it be possible to update the precompiled geant.c file in the  
> 'tags/gobo-3.5' branch? It currently is still from gobo 3.4.

I'm reluctant to do that because tags/gobo-3.5 is meant to be
a tag, not a branch.

> This would making bootstrapping the automated build scripts for  
> EiffelStudio easier, as some of them rely on geant features introduced by  
> gobo-3.5.

Why don't you use tags/gobo-3.5/work/bootstrap/bootstrap.(sh|bat)
to get the Gobo 3.5 binaries? geant.c and the other C files in
there were never meant to be used other than through these bootstrap
scripts.

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

[gobo-eiffel-develop] Precompiled geant.c in gobo-3.5 tag

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

Hi,

would it be possible to update the precompiled geant.c file in the  
'tags/gobo-3.5' branch? It currently is still from gobo 3.4.

This would making bootstrapping the automated build scripts for  
EiffelStudio easier, as some of them rely on geant features introduced by  
gobo-3.5.

Bernd

Re: [gobo-eiffel-develop] Problem when compiling XM_XPATH_MACHINE_INTEGER_VALUE with SE 1.2r7

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

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

    Eric> ------ ****** Error: Current type is STRING. There is no
    Eric> feature to_integer_64 in class STRING.  Line 49 column 21 in
    Eric> XM_XPATH_MACHINE_INTEGER_VALUE
    Eric> (C:\DriveE\gobo\gobo\library\xml\xpath\value\xm_xpath_machine_integer_value.e)
    Eric> :
    Eric> 			value := a_value.to_integer_64 ^
    Eric> ------ ****** Fatal Error: Feature "to_integer_64" not
    Eric> found.  Line 49 column 21 in XM_XPATH_MACHINE_INTEGER_VALUE
    Eric> (C:\DriveE\gobo\gobo\library\xml\xpath\value\xm_xpath_machine_integer_value.e)
    Eric> :
    Eric> 			value := a_value.to_integer_64 ^
    Eric> ------

I'm removing this routine locally, as it has no callers in
integration. I may not be able to check-in this weekend though.
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] Problem when compiling XM_XPATH_MACHINE_INTEGER_VALUE with SE 1.2r7

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

------
****** Error: Current type is STRING. There is no feature to_integer_64
in class STRING.
Line 49 column 21 in XM_XPATH_MACHINE_INTEGER_VALUE 
(C:\DriveE\gobo\gobo\library\xml\xpath\value\xm_xpath_machine_integer_value.e) 
:
			value := a_value.to_integer_64
			                 ^
------
****** Fatal Error: Feature "to_integer_64" not found.
Line 49 column 21 in XM_XPATH_MACHINE_INTEGER_VALUE 
(C:\DriveE\gobo\gobo\library\xml\xpath\value\xm_xpath_machine_integer_value.e) 
:
			value := a_value.to_integer_64
			                 ^
------

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

Re: [gobo-eiffel-develop] [Es-devel] .NET namespace configuration

[Emmanuel S. [ES] <ma...@ei...>]

> So I think the current state of gobo.ecf is fine, with two changes:
> 1. <option namespace="Gobo.Library"/>
> 2. Drop the "gobo_" prefixes.

For the moment, I've done that. Let us know if something else is needed.

Thanks,
Manu

Re: [gobo-eiffel-develop] [Es-devel] .NET namespace configuration

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

Emmanuel Stapf [ES] wrote:
>> Our non-Eiffel code will break when we move to 6.0, but the 
>> fix is an easy, one-off search-and-replace operation. A few 
>> class names changed already in 5.7. (Speaking of which, I'm 
>> using an ugly override-and-alias hack to rename
>> STRING_8 and INTEGER_32 back to STRING and INTEGER for our 
>> non-Eiffel consumers. Does 6.0 allow us to do this purely 
>> within the ECF?)
> 
> Unfortunately it does not. This would go against the above principle that says
> that a library is fully in control of its namespace.
>  
>> My only quibble with your proposal is the name 
>> EiffelSoftware.Library. I would have expected:
>>     EiffelSoftware.Base
>>     EiffelSoftware.Vision
>>     EiffelSoftware.Wel
> 
> See Paul's anser on the subject.
> 
>> Yes, gobo.ecf specifies the EiffelSoftware.Library namespace!
> 
> This is the result of a blind addition of namespace to all our ECFs. I'll check
> with Eric what he would like.

I'm not a .NET user, so I don't have an opinion.
Perhaps people on the Gobo mailing lists have one.
The context of this discussion is here:

  http://www.nabble.com/.NET-namespace-configuration-tf3428939.html

and namespace suggested by Manu for the Gobo libraries is
Gobosoft.Library.Gobo.

We should perhaps take into account that Gobo is not just
one library, despite what the gobo.ecf file provided by ISE
may tend to imply. And Gobosoft is an artifact to get a
domain name because gobo.com/gobo.org were already used.
So what about:

    Gobo.Library.Structure
    Gobo.Library.XML
    Gobo.Library.Time
    ...

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

Re: [gobo-eiffel-develop] File URI resolution

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

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

    Colin> I shall try to find the time to repeat the tests on
    Colin> Windows.

The name looks right on Windows, and the test fails.

The drive is NTFS.

I don't know how to find out any other relevant information. There are
no environment variables that look relevant. I assume the file-name
encoding must be ISO-8859-1, but I thought a windows NTFS system would
be using UTF-16.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] File URI resolution

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

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

    Colin> xgespr%C3%A4ch.xml

    Colin> The percent encoding equates to lower case a-umlaut.

    Colin> Now on my linux system, file name encoding is UTF-8 (I
    Colin> think), but the file supplied with the test suite exists on
    Colin> my system with the a-umlaut as a Latin-1 character. I am
    Colin> not sure if this is a bug with the unzip command, or what
    Colin> (in fact, I am very unsure about everything to do with this
    Colin> - the one thing I am certain about is that the percent
    Colin> encoding MUST be interpreted as UTF-8, and the file name
    Colin> decoded accordingly).

    Colin> Not surprsingly, the test fails on my system.

    Colin> But I begin to wonder if the test would not also have
    Colin> failed if the file name were correct as a UTF-8 file name.

    Colin> The resolver uses UT_FILE_URI_ROUTINES, whichj in turn make
    Colin> use of

    Colin> file_system.pathname_to_string (uri_to_pathname (a_uri))

    Colin> As far as I can tell, the net result of this is to pass a
    Colin> UTF-8 byte string to the Eiffel runtime as a
    Colin> STRING/STRING_8.

    Colin> I suspect the runtime expects a Latin-1 name, but I don't
    Colin> know.  What about on a windows system with the file system
    Colin> using UTF-16.

I tried some experimenting.

Changing the LANG env. var. on my system from en_GB.UTF-8 to en_GB,
and then unzipping the distribution afresh didn't help.

So Instead I renamed the file to give it its proper Unicode name (in
UTF-8).
Now the test works on Linux.

This confirms that the byte-sequence is being passed straight to
fopen, and apparently fopen isn't doing any translations with it.

I shall try to find the time to repeat the tests on Windows.

Does anyone have a Linux system where ISO-8859-1 is the standard
encoding? If so, perhaps we can try the test there. But I bet it
fails.

It looks like we can't do any better within Gobo though.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Possible bug iinXM_DEFAULT_ATTRIBUTE_FILTER

[Colin A. <col...@ho...>]

>From: "Franck Arnaud" <fr...@ne...>

> > > It looks like XM_DEFAULT_ATTRIBUTE_FILTER is at fault.
> >
> > I have been able to reproduce the problem. I couldn't figure out why yet
> > (the filter is not really namespace aware!), perhaps some aliasing
> > issue, will investigate further.
>
>the fix is now checked in. it was simpler, a typo caused the filter to
>never work in the presence of prefixes.

Confirmed that it fixes all the problems I had.

_________________________________________________________________
MSN Hotmail is evolving - check out the new Windows Live Mail 
http://ideas.live.co.uk

Re: [gobo-eiffel-develop] Possible bug iin XM_DEFAULT_ATTRIBUTE_FILTER

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

> > It looks like XM_DEFAULT_ATTRIBUTE_FILTER is at fault.
> 
> I have been able to reproduce the problem. I couldn't figure out why yet
> (the filter is not really namespace aware!), perhaps some aliasing
> issue, will investigate further.

the fix is now checked in. it was simpler, a typo caused the filter to
never work in the presence of prefixes.

Re: [gobo-eiffel-develop] Cannot reuse RX_PCRE_REGULAR_EXPRESSION instance

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

Jason Wei [ES] wrote:
> Thanks for the answer.
> But why is_anchored is not affected even by `reset'? (or does it belong 
> to an option such as caseless?)

Yes, it's like caseless, that's what I meant by option.

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

Re: [gobo-eiffel-develop] Cannot reuse RX_PCRE_REGULAR_EXPRESSION instance

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

"Jason Wei [ES]" <ja...@ei...> wrote:
> I created an RX_PCRE_REGULAR_EXPRESSION object for regular expression 
> matching.
> And I have setup options I need.
> 
> I used it to do a first match using keyword *"a*"*, I got the right result.
> I used it to do a second match using keyword *"^a*"*, I got the right 
> result again. (Of course, I called `compile (keyword)' everytime).
> Now I used it to do a third match using the keyword *"a*"* again over 
> the same context, then I got different result from the first match.
> 
> During these three tries, I don't change any options, so I think I don't 
> need to call `reset'. But even if I called `reset' every time, I got 
> different results.
> 
> And I provided a small application to show this problem. Just run this 
> application which check enabled and observe the assertion violation.
> 
> It there anything else that I need to do to make it work?

There are two ways to tell the regexp to match from the
start: either put the character '^' at the beginning of
the regexp:

    regexp.compile ("^a*")

or set the option `is_anchored':

    regexp.set_anchored (True)
    regexp.compile ("a*")

In both cases `is_anchored' is set to True. If later on
you want the regexp to match anywhere in the string, you
have to unset `is_anchored':

    regexp.set_anchored (False)
    regexp.compile ("a*")

So, in your example:

    l_filter := filter_engine
    l_filter.set_anchored (False)
    l_filter.reset
    l_filter.compile (a_keyword)

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

Re: [gobo-eiffel-develop] Cannot reuse RX_PCRE_REGULAR_EXPRESSION instance

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

"Jason Wei [ES]" <ja...@ei...> wrote:
> I created an RX_PCRE_REGULAR_EXPRESSION object for regular expression 
> matching.
> And I have setup options I need.
> 
> I used it to do a first match using keyword *"a*"*, I got the right result.
> I used it to do a second match using keyword *"^a*"*, I got the right 
> result again. (Of course, I called `compile (keyword)' everytime).
> Now I used it to do a third match using the keyword *"a*"* again over 
> the same context, then I got different result from the first match.
> 
> During these three tries, I don't change any options, so I think I don't 
> need to call `reset'. But even if I called `reset' every time, I got 
> different results.
> 
> And I provided a small application to show this problem. Just run this 
> application which check enabled and observe the assertion violation.

I cannot read you .rar file. Can you send your example using
another format?

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