gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] Cannot reuse RX_PCRE_REGULAR_EXPRESSION instance

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

Re: [gobo-eiffel-develop] Parsing parameters using the arguments library

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

On Mon, 12 Mar 2007 10:18:29 +0100, Colin Adams  
<col...@ho...> wrote:

> I was not talking about options, but parameters.
> So the minimum would be the minimum number of parameters that can appear  
> on the command line. By default, zero.

Sorry, missunderstood you there. Yes, the problem with parameters is still  
a bit tricker, as you are describing.

> And the maximum woudl default to max INTEGER (a practical proxy for  
> infinity).

Yes, INFINITY would not be a problem, and is the default. I normally do  
not like to work with MAXIMUM_INTEGER.

> So ls can use the defaults.
>
> But many commands would require at least one parameter, and others will  
> require exactly one, or one or two. But it may depend upon the  
> option-set used.

I think it would be enough to have a default min and max, and to override  
these if an ALTERNATIVE_OPTIONS_LIST is selected. Anything more  
complicated would clobber the library.

We have to be aware that there is always some level of command line  
parsing that needs to be done manually anyway. For example, to see if the  
strings passed as parameters are really existing filenames, or at least  
are creatable filenames, cannot be done by the library without a  
significant raise in complexity that I do not want.

> For instance, with gexslt, if the --use-pi option is passed, then  
> exactly one parameter is needed (the source document URI or file name).
> If the --template option is used, then one or two paramters are possible  
> (the transformation URI or file name is mandatory, and the source  
> document is optional).
>
> But if neither option is specified, then both of these parameters are  
> compulsory.

If '--use-pi' and '--template' are ALTERNATIVE_OPTIONS_LISTs, then this  
can be achieved with the suggestion above. And it would keep the  
complexity low.

> It would also be nice to be able to name the individual parameters, for  
> use in the error messages that are generated when the wrong number is  
> passed, but that is a further step, I think.

Also a good idea, if it does not clobber the interface. Anyway, an  
AP_ALTERNATIVE_OPTIONS_LIST already now has an own description string for  
the parameters that is shown in the help page. Perhaps just integrating  
this string into the error text would help.

Bernd

Re: [gobo-eiffel-develop] Parsing parameters using the arguments library

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

>From: "Bernd Schoeller" <ber...@in...>
>>It seems to me that it would be convenient to be able to set the minimum  
>>and
>>maximum number of parameters expected, which would then reduce the  
>>checking
>>the application had to do.
>>
>>As the number expected might differ according to the option set, then  
>>this
>>should be settable at the option list level (as well as on the parser,  if 
>>it
>>is the same for all (or most) option sets).
>>
>>What do you think?
>
>I had already experimented with such a features, but had not full decided  
>for a satisfactory design. Currently I only differenciate between  
>mandatory or not mandatory.
>
>Giving the maximum number of occurencies seems very reasonable. With  
>minimum: It seems very rare that an option is required 'at least 3 times'.  
>But I might be wrong here. I will probably extend the mandatory mechanism  
>to cover such cases.

I was not talking about options, but parameters.
So the minimum would be the minimum number of parameters that can appear on 
the command line. By default, zero.

And the maximum woudl default to max INTEGER (a practical proxy for 
infinity).

So ls can use the defaults.

But many commands would require at least one parameter, and others will 
require exactly one, or one or two. But it may depend upon the option-set 
used.

For instance, with gexslt, if the --use-pi option is passed, then exactly 
one parameter is needed (the source document URI or file name).
If the --template option is used, then one or two paramters are possible 
(the transformation URI or file name is mandatory, and the source document 
is optional).

But if neither option is specified, then both of these parameters are 
compulsory.

It would also be nice to be able to name the individual parameters, for use 
in the error messages that are generated when the wrong number is passed, 
but that is a further step, I think.

_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.  
http://www.msn.txt4content.com/

Re: [gobo-eiffel-develop] Parsing parameters using the arguments library

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

On Sun, 11 Mar 2007 19:52:41 +0100, Colin Adams  
<col...@ho...> wrote:

>> From reading the documentation, it seems that the parser can not check  
>> the
> number of parameters passed.
>
> It seems to me that it would be convenient to be able to set the minimum  
> and
> maximum number of parameters expected, which would then reduce the  
> checking
> the application had to do.
>
> As the number expected might differ according to the option set, then  
> this
> should be settable at the option list level (as well as on the parser,  
> if it
> is the same for all (or most) option sets).
>
> What do you think?

I had already experimented with such a features, but had not full decided  
for a satisfactory design. Currently I only differenciate between  
mandatory or not mandatory.

Giving the maximum number of occurencies seems very reasonable. With  
minimum: It seems very rare that an option is required 'at least 3 times'.  
But I might be wrong here. I will probably extend the mandatory mechanism  
to cover such cases.

Bernd

Re: [gobo-eiffel-develop] Possible bug in 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.

[gobo-eiffel-develop] Parsing parameters using the arguments library

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

>From reading the documentation, it seems that the parser can not check the 
number of parameters passed.

It seems to me that it would be convenient to be able to set the minimum and 
maximum number of parameters expected, which would then reduce the checking 
the application had to do.

As the number expected might differ according to the option set, then this 
should be settable at the option list level (as well as on the parser, if it 
is the same for all (or most) option sets).

What do you think?

_________________________________________________________________
Solve the Conspiracy and win fantastic prizes.  
http://www.theconspiracygame.co.uk/

[gobo-eiffel-develop] Possible bug in XM_DEFAULT_ATTRIBUTE_FILTER

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

Hello Franck,

I'm having a problem with a bunch of the W3C XSLT tests involving embedded 
stylesheets and a DTD.

It looks like XM_DEFAULT_ATTRIBUTE_FILTER is at fault.

The reason I say this is I see calls to forward_attribute where a_ns and 
a_prefix are both Void, a_local = "xsl", and a_value = 
"http://www.w3.org/1999/XSL/Transform" - this looks wrong - I assume 
a_prefix should be set to xmlns.

Here is the complete file, including DTD internal subset.

Can you verify that the bug is in this class, and if so, how about a fix (or 
a sketch of how to do it)?

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="#style1"?>
<!DOCTYPE doc [
<!ELEMENT doc (#PCDATA | head | body)*>
<!ATTLIST doc
		  xmlns:xsl CDATA #FIXED "http://www.w3.org/1999/XSL/Transform"
		  xsl:xpath-default-namespace CDATA #FIXED "http://example.org/ibm">

<!ELEMENT head (#PCDATA | xsl:stylesheet)*>
<!ELEMENT body (#PCDATA | elem)*>

<!ELEMENT xsl:stylesheet (#PCDATA | xsl:template)*>
<!ATTLIST xsl:stylesheet
		  id ID #REQUIRED
		  xmlns:xsl CDATA #FIXED "http://www.w3.org/1999/XSL/Transform"
		  version NMTOKEN #REQUIRED>

<!ELEMENT xsl:template (#PCDATA | out)*>
<!ATTLIST xsl:template  match CDATA #IMPLIED>

<!ELEMENT out (#PCDATA | xsl:for-each )*>

<!ELEMENT xsl:for-each (#PCDATA | xsl:copy-of )*>
<!ATTLIST xsl:for-each  select CDATA #IMPLIED>

<!ELEMENT xsl:copy-of (#PCDATA)*>
<!ATTLIST xsl:copy-of select CDATA #IMPLIED>

<!ELEMENT elem (#PCDATA | item)*>
<!ELEMENT subitem (#PCDATA)*>

<!ELEMENT item (#PCDATA | subitem)*>
<!ATTLIST item attr CDATA #IMPLIED
		  xmlns CDATA #IMPLIED>
]>

<doc xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
xsl:xpath-default-namespace="http://example.org/ibm" >
  <head>
	<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
version="2.0"
                id="style1">

	<!-- FileName: embed20_005 -->
	<!-- Document: http://www.w3.org/TR/xslt20 -->
	<!-- DocVersion: 20051103 -->
	<!-- Section: 3.11 Embedded Stylesheet Modules -->
	<!-- Purpose: Test case to verify that in a embedded standard stylesheet 
module, standard attribute
				 (xsl:xpath-default-namespace) appearing on ancestors of the outermost 
element of
				 the stylesheet module has no effect. -->

		<xsl:template match="/" >
  			<out>
    			<xsl:for-each select="doc/body/elem/item"  >
					<xsl:copy-of select="." />
				</xsl:for-each>
  			</out>
		</xsl:template>
	</xsl:stylesheet>
  </head>

  <body>
	<elem>
		<item attr="atr1" xmlns="http://example.org/ibm">
			<subitem>a</subitem>
		</item>
		<item attr="atr2" xmlns="http://example.org/ibm">
			<subitem>b</subitem>
		</item>
		<item attr="atr3"><subitem>c</subitem></item>
	</elem>
  </body>

<!-- Copyright IBM Corp. 2006 -->

</doc>

_________________________________________________________________
Get Messenger FREE on your Mobile https://livemessenger.mobile.uk.msn.com/

Re: [gobo-eiffel-develop] Gelint output

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

>From: Eric Bezault <er...@go...>
> > This message at the top of the output was:
> >
> > [GVKFE-2] class TYPED_POINTER: feature `to_pointer' in kernel class 
>TYPED_POINTER is not an attribute.
>
>It's because gelint/gec expects to get the version from
>FreeELKS I guess, and ISE 5.7 still uses its own version.
>I'll look at it.

Last night, it caused the build to fail when I tried:

geant test_debug_ge

for the XPath test suite.

This is with ISE 5.7.

_________________________________________________________________
Rate your skiving credentials with our Slack-o-meter 
http://www.slack-o-meter.com

Re: [gobo-eiffel-develop] Gelint output

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

Colin Paul Adams wrote:
> Now that I have an integration ace file again, I ran gelint on it with
> the command line:
> 
> gelint --ise=5.7 --flat --cat ise.ace >gelint.out 2>&1

--cat does not make sense with an integration ace file.
It is to be used with application ace files.

I use the integration Ace file that I gave you only with
EiffelStudio. The --cat option is exercised when running
'geant test_debug_ge' in $GOBO/test/example and
$GOBO/test/src because 'gec' uses it. --flat is exercised
on the libraries when running 'geant test_debug_ge'
in $GOBO/test/precomp.

> This message at the top of the output was:
> 
> [GVKFE-2] class TYPED_POINTER: feature `to_pointer' in kernel class TYPED_POINTER is not an attribute.

It's because gelint/gec expects to get the version from
FreeELKS I guess, and ISE 5.7 still uses its own version.
I'll look at it.

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

[gobo-eiffel-develop] Gelint output

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

Now that I have an integration ace file again, I ran gelint on it with
the command line:

gelint --ise=5.7 --flat --cat ise.ace >gelint.out 2>&1

(are those the best options to use? I ask because the size of the
output file is 422545209 bytes, which is a lot to look at :-). I think
it is all just one catcall, in essence - I will take a look at
correcting this in the near future.)

This message at the top of the output was:

[GVKFE-2] class TYPED_POINTER: feature `to_pointer' in kernel class TYPED_POINTER is not an attribute.

-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] File URI resolution

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

An interesting problem has emerged from one of the W3C XSLT tests.

The test looks like this:

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

   <?spec xslt#document?>

<xsl:template match="/">
  <out>
      <!-- test use of an escaped URI with document() function -->
      <xsl:copy-of select="document('xgespr%C3%A4ch.xml')/*"/>
  </out>
</xsl:template>

</xsl:stylesheet>


Note the (relative) file URI:

xgespr%C3%A4ch.xml

The percent encoding equates to lower case a-umlaut.

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

Not surprsingly, the test fails on my system.

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

The resolver uses UT_FILE_URI_ROUTINES, whichj in turn make use of

file_system.pathname_to_string (uri_to_pathname (a_uri))

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

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

Manu, can you tell me what the ISE runtime expects? And does it make a
difference if you pass a STRING_32?
-- 
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 wonder whether ISE (and hence FreeELKS) accepts leading
>     Eric> and trailing spaces.
> 
> I've assumed not (this needs checking, but do we need to be
> consistent?).

We need to be consistent if we want to call the compiler version
(which might be more optimized than what we can do) when available.

And having {STRING}.to_integer_64 (when available) and
{KL_STRING_ROUTINES}.to_integer_64 with different behaviors is
just asking for troubles.

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

[gobo-eiffel-develop] Flat Degree 3 in XM_XPATH_EXCEPTION_ROUTINES

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

Running 'geant test_debug_ge' in $GOBO/test/precomp showed these
flat Degree 3 errors:

[VUEX-2] class XM_XPATH_EXCEPTION_ROUTINES (ANY,158,21): feature 
`is_equal' of class XM_XPATH_EXCEPTION_ROUTINES is not exported to class 
XM_XPATH_EXCEPTION_ROUTINES.
----
[VUEX-2] class XM_XPATH_EXCEPTION_ROUTINES (ANY,130,36): feature 
`is_deep_equal' of class XM_XPATH_EXCEPTION_ROUTINES is not exported to 
class XM_XPATH_EXCEPTION_ROUTINES.
----
[VUEX-2] class XM_XPATH_EXCEPTION_ROUTINES (ANY,85,36): feature 
`standard_is_equal' of class XM_XPATH_EXCEPTION_ROUTINES is not exported 
to class XM_XPATH_EXCEPTION_ROUTINES.
----
[VUEX-2] class XM_XPATH_EXCEPTION_ROUTINES (ANY,72,36): feature 
`is_equal' of class XM_XPATH_EXCEPTION_ROUTINES is not exported to class 
XM_XPATH_EXCEPTION_ROUTINES.
----
[VUEX-2] class XM_XPATH_EXCEPTION_ROUTINES (ANY,253,16): feature 
`deep_twin' of class XM_XPATH_EXCEPTION_ROUTINES is not exported to 
class XM_XPATH_EXCEPTION_ROUTINES.
----

I fixed them by explicitly inheriting from ANY to make sure that
its features were exported.

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

[gobo-eiffel-develop] SVN properties for new files

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

col...@us... wrote:
> Added Paths:
> -----------
>     gobo/trunk/library/xml/xpath/expression/xm_xpath_arithmetic_signature.e
>     gobo/trunk/library/xml/xpath/sort/xm_xpath_exception_routines.e
>     gobo/trunk/library/xml/xslt/sort/xm_xslt_sorted_node_iterator.e

When adding new files to SVN, please make sure that the following
properties are set correctly,

    svn:eol-style   native
    svn:keywords    Author Date Id Revision

as indicated in this message:

    http://www.nabble.com/Subversion-tf3117603.html

Here the property svn:keywords is missing. I just added it.

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

Re: [gobo-eiffel-develop] Compiling Gobo integration

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

Colin Paul Adams wrote:
> Eric, do you have an ace file for compiling integration on Gobo?

My Ace file has been converted to ECF by EiffelStudio some time
ago, so I'm not sure the Ace file is still OK. It would be easier
if EiffelStudio supported Ace file natively instead of converting
them. Anyway, here it is.

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

[gobo-eiffel-develop] Compiling Gobo integration

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

Eric, do you have an ace file for compiling integration on Gobo?

I've finally got round to checking out a pristine copy from subversion
for checking missing classes.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Error compiling with gec

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

Colin Paul Adams wrote:
> When I try to run the xpath and xslt test suites (I have made a lot of
> changes to the library) with gec, I get:
> 
> [GVKFE-1] class TYPED_POINTER: feature `pointer_item' is missing in kernel class TYPED_POINTER. 

It's because gec needs to be recompiled. You need
to make an update from SVN and then run the bootstrap
(or just compile gec in $GOBO/src/gec and copy it to
$GOBO/bin).

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

[gobo-eiffel-develop] Error compiling with gec

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

When I try to run the xpath and xslt test suites (I have made a lot of
changes to the library) with gec, I get:

[GVKFE-1] class TYPED_POINTER: feature `pointer_item' is missing in kernel class TYPED_POINTER. 
-- 
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> For consistency with
>     Eric> `is_hexadecimal' I would name the old feature `is_decimal'
>     Eric> (rather than `is_decimal_digits').
> 
> OK.
> And perhaps the header comment should explain that it returns True
> only if every character is a decimal digit from the ASCII block of
> Unicode (there are other sets of decimal digits).

OK. That's what the ELKS spec for `is_integer' does:

     http://www.gobosoft.com/eiffel/nice/elks01/string.html#is_integer

I wonder whether ISE (and hence FreeELKS) accepts leading and
trailing spaces.

>     Eric> what is in ELKS for `is_integer' to see how we can apply it
>     Eric> to `is_integer_64'. As far as I can see, none of those
>     Eric> accepts underscores (unlike Eiffel INTEGER_64 literals).
> 
> What about leading +/-?

They're accepted.

>     >> But then we have an inconsistent story with is_integer. Can we
>     >> rename this to is_decimal_digits? This will break existing
>     >> clients, so we can only do that if the next Gobo release is
>     >> numbered 4.0 (there is a precedent in that the upgrade from 2.0
>     >> to 3.0 broke some existing clients).
> 
>     Eric> Do we need to break code now, or go to the "obsolete" stage
>     Eric> before?
> 
> I guess we can define is_decimal as a duplicate of is_integer for now,
> and mark is_integer as obsolete for the next release.

Yes.

-- 
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> For consistency with
    Eric> `is_hexadecimal' I would name the old feature `is_decimal'
    Eric> (rather than `is_decimal_digits').

OK.
And perhaps the header comment should explain that it returns True
only if every character is a decimal digit from the ASCII block of
Unicode (there are other sets of decimal digits).

    Eric> what is in ELKS for `is_integer' to see how we can apply it
    Eric> to `is_integer_64'. As far as I can see, none of those
    Eric> accepts underscores (unlike Eiffel INTEGER_64 literals).

What about leading +/-?

    >> But then we have an inconsistent story with is_integer. Can we
    >> rename this to is_decimal_digits? This will break existing
    >> clients, so we can only do that if the next Gobo release is
    >> numbered 4.0 (there is a precedent in that the upgrade from 2.0
    >> to 3.0 broke some existing clients).

    Eric> Do we need to break code now, or go to the "obsolete" stage
    Eric> before?

I guess we can define is_decimal as a duplicate of is_integer for now,
and mark is_integer as obsolete for the next release.
-- 
Colin Adams
Preston Lancashire

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

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

Colin Paul Adams wrote:
> and is_decimal_digits is certainly a better name than is_integer,
> because the latter suggests (to me) a necessary and sufficient
> condition for converting to INTEGER, which it isn't.

Class KL_STRING_ROUTINES was initially written to have a
compiler independent version of features that are in class
STRING. At the time of writing, feature `is_integer' was
what was available in some compilers but not in others.
ELKS fixed the specification of `is_integer' and now it
is clear that we should rename this feature in KL_STRING_ROUTINE
and provide another implementation (following ELKS spec)
for `is_integer'. In fact when `is_integer' was introduced
in KL_STRING_ROUTINES it was to be used as precondition
of STRING.to_integer, so this modification will just fix
a potential bug (old versions of compilers were not dealing
with the fact that the value had to fit into an INTEGER).
For consistency with `is_hexadecimal' I would name the
old feature `is_decimal' (rather than `is_decimal_digits').

> In any case, an is_integer_64 routine is needed as a pre-condition for
> to_integer_64.
> 
> And we first need to decide what it should stand for.
> 
> The most intuitive meaning is that is_integer_64 implies that the
> contents of the string concerned matches the lexical pattern of an
> Eiffel INTEGER_64 literal. In which case my initial implementation of
> to_integer_64 is insufficient.

I don't think that KL_STRING_ROUTINES is there to reinvent
the wheel (we have the string library for that). In KL_STRING_ROUTINES
we should just make routines compiler independent. So we should
just look at what is already provided in Eiffel compilers supporting
this feature, and what is in ELKS for `is_integer' to see how
we can apply it to `is_integer_64'. As far as I can see, none
of those accepts underscores (unlike Eiffel INTEGER_64 literals).

> But then we have an inconsistent story with is_integer. Can we rename
> this to is_decimal_digits? This will break existing clients, so we can
> only do that if the next Gobo release is numbered 4.0 (there is a
> precedent in that the upgrade from 2.0 to 3.0 broke some existing clients).

Do we need to break code now, or go to the "obsolete" stage
before?

-- 
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:
    >> 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 still believe that a routine in KL_STRING_ROUTINES should
    Eric> not make such assumption as to whether the string comes from
    Eric> a parser or not.

Actually, the assumption is not that it ALWAYS comes from a parser,
but that it usually does.

In the other cases, the client can always call:

if is_integer and then is_integer_64 then

Of course you didn't like this.

It wouldn't like quite so bad if it were written as:

if is_decimal_digits and then is_integer_64 then

and is_decimal_digits is certainly a better name than is_integer,
because the latter suggests (to me) a necessary and sufficient
condition for converting to INTEGER, which it isn't.

But I'm guessing you won't like it any better.

    Eric>     if my_string.count < 19 then use INTEGER_64 else use
    Eric> MA_DECIMAL end

I had thought of that, and indeed it may be the better practical
solution (this isn't clear - runtime performance is far more important
than XPath parsing time on the whole, but the extra times that
MA_DECIMAL is needed are unlikely to occur often).

In any case, an is_integer_64 routine is needed as a pre-condition for
to_integer_64.

And we first need to decide what it should stand for.

The most intuitive meaning is that is_integer_64 implies that the
contents of the string concerned matches the lexical pattern of an
Eiffel INTEGER_64 literal. In which case my initial implementation of
to_integer_64 is insufficient.

But then we have an inconsistent story with is_integer. Can we rename
this to is_decimal_digits? This will break existing clients, so we can
only do that if the next Gobo release is numbered 4.0 (there is a
precedent in that the upgrade from 2.0 to 3.0 broke some existing clients).
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] signature of XM_XPATH_DECIMAL_VALUE.make_from_integer

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

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

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

    Eric> I also had to comment out the precondition of
    Eric> `make_from_string' in XM_XPATH_MACHINE_INTEGER_VALUE because
    Eric> `is_integer_64' does not exist in class STRING in ISE
    Eric> 5.6. I'm not sure if it's in SE 1.2r7 either, but I didn't
    Eric> try. This routine ought to be in KL_STRING_ROUTINES, but the
    Eric> name has been hijacked by a more specific need.

It isn't. Would need such a routine as well.

- -- 
All the best,

Berend de Boer


PS: This email has been digitally signed if you wonder what the strange
characters are that your outdated 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/>

iD8DBQFF3oWXIyuuaiRyjTYRAnLaAKDVI1048JTWucAOOYy9AUaKPP4vbACgn1k9
wlM1ak/8LnkhxqjyXGryF7w=
=EpV+
-----END PGP SIGNATURE-----

Re: [gobo-eiffel-develop] group task for geant

[Jocelyn <li...@dj...>]

May be we can not define a proper RND "define" for this "group"
but use it whenever needed with <element name="group" />
<element name="target">
...
    <zeroOrMore>
        <ref  name="tasks" />
        <element name="group">
            <zeroOrMore>
                   <ref name="tasks" />
            </zeroOrMore>
        </element>
     </zeroOrMore>
</element>

Except the RNG point, I guess we could try to have a notion of group in
geant ..
and then do not have a specific "group" task.

In my (test) code, the group task and command were almost empty ...
so we could create a GEANT_GROUP  and handle this for tasks, or even
group of options, group of .. whatever

Jocelyn

On 2/22/2007 15:16 PM, Eric Bezault wrote:
> Jocelyn wrote:
>> For now, I made the GEANT_GROUP_TASK and GEANT_GROUP_COMMAND.
>> So this is a basic geant task, which can be used as any task.
>> It doesn't have any extra semantic appart from being a tasks containing
>> a sequential group of tasks.
>>
>> The schema should looks like
>> <define name="group">
>>   <element name="group">
>>     <ref name="dir_if_unless"/>
>>     <optional>
>>         <attribute name="name"/>
>>     </optional>
>>     <ref name="tasks"/>
>>   </element>
>> </define>
>>
>> so a group can include another group and so on, as the example in my
>> previous post.
>> Does it answer the question ?
>
> Yes, but it's more restrictive than I thought. It would
> be great if there was a mean to use groups as a kind of
> parentheses to group any kind of elements. Now that <group>
> is used to group tasks, will it be possible to use it
> later on to group other kinds of elements? Or will we be
> out of luck because <group> is already used for tasks?
>

Re: [gobo-eiffel-develop] group task for geant

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

Jocelyn wrote:
> For now, I made the GEANT_GROUP_TASK and GEANT_GROUP_COMMAND.
> So this is a basic geant task, which can be used as any task.
> It doesn't have any extra semantic appart from being a tasks containing
> a sequential group of tasks.
> 
> The schema should looks like
> <define name="group">
>   <element name="group">
>     <ref name="dir_if_unless"/>
>     <optional>
>         <attribute name="name"/>
>     </optional>
>     <ref name="tasks"/>
>   </element>
> </define>
> 
> so a group can include another group and so on, as the example in my
> previous post.
> Does it answer the question ?

Yes, but it's more restrictive than I thought. It would
be great if there was a mean to use groups as a kind of
parentheses to group any kind of elements. Now that <group>
is used to group tasks, will it be possible to use it
later on to group other kinds of elements? Or will we be
out of luck because <group> is already used for tasks?

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