gobo-eiffel-develop — Development discussions

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

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

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 ?

Jocelyn

On 2/21/2007 20:08 PM, Eric Bezault wrote:

> > How does it look in the schema? Is there a way to express
> > that when <group> appears where a task is expected, then
> > it should contain tasks. And when it appears in places
> > where a foo is expected then it should contain foos, and
> > not tasks.
> >
>   

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

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

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 ?

Jocelyn

On 2/21/2007 20:08 PM, Eric Bezault wrote:
> How does it look in the schema? Is there a way to express
> that when <group> appears where a task is expected, then
> it should contain tasks. And when it appears in places
> where a foo is expected then it should contain foos, and
> not tasks.
>

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

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

Jocelyn wrote:
> I quickly made some changes and addition to geant to be able to have
> <group /> task
> the addition and changes are in the attached zip file.
> 
> I could have commited it, but first I wanted to know your feeling about
> this.
> And ... I made small changes to geant to handle this, maybe this could
> be better by having a common ancestor GEANT_GROUP
> for GEANT_TARGET and GEANT_GROUP_TASK for instance ...
> 
> But for now, my changes are safe and do not break any code. It is just
> addition.
> 
> So I'll wait for your comments, and if none, I guess I'll commit the
> changes to the svn repository.
> 
> an example is:
> 
> <?xml version="1.0"?>
> <project name="test_group" default="test">
>     <target name="test" >
>         <echo message="test group..." />
>         <input variable="cont" message="Continue ?" validargs="y,n"
> defaultvalue="y" answer_required="true" />
>         <group if="${cont}=y" >
>             <echo message="group started" />
>             <echo message=" ### Select group ### " />
>             <input variable="selection" message="Select a group (a|b|c)"
> validargs="a,b,c" defaultvalue="a" answer_required="true" />
>             <group name="A" if="$selection=a" >
>                 <echo message="group A.1" />
>                 <echo message="group A.2" />
>                 <echo message="group A.3" />
>             </group>
>             <group name="B" if="$selection=b" >
>                 <echo message="group B.1" />
>                 <echo message="group B.2" />
>                 <echo message="group B.3" />
>             </group>
>             <echo message="Group C" if="$selection=c" />
>             <echo message="group terminated" />
>         </group>
>     </target>
> </project>

How does it look in the schema? Is there a way to express
that when <group> appears where a task is expected, then
it should contain tasks. And when it appears in places
where a foo is expected then it should contain foos, and
not tasks.

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

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

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

In order to keep it compilable with ISE 5.6, I had to change
the signature of `make_from_integer' in XM_XPATH_DECIMAL_VALUE
from:

   make_from_integer (a_value: INTEGER_32) is

to:

   make_from_integer (a_value: INTEGER) is

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

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

Re: [gobo-eiffel-develop] Gobo Eiffel Library 3.4/3.5: Bug Found

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

Kwon, Jimmy Y. wrote:
> Eric Bezault, Gobosoft:
> 
> No problem... glad I could help. It's good to know that "pi" is still
> the same constant I remember!
> 
> Would I be able to get the updated st_double_formatter.e file from your
> official repository. Is it under Subversion, publicly accessible through
> the Internet, or is it restricted only to Gobo developers? Thanks.

It's publicly available:

     https://sourceforge.net/svn/?group_id=24591

The file is here:

http://gobo-eiffel.svn.sourceforge.net/viewvc/gobo-eiffel/gobo/trunk/library/string/formatter/parameter/st_double_formatter.e?revision=5892&view=markup

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

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

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

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.

I still believe that a routine in KL_STRING_ROUTINES should
not make such assumption as to whether the string comes from
a parser or not.

If you don't want to parse the string twice, then ask your
tokenizer to make the segregation between numbers that fit
into INTEGER_64 and those that don't. And if this appears to
be too complicated, then there is another solution. If I
understood correctly the whole idea is to improve performance
by using INTEGER_64 instead of MA_DECIMAL whenever possible.
But should you use INTEGER_64 every time it is possible, or
have a heuristic which is even faster than your current
implementation of `is_integer_64' and will work most of the
time? A possible heuristic for example is just to check the
number of characters in your string:

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

This check is just a heuristic. It will not catch leading zeros
and numbers between 1000000000000000000 and 9223372036854775807.
But it's super-fast. So it might be worth using that, even if
for some numbers you will use MA_DECIMAL instead of INTEGER_64.
But hey, we have to make trade-off and stop somewhere. For example
in your current implementation there are numbers that could fit
into an NATURAL_64 but are handled as MA_DECIMAL because they
don't fit into INTEGER_64.

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

Re: [gobo-eiffel-develop] Gobo Eiffel Library 3.4/3.5: Bug Found

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

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

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

    Eric> Apart from that, if nobody objects, I will keep your patch
    Eric> as-is.

No, good catch and excellent fix.

- -- 
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/>

iD8DBQFF1oHtIyuuaiRyjTYRAm1cAKDBVqoBG5gf+/HFumonXDUG/9h2hQCg0VgS
B7kjyLkP9NUn0VO3KBttF5M=
=TCHd
-----END PGP SIGNATURE-----

Re: [gobo-eiffel-develop] Gobo Eiffel Library 3.4/3.5: Bug Found

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

Kwon, Jimmy Y. wrote:
> Running the above test procedure with the fix produces the expected
> results:
> d1=941.65899999999817
> d2=941.659000000
> 
> Other test cases:
> d := 941.99999999999817
> produces the expected:
> d1=941.99999999999818
> d2=942.000000000
> 
> I haven't done exhaustive testing on this, but the temporary fix is
> enough of a workaround for me at the moment.
> 
> I hope this was helpful.

Yes, thank you very much Jim. I made a quick review of your patch.
In order to reuse memory space (and avoid to put too much on the GC),
I think that I will but your `fff_list' list out of the routine and
turn it to a DS_ARRAYED_LIST. That way it can be reused at each call
instead of creating a new one each time. Apart from that, if nobody
objects, I will keep your patch as-is.

I ran our test cases with your patch and one test failed:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\gobo\test\string>geant test_debug_ge

Testing xstring...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

Test Summary for xstring

# Passed:     41 tests
# FAILED:     1 test
# Aborted:    0 test
# Total:      42 tests (253 assertions)

Test Results:
FAIL:  [ST_TEST_SCIENTIFIC_FORMATTER.test_other_examples] test6
    expected:  -123  100    400 123 c true some string 3.141593e+00 
4.41593451
    but  got:  -123  100    400 123 c true some string 3.141593e+00 
3.14159346

BUILD FAILED!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After looking at it, it looks like the test was wrong:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
a_format := "$5i $4x $6o $u $c $b $3s $8e $7.8f "
assert_equal ("test6", " -123  100    400 123 c true some string 
3.141593e+00 4.41593451 ", format (a_format, << integer_cell (-123), 
integer_cell (256), integer_cell (256), integer_cell (123), 
character_cell ('c'), boolean_cell (True), "some string", double_cell 
(3.1415934563), double_cell (3.1415934563)>>))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and your patch allowed us to point it out. Indeed, applying
$7.8f on 3.1415934563 cannot yield 4.41593451!

Thank you.

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

Re: [gobo-eiffel-develop] Gobo Eiffel Library 3.4/3.5: Bug Found

[Kwon, J. Y. <jim...@ng...>]

Gobo Developers Mailing List:

There's a small precision problem in using ST_FORMATTING_ROUTINES to
format doubles, e.g.:

test_0001 is
        -- Test procedure.
    local
        str_fmt: ST_FORMATTING_ROUTINES
        d: DOUBLE
    do
        d :=3D 941.65899999999817
        print( "d1=3D" + d.out + "%N" )
        print( "d2=3D" + str_fmt.format_single( "$11.9f",
str_fmt.double_cell( d ) ) + "%N" )
    end -- test_local

Running the above test procedure will produce the results:
d1=3D941.65899999999817
d2=3D942.589999910


'd2' is bizarre and unexpected.

The problem area is in ST_DOUBLE_FORMATTER (under the
string/formatter/parameter/st_double_formatter.e), in the routine
'build_integer_and_fractional_parts'. The developer comment in the
routine mentions a fix to handle large precisions (e.g., 8 or more
decimal places) by handling the fractional part of the original value
into "pieces" of 8 digits. Unfortunately, this fix didn't quite handle
rounding issues correctly.

Here's the old code:

	build_integer_and_fractional_parts (d: DOUBLE) is
			-- Build `integer_part', `fractional_part' and
`fsign' for `d'.
			--=20
			-- This function entered as replacing of simple
expression:
			--   create f_f.make
(floor((fractional_part*10^(precision))+0.5))
			-- which fails in case of large precision.
			-- Now we obtain fraction part with pieces of
decimal_digit_count digits.
		local
			i: INTEGER
			fa: DOUBLE
			fp, fff: DOUBLE
		do
			fa :=3D d.abs
			fsign :=3D double_sign (d)
			STRING_.wipe_out (fractional_part)
			integer_part :=3D DOUBLE_.floor_to_integer (fa)
			from
				i :=3D precision
				fp :=3D fa - integer_part
			until
				i <=3D decimal_digit_count - 1
			loop
				fff :=3D fp * (10.0 ^ decimal_digit_count)
-- .truncated_to_real
				append_integer_to_string
(DOUBLE_.floor_to_integer (fff), decimal_digit_count, fractional_part)
				fp :=3D fff - fff.floor
				i :=3D i - decimal_digit_count
			end
			append_integer_to_string
(DOUBLE_.floor_to_integer ((fp * 10.0 ^ i) + 0.5), i, fractional_part)
			check new_count: fractional_part.count =3D
precision or fractional_part.count =3D precision + 1 end
			if fractional_part.count =3D precision then
				integer_part :=3D integer_part * fsign
			else
					-- There is overflow.
					-- We should add 1 to the
int_part ...
				integer_part :=3D (integer_part + 1) *
fsign
					-- ... and remove extraneous '1'
				fractional_part.remove (1)
			end
			if not fractional_part.is_empty then
				fractional_part.precede ('.')
			end
		end


Here's a temporary fix, until perhaps one of the Gobo Eiffel library
developers can come up with a proper (more elegant?) solution (I've left
in parts of the old code commented out for reference). The fix stores
the "pieces" of 8 fractional digits in a temporary list, rounds the last
"piece," back-propagates the "overflow" carry through the temporary list
if necessary, then finally assembles the fractional digits string. If
the entire fractional part overflowed, then the integer portion is
incremented as well:

	build_integer_and_fractional_parts (d: DOUBLE) is
			-- Build `integer_part', `fractional_part' and
`fsign' for `d'.
			--
			-- This function entered as replacing of simple
expression:
			--   create f_f.make
(floor((fractional_part*10^(precision))+0.5))
			-- which fails in case of large precision.
			-- Now we obtain fraction part with pieces of
decimal_digit_count digits.
			-- 02/14/2007 JYK - Added correct handling of
those "pieces."
		local
			i: INTEGER
			fa: DOUBLE
			fp, fff: DOUBLE
			fff_list: DS_BILINKED_LIST[ INTEGER ] -- Holds
fractional part pieces
			rounded_int: INTEGER
			overflow_int: INTEGER
			is_overflow_consumed: BOOLEAN
		do
		    create fff_list.make
			fa :=3D d.abs
			fsign :=3D double_sign (d)
			STRING_.wipe_out (fractional_part)
			integer_part :=3D DOUBLE_.floor_to_integer (fa)
			from
				i :=3D precision
				fp :=3D fa - integer_part
			until
				i <=3D decimal_digit_count - 1
			loop
				fff :=3D fp * (10.0 ^ decimal_digit_count)
-- .truncated_to_real
--				append_integer_to_string
(DOUBLE_.floor_to_integer (fff), decimal_digit_count, fractional_part)
				fff_list.put_last
(DOUBLE_.floor_to_integer (fff))
				fp :=3D fff - fff.floor
				i :=3D i - decimal_digit_count
			end
			rounded_int :=3D DOUBLE_.rounded_to_integer (fp *
10.0 ^ i)
			overflow_int :=3D DOUBLE_.truncated_to_integer (10
^ i)
			if rounded_int >=3D overflow_int then
			    -- The final digits have "overflowed" -
reinitialize 'rounded_int'
			    -- and propagate the carry through the
previous fractional digit
			    -- pieces.
			    rounded_int :=3D 0
			    from
			        fff_list.finish
			        overflow_int :=3D
DOUBLE_.truncated_to_integer (10 ^ decimal_digit_count)
			    until
					is_overflow_consumed or
fff_list.off
			    loop
					fff_list.replace_at
(fff_list.item_for_iteration + 1)
			        if fff_list.item_for_iteration <
overflow_int then
			            -- No more overflow - all done.
			            is_overflow_consumed :=3D True
			        else
			            -- Current digits have "overflowed"
- reset the digits and
			            -- continue propagating the carry.
						fff_list.replace_at (0)
			        end
			        fff_list.back
			    end
			else
				-- No overflow condition.
			    is_overflow_consumed :=3D True
			end
			-- Build up the fractional digits string from
the digit pieces in
			-- 'fff_list' and 'rounded_int' (containing the
final digits).
			from
			    fff_list.start
			until
			    fff_list.off
			loop
				append_integer_to_string
(fff_list.item_for_iteration, decimal_digit_count, fractional_part)
			    fff_list.forth
			end
--			append_integer_to_string
(DOUBLE_.floor_to_integer ((fp * 10.0 ^ i) + 0.5), i, fractional_part)
			append_integer_to_string ( rounded_int, i,
fractional_part )
--			check new_count: fractional_part.count =3D
precision or fractional_part.count =3D precision + 1 end
--			if fractional_part.count =3D precision then
			if is_overflow_consumed then
				integer_part :=3D integer_part * fsign
			else
					-- There is overflow.
					-- We should add 1 to the
int_part ...
				integer_part :=3D (integer_part + 1) *
fsign
--					-- ... and remove extraneous '1'
--				fractional_part.remove (1)
			end
			if not fractional_part.is_empty then
				fractional_part.precede ('.')
			end
		end



Running the above test procedure with the fix produces the expected
results:
d1=3D941.65899999999817
d2=3D941.659000000

Other test cases:
d :=3D 941.99999999999817
produces the expected:
d1=3D941.99999999999818
d2=3D942.000000000

I haven't done exhaustive testing on this, but the temporary fix is
enough of a workaround for me at the moment.

I hope this was helpful.

-Jim

Jimmy Y. Kwon
Northrop Grumman Mission Systems
222 W. 6th St., San Pedro, CA 90731
(310) 831-0611 x2209


-----Original Message-----
From: Eric Bezault [mailto:er...@go...]=20
Sent: Wednesday, February 14, 2007 4:31 PM
To: Kwon, Jimmy Y.
Cc: Gobo Developers Mailing List
Subject: Re: Gobo Eiffel Library 3.4/3.5: Bug Found

Hi Jim,

Kwon, Jimmy Y. wrote:
> Eric Bezault, Gobosoft:
>=20
> I'm a software engineer at Northrop Grumman, using Eiffel in my
project.
>=20
> I've found a code bug within Gobo Eiffel Library version 3.5 (the same
> bug exists in version 3.4). The class with the problem is
> ST_DOUBLE_FORMATTER. Although I've (at least temporarily) fixed the
> problem for myself, I was wondering if there was an official way to
> inform Gobosoft of the problem, steps to reproduce the problem, etc.,
so
> that a fix could be released in the next official release.
>=20
> I could also provide source code containing the (temporary) fix if you
> wish. Thank goodness for open source libraries.

We don't use SourceForge's bug tracker yet, although we will
use it soon. In the meantime you can report the bug (with the
possible fix) to the developer mailing list:
<gob...@li...>

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

Re: [gobo-eiffel-develop] Gobo Eiffel Library 3.4/3.5: Bug Found

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

Hi Jim,

Kwon, Jimmy Y. wrote:
> Eric Bezault, Gobosoft:
> 
> I'm a software engineer at Northrop Grumman, using Eiffel in my project.
> 
> I've found a code bug within Gobo Eiffel Library version 3.5 (the same
> bug exists in version 3.4). The class with the problem is
> ST_DOUBLE_FORMATTER. Although I've (at least temporarily) fixed the
> problem for myself, I was wondering if there was an official way to
> inform Gobosoft of the problem, steps to reproduce the problem, etc., so
> that a fix could be released in the next official release.
> 
> I could also provide source code containing the (temporary) fix if you
> wish. Thank goodness for open source libraries.

We don't use SourceForge's bug tracker yet, although we will
use it soon. In the meantime you can report the bug (with the
possible fix) to the developer mailing list:
<gob...@li...>

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

Re: [gobo-eiffel-develop] Dynamic type set for Result of an external function

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

Howard Thomson wrote:
> Hi all,
> 
> I am attempting to compile a WIN32 version of my EDP project using gec.
> 
> The gobo-3.5 version of gec does not (apparently) recognize that an external 
> 'C' routine can return a non-Void result, in that it generates a direct call 
> to gevoid() when making a qualified call on the result of the external call.

This is true. So far only results of expanded basic types and STRING
are implemented.

> I need to adapt the compiler to assume that the typeset of the return from an 
> external call is the full typeset of the descendants of the type of the 
> Result of the external call.

This is indeed what needs to be done, but even more. And that's
the even more which made me postpone the implementation of that.
Indeed, for each such descendants, you should also consider the
full type set for each of its attributes, and so one recursively.
Indeed, who knows what has been done on the C side, assigning
values to attributes of attributes of the result without the
dynamic type set builder knowing about that.

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

Re: [gobo-eiffel-develop] Dynamic type set for Result of an external function

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

Howard Thomson wrote:
> Hi all,
> 
> I am attempting to compile a WIN32 version of my EDP project using gec.
> 
> The gobo-3.5 version of gec does not (apparently) recognize that an external 
> 'C' routine can return a non-Void result, in that it generates a direct call 
> to gevoid() when making a qualified call on the result of the external call.

This is true. So far only results of expanded basic types and STRING
are implemented.

> I need to adapt the compiler to assume that the typeset of the return from an 
> external call is the full typeset of the descendants of the type of the 
> Result of the external call.

This is indeed what needs to be done, but even more. And that's
the even more which made me postpone the implementation of that.
Indeed, for each such descendants, you should also consider the
full type set for each of its attributes, and so one recursively.
Indeed, who knows what has been done on the C side, assigning
values to attributes of attributes of the result without the
dynamic type set builder knowing about that.

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

[gobo-eiffel-develop] Dynamic type set for Result of an external function

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

Hi all,

I am attempting to compile a WIN32 version of my EDP project using gec.

The gobo-3.5 version of gec does not (apparently) recognize that an external 
'C' routine can return a non-Void result, in that it generates a direct call 
to gevoid() when making a qualified call on the result of the external call.

I need to adapt the compiler to assume that the typeset of the return from an 
external call is the full typeset of the descendants of the type of the 
Result of the external call.

Can anyone suggest what is needed ?

I will be updating the SVN code on sf.net/projects/edp with the gobo-3.5 
version of Linux and WIN32 alpha(!) code when I have both versions working.

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] Regular expression syntax

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Colin Paul Adams wrote:
>     >>>>>>> "Colin" == Colin Paul Adams <co...@co...>
>     >>>>>>> writes:
>     Colin> For XML 1.1, the equivalent to \c is 3830417 bytes long.
>     Colin> This is definitely too big, so something is wrong with the
>     Colin> test program.
>     >> No.  What is wrong is that this figure includes all as yet
>     >> unallocated code-points (barring a few excluded ones).  For XML
>     >> 1.0, the figure is 104080.  Either way, the strings are too
>     >> long
> 
>     Eric> You're probably right. On the other hand is it that big
>     Eric> compared to what you have generated in the classes
>     Eric> ST_UNICODE_VNNN_*_ROUTINES?
> 
> Yes.
> Because the latter are direct access (looking up values in an array),
> whereas the former requires a search of the entire string 

For compiled regexp, I don't think it searches in the
pattern string. It builds arrays and uses these arrays
to match the input string.

-- 
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> Colin Paul Adams wrote:
    >>>>>>> "Colin" == Colin Paul Adams <co...@co...>
    >>>>>>> writes:
    Colin> For XML 1.1, the equivalent to \c is 3830417 bytes long.
    Colin> This is definitely too big, so something is wrong with the
    Colin> test program.
    >> No.  What is wrong is that this figure includes all as yet
    >> unallocated code-points (barring a few excluded ones).  For XML
    >> 1.0, the figure is 104080.  Either way, the strings are too
    >> long

    Eric> You're probably right. On the other hand is it that big
    Eric> compared to what you have generated in the classes
    Eric> ST_UNICODE_VNNN_*_ROUTINES?

Yes.
Because the latter are direct access (looking up values in an array),
whereas the former requires a search of the entire string (in the
worst case of no match).
-- 
Colin Adams
Preston Lancashire

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

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

Colin Paul Adams wrote:
>>>>>> "Franck" == Franck Arnaud <fr...@ne...> writes:
> 
>     >> For XML 1.1, the equivalent to \c is 3830417 bytes long.
>     >> 
>     >> This is definitely too big, so something is wrong with the test
>     >> program. Can anyone see where the fault is (I know it's not the
>     >> most efficient way of doing it):
> 
>     Franck> it should get (much?) more compact by collapsing adjacent
>     Franck> ranges into forms "\x\y[\z1-\z2]" or "\x\y." (example for
>     Franck> 3 byte utf8 sequences.)
> 
> I don't understand what you mean.

Instead of having:

    (...|\x\y\z1|\x\y\z2|...|\x\y\zn|...)

where \z1, \z2, ..., \zn are consecutive bytes,
you can generate:

    (...|\x\y[\z1-\zn]|...)

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

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

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

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> 
>     Colin> For XML 1.1, the equivalent to \c is 3830417 bytes long.
> 
>     Colin> This is definitely too big, so something is wrong with the
>     Colin> test program.
> 
> No.
> What is wrong is that this figure includes all as yet unallocated
> code-points (barring a few excluded ones).
> 
> For XML 1.0, the figure is 104080.
> 
> Either way, the strings are too long

You're probably right. On the other hand is it that big compared
to what you have generated in the classes ST_UNICODE_VNNN_*_ROUTINES?

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

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

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

>>>>> "Franck" == Franck Arnaud <fr...@ne...> writes:

    >> For XML 1.1, the equivalent to \c is 3830417 bytes long.
    >> 
    >> This is definitely too big, so something is wrong with the test
    >> program. Can anyone see where the fault is (I know it's not the
    >> most efficient way of doing it):

    Franck> it should get (much?) more compact by collapsing adjacent
    Franck> ranges into forms "\x\y[\z1-\z2]" or "\x\y." (example for
    Franck> 3 byte utf8 sequences.)

I don't understand what you mean.

But you have drawn my attention to ranges. E.g. [a-z] is fine, because
both ends are single-byte UTF-8 sequences. But if you put latin-1
accented characters (for instance) at the end of the ranges, then
nothing works.
-- 
Colin Adams
Preston Lancashire

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

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

> For XML 1.1, the equivalent to \c is  3830417 bytes long.
> 
> This is definitely too big, so something is wrong with the test
> program. Can anyone see where the fault is (I know it's not the most
> efficient way of doing it):

it should get (much?) more compact by collapsing adjacent ranges into
forms "\x\y[\z1-\z2]" or "\x\y." (example for 3 byte utf8 sequences.) 

perhaps not to usable level for repetitive use of \c. maybe with a 'let'
construct?

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

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

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

    Colin> For XML 1.1, the equivalent to \c is 3830417 bytes long.

    Colin> This is definitely too big, so something is wrong with the
    Colin> test program.

No.
What is wrong is that this figure includes all as yet unallocated
code-points (barring a few excluded ones).

For XML 1.0, the figure is 104080.

Either way, the strings are too long, so a proper Unicode-aware
regular expression engine is needed.
-- 
Colin Adams
Preston Lancashire

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

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

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

>>>>> "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.

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

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

I wrote a test program to measure this.

For XML 1.1, the equivalent to \c is  3830417 bytes long.

This is definitely too big, so something is wrong with the test
program. Can anyone see where the fault is (I know it's not the most
efficient way of doing it):

class TEST

inherit

	UC_UNICODE_FACTORY

	UC_UNICODE_CONSTANTS

	XM_UNICODE_CHARACTERS_1_1

	KL_IMPORTED_STRING_ROUTINES

create

	make

feature {NONE} -- Initialization

	make is
		-- Test byte count of equivalent regexp to [\c]+.
		local
			i: INTEGER
			l_regexp: STRING
		do
			from
				l_regexp := ""
				i := 1
			until
				i > maximum_unicode_character_code
			loop
				if is_name_char (i) then
					l_regexp := STRING_.appended_string (l_regexp, 	new_unicode_string_filled_code (i, 1))
				end
				i := i + 1
			end
			print (utf8.to_utf8 (l_regexp).count.out + "%N")
		end
	
end
-- 
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> 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.
> 
>     Eric> That's true I forgot about that.
> 
> I have taken that as expressing some more sympathy with my original
> usage presumption.

Well, I still believe that in general purpose class
like KL_STRING_ROUTINES there should not be any
assumption.

-- 
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:
    >> 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.

    Eric> That's true I forgot about that.

I have taken that as expressing some more sympathy with my original
usage presumption.

Therefore I have updated the tests and routines (which should now be
more efficient).
All tests pass with all three compilers (but I didn't try with
assertions on for SE, as I'm getting too short of remaining years).
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] SE 2.1 work-rounds

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

Colin Paul Adams wrote:
> In KI_PLATFORM I see:
> 
> 	Minimum_integer: INTEGER is
> 			-- Smallest supported value of type INTEGER
> 		deferred
> 		ensure
> 			meaningful: Result <= 0
> 				-- Result = - (2 ^ (Integer_bits - 1)):
> #ifdef ISE || VE 
> 			definition: Result = (2 ^ (Integer_bits - 2)) * -2
> #else
> 			-- Problem with ^ in SE 2.1b1:
> 			-- definition: Result = (2 ^ (Integer_bits - 2)) * -2
> #endif
> 
> I think there is a lot of stuff like this still around that could be
> usefully removed, now that we have dropped SE 2.1.

It should be checked that it works with SE 1.2.

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

[gobo-eiffel-develop] SE 2.1 work-rounds

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

In KI_PLATFORM I see:

	Minimum_integer: INTEGER is
			-- Smallest supported value of type INTEGER
		deferred
		ensure
			meaningful: Result <= 0
				-- Result = - (2 ^ (Integer_bits - 1)):
#ifdef ISE || VE 
			definition: Result = (2 ^ (Integer_bits - 2)) * -2
#else
			-- Problem with ^ in SE 2.1b1:
			-- definition: Result = (2 ^ (Integer_bits - 2)) * -2
#endif

I think there is a lot of stuff like this still around that could be
usefully removed, now that we have dropped SE 2.1.
-- 
Colin Adams
Preston Lancashire