gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] Cygwin unsupported?

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

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.
-- 
Colin Adams
Preston Lancashire

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

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

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

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

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

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.

Re: [gobo-eiffel-develop] [review] comment and expected deferred status of KI_BUFFER.item

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

Eric Bezault wrote:
> Emmanuel Stapf [ES] wrote:
>>> I already spent 2 hours yesterday to try to reproduce it on a small
>>> example to no avail.
>>
>> Can you ask whoever had the problem to contact me and I'll try to 
>> shadow him?
> 
> Too late: we rolled back the modification as soon as we noticed
> the problem.
> 
> In the meantime, even though I didn't manage to reproduce the problem
> I know why: it depends on whether two C header files happened to be
> grouped in the same Big C file or not. But even when they are not,
> the problem is there, even though the C compiler does not complain.
> 
> I'll submit a detailed bug report next week when I'll be back from
> vacation.

I reported it in support.eiffel.com: [Compiler #15375].

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

Re: [gobo-eiffel-develop] [review] comment and expected deferred status of KI_BUFFER.item

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

Emmanuel Stapf [ES] wrote:
>> I already spent 2 hours yesterday to try to reproduce it on a small
>> example to no avail.
> 
> Can you ask whoever had the problem to contact me and I'll try to shadow him?

Too late: we rolled back the modification as soon as we noticed
the problem.

In the meantime, even though I didn't manage to reproduce the problem
I know why: it depends on whether two C header files happened to be
grouped in the same Big C file or not. But even when they are not,
the problem is there, even though the C compiler does not complain.

I'll submit a detailed bug report next week when I'll be back from
vacation.

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

Re: [gobo-eiffel-develop] [review] comment and expected deferred status of KI_BUFFER.item

[Emmanuel S. [ES] <ma...@ei...>]

> I already spent 2 hours yesterday to try to reproduce it on a small
> example to no avail.

Can you ask whoever had the problem to contact me and I'll try to shadow him?

Thanks,
Manu

Re: [gobo-eiffel-develop] [review] comment and expected deferred status of KI_BUFFER.item

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

Emmanuel Stapf [ES] wrote:
> Can you send me some details on the failure?

I already spent 2 hours yesterday to try to reproduce it on a small
example to no avail.

> I tried on our code and I don't have
> any trouble when I make them deferred. Note that making them deferred forced me to
> change KI_CHARACTER_BUFFER to remove the undefinition of `put' and `item'.

Yes, that's what I had done.

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

Re: [gobo-eiffel-develop] [review] comment and expected deferred status of KI_BUFFER.item

[Emmanuel S. [ES] <ma...@ei...>]

Can you send me some details on the failure? I tried on our code and I don't have
any trouble when I make them deferred. Note that making them deferred forced me to
change KI_CHARACTER_BUFFER to remove the undefinition of `put' and `item'.

Manu

> -----Original Message-----
> From: Eric Bezault [mailto:er...@go...]
> Sent: Wednesday, January 28, 2009 5:09 AM
> To: Jocelyn
> Cc: gobodev
> Subject: Re: [gobo-eiffel-develop] [review] comment and expected deferred
> status of KI_BUFFER.item
> 
> Eric Bezault wrote:
> > Eric Bezault wrote:
> >> Jocelyn wrote:
> >>> The feature KI_BUFFER.item has a comment which seems quite obsolete.
> >>>
> >>>     item (i: INTEGER): G is
> >>>             -- Item at position `i'
> >>>         require
> >>>             i_large_enough: i >= 1
> >>>             i_small_enough: i <= count
> >>>         do
> >>>                 -- TODO: This routine should be deferred, but there
> is
> >>>                 -- a bug with ISE Eiffel 5.1.5 and 5.2 in the
> generated
> >>>                 -- C code in finalized mode, and having this
> >>>                 -- routine effective is a workaround.
> >>>         end
> >>>
> >>> I think, it is now safe to remove this TODO comment, and make this
> >>> feature deferred
> >>> especially since the very old ISE Eiffel 5.1 and 5.2 are not
> supported
> >>> anymore in Gobo's code
> >> But is the bug still "supported" in ISE Eiffel 6.2? ;-)
> >> I'll make the change and we'll see.
> >
> > The workaround has now been removed both in `item' and `put'.
> 
> Bad move. I had to learn the hard way that the bug is still there in
> EiffelStudio 6.2 (and I didn't check for earlier versions): some of
> my colleagues at work complained that the generated C code of their
> finalized applications did not compile anymore after I made the change.
> 
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
> 
> -------------------------------------------------------------------------
> -----
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Re: [gobo-eiffel-develop] [review] comment and expected deferred status of KI_BUFFER.item

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

Eric Bezault wrote:
> Eric Bezault wrote:
>> Jocelyn wrote:
>>> The feature KI_BUFFER.item has a comment which seems quite obsolete.
>>>
>>>     item (i: INTEGER): G is
>>>             -- Item at position `i'
>>>         require
>>>             i_large_enough: i >= 1
>>>             i_small_enough: i <= count
>>>         do
>>>                 -- TODO: This routine should be deferred, but there is
>>>                 -- a bug with ISE Eiffel 5.1.5 and 5.2 in the generated
>>>                 -- C code in finalized mode, and having this
>>>                 -- routine effective is a workaround.
>>>         end
>>>
>>> I think, it is now safe to remove this TODO comment, and make this
>>> feature deferred
>>> especially since the very old ISE Eiffel 5.1 and 5.2 are not supported
>>> anymore in Gobo's code
>> But is the bug still "supported" in ISE Eiffel 6.2? ;-)
>> I'll make the change and we'll see.
> 
> The workaround has now been removed both in `item' and `put'.

Bad move. I had to learn the hard way that the bug is still there in
EiffelStudio 6.2 (and I didn't check for earlier versions): some of
my colleagues at work complained that the generated C code of their
finalized applications did not compile anymore after I made the change.

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

Re: [gobo-eiffel-develop] [review] UC_STRING.area_lower, and area_upper should be exported to {READABLE_STRING_8, READABLE_STRING_32}

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

Hi all,

I am now using the gobo-eiffel tracker at
https://sourceforge.net/tracker2/?group_id=24591&atid=381937
I was first using the mailing list, since I was not sure everyone
follows the bug tracker's activity for the gobo-eiffel project.
Anyway, I think Eric will assigned himself or other people to specific
report. So no need to pollute this mailing list.

Best regards,
--Jocelyn

Eric Bezault wrote:
> Emmanuel Stapf [ES] wrote:
>   
>> Should Jocelyn send those specific issues using the sourceforge bug tracker?
>>     
>
> That would indeed make it easier to follow each issue.
>
>   

Re: [gobo-eiffel-develop] [review] invariant error in XM_XPOINTER_EVENT_FILTER

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

Jocelyn wrote:
> The following invariant is wrong regarding the code related to
> `attribute_types'
> 
> invariant
>     attribute_types_not_void: attribute_types /= Void
> 
> However the implementation of the creation procedure `make' does not
> guarantee `attribute_types' is not Void
> Indeed if you check the implementation the `attribute_types' is only set
> by feature `set_xpointer', and not by `set_no_filtering'
> 
> Suggestion: correct the invariant with the following contracts
> 
>     attribute_types_not_void: is_filtering implies attribute_types /= Void

Done. I also reset `attribute_types' to Void in `set_no_filtering'.

> And maybe precise the contract between is_filtering and is_forwarding to
> prevent trouble in `on_attribute'
> I guess that
>         is_forwarding implies is_filtering

I don't see where the trouble is in `on_attribute'.

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

Re: [gobo-eiffel-develop] [review] error in XM_NAMESPACE

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

Jocelyn wrote:
> The invariant and code are contradictory for XM_NAMESPACE
> 
>     invariant
>         uri_not_void: uri /= Void
> 
> 
> But code handle the case it is Void
> 
>         is_equal (other: like Current): BOOLEAN is
>                 -- Are the two namespaces equal?
>             do
>                 Result := (uri = other.uri) or else
>                     (uri /= Void and then STRING_.same_string (uri,
>     other.uri))
>             ensure then
>                 definition: Result = STRING_.same_string (uri, other.uri)
>             end
> 
>         hash_code: INTEGER is
>                 -- Hash code of URI.
>             do
>                 if uri /= Void then
>                     Result := uri.hash_code
>                 end
>             end
> 
>         out: STRING is
>                 -- Out.
>             do
>                 if uri = Void then
>                     Result := ""
>                 else
>                     Result := uri
>                 end
>             end
> 
> However, the creation procedure's implementation ensure `uri' is never Void.
> 
> Suggestion: keep invariant, and remove case where `uri' can be Void

Done.

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

Re: [gobo-eiffel-develop] [review] XM_CATALOG_BOOTSTRAP_RESOLVER.Reserved_directory_path is not safe

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

Jocelyn wrote:
> In the code of {XM_CATALOG_BOOTSTRAP_RESOLVER}.Reserved_directory_path
> we have
>             Result := Execution_environment.variable_value ("GOBO")
>             Result := unix_file_system.pathname_from_file_system
> (Result, file_system)
> 
> However `Execution_environment.variable_value ("GOBO")' can return a
> Void value
> and then the call to unix_file_system.pathname_from_file_system (Result,
> file_system) will violate precondition of  `pathname_from_file_system'
> or raise exception (if assertion are disabled).

I modified it as follows:

	Reserved_directory_path: STRING is
			-- Path to directory containing latest schemas
		once
			Result := file_system.pathname ("${GOBO}", "misc")
			Result := Execution_environment.interpreted_string (Result)
		ensure
			reserved_directory_path_not_void: Result /= Void
		end

Note that it looks like this routine is never called.

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

Re: [gobo-eiffel-develop] [review] comment and expected deferred status of KI_BUFFER.item

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

Eric Bezault wrote:
> Jocelyn wrote:
>> The feature KI_BUFFER.item has a comment which seems quite obsolete.
>>
>>     item (i: INTEGER): G is
>>             -- Item at position `i'
>>         require
>>             i_large_enough: i >= 1
>>             i_small_enough: i <= count
>>         do
>>                 -- TODO: This routine should be deferred, but there is
>>                 -- a bug with ISE Eiffel 5.1.5 and 5.2 in the generated
>>                 -- C code in finalized mode, and having this
>>                 -- routine effective is a workaround.
>>         end
>>
>> I think, it is now safe to remove this TODO comment, and make this
>> feature deferred
>> especially since the very old ISE Eiffel 5.1 and 5.2 are not supported
>> anymore in Gobo's code
> 
> But is the bug still "supported" in ISE Eiffel 6.2? ;-)
> I'll make the change and we'll see.

The workaround has now been removed both in `item' and `put'.

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

Re: [gobo-eiffel-develop] [review] UC_STRING.area_lower, and area_upper should be exported to {READABLE_STRING_8, READABLE_STRING_32}

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

Eric Bezault wrote:
> Jocelyn wrote:
>> Compiling Gobo's with ISE's "full class checking" option enabled, you
>> can notice that
>>
>> In class UC_STRING, the feature  `area_lower', `area_upper' should be
>> exported to {READABLE_STRING_8, READABLE_STRING_32}
> 
> According to gelint, the problem was only on `area_lower'.
> The problem is that this routine does not exist in ISE 6.3
> and READABLE_STRING_8 does not exist in ISE 6.2.
> 
> I'll try to find another solution.

I think that this is now fixed in SVN.

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

Re: [gobo-eiffel-develop] [review] UC_STRING.area_lower, and area_upper should be exported to {READABLE_STRING_8, READABLE_STRING_32}

[Emmanuel S. [ES] <ma...@ei...>]

Should Jocelyn send those specific issues using the sourceforge bug tracker?

Manu

> -----Original Message-----
> From: Eric Bezault [mailto:er...@go...]
> Sent: Friday, January 23, 2009 8:13 AM
> To: Jocelyn
> Cc: gobodev
> Subject: Re: [gobo-eiffel-develop] [review] UC_STRING.area_lower, and
> area_upper should be exported to {READABLE_STRING_8, READABLE_STRING_32}
> 
> Jocelyn wrote:
> > Compiling Gobo's with ISE's "full class checking" option enabled, you
> > can notice that
> >
> > In class UC_STRING, the feature  `area_lower', `area_upper' should be
> > exported to {READABLE_STRING_8, READABLE_STRING_32}
> 
> According to gelint, the problem was only on `area_lower'.
> The problem is that this routine does not exist in ISE 6.3
> and READABLE_STRING_8 does not exist in ISE 6.2.
> 
> I'll try to find another solution.
> 
> > ps: Maybe, there are other similar cases in UC_STRING, and this class
> > might benefit a deep review to match recent changes of the STRING_*
> > interface.
> 
> Yes, but it is a huge task, because the XML library will have to be
> updated accordingly.
> 
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
> 
> -------------------------------------------------------------------------
> -----
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Re: [gobo-eiffel-develop] [review] UC_STRING.area_lower, and area_upper should be exported to {READABLE_STRING_8, READABLE_STRING_32}

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

Emmanuel Stapf [ES] wrote:
> Should Jocelyn send those specific issues using the sourceforge bug tracker?

That would indeed make it easier to follow each issue.

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

Re: [gobo-eiffel-develop] [review] UC_STRING.area_lower, and area_upper should be exported to {READABLE_STRING_8, READABLE_STRING_32}

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

Jocelyn wrote:
> Compiling Gobo's with ISE's "full class checking" option enabled, you
> can notice that
> 
> In class UC_STRING, the feature  `area_lower', `area_upper' should be
> exported to {READABLE_STRING_8, READABLE_STRING_32}

According to gelint, the problem was only on `area_lower'.
The problem is that this routine does not exist in ISE 6.3
and READABLE_STRING_8 does not exist in ISE 6.2.

I'll try to find another solution.

> ps: Maybe, there are other similar cases in UC_STRING, and this class
> might benefit a deep review to match recent changes of the STRING_*
> interface.

Yes, but it is a huge task, because the XML library will have to be
updated accordingly.

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

Re: [gobo-eiffel-develop] [review] comment and expected deferred status of KI_BUFFER.item

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

Jocelyn wrote:
> The feature KI_BUFFER.item has a comment which seems quite obsolete.
> 
>     item (i: INTEGER): G is
>             -- Item at position `i'
>         require
>             i_large_enough: i >= 1
>             i_small_enough: i <= count
>         do
>                 -- TODO: This routine should be deferred, but there is
>                 -- a bug with ISE Eiffel 5.1.5 and 5.2 in the generated
>                 -- C code in finalized mode, and having this
>                 -- routine effective is a workaround.
>         end
> 
> I think, it is now safe to remove this TODO comment, and make this
> feature deferred
> especially since the very old ISE Eiffel 5.1 and 5.2 are not supported
> anymore in Gobo's code

But is the bug still "supported" in ISE Eiffel 6.2? ;-)
I'll make the change and we'll see.

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

[gobo-eiffel-develop] [review] XM_CATALOG_BOOTSTRAP_RESOLVER.Reserved_directory_path is not safe

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

In the code of {XM_CATALOG_BOOTSTRAP_RESOLVER}.Reserved_directory_path
we have
            Result := Execution_environment.variable_value ("GOBO")
            Result := unix_file_system.pathname_from_file_system
(Result, file_system)

However `Execution_environment.variable_value ("GOBO")' can return a
Void value
and then the call to unix_file_system.pathname_from_file_system (Result,
file_system) will violate precondition of  `pathname_from_file_system'
or raise exception (if assertion are disabled).

Regards,
-- Jocelyn

[gobo-eiffel-develop] [review] UC_STRING.area_lower, and area_upper should be exported to {READABLE_STRING_8, READABLE_STRING_32}

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

Compiling Gobo's with ISE's "full class checking" option enabled, you
can notice that

In class UC_STRING, the feature  `area_lower', `area_upper' should be
exported to {READABLE_STRING_8, READABLE_STRING_32}

Suggestion: following patch

Index: uc_string.e
===================================================================
--- uc_string.e    (revision 76809)
+++ uc_string.e    (working copy)
@@ -70,6 +70,8 @@
                 is_case_insensitive_equal,
                 valid_code,
                 to_string_32
+            {READABLE_STRING_8, READABLE_STRING_32}
+                area_lower, area_upper
             {ANY}
                 is_string_8,
                 valid_index


Regards,
-- Jocelyn
ps: Maybe, there are other similar cases in UC_STRING, and this class
might benefit a deep review to match recent changes of the STRING_*
interface.

[gobo-eiffel-develop] [review] comment and expected deferred status of KI_BUFFER.item

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

The feature KI_BUFFER.item has a comment which seems quite obsolete.

    item (i: INTEGER): G is
            -- Item at position `i'
        require
            i_large_enough: i >= 1
            i_small_enough: i <= count
        do
                -- TODO: This routine should be deferred, but there is
                -- a bug with ISE Eiffel 5.1.5 and 5.2 in the generated
                -- C code in finalized mode, and having this
                -- routine effective is a workaround.
        end

I think, it is now safe to remove this TODO comment, and make this
feature deferred
especially since the very old ISE Eiffel 5.1 and 5.2 are not supported
anymore in Gobo's code

Regards,
-- Jocelyn

[gobo-eiffel-develop] [review] invariant error in XM_XPOINTER_EVENT_FILTER

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

The following invariant is wrong regarding the code related to
`attribute_types'

invariant
    attribute_types_not_void: attribute_types /= Void

However the implementation of the creation procedure `make' does not
guarantee `attribute_types' is not Void
Indeed if you check the implementation the `attribute_types' is only set
by feature `set_xpointer', and not by `set_no_filtering'

Suggestion: correct the invariant with the following contracts

    attribute_types_not_void: is_filtering implies attribute_types /= Void

And maybe precise the contract between is_filtering and is_forwarding to
prevent trouble in `on_attribute'
I guess that
        is_forwarding implies is_filtering


Regards,
Jocelyn

[gobo-eiffel-develop] [review] error in XM_NAMESPACE

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

The invariant and code are contradictory for XM_NAMESPACE

    invariant
        uri_not_void: uri /= Void


But code handle the case it is Void

        is_equal (other: like Current): BOOLEAN is
                -- Are the two namespaces equal?
            do
                Result := (uri = other.uri) or else
                    (uri /= Void and then STRING_.same_string (uri,
    other.uri))
            ensure then
                definition: Result = STRING_.same_string (uri, other.uri)
            end

        hash_code: INTEGER is
                -- Hash code of URI.
            do
                if uri /= Void then
                    Result := uri.hash_code
                end
            end

        out: STRING is
                -- Out.
            do
                if uri = Void then
                    Result := ""
                else
                    Result := uri
                end
            end

However, the creation procedure's implementation ensure `uri' is never Void.

Suggestion: keep invariant, and remove case where `uri' can be Void

[gobo-eiffel-develop] Review of Gobo-eiffel's code and conversion to void-safety

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

Hi all,

I am Jocelyn FIAT (working for Eiffel Software).
As part of Eiffel Software's effort to convert libraries to void-safety,
we are currently working on Gobo's conversion.

During this process, we noticed a few (minor) errors in code.
So I will try to send one email per issue, and I might eventually ask on
this mailing list explanations on specific design,
and maybe suggest minor changes to improve Gobo's quality, and probably
ease conversion to void-safety.

See following emails.

Best regards,
--Jocelyn