gobo-eiffel-develop

[gobo-eiffel-develop] New release of Gobo

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

I plan to build and test a new release of Gobo by the end
of the week, so that it can be included in the forthcoming
release of EiffelStudio. If you need to commit code in
SVN, can you let me know first so that we can decide whether
it should go it this release or if it can wait until the
next release? Thanks.

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

Re: [gobo-eiffel-develop] New release of Gobo

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

I am still trying to fix regressions to the W3C test suite that
inadvertently introduced when attempting to improve performance.
I expect to finish fixing these this weekend (but I cannot be sure how
long it will take).

Since all the Gobo tests pass, provided documentation can be built OK,
then I would think it unlikely for users to encounter any of the
problems (but not that unlikley - the problems have mostly arisen from
bugs in code that was not being activated due to incorrect
optimizations).


2008/5/7 Eric Bezault <er...@go...>:
> I plan to build and test a new release of Gobo by the end
>  of the week, so that it can be included in the forthcoming
>  release of EiffelStudio. If you need to commit code in
>  SVN, can you let me know first so that we can decide whether
>  it should go it this release or if it can wait until the
>  next release? Thanks.
>
>  --
>  Eric Bezault
>  mailto:er...@go...
>  http://www.gobosoft.com
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  gobo-eiffel-develop mailing list
>  gob...@li...
>  https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] New release of Gobo

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

Eric Bezault wrote:
> I plan to build and test a new release of Gobo by the end
> of the week, so that it can be included in the forthcoming
> release of EiffelStudio.

I will start now. Please try to avoid committing stuff in
SVN during that time. Thanks

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

Re: [gobo-eiffel-develop] New release of Gobo

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

Eric Bezault wrote:
> Eric Bezault wrote:
>> I plan to build and test a new release of Gobo by the end
>> of the week, so that it can be included in the forthcoming
>> release of EiffelStudio.
> 
> I will start now. Please try to avoid committing stuff in
> SVN during that time. Thanks

It's OK to commit stuff in SVN again.

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

[gobo-eiffel-develop] Question about catcalls

[Daniel T. <dan...@gm...>]

In my opinion the code in catcall_problem.e contains no catcall. The 
following lines show the output of gec. I understand the problem of gec, 
but it will never happen. Is that a catcall according to the ECMA 
specification?

[CATCALL] class CATCALL_PROBLEM (32,7): type 'DS_HASH_TABLE_CURSOR 
[INTEGER, INTEGER]' of actual argument #1 does not conform to type 
'DS_ARRAYED_LIST_CURSOR [INTEGER]' of formal argument in feature 
`same_position' in class 'DS_ARRAYED_LIST_CURSOR [INTEGER]'

[CATCALL] class CATCALL_PROBLEM (32,7): type 'DS_ARRAYED_LIST_CURSOR 
[INTEGER]' of actual argument #1 does not conform to type 
'DS_HASH_TABLE_CURSOR [INTEGER, INTEGER]' of formal argument in feature 
`same_position' in class 'DS_HASH_TABLE_CURSOR [INTEGER, INTEGER]'

[CATCALL] class CATCALL_PROBLEM (37,4): type 'DS_HASH_TABLE_CURSOR 
[INTEGER, INTEGER]' of actual argument #1 does not conform to type 
'DS_ARRAYED_LIST_CURSOR [INTEGER]' of formal argument in feature `go_to' 
in class 'DS_ARRAYED_LIST_CURSOR [INTEGER]'

[CATCALL] class CATCALL_PROBLEM (37,4): type 'DS_ARRAYED_LIST_CURSOR 
[INTEGER]' of actual argument #1 does not conform to type 
'DS_HASH_TABLE_CURSOR [INTEGER, INTEGER]' of formal argument in feature 
`go_to' in class 'DS_HASH_TABLE_CURSOR [INTEGER, INTEGER]'

Re: [gobo-eiffel-develop] Question about catcalls

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

Daniel Tuser wrote:
> In my opinion the code in catcall_problem.e contains no catcall. The 
> following lines show the output of gec. I understand the problem of gec, 
> but it will never happen. Is that a catcall according to the ECMA 
> specification?

The ECMA specification does not say much about CAT-calls.
In gec, there can be false alarms like these, but the
advantage is that when there is no error reported we know
for sure that there will be no CAT-calls at runtime. It
is usually possible to rewrite the code to avoid such
CAT-calls messages. At least it was possible to do so
for the code currently in the Gobo package.

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

Re: [gobo-eiffel-develop] Question about catcalls

[Daniel T. <dan...@gm...>]

Eric Bezault wrote:
> Daniel Tuser wrote:
>> In my opinion the code in catcall_problem.e contains no catcall. The 
>> following lines show the output of gec. I understand the problem of 
>> gec, but it will never happen. Is that a catcall according to the 
>> ECMA specification?
>
> The ECMA specification does not say much about CAT-calls.
> In gec, there can be false alarms like these, but the
> advantage is that when there is no error reported we know
> for sure that there will be no CAT-calls at runtime. It
> is usually possible to rewrite the code to avoid such
> CAT-calls messages. At least it was possible to do so
> for the code currently in the Gobo package.
>
My goal was to write test cases for DS_BILINEAR_TABLE and 
DS_BILINEAR_SET. All the binary search tree variants could have used 
them and maybe DS_HASH_[TABLE|SET] as well. But I had to stop because of 
those CAT-calls. Should I write separate test cases for all the variants 
or do you think it would be manageable to improve the CAT-call detection?

Re: [gobo-eiffel-develop] Question about catcalls

[Daniel T. <dan...@gm...>]

Daniel Tuser wrote:
> Eric Bezault wrote:
>> Daniel Tuser wrote:
>>> In my opinion the code in catcall_problem.e contains no catcall. The 
>>> following lines show the output of gec. I understand the problem of 
>>> gec, but it will never happen. Is that a catcall according to the 
>>> ECMA specification?
>>
>> The ECMA specification does not say much about CAT-calls.
>> In gec, there can be false alarms like these, but the
>> advantage is that when there is no error reported we know
>> for sure that there will be no CAT-calls at runtime. It
>> is usually possible to rewrite the code to avoid such
>> CAT-calls messages. At least it was possible to do so
>> for the code currently in the Gobo package.
>>
> My goal was to write test cases for DS_BILINEAR_TABLE and 
> DS_BILINEAR_SET. All the binary search tree variants could have used 
> them and maybe DS_HASH_[TABLE|SET] as well. But I had to stop because 
> of those CAT-calls. Should I write separate test cases for all the 
> variants or do you think it would be manageable to improve the 
> CAT-call detection?
>
I had a look at the classes that are involved in detecting the 
CAT-calls. From my point of view it is not worth the effort (at least 
for me), so I will write separate test cases.

Re: [gobo-eiffel-develop] Question about catcalls

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

Daniel Tuser wrote:
> Daniel Tuser wrote:
>> Eric Bezault wrote:
>>> Daniel Tuser wrote:
>>>> In my opinion the code in catcall_problem.e contains no catcall. The 
>>>> following lines show the output of gec. I understand the problem of 
>>>> gec, but it will never happen. Is that a catcall according to the 
>>>> ECMA specification?
>>>
>>> The ECMA specification does not say much about CAT-calls.
>>> In gec, there can be false alarms like these, but the
>>> advantage is that when there is no error reported we know
>>> for sure that there will be no CAT-calls at runtime. It
>>> is usually possible to rewrite the code to avoid such
>>> CAT-calls messages. At least it was possible to do so
>>> for the code currently in the Gobo package.
>>>
>> My goal was to write test cases for DS_BILINEAR_TABLE and 
>> DS_BILINEAR_SET. All the binary search tree variants could have used 
>> them and maybe DS_HASH_[TABLE|SET] as well. But I had to stop because 
>> of those CAT-calls. Should I write separate test cases for all the 
>> variants or do you think it would be manageable to improve the 
>> CAT-call detection?
>>
> I had a look at the classes that are involved in detecting the 
> CAT-calls. From my point of view it is not worth the effort (at least 
> for me), so I will write separate test cases.

OK.

I tried to find ways to rewrite the code to avoid the CAT-call
error messages, but could not find one yet (apart from duplicating
the code for each container).

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

Re: [gobo-eiffel-develop] Question about catcalls

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

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


    Eric> I tried to find ways to rewrite the code to avoid the
    Eric> CAT-call error messages, but could not find one yet (apart
    Eric> from duplicating the code for each container).

A different approach might be for a burden-off-proof requirement.

Define an indexing term for a routine that declares no
catcalls. Gelint would just skip those routines.

Should be acceptable for test cases.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Question about catcalls

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
> 
>     Eric> I tried to find ways to rewrite the code to avoid the
>     Eric> CAT-call error messages, but could not find one yet (apart
>     Eric> from duplicating the code for each container).
> 
> A different approach might be for a burden-off-proof requirement.
> 
> Define an indexing term for a routine that declares no
> catcalls. Gelint would just skip those routines.
> 
> Should be acceptable for test cases.

A class that has no CAT-call today might have CAT-calls
tomorrow without even modifying this class or any of
its ancestors. So I think that marking a class as CAT-call
free is dangerous because the compiler will not tell you
when a new CAT-call is introduced.

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