gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Problems with GEC

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> You need to do a full svn update followed by a full
>     Eric> bootstrap.
> 
> And with gec I get:
> 
> [GCAAA] cluster eiffel_testgen: cannot read cluster directory 'TESTGEN'.
> 
> [GVSRC4] unknown root class XPATH.

I just made a svn checkout from scratch, ran the bootstrap, and then
'geant test_ge' works fine for me in $GOBO/test.

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

Re: [gobo-eiffel-develop] Problems with GEC

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

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

    Eric> You need to do a full svn update followed by a full
    Eric> bootstrap.

And with gec I get:

[GCAAA] cluster eiffel_testgen: cannot read cluster directory 'TESTGEN'.

[GVSRC4] unknown root class XPATH.


-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Problems with GEC

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

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

    >> Now trying to compile the XPath test suite gives me:
    >> 
    >> Unknown option 'nocc'.  Errors parsing arguments, aborting.

    Eric> You need to do a full svn update followed by a full
    Eric> bootstrap.

I've done this, but now I can't compile with ise 6.0. I get:

<snip/>
[  0% - 1] Degree 6 group eiffel_testgen

Error code: VD71
Configuration error


Directory open error: /home/colin/gobo/test/xml/xpath/TESTGEN
TESTGEN\
Configuration: /home/colin/gobo/test/xml/xpath/./xpath.ecf

-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] bootstrap with se 1.2r7

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

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

    Eric> As a workaround you might try to indent all lines of the
    Eric> string with the same number of tabs.

It doesn't help.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] bootstrap with se 1.2r7

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> As you may have noticed, I don't use SE 1.2 anymore. I'm not
>     Eric> really interested in a compiler that does not say clearly
>     Eric> that it will target ECMA Eiffel. Sooner or later we will
>     Eric> have to drop it like we did for Visual Eiffel because of
>     Eric> that.
> 
> I too have just encountered a problem with it:
> 
> ****** Fatal Error: Error inside multi-line manifest string.
> Line 5 column 3 in XM_XPATH_ITEM_MAPPING_FUNCTION (/home/colin/gobo/library/xml/xpath/expression/xm_xpath_item_mapping_function.e) :
>                 "[
>                 ^
> Line 7 column 7 in XM_XPATH_ITEM_MAPPING_FUNCTION (/home/colin/gobo/library/xml/xpath/expression/xm_xpath_item_mapping_function.e) :
>              Such objects, when given an XM_XPATH_ITEM, generate
>              ^
> 
> The header concerned looks like this:
> 
> indexing
> 
> 	description:
> 
> 		"[
>         Objects that can be passed to an XM_XPATH_ITEM_MAPPING_ITERATOR.
> 	     Such objects, when given an XM_XPATH_ITEM, generate
> 	     zero or one items.
>       ]"
> 
> 	library: "Gobo Eiffel XPath Library"
> 
> ISE 6.0 is happy with it.

As a workaround you might try to indent all lines of the string
with the same number of tabs.

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

Re: [gobo-eiffel-develop] Problems with GEC

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

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> 
>     Colin> I was attempting to run the XPath test suite with gec, and
>     Colin> I got the following errors:
> 
>     Colin> [GVKBU-1] class TYPE (41,2): unknown built-in routine
>     Colin> `name' in class TYPE.
>  
>     Colin> [GVKBU-1] class TYPE (50,2): unknown built-in routine
>     Colin> `type_id' in class TYPE.
>  
>     Colin> Assuming that I needed an update, I did an svn update
>     Colin> followed by geant install.
> 
> Since re-compiling with gec didn't work, I used ise 6.0 instead.
> 
> Now trying to compile the XPath test suite gives me:
> 
> Unknown option 'nocc'.
> Errors parsing arguments, aborting.

You need to do a full svn update followed by a full bootstrap.

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

Re: [gobo-eiffel-develop] bootstrap with se 1.2r7

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

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

    Eric> As you may have noticed, I don't use SE 1.2 anymore. I'm not
    Eric> really interested in a compiler that does not say clearly
    Eric> that it will target ECMA Eiffel. Sooner or later we will
    Eric> have to drop it like we did for Visual Eiffel because of
    Eric> that.

I too have just encountered a problem with it:

****** Fatal Error: Error inside multi-line manifest string.
Line 5 column 3 in XM_XPATH_ITEM_MAPPING_FUNCTION (/home/colin/gobo/library/xml/xpath/expression/xm_xpath_item_mapping_function.e) :
                "[
                ^
Line 7 column 7 in XM_XPATH_ITEM_MAPPING_FUNCTION (/home/colin/gobo/library/xml/xpath/expression/xm_xpath_item_mapping_function.e) :
             Such objects, when given an XM_XPATH_ITEM, generate
             ^

The header concerned looks like this:

indexing

	description:

		"[
        Objects that can be passed to an XM_XPATH_ITEM_MAPPING_ITERATOR.
	     Such objects, when given an XM_XPATH_ITEM, generate
	     zero or one items.
      ]"

	library: "Gobo Eiffel XPath Library"

ISE 6.0 is happy with it.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Problems with GEC

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

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

    Colin> I was attempting to run the XPath test suite with gec, and
    Colin> I got the following errors:

    Colin> [GVKBU-1] class TYPE (41,2): unknown built-in routine
    Colin> `name' in class TYPE.
 
    Colin> [GVKBU-1] class TYPE (50,2): unknown built-in routine
    Colin> `type_id' in class TYPE.
 
    Colin> Assuming that I needed an update, I did an svn update
    Colin> followed by geant install.

Since re-compiling with gec didn't work, I used ise 6.0 instead.

Now trying to compile the XPath test suite gives me:

Unknown option 'nocc'.
Errors parsing arguments, aborting.

-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] Problems with GEC

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

I was attempting to run the XPath test suite with gec, and I got the
following errors:

[GVKBU-1] class TYPE (41,2): unknown built-in routine `name' in class TYPE.
=20
[GVKBU-1] class TYPE (50,2): unknown built-in routine `type_id' in class TY=
PE.
=20
Assuming that I needed an update, I did an svn update followed by
geant install.

Then in src/gec I did a geant clobber followed by geant compile_ge.

I get the following output:

gec.c: In function =E2=80=98geboxed1=E2=80=99:
gec.c:11: error: request for member =E2=80=98id=E2=80=99 in something not a=
 structure or union
gec.c: In function =E2=80=98geboxed2=E2=80=99:
<snip>
message repeated very many times
</snip>
gec.c: In function =E2=80=98gemt237=E2=80=99:
gec.c:507348: error: request for member =E2=80=98id=E2=80=99 in something n=
ot a structure or union
gec.c: In function =E2=80=98file_owner=E2=80=99:
gec.c:512259: warning: return from incompatible pointer type
gec.c: In function =E2=80=98file_group=E2=80=99:
gec.c:512279: warning: return from incompatible pointer type
gec.c: In function =E2=80=98dir_next=E2=80=99:
gec.c:512800: warning: return from incompatible pointer type
gec.c: In function =E2=80=98dir_current=E2=80=99:
gec.c:512942: warning: assignment from incompatible pointer type
gcc: gec.o: No such file or directory

BUILD FAILED!

--=20
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] bootstrap with se 1.2r7

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

Berend de Boer wrote:
> Decided to bootstrap the latest Gobo with se, but that didn't
> work. 
>
> ****** Error: Current type is STRING. There is no feature append_integer
> in class STRING. 
> Line 338 column 12 in GEANT_GEC_COMMAND (/home/berend/src/gobo/src/geant/command/geant_gec_command.e) :
>                                 Result.append_integer (split_size)
>                                        ^
> - ------
> ****** Fatal Error: Feature "append_integer" not found.
> Line 338 column 12 in GEANT_GEC_COMMAND (/home/berend/src/gobo/src/geant/command/geant_gec_command.e) :
>                                 Result.append_integer (split_size)
>                                        ^
> - ------
> File "geant.make" not found. Error(s) during `compile_to_c'.

It should be fixed now.

> What version of se is actually still supported?

1.2r7

> I'm happy to
> move to ge, but I don't have the experience of reliability I had with
> se, so it would be nice of se somehow still kept working.

As you may have noticed, I don't use SE 1.2 anymore. I'm not really
interested in a compiler that does not say clearly that it will target
ECMA Eiffel. Sooner or later we will have to drop it like we did for
Visual Eiffel because of that. Furthermore, the SE compiler crashes
on me when I put Agents in assertions. So it's not that reliable to
me. It's probably easy to fix, but its maintenance is currently dead
until resurrected, whenever that happens. The Gobo compiler is probably
less reliable and complete than SE 1.2, but I'm actively working on it
and I'm fixing bugs as they occur.

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

[gobo-eiffel-develop] bootstrap with se 1.2r7

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

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

Hi Eric,

Decided to bootstrap the latest Gobo with se, but that didn't
work. What version of se is actually still supported? I'm happy to
move to ge, but I don't have the experience of reliability I had with
se, so it would be nice of se somehow still kept working.

****** Error: Current type is STRING. There is no feature append_integer
in class STRING. 
Line 338 column 12 in GEANT_GEC_COMMAND (/home/berend/src/gobo/src/geant/command/geant_gec_command.e) :
                                Result.append_integer (split_size)
                                       ^
- ------
****** Fatal Error: Feature "append_integer" not found.
Line 338 column 12 in GEANT_GEC_COMMAND (/home/berend/src/gobo/src/geant/command/geant_gec_command.e) :
                                Result.append_integer (split_size)
                                       ^
- ------
File "geant.make" not found. Error(s) during `compile_to_c'.


- -- 
Live long and prosper,

Berend de Boer


PS: This email has been digitally signed if you wonder what the strange
characters are that your email client displays.
PGP public key: http://www.pobox.com/~berend/berend-public-key.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFG4HpRIyuuaiRyjTYRAvOkAJ0VbA6wW2hz2k2zcKj1cguJ/vCjhgCgg4Il
ZG2YQZWZFjhTBTgXAd/68h0=
=x60p
-----END PGP SIGNATURE-----

[gobo-eiffel-develop] Inconsistency in creation routines of UT_URI

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

I have just written a class XM_STDIN_URI_RESOLVER, which resolves URIs
of the form stdin:[#fragment-identifier] to the standard input stream.


The source for the `resolve' routine looks like this:

	resolve (a_uri: UT_URI) is
			-- Resolve file URI.
		do
			if not a_uri.is_absolute then
				last_error := STRING_.concat (Valid_uri_message, a_uri.full_reference)
			elseif a_uri.has_authority then
				last_error := STRING_.concat (Valid_uri_message, a_uri.full_reference)
			-- commented out as it fails: elseif not a_uri.has_absolute_path then
			--	last_error := STRING_.concat (Valid_uri_message, a_uri.full_reference)
			elseif not a_uri.path_items.is_empty then
				last_error := STRING_.concat (Valid_uri_message, a_uri.full_reference)
			elseif a_uri.has_query then
				last_error := STRING_.concat (Valid_uri_message, a_uri.full_reference)
			else
				last_stream := std.input
				if last_stream.is_open_read then
					last_error := Void
				else
					last_error := "Standard input is closed"
				end
			end
		end

The reason for the commented out lines is that has_absolute_path is a
postcondition of {UT_URI}.make_absolute, but gexslt is calling
{UT_URI}.make_resolve (or make_resolve_uri) with an argument of
"stdin:" (which ought to be equivalent to call make_absolute
("stdin"), and this fails, so I commented it out.

Franck, can you explain the inconsistency?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] EDP and ET_C_GENERATOR

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

Howard Thomson wrote:
> I have been bringing my EDP project up to date with respect to Gobo SVN, and 
> have identified a couple of bugs somewhere in ET_C_GENERATOR as of SVN 
> revision 6046 (I think).
> 
> The new implementation of once manifest strings has a bug, in that at least 
> one once manifest string has been misplaced by another one in EDP when 
> generated with the new ET_C_GENERATOR.

I will need more information about this, because just by looking at
the code I cannot see any bug. I will probably have to wait for your
SVN repository to be fixed, and then you will have to tell me
which once manifest string is wrong.

> There is also a C emitted code problem for an external C routine, where 
> previously the arguments were passed without casts, and are now cast to (char 
> *) which the C compiler complains about, although it does not alter (for a 
> 32-bit platform) the resulting code.

You are probably referring to these lines:

         -- When compiling with C++, MSVC++ does not want to convert
         -- 'void*' to non-'void*' implicitly.
     current_file.put_string ("(char*)")
     print_argument_name (l_name, current_file)

in class ET_C_GENERATOR in features `print_external_c_body' and
`print_external_cpp_body'. The explicit cast to char* is a quick
hack to make the C++ compiler happy (my C compiler did not complain
about this hack). Any more appropriate solution is welcome.

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

[gobo-eiffel-develop] EDP and ET_C_GENERATOR

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

Hi all,

I have been bringing my EDP project up to date with respect to Gobo SVN, and 
have identified a couple of bugs somewhere in ET_C_GENERATOR as of SVN 
revision 6046 (I think).

The new implementation of once manifest strings has a bug, in that at least 
one once manifest string has been misplaced by another one in EDP when 
generated with the new ET_C_GENERATOR.

There is also a C emitted code problem for an external C routine, where 
previously the arguments were passed without casts, and are now cast to (char 
*) which the C compiler complains about, although it does not alter (for a 
32-bit platform) the resulting code.

Unfortunately, the SVN repository on Sourceforge for EDP has become corrupted 
and I am unable to update it. This has been reported to the SF team.

The problem appears to have arisen as a result of committing one of the 
generated C files for EDP, as a single file, to SVN. As Eric has now 
implemented file splitting for the C generation (thanks Eric !), this problem 
may not recur (hopefully) after SF have fixed or expunged the existing 
repository.

Regards,

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

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

Ah yes, of course .... I hadn't noticed that class.

Thanks.

On Wednesday 22 August 2007 13:53, you wrote:
> Howard Thomson wrote:
> > The problem with ET_AST_ITERATOR.process_features was that the
> > feature_clause attribute was Void for the queries and procedures being
> > processed and therefore not matching the current feature_clause.
> >
> > In the parsing process, the current feature is passed as an argument to
> > the new_do_procedure / new_do_function etc routines in ET_AST_FACTORY but
> > are not used in those routines to do set_feature_clause for that
> > argument.
> >
> > Having added Result.set_feature_clause to the relevant 8 routines of
> > ET_AST_FACTORY, I am now getting features processed.
>
> You should not do that, but use ET_DECORATED_AST_FACTORY instead.
> This is what is done in $GOBO/test/tools and in
> $GOBO/example/tools/bang2create.

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

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

Howard Thomson wrote:
> The problem with ET_AST_ITERATOR.process_features was that the feature_clause 
> attribute was Void for the queries and procedures being processed and 
> therefore not matching the current feature_clause.
> 
> In the parsing process, the current feature is passed as an argument to the 
> new_do_procedure / new_do_function etc routines in ET_AST_FACTORY but are not 
> used in those routines to do set_feature_clause for that argument.
> 
> Having added Result.set_feature_clause to the relevant 8 routines of 
> ET_AST_FACTORY, I am now getting features processed.

You should not do that, but use ET_DECORATED_AST_FACTORY instead.
This is what is done in $GOBO/test/tools and in
$GOBO/example/tools/bang2create.

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

[gobo-eiffel-develop] ET_FEATURE.set_feature_clause

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

Hi Eric,

The problem with ET_AST_ITERATOR.process_features was that the feature_clause 
attribute was Void for the queries and procedures being processed and 
therefore not matching the current feature_clause.

In the parsing process, the current feature is passed as an argument to the 
new_do_procedure / new_do_function etc routines in ET_AST_FACTORY but are not 
used in those routines to do set_feature_clause for that argument.

Having added Result.set_feature_clause to the relevant 8 routines of 
ET_AST_FACTORY, I am now getting features processed.

Cheers,

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

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

Howard Thomson wrote:
> I don't yet fully understand the implications of the presence of synonyms in a 
> class,

The trick is that the ET_AST_PRINTER prints:

    foo, bar (...) is
        do
           ...
        end

and not:

    foo (...) is
        do
           ...
        end

    bar (...) is
        do
           ...
        end

when it finds synonyms. This is needed when what we want it just
change the formating of a class text without decoupling synonym
features. This trick about synonyms is done if class ET_AST_ITERATOR
in feature `process_features' and for example in feature
`process_do_procedure'. If you don't want this behavior and want
the synonym features to stand by themsleves, then you would need
to redefine these features in a descendant of ET_AST_PRINTER.

> and I am unsure as to what assumptions one can make about the ordering 
> of features in ET_CLASS.queries and ET_CLASS.procedures.

Queries in ET_CLASS.queries between 1 and `queries.declared_count' are
guaranteed to be sorted in the order they appear in the class text.
Likewise for procedures. However we know nothing about the ordering
between a query and a procedure. We have to compare their position
in the class text in that case.

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

Re: [gobo-eiffel-develop] ET_AST_ITERATOR.process_features

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

Hi Eric,

It doesn't work, as you say !

My gecmp program uses Gobo tools to parse pairs of class files, uses a 
derivation of ET_AST_PRINTER to accumulate the sequence of ET_AST_LEAF 
elements that were parsed, does a 'diff' pass over the pair of sequences 
(arrays) of leaf elements, marks the elements according to whether they are 
equal, not-equal, or excluded, and uses a derivation of ET_AST_PRINTER to 
print the sequence of elements tagged with the "== ","/= ","   " marking.

The process worked fine on my initial test pair of classes with just a single 
feature clause and one feature.

When I started processing all classes in the Universe for the EDP project, 
modified to add the current $GOBO/library/tools/eiffel class set to provide 
pairs of class files for comparison, I ended up with (some) classes with 
feature clauses with only the word 'feature' and no features at all.

I don't yet fully understand the implications of the presence of synonyms in a 
class, and I am unsure as to what assumptions one can make about the ordering 
of features in ET_CLASS.queries and ET_CLASS.procedures.

I need it to work for all valid class texts, so I will find the problem, 
eventually !

Howard

On Wednesday 22 August 2007 08:29, you wrote:
> Howard Thomson wrote:
> > In working on my Eiffel comparison code, I found that the
> > process_features feature of ET_AST_ITERATOR fails to process features in
> > some classes.
> >
> > According to feedback from my EDP project, this feature is not part of
> > the reachable feature set of the Eiffel compilation process in 'gec' and
> > is therfeore untested in that environment.
>
> It is in fact tested by $GOBO/test/tools.
>
> > I append a reimplementation that seems to work somewhat better, although
> > not yet proven correct:
>
> It is in fact proven not correct when running the test $GOBO/test/tools.
>
> Can you be more explicit about what ET_AST_ITERATOR.process_features
> fails to process? Is your AST well formed with synonyms correctly
> chained?
>
> > By the way, did you get my previous e-mail about waiting for me to update
> > SF svn ?
>
> Yes.

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

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

Howard Thomson wrote:
> In working on my Eiffel comparison code, I found that the process_features feature of ET_AST_ITERATOR
> fails to process features in some classes.
> 
> According to feedback from my EDP project, this feature is not part of the reachable feature set of the Eiffel
> compilation process in 'gec' and is therfeore untested in that environment.

It is in fact tested by $GOBO/test/tools.

> I append a reimplementation that seems to work somewhat better, although not yet proven correct:

It is in fact proven not correct when running the test $GOBO/test/tools.

Can you be more explicit about what ET_AST_ITERATOR.process_features
fails to process? Is your AST well formed with synonyms correctly
chained?

> By the way, did you get my previous e-mail about waiting for me to update SF svn ?

Yes.

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

[gobo-eiffel-develop] ET_AST_ITERATOR.process_features

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

Hi Eric,

In working on my Eiffel comparison code, I found that the process_features feature of ET_AST_ITERATOR
fails to process features in some classes.

According to feedback from my EDP project, this feature is not part of the reachable feature set of the Eiffel
compilation process in 'gec' and is therfeore untested in that environment.

I append a reimplementation that seems to work somewhat better, although not yet proven correct:

	process_features (a_class: ET_CLASS) is
			-- Process feature clauses of `a_class'.
		require
			a_class_not_void: a_class /= Void
		local
			a_feature_clauses: ET_FEATURE_CLAUSE_LIST
			a_feature_clause: ET_FEATURE_CLAUSE
			l_queries: ET_QUERY_LIST
			l_query: ET_QUERY
			l_procedures: ET_PROCEDURE_LIST
			l_procedure: ET_PROCEDURE
			i, nb: INTEGER
			j, nb_queries: INTEGER
			k, nb_procedures: INTEGER
		do
			a_feature_clauses := a_class.feature_clauses
			if a_feature_clauses /= Void then
				from
						-- Setup for 'feature' sequence
					i := 1
					nb := a_feature_clauses.count
						-- Setup for 'queries' sequence
					j := 1
					l_queries := a_class.queries
					nb_queries := l_queries.count
					if j <= nb_queries then
						l_query := l_queries.item (j)
					else
						l_query := Void
					end
						-- Setup for 'procedures' sequence
					k := 1
					l_procedures := a_class.procedures
					nb_procedures := l_procedures.count
					if k <= nb_procedures then
						l_procedure := l_procedures.item (k)
					else
						l_procedure := Void
					end
				until
					i > nb
				loop
						-- Set feature clause for this iteration
					a_feature_clause := a_feature_clauses.item (i)

						-- Process either the next query, or the next procedure
						-- and select the next query or procedure ...
					if l_query /= Void and then l_query.feature_clause = a_feature_clause then
						if l_procedure /= Void and then l_procedure.feature_clause = a_feature_clause then
							if l_query.name.position < l_procedure.name.position then
									-- Here, both the current query and the current procedure lie within
									-- the current feature, and the query comes first
								l_query.process (Current)
								j := j + 1
								if j <= nb_queries then
									l_query := l_queries.item (j)
								else
									l_query := Void
								end
							else
									-- Here, both the current query and the current procedure lie within
									-- the current feature, and the procedure comes first
								l_procedure.process (Current)
								k := k + 1
								if k <= nb_procedures then
									l_procedure := l_procedures.item (k)
								else
									l_procedure := Void
								end
							end -- if
						else
								-- Here, only the query lies in the current feature clause
							l_query.process (Current)
							j := j + 1
							if j <= nb_queries then
								l_query := l_queries.item (j)
							else
								l_query := Void
							end
						end -- if
					elseif l_procedure /= Void and then l_procedure.feature_clause = a_feature_clause then
							-- Here, only the current procedure lies within the current feature clause
						l_procedure.process (Current)
						k := k + 1
						if k <= nb_procedures then
							l_procedure := l_procedures.item (k)
						else
							l_procedure := Void
						end
					end -- if
					
						-- If both the current query and procedure are not in
						-- the current feature clause, then select the next feature clause
					if (l_query = Void or else l_query.feature_clause /= a_feature_clause)
					and then (l_procedure = Void or else l_procedure.feature_clause /= a_feature_clause) then
						i := i + 1
					end -- if
				end -- loop
			end -- if
		end

Cheers,

Howard Thomson

By the way, did you get my previous e-mail about waiting for me to update SF svn ?

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

Re: [gobo-eiffel-develop] Problems with converting DOUBLE to INTEGER_64

[Mark A. B. <mbo...@ar...>]

Colin Paul Adams wrote:
> It seems that truncated_to_integer_64 is not enough in itself, and (in
> ISE 6.0) isn't sufficiently accurate anyway.
>
> My problem is converting 1e100 to an integer.
>
> The debugger displays this as something like 1.000000000000000006e100
> (I have not counted the the exact number of zeros).
>
> Calling truncated_to_integer_64 on this produces -9223372036854775808.
>
> The alternative (which I have adopted) is to convert to MA_DECIMAL
> first, using make_from_string ({DOUBLE}.out), works, but gives an
> inaccurate value (because of the 6). I guess this is acceptable, as
> doubles are inherently inaccurate.
>   
It isn't a fault with ISE, but with computer arithmetic in general. 
64-bit integers cover the range -9,223,372,036,854,775,808 to 
+9,223,372,036,854,775,807, so 1e100 is not representable as an integer 
(you would need 512-bit integers to represent 1e100).

So your method is probably the best general, unless you wanted to test 
if your double is smaller than max_int, and treat accordingly if above 
or below.

Mark

[gobo-eiffel-develop] Problems with converting DOUBLE to INTEGER_64

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

It seems that truncated_to_integer_64 is not enough in itself, and (in
ISE 6.0) isn't sufficiently accurate anyway.

My problem is converting 1e100 to an integer.

The debugger displays this as something like 1.000000000000000006e100
(I have not counted the the exact number of zeros).

Calling truncated_to_integer_64 on this produces -9223372036854775808.

The alternative (which I have adopted) is to convert to MA_DECIMAL
first, using make_from_string ({DOUBLE}.out), works, but gives an
inaccurate value (because of the 6). I guess this is acceptable, as
doubles are inherently inaccurate.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Gobo-Eiffel extensions

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

Hi Howard,

Howard Thomson wrote:
> I am continuing to work on my project based on gobo-eiffel, named EDP, the 
> Eiffel Developer's Project on Sourceforge, although I haven't been keeping 
> the SF SVN repository up-to-date with my work.

Am I right to assume that I can find all modifications that you made
to Gobo classes in:

     http://edp.svn.sourceforge.net/viewvc/edp/gobo-mods/

I want to see to what extent I can retrofit some of your modifications
to the Gobo project.

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

Re: [gobo-eiffel-develop] Converting large DOUBLEs to INTEGER_64

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

Mark A. Bolstad wrote:
> Is there a reason you can't simply use an external C routine to 
> do the conversion,

I don't know if SE 1.2 can target JVM, but if it does and will do
in the future, then it's probably better not to use external "C".
During the past 10 years the policy of the Gobo kernel classes
adapter was to only use features provided by the supported
compilers and not introduce new external routines. It would be
great if we could continue to do that during the next 10 years.

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