gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Converting UC_STRING to/from C pointer to UTF8 octet sequences

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

>>>>> "Paul" == Paul Cohen <pa...@se...> writes:

    Paul> Hi all, I need some advice/feedback on how to convert/create
    Paul> a UC_STRING from a C pointer to a UTF8 byte sequence (and
    Paul> vice versa). I can't find any routines or examples in the
    Paul> Gobo unicode library for doing it. The need for this arises
    Paul> when writing Eiffel shared libraries (with C-style API:s).

    Paul> It is unfortunate that I have to create two "string objects"
    Paul> to perform the "conversion".

You can iterate over the C pointer and do what make_from_utf8 does if
this is a concern. 


    Paul> Returning a pointer to a UTF8 octet sequence is trickier.

It is. I've found out that the only safe way to do this in ISE is to
allocate memory with C (malloc), copy the string to there and give a
pointer to that area to C.

This was tested on a large production system with millions of such
calls, and any attempt to give pointers to an Eiffel object would fail
with weird errors after a while. There appeared to be no safe way to
retrieve a pointer to an ISE Eiffel object, whatever tricks were
applied.

-- 
Cheers,

Berend de Boer

[gobo-eiffel-develop] Converting UC_STRING to/from C pointer to UTF8 octet sequences

[Paul C. <pa...@se...>]

Hi all,

I need some advice/feedback on how to convert/create a UC_STRING from
a C pointer to a UTF8 byte sequence (and vice versa). I can't find any
routines or examples in the Gobo unicode library for doing it. The
need for this arises when writing Eiffel shared libraries (with
C-style API:s).

This is my current appach:

    uc_string_from_utf8_pointer (p: POINTER): UC_STRING is
            -- New UC_STRING object from UTF8 octet sequence pointed to by `p'.
        require
            p_not_default_pointer: p /= default_pointer
        local
            utf8: STRING_8
        do
            create utf8.make_from_c (p)
            create Result.make_from_utf8 (utf8)
        ensure
            result_not_void: Result /= Void
        end

It is unfortunate that I have to create two "string objects" to
perform the "conversion".

Returning a pointer to a UTF8 octet sequence is trickier. An initial
approach could be:

    utf8_pointer_from_uc_string (s: UC_STRING): POINTER is
            -- A pointer to the UTF8 octet sequence of `s'.
        require
            s_not_void: s /= Void
        local
            utf8: STRING_8
            a: ANY
        do
            utf8 := s.to_utf8
            a := utf8.to_c
            Result := $a
        ensure
            result_not_default_pointer: Result /= default_pointer
        end

This is not a good solution since 'utf8' and its memory area may not
be available any longer when the client tries to access the octet
sequence (they are on the stack). Many C API:s are written so that the
caller must supply a memory buffer that the API implementation uses
for returning the result, leaving the caller responsable for memory
management. So a better approach would maybe be something like:

    fill_utf8_buffer_from_uc_string (s: UC_STRING; buffer: STRING_8) is
            -- Fill the buffer with the UTF8 octet sequence of `s'.
        require
            s_not_void: s /= Void
            buffer_not_void: buffer /= Void
            buffer_large_enough: s.to_utf8.count <= buffer.count
        local
            utf8: STRING_8
            a: ANY
            p_buffer, p_utf8: POINTER
        do
            utf8 := s.to_utf8
            a := buffer.to_c
            p_buffer := $buffer
            a := utf8.to_c
            p_utf8 := $a
            p_buffer.memory_copy (p_utf8, utf8.count)
        end

Yet another approach would be for the Eiffel class that implements the
API to maintain a buffer of memory where the returned result is put.
However then one will run into multprogramming problems with accessing
shared data.

Any feedback on this issue would be welcome!

/Paul

-- 
Paul Cohen
www.seibostudios.se
mobile: +46 730 787 035
e-mail: pau...@se...

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

Indeed,
The current gobo's trunk is not Void safe.
At ISE we converted (almost) all Gobo's libraries, and made this version
available at http://github.com/jocelyn/void-safe-gobo-eiffel/tree/master
(almost because currently the ools, tests, and some XSLT related classes
are not converted).

Since Eric doesn't have that much time to integrate the result of the
conversion, I send him small patches from time to time, so that the
official gobo's lib is converted slowly.
The integration sometime requires implementation or interface change to
avoid having dirty code, and there are still points such as
DS_TRAVERSABLE.internal_cursor which should be detachable for
invariant's purpose, which slow down (or even block the progression).

If you see at the code hosted at github (See previous link), you might
noticed the xml cluster has a lot of changes (mostly  check var /= Void
end) to make it Void safe. This is mainly due to the fact some of those
classes use different attribute according to other (boolean status
report) attribute.
So we end up with many "detachable" attribute, and whenever the code use
them, it needs to check if this is attached or not.

Anyway, the conversion goes slowly, but surely. I doubt the official
gobo will integrate all the changes for 6.4, but we never knows ... Eric
might have more time, and maybe someone can review the changes from the
xml cluster, and eventually redesign some part to make it more
void-safety friendly.

So my short answer to your question
1) the official gobo's libraries get converted+integrated incrementally
2) however, the fully converted gobo's lib are available at
http://github.com/jocelyn/void-safe-gobo-eiffel/tree/master

Hope this helps,
-- Jocelyn


Eric Bezault wrote:
> Colin Adams wrote:
>   
>> One client was the test case. I've added a check statement so that it
>> should pass Void-safety.
>>
>> Geant test_debug_ge and geant test_debug_ise both pass, but I presume
>> these are NOT running in Void-safe mode. Is there a way to check that
>> what I have done is sufficient?
>>     
>
> Jocelyn might give a better answer here, but my feeling is that
> the classes are not fully void-safe yet. What is done is incremental
> modifications towards void-safety. So running in void-safe mode
> would still trigger a lot of errors I guess.
>
>   

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

Done.

2009/5/6 Eric Bezault <er...@go...>:
> Colin Adams wrote:
>>
>> Also DT_TEST_STOPWATCH.test_start_stop fails with
>> elapsed_time_positive1 when run with:
>>
>> geant test_ge
>>
>> This is on 64-bit Linux, for what that's worth.
>>
>> Again, I can't see any connection with my changes to the URI classes.
>> Shall I check-in anyway?
>
> Yes.
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

Colin Adams wrote:
> Also DT_TEST_STOPWATCH.test_start_stop fails with
> elapsed_time_positive1 when run with:
> 
> geant test_ge
> 
> This is on 64-bit Linux, for what that's worth.
> 
> Again, I can't see any connection with my changes to the URI classes.
> Shall I check-in anyway?

Yes.

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

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

Also DT_TEST_STOPWATCH.test_start_stop fails with
elapsed_time_positive1 when run with:

geant test_ge

This is on 64-bit Linux, for what that's worth.

Again, I can't see any connection with my changes to the URI classes.
Shall I check-in anyway?

2009/5/6 Colin Adams <col...@go...>:
> OK.
>
> On that basis I was prepared to check in my changes.
>
> But one of the tests has failed - for geant, so I guess this cannot be
> something I have changed, as it will not be using the URI stuff.
>
> Anyway, the failing test is GEANT_FUNCTIONAL_ECHO_TEST.test_built_in_var.
> The failing assertion is test_builtin_var_2 (diff between files
> 'out.txt' and 'out2.txt' at line 1)
>
> I cannot find a file named out2.txt or out.txt.
>
> 2009/5/6 Eric Bezault <er...@go...>:
>> Colin Adams wrote:
>>>
>>> One client was the test case. I've added a check statement so that it
>>> should pass Void-safety.
>>>
>>> Geant test_debug_ge and geant test_debug_ise both pass, but I presume
>>> these are NOT running in Void-safe mode. Is there a way to check that
>>> what I have done is sufficient?
>>
>> Jocelyn might give a better answer here, but my feeling is that
>> the classes are not fully void-safe yet. What is done is incremental
>> modifications towards void-safety. So running in void-safe mode
>> would still trigger a lot of errors I guess.
>>
>> --
>> Eric Bezault
>> mailto:er...@go...
>> http://www.gobosoft.com
>>
>

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

OK.

On that basis I was prepared to check in my changes.

But one of the tests has failed - for geant, so I guess this cannot be
something I have changed, as it will not be using the URI stuff.

Anyway, the failing test is GEANT_FUNCTIONAL_ECHO_TEST.test_built_in_var.
The failing assertion is test_builtin_var_2 (diff between files
'out.txt' and 'out2.txt' at line 1)

I cannot find a file named out2.txt or out.txt.

2009/5/6 Eric Bezault <er...@go...>:
> Colin Adams wrote:
>>
>> One client was the test case. I've added a check statement so that it
>> should pass Void-safety.
>>
>> Geant test_debug_ge and geant test_debug_ise both pass, but I presume
>> these are NOT running in Void-safe mode. Is there a way to check that
>> what I have done is sufficient?
>
> Jocelyn might give a better answer here, but my feeling is that
> the classes are not fully void-safe yet. What is done is incremental
> modifications towards void-safety. So running in void-safe mode
> would still trigger a lot of errors I guess.
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

Colin Adams wrote:
> One client was the test case. I've added a check statement so that it
> should pass Void-safety.
> 
> Geant test_debug_ge and geant test_debug_ise both pass, but I presume
> these are NOT running in Void-safe mode. Is there a way to check that
> what I have done is sufficient?

Jocelyn might give a better answer here, but my feeling is that
the classes are not fully void-safe yet. What is done is incremental
modifications towards void-safety. So running in void-safe mode
would still trigger a lot of errors I guess.

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

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

Colin Adams wrote:
> Looking at the latest code in SVN, I see that ?STRING is used on
> return type of unescape_utf8, but unescape_string has plain STRING
> (not !STRING).
> 
> Is this the policy to follow? Doesn't it mean that the library will
> only be Void-safe if types are considered attached by default?

I guess so. Note that when there is a plain STRING, the postcondition
Result /= Void should be retained for the time being. That way the
code is still correct in non void-safe mode.

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

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

One client was the test case. I've added a check statement so that it
should pass Void-safety.

Geant test_debug_ge and geant test_debug_ise both pass, but I presume
these are NOT running in Void-safe mode. Is there a way to check that
what I have done is sufficient?

2009/5/2 Eric Bezault <er...@go...>:
> Hi Colin,
>
> On January 18, 2007, in commit svn#5840, you changed the implementation
> and contracts of feature `unescaped_utf8' in UT_URL_ENCODING. However,
> after this change of contracts, it looks like you didn't update its
> callers. For example feature `decoded_utf8' in class UT_URI_STRING,
> and hence its callers, still rely on the fact that the result of
> `unescaped_utf8' is supposed to be non-void.
>
> Can you have a look at that? This is a bug which is blocking the
> conversion of Gobo to void-safe mode.
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

Looking at the latest code in SVN, I see that ?STRING is used on
return type of unescape_utf8, but unescape_string has plain STRING
(not !STRING).

Is this the policy to follow? Doesn't it mean that the library will
only be Void-safe if types are considered attached by default?

2009/5/6 Colin Adams <col...@go...>:
> There is a complication in that UT_FILE_URI_ROUTINES is buggy. In
> particular, the routine uri_to_pathname has too liberal a contract.
> I've discussed this extensively with Franck.
>
> One possible solution is to strengthen the precondition so that the
> argument wither contains no colon characters, or it contains exactly
> one, and then the argument starts with "file:" (this would be in
> accordance with the class-level documentation).
>
> With such a precondition, it would then be possible to leave the
> postcondition unchanged - that is, a non-Void Result. In such cases we
> could simply return "create Result.make" for an invalid URI. Since
> this is equivalent to the URI "file:///" (the rot of the file system),
> this isn't attractive.
>
> The more attractive (to me) alternative is to weaken the
> postcondition, so that the return only returns non-Void if a good file
> URI is passed to it. So http://www.some.host/my/path/to/file will
> return Void (currently it returns the same pathname as
> file:///my/path/to/file, which is a clear bug). Then if decoding a
> percent-encoded URI fails (returns Void), we simply return a Void
> pathname.
>
> This means that this routine will always return Void for URIs which
> include percent-encodings which are intended to be in Latin-1. Well,
> that has never been supported by this class, so it should be added to
> the class-level documentation. Note that the inverse routine,
> pathname_to_uri, always produces UTF-8 encoded URIs (when encoding is
> necessary).
>
> 2009/5/3 Colin Adams <col...@go...>:
>> The contract for the routine is correct (the preconditions do not
>> exclude a string which includes escapes representing a non-valid UTF-8
>> byte sequence,
>> such as Latin-1 bytes, or just pure garbage).
>>
>> There is a test that unescape_string returns no byte greater than 255
>> - I think this is redundant (but it would need a postcondition on
>> unescape_string to make it secure),
>> but this is not relevant to the issue in hand.
>>
>> So the clients need changing to accept the possibility of a Void
>> result. I'll look into this on Wednesday (or possibly Tuesday if I
>> have more time than expected).
>>
>> 2009/5/2 Colin Paul Adams <co...@co...>:
>>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>>
>>>    Eric> Hi Colin, On January 18, 2007, in commit svn#5840, you
>>>    Eric> changed the implementation and contracts of feature
>>>    Eric> `unescaped_utf8' in UT_URL_ENCODING. However, after this
>>>    Eric> change of contracts, it looks like you didn't update its
>>>    Eric> callers. For example feature `decoded_utf8' in class
>>>    Eric> UT_URI_STRING, and hence its callers, still rely on the fact
>>>    Eric> that the result of `unescaped_utf8' is supposed to be
>>>    Eric> non-void.
>>>
>>>    Eric> Can you have a look at that? This is a bug which is blocking
>>>    Eric> the conversion of Gobo to void-safe mode.
>>>
>>> I'll take a look early next week.
>>> --
>>> Colin Adams
>>> Preston Lancashire
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now & Save for Velocity, the Web Performance & Operations
>>> Conference from O'Reilly Media. Velocity features a full day of
>>> expert-led, hands-on workshops and two days of sessions from industry
>>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>> _______________________________________________
>>> gobo-eiffel-develop mailing list
>>> gob...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>>>
>>
>

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

There is a complication in that UT_FILE_URI_ROUTINES is buggy. In
particular, the routine uri_to_pathname has too liberal a contract.
I've discussed this extensively with Franck.

One possible solution is to strengthen the precondition so that the
argument wither contains no colon characters, or it contains exactly
one, and then the argument starts with "file:" (this would be in
accordance with the class-level documentation).

With such a precondition, it would then be possible to leave the
postcondition unchanged - that is, a non-Void Result. In such cases we
could simply return "create Result.make" for an invalid URI. Since
this is equivalent to the URI "file:///" (the rot of the file system),
this isn't attractive.

The more attractive (to me) alternative is to weaken the
postcondition, so that the return only returns non-Void if a good file
URI is passed to it. So http://www.some.host/my/path/to/file will
return Void (currently it returns the same pathname as
file:///my/path/to/file, which is a clear bug). Then if decoding a
percent-encoded URI fails (returns Void), we simply return a Void
pathname.

This means that this routine will always return Void for URIs which
include percent-encodings which are intended to be in Latin-1. Well,
that has never been supported by this class, so it should be added to
the class-level documentation. Note that the inverse routine,
pathname_to_uri, always produces UTF-8 encoded URIs (when encoding is
necessary).

2009/5/3 Colin Adams <col...@go...>:
> The contract for the routine is correct (the preconditions do not
> exclude a string which includes escapes representing a non-valid UTF-8
> byte sequence,
> such as Latin-1 bytes, or just pure garbage).
>
> There is a test that unescape_string returns no byte greater than 255
> - I think this is redundant (but it would need a postcondition on
> unescape_string to make it secure),
> but this is not relevant to the issue in hand.
>
> So the clients need changing to accept the possibility of a Void
> result. I'll look into this on Wednesday (or possibly Tuesday if I
> have more time than expected).
>
> 2009/5/2 Colin Paul Adams <co...@co...>:
>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>
>>    Eric> Hi Colin, On January 18, 2007, in commit svn#5840, you
>>    Eric> changed the implementation and contracts of feature
>>    Eric> `unescaped_utf8' in UT_URL_ENCODING. However, after this
>>    Eric> change of contracts, it looks like you didn't update its
>>    Eric> callers. For example feature `decoded_utf8' in class
>>    Eric> UT_URI_STRING, and hence its callers, still rely on the fact
>>    Eric> that the result of `unescaped_utf8' is supposed to be
>>    Eric> non-void.
>>
>>    Eric> Can you have a look at that? This is a bug which is blocking
>>    Eric> the conversion of Gobo to void-safe mode.
>>
>> I'll take a look early next week.
>> --
>> Colin Adams
>> Preston Lancashire
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> gobo-eiffel-develop mailing list
>> gob...@li...
>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>>
>

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

The contract for the routine is correct (the preconditions do not
exclude a string which includes escapes represnting a non-valid UTF-8
byte sequence,
such as Latin-1 bytes, or just pure garbage).

There is a test that unescape_string returns no byte greater than 255
- I think this is redundant (but it would need a postcondition on
unescape_string to make it secure),
but this is not relevant to the issue in hand.

So the clients need changing to accept the possibility of a Void
result. I'll look into this on Wednesday (or possibly Tuesday if I
have more time than expected).

2009/5/2 Colin Paul Adams <co...@co...>:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>
>    Eric> Hi Colin, On January 18, 2007, in commit svn#5840, you
>    Eric> changed the implementation and contracts of feature
>    Eric> `unescaped_utf8' in UT_URL_ENCODING. However, after this
>    Eric> change of contracts, it looks like you didn't update its
>    Eric> callers. For example feature `decoded_utf8' in class
>    Eric> UT_URI_STRING, and hence its callers, still rely on the fact
>    Eric> that the result of `unescaped_utf8' is supposed to be
>    Eric> non-void.
>
>    Eric> Can you have a look at that? This is a bug which is blocking
>    Eric> the conversion of Gobo to void-safe mode.
>
> I'll take a look early next week.
> --
> Colin Adams
> Preston Lancashire
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

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

    Eric> Hi Colin, On January 18, 2007, in commit svn#5840, you
    Eric> changed the implementation and contracts of feature
    Eric> `unescaped_utf8' in UT_URL_ENCODING. However, after this
    Eric> change of contracts, it looks like you didn't update its
    Eric> callers. For example feature `decoded_utf8' in class
    Eric> UT_URI_STRING, and hence its callers, still rely on the fact
    Eric> that the result of `unescaped_utf8' is supposed to be
    Eric> non-void.

    Eric> Can you have a look at that? This is a bug which is blocking
    Eric> the conversion of Gobo to void-safe mode.

I'll take a look early next week.
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] Change of contract in UT_URL_ENCODING.unescaped_utf8

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

Hi Colin,

On January 18, 2007, in commit svn#5840, you changed the implementation
and contracts of feature `unescaped_utf8' in UT_URL_ENCODING. However,
after this change of contracts, it looks like you didn't update its
callers. For example feature `decoded_utf8' in class UT_URI_STRING,
and hence its callers, still rely on the fact that the result of
`unescaped_utf8' is supposed to be non-void.

Can you have a look at that? This is a bug which is blocking the
conversion of Gobo to void-safe mode.

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

Re: [gobo-eiffel-develop] Questions regarding DT_TIME

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

Paul Cohen wrote:
>>>>   4. Is the Gobo project interested in my DT_STOPWATCH class?

It's now in Gobo SVN repository.

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

Re: [gobo-eiffel-develop] Formatting service does not display plus sign

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

Colin Adams wrote:
> I inherited from ST_FORMATTING_SERVICES, and called:
> 
> format ("$+G", <<ds-cell-of-double>>)
> 
> The result was formatted fine except no + sign appeared (it was a
> positive number).
> 
> This looks like a bug to me - I did some debugging, and the + flag was
> recognised and the boolean set accordingly.

It's now fixed and committed in SVN.

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

Re: [gobo-eiffel-develop] Line numbers and other information in XML parsing

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

Sandro De Zanet wrote:
> What is the best method of figuring out data like line or column numbers
> while parsing XML?
> 
> I use the XM_EIFFEL_PARSER with an implementation of XM_CALLBACKS. The
> provided features (callbacks) do not allow to query the current parse
> position in the file. I solve the problem by passing the
> XM_EIFFEL_PARSER instance to the implementation of XM_CALLBACKS.
> 
> Is there a better way of doing this?

It looks like that's how it's done in XM_CALLBACKS_TO_TREE_FILTER.
You have to first call `enable_position_table' to pass the parser.
Then `handle_position' is able to fill in `last_position_table'.

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

[gobo-eiffel-develop] Line numbers and other information in XML parsing

[Sandro De Z. <sa...@ei...>]

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

What is the best method of figuring out data like line or column numbers
while parsing XML?

I use the XM_EIFFEL_PARSER with an implementation of XM_CALLBACKS. The
provided features (callbacks) do not allow to query the current parse
position in the file. I solve the problem by passing the
XM_EIFFEL_PARSER instance to the implementation of XM_CALLBACKS.

Is there a better way of doing this?

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

iEYEARECAAYFAknbx0MACgkQMQrpLaQQ008rZACfauXnJFe4Z2a+58srYmgnmZWF
UA0An21c8tbB1AnlhtTdjbTmDh1c1CjU
=cbbQ
-----END PGP SIGNATURE-----

Re: [gobo-eiffel-develop] Questions regarding DT_TIME

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

Paul Cohen wrote:
>>>   1. Why doesn't DT_TIME.duration use DT_TIME.canonical_duration?
> 
> As a client, without reading the contracts,

"Without reading the contracts"! What a strange thing to do ;-)

>>>   4. Is the Gobo project interested in my DT_STOPWATCH class?
>> Yes. But I'm just wondering why you use DT_TIME and not
>> DT_DATE_TIME. Don't you have problems when running it
>> around midnight?
> 
> So far I've been timing seconds and milliseconds in command line
> programs so it hasn't been a problem. But you are right of course.
> I'll change that.
> 
> I've written small DS_TEST_CASE based test case for the class. Either
> you give me write access to the SVN repository or I can send you a
> small tarball with the code (2 classes and an ugly .ecf file).

I can send me a small tarball.
Thanks.

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

Re: [gobo-eiffel-develop] Questions regarding DT_TIME

[Paul C. <pa...@se...>]

Hi Eric,

On Thu, Apr 2, 2009 at 12:30 PM, Eric Bezault <er...@go...> wrote:
> All that is explained in $GOBO/doc/time/absolute.html#time

Oops! Sorry. Please accept my humble apology!

>> My questions are:
>>
>>   1. Why doesn't DT_TIME.duration use DT_TIME.canonical_duration?

As a client, without reading the contracts, I would still simply
assume "duration" had the semantics of "canonical_duration". But ok,
now I know why it works like it does.

>>   4. Is the Gobo project interested in my DT_STOPWATCH class?
>
> Yes. But I'm just wondering why you use DT_TIME and not
> DT_DATE_TIME. Don't you have problems when running it
> around midnight?

So far I've been timing seconds and milliseconds in command line
programs so it hasn't been a problem. But you are right of course.
I'll change that.

I've written small DS_TEST_CASE based test case for the class. Either
you give me write access to the SVN repository or I can send you a
small tarball with the code (2 classes and an ugly .ecf file).

/Paul

-- 
Paul Cohen
www.seibostudios.se
mobile: +46 730 787 035
e-mail: pau...@se...

Re: [gobo-eiffel-develop] Questions regarding DT_TIME

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

Paul Cohen wrote:
> I have implemented a very simple DT_STOPWATCH class for doing simple
> timing stuff (ie. start, stop & elapsed_time). In that class I use the
> feature DT_TIME.duration. To my surprise I occasionally get negative
> seconds and milliseconds.
> 
> In DT_TIME there is the feature:
> 
>     duration (other: like Current): DT_TIME_DURATION is
>             -- Duration between `other' and `Current'
>         do
>             Result := time_duration (other)
>         end
> 
> I then realize that DT_TIME.duration uses DT_TIME.time_duration which does:
> 
>     create Result.make_precise (hour - other.hour, minute -
> other.minute, second - other.second, millisecond - other.millisecond)
> 
> where Result & other are DT_TIME. I now realize that I must use
> DT_TIME.canonical_duration to get the result I expect since it
> calculates the difference (correctly) based on the milliseconds count
> of both DT_TIME instances.

All that is explained in $GOBO/doc/time/absolute.html#time

> My questions are:
> 
>    1. Why doesn't DT_TIME.duration use DT_TIME.canonical_duration?

DT_TIME.duration is just a quick way to compute the duration.
The result is correct. It's just that it is not canonical.
As you figured out, to get canonical result you can use
DT_TIME.canonical_duration, or call `set_canonical' on the
result of DT_TIME.duration.

>    2. When & why does anyone want to use DT_TIME.time_duration in its
> current implementation?

A program might want to compute several durations, add them together
and then compute the canonical form of the result instead of computing
the canonical form at each stage.

>    3. DT_TIME.time_duration has a misleading name. Better is
> DT_TIME.time_unit_differences or something like that which says what
> it does.

In fact `time_duration' is not meant to be used in DT_TIME.
You should use DT_TIME.duration instead. The usefulness of
`time_duration' comes in the descendant class DT_DATE_TIME.
It means the time part of the duration. In the same way
`date_duration' is the date part of the duration.

>    4. Is the Gobo project interested in my DT_STOPWATCH class?

Yes. But I'm just wondering why you use DT_TIME and not
DT_DATE_TIME. Don't you have problems when running it
around midnight?

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

[gobo-eiffel-develop] Questions regarding DT_TIME

[Paul C. <pa...@se...>]

Hi,

I have implemented a very simple DT_STOPWATCH class for doing simple
timing stuff (ie. start, stop & elapsed_time). In that class I use the
feature DT_TIME.duration. To my surprise I occasionally get negative
seconds and milliseconds.

In DT_TIME there is the feature:

    duration (other: like Current): DT_TIME_DURATION is
            -- Duration between `other' and `Current'
        do
            Result := time_duration (other)
        end

I then realize that DT_TIME.duration uses DT_TIME.time_duration which does:

    create Result.make_precise (hour - other.hour, minute -
other.minute, second - other.second, millisecond - other.millisecond)

where Result & other are DT_TIME. I now realize that I must use
DT_TIME.canonical_duration to get the result I expect since it
calculates the difference (correctly) based on the milliseconds count
of both DT_TIME instances. My questions are:

   1. Why doesn't DT_TIME.duration use DT_TIME.canonical_duration?

   2. When & why does anyone want to use DT_TIME.time_duration in its
current implementation?

   3. DT_TIME.time_duration has a misleading name. Better is
DT_TIME.time_unit_differences or something like that which says what
it does.

   4. Is the Gobo project interested in my DT_STOPWATCH class?

I'm using:
  * Gobo 3.8
  * EiffelStudio: 6.2
  * On Linux/gcc

/Paul

-- 
Paul Cohen
www.seibostudios.se
mobile: +46 730 787 035
e-mail: pau...@se...

Re: [gobo-eiffel-develop] Bug in GEUC-generated class

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

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

    Colin> I've opened tracker ticket 2724679 for this bug, and I'll
    Colin> fix it as outlined there, unless anyone thinks otherwise.

Fix is now committed.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Cygwin unsupported?

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

Colin Paul Adams wrote:
> I guess cygwin is an unsupported environment?
> 
> I just tried running a test case under cygwin, and I got an error
> message that said:
> 
> cannot read build file 's:\cygdrive\s\......'
> 
> $GOBO evaluates to /cygdrive/s/...
> 
> I guess I have to use a DOS command window instead.

I think I remember that some people used cygwin in the past.
But it might be a long time ago and it might not work anymore.
You might need to explicitly set the environment variable
GOBO_OS to unix.

But in any case, the recommended way to use Gobo on any platform
is to use the native shell on that platform.

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