gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] Problem with DS_HASH_TABLE

[Paul G. C. <pau...@sc...>]

Hello,

I have a problem with DS_HASH_TABLE.  A precondition violation in 
'clashes_put'.

Class / Object      Routine                Nature of exception           Effect
-------------------------------------------------------------------------------
DS_HASH_TABLE       clashes_put @12        index_small_enough:          
<000000000B20FEF8>  (From DS_ARRAYED_SPARSE_TABLE)
                                           Runtime check violated.       Fail
-------------------------------------------------------------------------------
DS_HASH_TABLE       clashes_put @3                                      
<000000000B20FEF8>  (From DS_ARRAYED_SPARSE_TABLE)
                                           Routine failure.              Fail
-------------------------------------------------------------------------------
DS_HASH_TABLE       put @12                                             
<000000000B20FEF8>  (From DS_SPARSE_TABLE) Routine failure.              Fail
-------------------------------------------------------------------------------

How does it come?  Before putting the new element we check the table is 
not full.
Is there a known problem with DS_HASH_TABLE?

Best regards,

Paul G. Crismer

Re: [gobo-eiffel-develop] Binary search tree

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

Daniel Tuser wrote:
> My todo list for the binary search trees is now empty. From my point of 
> view it is ready to be released if no one finds weaknesses in the code. 
> The documentation and some examples are missing.
> There are no xml files for table.html and set.html yet. So I assume that 
> I need to be translated them into xml files first (gobodoc format). Or 
> is there another location where the xml files are?

The doc for the structure library was used as a proof of
concept for the gobodoc format. The doc was initially
written in html, and I wanted to make sure that it was
possible to write the doc in gobodoc format and then
produce html files that look like the original. That's
where the .xml files come from. But the doc for the
structure library was never fully translated into the
gobodoc format, so I think that the most up-to-date files
are the .html files. You should probably use these .html
files for the time being.

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

Re: [gobo-eiffel-develop] Binary search tree

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

My todo list for the binary search trees is now empty. From my point of 
view it is ready to be released if no one finds weaknesses in the code. 
The documentation and some examples are missing.
There are no xml files for table.html and set.html yet. So I assume that 
I need to be translated them into xml files first (gobodoc format). Or 
is there another location where the xml files are?

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

>>>>> "Berend" == Berend de Boer <be...@po...> writes:

>>>>> "Colin" == Colin Adams <col...@go...> writes:
    >>> The problem is that I develop sites with dozens of small
    >>> cgis. The disk space needed for EiffelStudio is simply
    >>> horrendous, and the initial compile doesn't make me happy
    >>> either. So SE is still the only solution in town
    >>> unfortunately.

    Colin> Then you have two solutions at hand:

    Colin> 1) Upgrade SmartEiffel 1.2r8, or 2) Use Gobo 3.7

    Berend> Ah, does 1.2r8 work? I thought the differences were minor
    Berend> so I haven't bothered to upgrade from 1.2r7. But Eric said
    Berend> SE support was dropped.

I meant upgrade 1.2r8 to support FreeElks, or equivalent.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

>>>>> "Colin" == Colin Adams <col...@go...> writes:

    >> The problem is that I develop sites with dozens of small
    >> cgis. The disk space needed for EiffelStudio is simply
    >> horrendous, and the initial compile doesn't make me happy
    >> either. So SE is still the only solution in town unfortunately.

    Colin> Then you have two solutions at hand:

    Colin> 1) Upgrade SmartEiffel 1.2r8, or 2) Use Gobo 3.7

Ah, does 1.2r8 work? I thought the differences were minor so I haven't
bothered to upgrade from 1.2r7. But Eric said SE support was dropped.

But else, Gobo 3.7 is indeed the only solution for now.

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

2008/5/29 Berend de Boer <be...@po...>:

> The problem is that I develop sites with dozens of small cgis. The disk
> space needed for EiffelStudio is simply horrendous, and the initial
> compile doesn't make me happy either. So SE is still the only solution
> in town unfortunately.

Then you have two solutions at hand:

1) Upgrade SmartEiffel 1.2r8, or
2) Use Gobo 3.7

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

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

    Eric> Debug can be implemented in gec without too much effort.  DbC
    Eric> requires more work. For DbC I use EiffelStudio.

The problem is that I develop sites with dozens of small cgis. The disk
space needed for EiffelStudio is simply horrendous, and the initial
compile doesn't make me happy either. So SE is still the only solution
in town unfortunately.

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Berend de Boer wrote:
>   
>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>>>>>>               
>>     >> I realise we have to move on, but it's a pity there's no solution
>>     >> now if you want to compile with debug info. Are there any plans
>>     >> to add that to gec?
>>
>>     Eric> Do you mean the "debug" instructions as in:
>>
>>     Eric>    debug ("some_key") valid_foo: foo.is_valid end
>>
>> And DbC support of course. It does not have to perform better than SE,
>> but if the performance is equal, it would really make me switch.
>>     
>
> Debug can be implemented in gec without too much effort.
> DbC requires more work. For DbC I use EiffelStudio.
>
>   
Hi,

Some time ago I proposed to add a debugger to the GEC.
Its took me much more time than expected.
But now an experimental version is nearly completed.
I hope that I can that version publish the next days.

WJ

-- 
Dr. Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

Berend de Boer wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     >> I realise we have to move on, but it's a pity there's no solution
>     >> now if you want to compile with debug info. Are there any plans
>     >> to add that to gec?
> 
>     Eric> Do you mean the "debug" instructions as in:
> 
>     Eric>    debug ("some_key") valid_foo: foo.is_valid end
> 
> And DbC support of course. It does not have to perform better than SE,
> but if the performance is equal, it would really make me switch.

Debug can be implemented in gec without too much effort.
DbC requires more work. For DbC I use EiffelStudio.

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

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

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

    >> I realise we have to move on, but it's a pity there's no solution
    >> now if you want to compile with debug info. Are there any plans
    >> to add that to gec?

    Eric> Do you mean the "debug" instructions as in:

    Eric>    debug ("some_key") valid_foo: foo.is_valid end

And DbC support of course. It does not have to perform better than SE,
but if the performance is equal, it would really make me switch.

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

Berend de Boer wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Yes, too tired to send messages to the SE 1.2 mailing list
>     Eric> without getting any answer back.
> 
> I realise we have to move on, but it's a pity there's no solution now if
> you want to compile with debug info. Are there any plans to add that to
> gec?

Do you mean the "debug" instructions as in:

    debug ("some_key")
        valid_foo: foo.is_valid
    end

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

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

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

    Eric> Yes, too tired to send messages to the SE 1.2 mailing list
    Eric> without getting any answer back.

I realise we have to move on, but it's a pity there's no solution now if
you want to compile with debug info. Are there any plans to add that to
gec?

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Binary search tree

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

The left-leaning red-black tree implementation is finished. 
Unfortunately it is very slow compared to the other binary search tree 
variants.

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

Colin Adams wrote:
> Support for SE has been dropped.

Yes, too tired to send messages to the SE 1.2 mailing list
without getting any answer back.

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

Re: [gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

Support for SE has been dropped.

2008/5/28 Berend de Boer <be...@po...>:
> Hi Guys,
>
> In UC_STRING there is now a make_from_string_general routine which
> doesn't work with SmartEiffel as it doesn't have a STRING_GENERAL class.
>
> --
> Cheers,
>
> Berend de Boer
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>

[gobo-eiffel-develop] Latest release doesn't work with SE 1.2 anymore

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

Hi Guys,

In UC_STRING there is now a make_from_string_general routine which
doesn't work with SmartEiffel as it doesn't have a STRING_GENERAL class.

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Binary search tree

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

Colin Paul Adams wrote:
> Daniel,
>
> Mark Howard (ECMA committee member and boss of Eric, Franck and myself
> at AXA Rosenberg) has expressed an interest in Sedgewick's recently
> introduced left-leaning red-black trees. You might want to add these
> too  (I googled and found quite a few hits, so I think there is
> sufficient information available).
>   
Left-leaning red-black trees are now implemented. It was surprising that 
they are slower than red-black and avl trees. In some random benchmarks 
avl and red-black trees show nearly the same performance, whereas plain 
binary search trees are a few percents slower. Left-leaning red-black 
trees are at least 50% slower than avl and red-black trees. The 
benchmark tests only put and delete.
I have to finish the test cases and check a few classes again. It should 
be possible to publish the code this week.

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

Re: [gobo-eiffel-develop] Obsolete classes

[Lothar S. <ll...@we...>]

Hello Berend,

Friday, May 23, 2008, 11:46:42 AM, you wrote:

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

BdB>     Eric> In fact, I always wondered how long should a class or feature
BdB>     Eric> be marked as obsolete before being able to remove it. Should
BdB>     Eric> it be after some number of releases (2, 5, 10, ...?)? Should
BdB>     Eric> it be after some number of years (2, 5, 10, ...?)? Never? A
BdB>     Eric> combination of these?

BdB> Difficult question. 5 years perhaps?

Well there has to be at least a good stable release in between.
So slowly migration is possible.

I got fucked by SmartEiffel more then once because they had no
migration path just from now to an unstable broken CVS head version.

-- 
Best regards,
 Lothar                            mailto:ll...@we...

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] GEC crashes when compiling

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

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

    >> They pass with ISE 6.2, but with GEC I get:
    >> 
    >> Call on Void target!
    >> 
    >> from the xcompile.log (i.e. at compile time, not runtime).
    >> 
    >> How can I go about debugging this? I can't find any dump or
    >> anything.

    Eric> It should be fixed now.

Yes. Thanks.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Obsolete classes

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

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

    Eric> In fact, I always wondered how long should a class or feature
    Eric> be marked as obsolete before being able to remove it. Should
    Eric> it be after some number of releases (2, 5, 10, ...?)? Should
    Eric> it be after some number of years (2, 5, 10, ...?)? Never? A
    Eric> combination of these?

Difficult question. 5 years perhaps?

-- 
Cheers,

Berend de Boer

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

[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] Obsolete classes

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

Colin Adams wrote:
> I just came upon an obsolete warning for DS_COMPARABLE_COMPARATOR.
> 
> I think these warnings are far past their sell-by date, and the old
> classes should be removed.

In fact, I always wondered how long should a class or feature be
marked as obsolete before being able to remove it. Should it be
after some number of releases (2, 5, 10, ...?)? Should it be after
some number of years (2, 5, 10, ...?)? Never? A combination of these?

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