gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Usage of INTEGER_64

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

Colin Paul Adams wrote:
> Then the question is under what circumstances should `is_integer_64'
> return True?
> One answer that is inconsistent with your desired post-condition would
> be an Eiffel INTEGER_64 literal (as it might contain
> underscores). Likewise it can't contain a leading negative sign. 

That's true I forgot about that.

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

Re: [gobo-eiffel-develop] Usage of INTEGER_64

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

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

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    Eric> I had a look at the routines `is_integer_64' and
    Eric> `to_integer_64' in class KL_STRING_ROUTINES. And there are
    Eric> two things that I don't like. The first thing is that they
    Eric> create too many temporary objects (calling `substring',
    Eric> creating manifest arrays).
    >> Yes. I wasn't happy with that myself.
    Eric> The second thing that I don't like is the precondition
    Eric> "is_integer". I don't think that it is a good idea to have
    Eric> to write: is_integer (s) and then is_integer_64 (s)
    >> Well I thought about that.  And I thought about the use case I
    >> have, which is parsing numbers. The tokenizer has already
    >> created tokens one of which is certified to consist entirely of
    >> decimal digits (there may be a preceding token consisting of a
    >> minus sign).  In this use case the pre-condition "is_integer"
    >> is guarenteed true.  So I tried to think about other use cases
    >> for "is_integer_64". All I could think of was parsing, and I
    >> presumed therefore that the pre-condition would always be
    >> satisfied.

    Eric> I think that this assumption is too strong for a general
    Eric> purpose library class like KL_STRING_ROUTINE. It would have
    Eric> been OK if this routine was part of your parsing class, but
    Eric> here with KL_STRING_ROUTINE we cannot make such an
    Eric> assumption.

Then the question is under what circumstances should `is_integer_64'
return True?
One answer that is inconsistent with your desired post-condition would
be an Eiffel INTEGER_64 literal (as it might contain
underscores). Likewise it can't contain a leading negative sign. I
still don't see any other uses for it.

In any case, I don't want to be using a routine that is doing the
additional checks, so I think it might be best if I simply remove
these routines, and add my own local routines to the XPath parser.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Usage of INTEGER_64

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

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

    Eric> We could also have a feature:

    Eric>      maximum_integer_64: INTEGER_64

    Eric> in class KL_PLATFORM. This latter solution would probably be
    Eric> better.

I've done this.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Regular expression syntax

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

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

    Eric> UTF-8 byte representation? Even if it's a multibyte, you can
    Eric> replace [\i:] by (multibyte1|...|multibyten|:) and likewise
    Eric> for similar regexp constructs.

While that is possible, I think the resultant string for \i, \c and
similar properties will be of the order of 20KB.

I don't know how the regular expression engine works, but if it needs
to compare a space character (for instance) with each of 20000
characters in order to reject a test, I think it will be far too inefficient.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Regular expression syntax

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

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

    Eric> I must confess that I don't know what you are talking about
    Eric> with "these kind of tests". Are you talking about \i and \c?

Yes.
And also the more general \p{property_name}.

Assuming we could implement it in the first place (I don't see how
that could be done by translation, so it would have to be an extension).
Suppose property_name is Upper_Case. Then because we are matching
against the UTF-8 byte-stream, the engine would produce matches based
on whether or not the individual bytes were upper-case in the Latin-1
character set, rather than if the Unicode characters were upper case.

For an extreme example, imagine a propery Is_Latin_1 (I don't think
there is such a property, but it#s a nice example). The engine will
then match the entire string for any input whatsoever!

-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Regular expression syntax

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

Colin Paul Adams wrote:
>     Eric> I think that would have to write a preparser that would
>     Eric> translate XPath regular expressions into PCRE regular
>     Eric> expressions.
> 
> I don't think it can work, because the trick of using the UTF-8 byte
> representation will fail in these kind of tests.

I must confess that I don't know what you are talking
about with "these kind of tests". Are you talking about
\i and \c? What does "all initial name characters and
all name characters" mean? To what extent wouldn't that
work with the UTF-8 byte representation? Even if it's
a multibyte, you can replace [\i:] by
(multibyte1|...|multibyten|:) and likewise for similar
regexp constructs.

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

Re: [gobo-eiffel-develop] Regular expression syntax

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

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

    Eric> I wrote the following test and it works:

    Eric> 	test_compile1 is -- Test feature 'compile'.  local
    Eric> a_regexp: RX_PCRE_REGULAR_EXPRESSION do create a_regexp.make
    Eric> a_regexp.compile ("^[abc]*$") assert ("compiled1",
    Eric> a_regexp.is_compiled) assert ("recognizes1",
    Eric> a_regexp.recognizes ("aaabbbccc")) assert
    Eric> ("not_recognizes1", not a_regexp.recognizes
    Eric> ("aaabbbcccddd")) end

    Eric> So I don't know why it would not work for you.

Strange. I shall have to investigate further.

    Eric> I think that would have to write a preparser that would
    Eric> translate XPath regular expressions into PCRE regular
    Eric> expressions.

I don't think it can work, because the trick of using the UTF-8 byte
representation will fail in these kind of tests.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Regular expression syntax

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

Colin Paul Adams wrote:
> Does anyone know the details of the regular expression syntax matched
> by class RX_PCRE_REGULAR_EXPRESSION?
> 
> It's baffling me.
> 
> For instance, the following regular expression:
> 
> ^[abc]*$
> 
> fails to compile, but
> 
> ^[abc]*
> 
> compiles OK.

I wrote the following test and it works:

	test_compile1 is
			-- Test feature 'compile'.
		local
			a_regexp: RX_PCRE_REGULAR_EXPRESSION
		do
			create a_regexp.make
			a_regexp.compile ("^[abc]*$")
			assert ("compiled1", a_regexp.is_compiled)
			assert ("recognizes1", a_regexp.recognizes ("aaabbbccc"))
			assert ("not_recognizes1", not a_regexp.recognizes ("aaabbbcccddd"))
		end

So I don't know why it would not work for you.

> I don't have great hopes of trying to get this to compile:
> 
> ^[\i-[:]][\c-[:]]*$
> 
> (that's XPath regular expression syntax, derived from XML Schema - \i
> and \c are all initial name characters and all name characters
> respectively.)

I think that would have to write a preparser that would
translate XPath regular expressions into PCRE regular
expressions.

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

[gobo-eiffel-develop] XML Inclusions

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

Erik Wilde (dr...@be...) has written an XSLT 2.0 transformation
for performing XInclude processing. Google for xipr.xsl.

It is therefore now possible (with certain limitations) to perform
XInclude processing within Gobo.

To do so, first create a transformation called xinclude.xsl like this:

<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">

 <xsl:include href="xipr.xsl"/>

 <xsl:template match="/">
  <xsl:apply-templates select="." mode="xipr"/>
 </xsl:template>

</xsl:transform>

Then from the command line:

gexslt xinclude.xsl my.xml

(or the equivalent from within an Eiffel program).

The output will be a copy of my.xml with all XInclude actions
performed.

This could be useful with geant scripts, for instance, or as a goanna
servlet, perhaps.

Limitations:

The accept and accept-language attributes are not supported (this is
not possible from XSLT).

Only shorthand and element() xpointers are supported (minimal conformance).

Additional gobo limitations:

Parse=text processing is currently only supported for UTF-8 (and
therefore ASCII). ACTION: Franck
Likewise, parse=xml is restricted to those encodings currently
supported by the Gobo Eiffel XML parser (UTF-8, UTF-16, ISO8859-1 and
US-ASCII if my memory serves me).

If the xpointer attribute is present, then gexslt will throw an error
due to the limitations of the Gobo PCRE regular expression library (it
does not understand Unicode character classes/properties). I think it
will not be possible to patch this, and so a new, Unicode-aware,
regular expression engine is needed. ACTION: Any takers?

It may be possible to get around this by patching xipr.xsl - simply
remove the matches (@xpointer, ...) tests. This will mean that bad
xpointers will slip through, causes spurious crashes, but it should
work for good ones.
Better would be to replace the matches (@xpointer, ...) function calls
with other, more cumbersome, regular expressions, that have the same
effect, or a specially written xsl:function to check the syntax
without using regular expressions.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] SE assertion checking more greedy

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

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

    Eric> When using SE 1.2r7 with assertions turned on I get the
    Eric> following errors:

These are all fixed now.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] SE assertion checking more greedy

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

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

    Eric> SE is not good at displaying the exception trace when going
    Eric> through a rescue clause. You can try to comment out the
    Eric> rescue clause. The exception trace will probably be more
    Eric> meaningful.

That proved to be useful. Thanks.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Usage of INTEGER_64

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> I had a look at the routines `is_integer_64' and
>     Eric> `to_integer_64' in class KL_STRING_ROUTINES. And there are
>     Eric> two things that I don't like. The first thing is that they
>     Eric> create too many temporary objects (calling `substring',
>     Eric> creating manifest arrays).
> 
> Yes. I wasn't happy with that myself.
> 
>     Eric> The second thing that I don't
>     Eric> like is the precondition "is_integer". I don't think that it
>     Eric> is a good idea to have to write:
> 
>     Eric>     is_integer (s) and then is_integer_64 (s)
> 
> Well I thought about that.
> And I thought about the use case I have, which is parsing
> numbers. The tokenizer has already created tokens one of which is
> certified to consist entirely of decimal digits (there may be a
> preceding token consisting of a minus sign).
> In this use case the pre-condition "is_integer" is guarenteed true.
> 
> So I tried to think about other use cases for "is_integer_64". All I
> could think of was parsing, and I presumed therefore that the
> pre-condition would always be satisfied.

I think that this assumption is too strong for a general
purpose library class like KL_STRING_ROUTINE. It would
have been OK if this routine was part of your parsing class,
but here with KL_STRING_ROUTINE we cannot make such an
assumption.

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

[gobo-eiffel-develop] Regular expression syntax

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

Does anyone know the details of the regular expression syntax matched
by class RX_PCRE_REGULAR_EXPRESSION?

It's baffling me.

For instance, the following regular expression:

^[abc]*$

fails to compile, but

^[abc]*

compiles OK.

I don't have great hopes of trying to get this to compile:

^[\i-[:]][\c-[:]]*$

(that's XPath regular expression syntax, derived from XML Schema - \i
and \c are all initial name characters and all name characters
respectively.)

No doubt it could be done, but without understanding what is supposed
to be accepted in the first place, it's a daunting task.
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] File URIs

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

It appears that my correction to
{UT_FILE_URI_ROUTINES}.pathname_to_uri on 20061221 was only partly
correct. It now produces file URIs of the form:

file:/home/colin/...

instead of the former result:

file://localhost/home/colin/...

Neither is canonical. The correct form is:

file:///home/colin/...

The current form is consistent with what is produced by Java, but this
does not make it correct. So I am changing the routine to now look
like this:

                        if a_pathname.is_relative then
				create Result.make_relative
				check no_hostname_when_relative: a_pathname.hostname = Void end
			else
				create Result.make_absolute (File_scheme)
				if a_pathname.hostname /= Void then
					Result.set_authority (hostname_to_authority (a_pathname.hostname))
					-- removed for correct canonization - CPA - 20061221: else
					--	Result.set_authority (hostname_to_authority (Localhost_authority))
				else
					-- added for correct canonization - CPA - 20070203:
					Result.set_authority (hostname_to_authority (""))
				end
			end
etc.


-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Usage of INTEGER_64

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

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

    Eric> I had a look at the routines `is_integer_64' and
    Eric> `to_integer_64' in class KL_STRING_ROUTINES. And there are
    Eric> two things that I don't like. The first thing is that they
    Eric> create too many temporary objects (calling `substring',
    Eric> creating manifest arrays).

Yes. I wasn't happy with that myself.

    Eric> The second thing that I don't
    Eric> like is the precondition "is_integer". I don't think that it
    Eric> is a good idea to have to write:

    Eric>     is_integer (s) and then is_integer_64 (s)

Well I thought about that.
And I thought about the use case I have, which is parsing
numbers. The tokenizer has already created tokens one of which is
certified to consist entirely of decimal digits (there may be a
preceding token consisting of a minus sign).
In this use case the pre-condition "is_integer" is guarenteed true.

So I tried to think about other use cases for "is_integer_64". All I
could think of was parsing, and I presumed therefore that the
pre-condition would always be satisfied.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Usage of INTEGER_64

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> We drop VE completely. If it's not for INTEGER_64, it will
>     Eric> be for Agents/Tuples. So let's drop it now.
> 
> OK.
> 
> There appears to be a problem with gec.
> 
> I have the following tests, which se and ise (5.7) pass:
> 
> 	test_is_integer_64 is
> 			-- Test feature `is_integer_64'.
> 		local
> 			uc_string: UC_UTF8_STRING
> 		do
> 			assert ("is_integer_64_1", STRING_.is_integer_64 ("1234"))
> 			assert ("is_integer_64_2", STRING_.is_integer_64 ("00078"))
> 			create uc_string.make_from_string ("4534")
> 			assert ("is_integer_64_3", STRING_.is_integer_64 (uc_string))
> 			assert ("is_integer_64_4", STRING_.is_integer_64 ("9223372036854775807"))
> 			assert ("is_integer_64_5", STRING_.is_integer_64 ("00000000009223372036854775807"))
> 			assert ("not_is_integer_64_1", not STRING_.is_integer_64 ("9223372036854775808"))
> 			assert ("not_is_integer_64_2", not STRING_.is_integer_64 ("10223372036854775807"))
> 			assert ("not_is_integer_64_1", not STRING_.is_integer_64 ("00019223372136854775807"))
> 		end
> 
> 	test_to_integer_64 is
> 			-- Test feature `to_integer_64'.
> 		local
> 			uc_string: UC_UTF8_STRING
> 		do
> 			assert_equal ("to_integer_64_1", (1234).to_integer_64, STRING_.to_integer_64 ("1234"))
> 			assert_equal ("to_integer_64_2", (78).to_integer_64, STRING_.to_integer_64 ("00078"))
> 			create uc_string.make_from_string ("4534")
> 			assert_equal ("to_integer_64_3", (4534).to_integer_64, STRING_.to_integer_64 (uc_string))
> 			assert_equal ("to_integer_64_4", (9223372036854775807).to_integer_64, STRING_.to_integer_64 ("9223372036854775807"))
> 			assert_equal ("to_integer_64_5", (9223372036854775807).to_integer_64, STRING_.to_integer_64 ("00000000009223372036854775807"))
> 		end
> 
> Gec fails one:
> 
> Test Results:
> FAIL:  [KL_TEST_STRING_ROUTINES.test_to_integer_64] to_integer_64_4
>    expected: -1
>    but  got: 9223372036854775807
> 
> so it looks like GEC's built-in {INTEGER}.to_integer_64 is off by one
> on the edge case.

This might be surprising at first, but the other compilers are wrong.
According to ECMA Eiffel, the number 9223372036854775807 in
(9223372036854775807).to_integer_64 is of type INTEGER. Therefore
this cannot work. The problem with GEC (and with the other compilers)
is that it should have reported an error at compile time.

The ECMA way to do it is:

       {INTEGER_64} 9223372036854775807

but this won't work with SE I think.

Note that I'm surprised that `assert_equal' in your test above works
with SE. It accepts ANY as arguments and in SE expanded types (such
as INTEGER_64) don't conform to ANY. That's why we introduced
`assert_integers_equal', `assert_characters_equal', etc. Or do
SE 1.2 and 2.* have a different behavior with this respect?

One way (which is not 100% ECMA compliant but would work with
all Eiffel compilers would be to introduce a routine
`assert_integer_64_equal' and write:

assert_integer_64_equal ("to_integer_64_4", 9223372036854775807, 
STRING_.to_integer_64 ("9223372036854775807"))

Here it works because the compilers know that the expected type
for 9223372036854775807 (the type of the formal argument of
the routine) is INTEGER_64. Likewise, this would work:

   i64: INTEGER_64
   ...
   i64 := 9223372036854775807
   assert_equal ("to_integer_64_4", i64, STRING_.to_integer_64 
("9223372036854775807"))

We could also have a feature:

     maximum_integer_64: INTEGER_64

in class KL_PLATFORM. This latter solution would probably be better.


I had a look at the routines `is_integer_64' and `to_integer_64'
in class KL_STRING_ROUTINES. And there are two things that I don't
like. The first thing is that they create too many temporary
objects (calling `substring', creating manifest arrays). I know
that Eiffel is a language equipped with GC, but the less work we
give to the GC, the faster the program will run. The second thing
that I don't like is the precondition "is_integer". I don't think
that it is a good idea to have to write:

    is_integer (s) and then is_integer_64 (s)

On the other hand "is_integer" should be a postcondition of
`is_integer_64':

    Result implies is_integer (a_string)

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

Re: [gobo-eiffel-develop] Usage of INTEGER_64

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

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

    Eric> We drop VE completely. If it's not for INTEGER_64, it will
    Eric> be for Agents/Tuples. So let's drop it now.

OK.

There appears to be a problem with gec.

I have the following tests, which se and ise (5.7) pass:

	test_is_integer_64 is
			-- Test feature `is_integer_64'.
		local
			uc_string: UC_UTF8_STRING
		do
			assert ("is_integer_64_1", STRING_.is_integer_64 ("1234"))
			assert ("is_integer_64_2", STRING_.is_integer_64 ("00078"))
			create uc_string.make_from_string ("4534")
			assert ("is_integer_64_3", STRING_.is_integer_64 (uc_string))
			assert ("is_integer_64_4", STRING_.is_integer_64 ("9223372036854775807"))
			assert ("is_integer_64_5", STRING_.is_integer_64 ("00000000009223372036854775807"))
			assert ("not_is_integer_64_1", not STRING_.is_integer_64 ("9223372036854775808"))
			assert ("not_is_integer_64_2", not STRING_.is_integer_64 ("10223372036854775807"))
			assert ("not_is_integer_64_1", not STRING_.is_integer_64 ("00019223372136854775807"))
		end

	test_to_integer_64 is
			-- Test feature `to_integer_64'.
		local
			uc_string: UC_UTF8_STRING
		do
			assert_equal ("to_integer_64_1", (1234).to_integer_64, STRING_.to_integer_64 ("1234"))
			assert_equal ("to_integer_64_2", (78).to_integer_64, STRING_.to_integer_64 ("00078"))
			create uc_string.make_from_string ("4534")
			assert_equal ("to_integer_64_3", (4534).to_integer_64, STRING_.to_integer_64 (uc_string))
			assert_equal ("to_integer_64_4", (9223372036854775807).to_integer_64, STRING_.to_integer_64 ("9223372036854775807"))
			assert_equal ("to_integer_64_5", (9223372036854775807).to_integer_64, STRING_.to_integer_64 ("00000000009223372036854775807"))
		end

Gec fails one:

Test Results:
FAIL:  [KL_TEST_STRING_ROUTINES.test_to_integer_64] to_integer_64_4
   expected: -1
   but  got: 9223372036854775807

so it looks like GEC's built-in {INTEGER}.to_integer_64 is off by one
on the edge case.

-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Usage of INTEGER_64

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

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> 
>     Eric> Colin Paul Adams wrote:
>     >>> So I need permission to start using INTEGER_64.
> 
>     Eric> OK. If I remember correctly this will rule out VE, but it
>     Eric> should be OK with the other compilers.
> 
>     Colin> SE fails to compile it as I am
>     Colin> using {STRING}.is_integer_64, which SE 1.2r7 doesn't
>     Colin> have. As at this point in the code I already know that the
>     Colin> string consists of decimal digits only, I could just check
>     Colin> the count, and err on the safe side. But I think we will
>     Colin> need a STRING_.is_integer_64 routine anyway, assuming we
>     Colin> are going to stay with SE for a while.
> 
> I've coded STRING_.is_integer_64 and (but not for VE)
> STRING_.to_integer_64.
> 
> I'm not sure what to do about writing tests.
> 
> Test_is_integer_64 is no problem.
> 
> But test_to_integer_64 will fail to compile for VE, and
> kl_test_string_routines.e is not a ge class. Perhaps a separate class?
> 
> Also, I should really but in a conditional in the .eant files for the
> xpath and xslt tests, so as not to run them for VE.
> 
> Or do we just drop VE completely now?

We drop VE completely. If it's not for INTEGER_64, it will be for
Agents/Tuples. So let's drop it now.

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

Re: [gobo-eiffel-develop] Usage of INTEGER_64

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

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

    Eric> Colin Paul Adams wrote:
    >>> So I need permission to start using INTEGER_64.

    Eric> OK. If I remember correctly this will rule out VE, but it
    Eric> should be OK with the other compilers.

    Colin> SE fails to compile it as I am
    Colin> using {STRING}.is_integer_64, which SE 1.2r7 doesn't
    Colin> have. As at this point in the code I already know that the
    Colin> string consists of decimal digits only, I could just check
    Colin> the count, and err on the safe side. But I think we will
    Colin> need a STRING_.is_integer_64 routine anyway, assuming we
    Colin> are going to stay with SE for a while.

I've coded STRING_.is_integer_64 and (but not for VE)
STRING_.to_integer_64.

I'm not sure what to do about writing tests.

Test_is_integer_64 is no problem.

But test_to_integer_64 will fail to compile for VE, and
kl_test_string_routines.e is not a ge class. Perhaps a separate class?

Also, I should really but in a conditional in the .eant files for the
xpath and xslt tests, so as not to run them for VE.

Or do we just drop VE completely now?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Bootstrap doesn't work on Linux withgcc and ge

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

Colin Adams wrote:
>> From: Andreas Leitner <ale...@ra...>
> 
>> On Mon, 2007-01-29 at 22:52 +0100, Eric Bezault wrote:
>> > Colin Adams wrote:
>> > > It said it couldn't find a file with a name something like 
>> tools/c/ise.cfg.
>> >
>> > This does not make sense. Why does ise appear in the name of
>> > this file which is supposed to contain C compiler names, and
>> > even more strange if you are not using ISE to bootstrap?
>>
>> Smells like GOBO_CC has been set to 'ise'? If I do this and then try to
>> bootstrap I get:
>> If this is indeed the case, unset GOBO_CC.
> 
> That did the trick.
> 
> But why is GOBO_CC being looked at in this case, since the compilers 
> have been specifically requested?

What you specify during the bootstrap is the C compiler
to be used to compile the C files in the bootstrap directory.
Not the C compiler to be used as back-end C compiler associated
with the chosen Eiffel compiler.

GOBO_CC is used to tell gec which C compiler to be used as
back-end C compiler. See:

     http://www.gobosoft.com/eiffel/gobo/gec/usage.html

Now I wonder why you set GOBO_CC to 'ise'. What did you try
to do when doing that?

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

Re: [gobo-eiffel-develop] Bootstrap doesn't work on Linux withgcc and ge

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

>From: Andreas Leitner <ale...@ra...>

>On Mon, 2007-01-29 at 22:52 +0100, Eric Bezault wrote:
> > Colin Adams wrote:
> > > It said it couldn't find a file with a name something like 
>tools/c/ise.cfg.
> >
> > This does not make sense. Why does ise appear in the name of
> > this file which is supposed to contain C compiler names, and
> > even more strange if you are not using ISE to bootstrap?
>
>Smells like GOBO_CC has been set to 'ise'? If I do this and then try to
>bootstrap I get:
>If this is indeed the case, unset GOBO_CC.

That did the trick.

But why is GOBO_CC being looked at in this case, since the compilers have 
been specifically requested?

_________________________________________________________________
MSN Hotmail is evolving – check out the new Windows Live Mail 
http://ideas.live.com

Re: [gobo-eiffel-develop] Bootstrap doesn't work on Linux with gcc and ge

[Andreas L. <ale...@ra...>]

Ooops, I pasted the output here one time too many. Sorry for that.

Andreas

Re: [gobo-eiffel-develop] Bootstrap doesn't work on Linux with gcc and ge

[Andreas L. <ale...@ra...>]

On Mon, 2007-01-29 at 22:52 +0100, Eric Bezault wrote:
> Colin Adams wrote:
> > It said it couldn't find a file with a name something like tools/c/ise.cfg.
> 
> This does not make sense. Why does ise appear in the name of
> this file which is supposed to contain C compiler names, and
> even more strange if you are not using ISE to bootstrap?

Smells like GOBO_CC has been set to 'ise'? If I do this and then try to
bootstrap I get:
------
aleitner@salzburg:~/tmp/elisa-0.1.3$ cd $GOBO
aleitner@salzburg:~/src/gobo$ export GOBO_CC=ise
aleitner@salzburg:~/src/gobo$ cd work/bootstrap/
aleitner@salzburg:~/src/gobo/work/bootstrap$ sh bootstrap.sh gcc ge
gec: cannot read '/home/aleitner/src/gobo/tool/gec/config/c/ise.cfg'

BUILD FAILED!aleitner@salzburg:~/tmp/elisa-0.1.3$ cd $GOBO
aleitner@salzburg:~/src/gobo$ export GOBO_CC=ise
aleitner@salzburg:~/src/gobo$ cd work/bootstrap/
aleitner@salzburg:~/src/gobo/work/bootstrap$ sh bootstrap.sh gcc ge
gec: cannot read '/home/aleitner/src/gobo/tool/gec/config/c/ise.cfg'

BUILD FAILED!

BUILD FAILED!


BUILD FAILED!
------

If this is indeed the case, unset GOBO_CC.

hth,
Andreas

Re: [gobo-eiffel-develop] Bootstrap doesn't work on Linux with gcc and ge

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

Colin Adams wrote:
> It said it couldn't find a file with a name something like tools/c/ise.cfg.

This does not make sense. Why does ise appear in the name of
this file which is supposed to contain C compiler names, and
even more strange if you are not using ISE to bootstrap?

> I switched to bootstrapping with gcc ise and there is no problem.

The only thing I can say is that Andreas successfully bootstrapped
with gcc and ge when building Gobo 3.5 under Linux.

Can you please send the full output?

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

[gobo-eiffel-develop] Bootstrap doesn't work on Linux with gcc and ge

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

It said it couldn't find a file with a name something like tools/c/ise.cfg.

I switched to bootstrapping with gcc ise and there is no problem.

P.S. Only ISE 5.7 is installed on this machine.

_________________________________________________________________
MSN Hotmail is evolving – check out the new Windows Live Mail 
http://ideas.live.com