gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] NGROUPS_MAX

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

Franck Arnaud wrote:
> and that's the last one, bootstrap worked after patching eif_file.c for
> this.

I just updated the version in SVN. Can you check that it works?

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

[gobo-eiffel-develop] UC_CTYPE

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

Looks like I failed to update this for Unicode 5.0.0. I will do so now.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] NGROUPS_MAX

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

Franck Arnaud wrote:
> Eric:
> 
>> The problem is that I cannot pass the array as argument because
>> it is not allocated yet. Sould I pass a dummy one, or can I pass
>> a null pointer?
> 
> thanks for your changes!
> 
> that's my understanding, it does say the array parameter is not going to
> be touched, the point of the call with zero is to get the size so that
> you can allocate enough space for next time you call with a real array
> so I think you can call with null instead of a dummy array.
> 
> I'd also check that the call with zero doesn't return <= 0 to avoid
> negative/zero malloc (though it might cope).
> 
> next problem is the lack of pwd.h and grp.h that define populated
> versions of the passwd and group structures used by getgrgid and
> getpwuid. I don't know for sure if it's portable, but it is in POSIX so
> should be a fair bet.
> 
> and that's the last one, bootstrap worked after patching eif_file.c for
> this.

Can you send me your patched eif_file.c?

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

Re: [gobo-eiffel-develop] NGROUPS_MAX

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

Eric:

> The problem is that I cannot pass the array as argument because
> it is not allocated yet. Sould I pass a dummy one, or can I pass
> a null pointer?

thanks for your changes!

that's my understanding, it does say the array parameter is not going to
be touched, the point of the call with zero is to get the size so that
you can allocate enough space for next time you call with a real array
so I think you can call with null instead of a dummy array.

I'd also check that the call with zero doesn't return <= 0 to avoid
negative/zero malloc (though it might cope).

next problem is the lack of pwd.h and grp.h that define populated
versions of the passwd and group structures used by getgrgid and
getpwuid. I don't know for sure if it's portable, but it is in POSIX so
should be a fair bet.

and that's the last one, bootstrap worked after patching eif_file.c for
this.

Re: [gobo-eiffel-develop] UNIX_FILE_INFO

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

Colin Paul Adams wrote:
>     Eric> Unfortunately what I checked-in does not seem to compile
>     Eric> with Franck.  So you might have the same problem.
> 
> Again, correct.

It should be fixed now, using Frank's suggestion.
Can you give it a try?

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

Re: [gobo-eiffel-develop] UNIX_FILE_INFO

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

Colin Paul Adams wrote:
> For owner_name and group_name, I am seeing 500 rather than colin.
> 
> Compiling with ISE 6.1 gives the expected results.
> 
> Looking at the C code, the obvious suspect is HAS_GETPWUID.
> 
> A quick grep of /usr/include failed to find it.

I guess you didn't run 'svn update' since yesterday evening ;-)
Unfortunately what I checked-in does not seem to compile with Franck.
So you might have the same problem.

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

Re: [gobo-eiffel-develop] NGROUPS_MAX

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

Franck Arnaud wrote:
> hi,
> 
> I can't bootstrap the current repository, fails on compiling
> eif_group_in_list because my Linux does not have NGROUPS_MAX (or not in
> the expected place).

I guess it is supposed to be in limits.h.
Does it work if you add this include explicitly at the beginning
of file $GOBO/tool/gec/runtime/c/eif_file.c?

> It seems NGROUPS_MAX was changed to 65000 from 32 between Linux kernel
> releases so the hardcoded NGROUPS_MAX technique not very reliable as the
> value depend on C library on the compiling machine and real value on
> kernel.
> 
> I guess the clean way is to malloc () the structure with the value
> returned by getgroups (0, _) which returns the actual number of items
> without touching the output array. Some POSIX page recommends a sysconf
> call but the former seems simpler. 

The problem is that I cannot pass the array as argument because
it is not allocated yet. Sould I pass a dummy one, or can I pass
a null pointer?

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

[gobo-eiffel-develop] UNIX_FILE_INFO

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

For owner_name and group_name, I am seeing 500 rather than colin.

Compiling with ISE 6.1 gives the expected results.

Looking at the C code, the obvious suspect is HAS_GETPWUID.

A quick grep of /usr/include failed to find it.
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] NGROUPS_MAX

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

hi,

I can't bootstrap the current repository, fails on compiling
eif_group_in_list because my Linux does not have NGROUPS_MAX (or not in
the expected place).

It seems NGROUPS_MAX was changed to 65000 from 32 between Linux kernel
releases so the hardcoded NGROUPS_MAX technique not very reliable as the
value depend on C library on the compiling machine and real value on
kernel.

I guess the clean way is to malloc () the structure with the value
returned by getgroups (0, _) which returns the actual number of items
without touching the output array. Some POSIX page recommends a sysconf
call but the former seems simpler. 

Re: [gobo-eiffel-develop] hash tables that are also bilinears

[Andreas L. <ale...@ra...>]

On Thu, 2007-12-13 at 16:10 +0100, Eric Bezault wrote:
> I don't know. I need more information to reproduce the problem.
> I just wrote this test, but it works as expected.

Hi Eric, 

now I cannot seem to reproduce the problem either. I will try some more
and if I can reproduce it, I send you a minimal example. Sorry for the
confusion.

Andreas

Re: [gobo-eiffel-develop] hash tables that are also bilinears

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

Andreas Leitner wrote:
> I am having problem with DS_HASH_TABLE. I have seen that DS_HASH_TABLE
> [G, K] conforms to DS_BILINEAR [G]. I am not sure if this is abuse, but
> I wanted to sell my hash table to others as a bilinear of the values in
> the hash table. Eg. given the table ["a" -> "1", "b" -> "2"] sold with
> the static type DS_BILINEAR appears to be the list ["1", "2"].

No abuse here.

> My problem is that this list always contains also Void, even though Void
> is not a value in the hash table. Also DS_HASH_TABLE.to_array does not
> contain Void.
> 
> Is there somewhere an off by one error

I don't know. I need more information to reproduce the problem.
I just wrote this test, but it works as expected.

	test_bilinear is
			-- Test hash-tables as being bilinear.
		local
			l_table1: DS_HASH_TABLE [STRING, STRING]
			l_bilinear1: DS_BILINEAR [STRING]
			i: INTEGER
		do
			create l_table1.make (5)
			l_table1.force_last ("1", "one")
			l_table1.force_last ("2", "two")
			l_table1.force_last ("3", "three")
			l_table1.force_last ("4", "four")
			l_table1.force_last ("5", "five")
			l_bilinear1 := l_table1
			from l_bilinear1.start until l_bilinear1.after loop
				i := i + 1
				assert_strings_equal ("item_" + i.out, i.out, 
l_bilinear1.item_for_iteration)
				l_bilinear1.forth
			end
		end

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

[gobo-eiffel-develop] hash tables that are also bilinears

[Andreas L. <ale...@ra...>]

Hi all,

I am having problem with DS_HASH_TABLE. I have seen that DS_HASH_TABLE
[G, K] conforms to DS_BILINEAR [G]. I am not sure if this is abuse, but
I wanted to sell my hash table to others as a bilinear of the values in
the hash table. Eg. given the table ["a" -> "1", "b" -> "2"] sold with
the static type DS_BILINEAR appears to be the list ["1", "2"].

My problem is that this list always contains also Void, even though Void
is not a value in the hash table. Also DS_HASH_TABLE.to_array does not
contain Void.

Is there somewhere an off by one error, or am I just using the hash
table outside its spec?

many thanks in advance,
Andreas  

Re: [gobo-eiffel-develop] Broken test

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

Colin Adams wrote:
> Perhaps the ACE -> ECF conversion is producing different
> assertion-checking levels in 6.1 compared with 5.7.

Ah, that's a good idea. You're probably right.

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

Re: [gobo-eiffel-develop] Broken test

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

Perhaps the ACE -> ECF conversion is producing different
assertion-checking levels in 6.1 compared with 5.7.

On 12/12/2007, Eric Bezault <er...@go...> wrote:
> I managed to reproduce the problem with 5.7 indeed. I have
> no idea why there is no postcondition violation when compiled
> with 6.0 or 6.1. In fact, I discovered that in all ISE versions
> (5.7, 6.x), comparing two NaNs returns False in frozen and
> finalized mode, but True in melted mode. But I don't understand
> how this bug could be related to the fact that our test does not
> violate the postcondition when compiled with 6.x.

Re: [gobo-eiffel-develop] UNIX_FILE_INFO

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

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

    Eric> But if we keep supporting for SE 1.2 we are stuck to stone
    Eric> age.  Is it fair to penalize ISE users who want to use new
    Eric> ECMA Eiffel extensions because SE 1.2 has not been maintained
    Eric> for 2 years?  So what do we do? I would say that people who
    Eric> wants to use an old version of Eiffel (e.g. SE 1.2) have to
    Eric> use old versions of libraries (e.g. Gobo 3.6).

Agree, sounds reasonable.

I only tried to goat you to adding DbC to gec :-)

=2D-=20
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Broken test

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

I managed to reproduce the problem with 5.7 indeed. I have
no idea why there is no postcondition violation when compiled
with 6.0 or 6.1. In fact, I discovered that in all ISE versions
(5.7, 6.x), comparing two NaNs returns False in frozen and
finalized mode, but True in melted mode. But I don't understand
how this bug could be related to the fact that our test does not
violate the postcondition when compiled with 6.x.

Anyway, instead of turning off some assertions, I implemented
a workaround in the relevant features of class KL_DOUBLE_ROUTINES.
The test should work fine now.

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



Colin Adams wrote:
> It is 5.7.
> 
> On 12/12/2007, Colin Adams <col...@go...> wrote:
>> It was probably 6.0 - I can check tonight.
>>
>> On 12/12/2007, Eric Bezault <er...@go...> wrote:
>>> Colin Adams wrote:
>>>> As a result of some changes I checked in last night, one of the XPath
>>>> tests failed.
>>>>
>>>> This is due to a postcondition in {MANAGED_POINTER}.put_real_64, which
>>>> is broken when the object is NaN.
>>> Which version of ISE did you use? I tried with 6.1.7.1223 and I
>>> didn't get the postcondition violation:
>>>
>>> C:\gobo\test\xml\xpath>geant test_debug_ise
>>>
>>> Testing xpath...
>>> Preparing Test Cases
>>> Compiling Test Cases
>>> Running Test Cases
>>>
>>> Test Summary for xpath
>>>
>>> # PASSED:     275 tests
>>> # Failed:     0 test
>>> # Aborted:    0 test
>>> # Total:      275 tests (1841 assertions)
>>>
>>> --
>>> Eric Bezault
>>> mailto:er...@go...
>>> http://www.gobosoft.com
>>>
> 
> 
> 


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

Re: [gobo-eiffel-develop] Broken test

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

Colin Adams wrote:
> As a result of some changes I checked in last night, one of the XPath
> tests failed.
> 
> This is due to a postcondition in {MANAGED_POINTER}.put_real_64, which
> is broken when the object is NaN.

Which version of ISE did you use? I tried with 6.1.7.1223 and I
didn't get the postcondition violation:

C:\gobo\test\xml\xpath>geant test_debug_ise

Testing xpath...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

Test Summary for xpath

# PASSED:     275 tests
# Failed:     0 test
# Aborted:    0 test
# Total:      275 tests (1841 assertions)

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

[gobo-eiffel-develop] Broken test

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

As a result of some changes I checked in last night, one of the XPath
tests failed.

This is due to a postcondition in {MANAGED_POINTER}.put_real_64, which
is broken when the object is NaN.

Can we suppress postcondition-checking for this class in the XPath
library.xace file, or is that not supported?

Re: [gobo-eiffel-develop] UNIX_FILE_INFO

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

Berend de Boer wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> As for dropping support for SE 1.2, let's wait until 2008
>     Eric> starts.  Then we will have other opportunities such as using
>     Eric> STRING_GENERAL or NATURAL_* classes for example.
> 
> The problem is that currently there is no good solution for people who
> compile many command-line or cgi utilities like I do. With ISE Eiffel
> the initial compile would be very slow and secondly it takes an awful
> lot of HD space, so you can't keep too many compiled projects around.
> 
> And gec doesn't support DbC yet.

But if we keep supporting for SE 1.2 we are stuck to stone age.
Is it fair to penalize ISE users who want to use new ECMA Eiffel
extensions because SE 1.2 has not been maintained for 2 years?
So what do we do? I would say that people who wants to use an
old version of Eiffel (e.g. SE 1.2) have to use old versions of
libraries (e.g. Gobo 3.6).

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

Re: [gobo-eiffel-develop] UNIX_FILE_INFO

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

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

    Eric> As for dropping support for SE 1.2, let's wait until 2008
    Eric> starts.  Then we will have other opportunities such as using
    Eric> STRING_GENERAL or NATURAL_* classes for example.

The problem is that currently there is no good solution for people who
compile many command-line or cgi utilities like I do. With ISE Eiffel
the initial compile would be very slow and secondly it takes an awful
lot of HD space, so you can't keep too many compiled projects around.

And gec doesn't support DbC yet.

=2D-=20
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Perverse bug with gec?

[Till G. B. <til...@in...>]

Eric Bezault wrote:
> Ber...@in... wrote:
>>> However I'm not sure they have enough resources and skills in
>> Right. Not only are we next to destitute, we're kind of dumb as
>> well.
> 
> Of course that's not what I meant. If SourceForge stopped providing 
> this offer, it's because it took them much effort to maintain these 
> system up and running, with constant system administration knowledge 
> on many different operating systems to keep these machines uptodate. 
> If Origo can provide such service to the open source community, then 
> that would be great. When this offer will be available, I will
> probably be the first one to use it. Note that in the sentence above
> I used "When" and not "If", because from what I understand from your
> answer, this should happen in the near future. So I cannot wait any
> longer.

Dear all -

thanks for raising this question! We are aware of the possibilities of
offering compilation facilities. If we are not offering it yet, it is
merely a question of manpower and time that prevented us from doing so.
What I read in this thread shows that others are struggling with the
considerable maintenance overhead compilation farms bring.

For Origo this will be different - we will offer API for compilation
machines to hook into our platform. Developers on exotic platforms can
then offer compilation services to other teams. We will host and
maintain a couple of the most popular platforms ourselves, but the real
added value will be coming from outsiders that help.

In the same spirit we are also trying to integrate numerous code-sanity
tools.

As usual, stay tuned for improvements on Origo.

thanks,
	Till

Re: [gobo-eiffel-develop] Garbage collector for use with gec-compiled applications

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

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

    Eric> Can you check it in into SVN?

Done.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Garbage collector for use with gec-compiled applications

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Windows when using msc. See the config file
>     Eric> $GOBO/tool/gec/config/msc.cfg. I didn't specify the proper
>     Eric> config options in the file $GOBO/tool/gec/config/gcc.cfg
>     Eric> yet, but it should be easy to do just by looking at what is
>     Eric> done in the msc.cfg file.
> 
> I got it working. For the first time ever, I can run the complete W3C
> test suite in one go, and quickly too.

Congratulations.

> Here is my gcc.cfg file:
> 
> -- Command lines
> cc: gcc $cflags $includes  $gc_includes -c $c
> link: gcc $lflags -lm -o $exe $objs $libs $gc_libs
> 
> -- File extensions
> obj: .o
> exe:
> 
> -- Variables
> #ifdef EIF_WORKBENCH
> cflags: 
> lflags:
> #else
> -- cflags: -O2
> cflags:
> lflags:
> #endif
> #ifdef EIF_BOEHM_GC
> gc_includes: -I$BOEHM_GC/include 
> gc_libs: $BOEHM_GC/lib/libgc.a
> #else
> gc_includes:
> gc_libs:
> #endif

Can you check it in into SVN?

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

Re: [gobo-eiffel-develop] Garbage collector for use with gec-compiled applications

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

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

    Eric> Windows when using msc. See the config file
    Eric> $GOBO/tool/gec/config/msc.cfg. I didn't specify the proper
    Eric> config options in the file $GOBO/tool/gec/config/gcc.cfg
    Eric> yet, but it should be easy to do just by looking at what is
    Eric> done in the msc.cfg file.

I got it working. For the first time ever, I can run the complete W3C
test suite in one go, and quickly too.

Here is my gcc.cfg file:

-- Command lines
cc: gcc $cflags $includes  $gc_includes -c $c
link: gcc $lflags -lm -o $exe $objs $libs $gc_libs

-- File extensions
obj: .o
exe:

-- Variables
#ifdef EIF_WORKBENCH
cflags: 
lflags:
#else
-- cflags: -O2
cflags:
lflags:
#endif
#ifdef EIF_BOEHM_GC
gc_includes: -I$BOEHM_GC/include 
gc_libs: $BOEHM_GC/lib/libgc.a
#else
gc_includes:
gc_libs:
#endif

-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Garbage collector for use with gec-compiled applications

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> The Gobo compiler does not take the Xace 'garbage_collector'
>     Eric> option yet into account. What you have to do to use the
>     Eric> Boehm GC is to use the gec command-line option --gc=boehm
>     Eric> (and make sure that the environment variable $BOEHM_GC
>     Eric> points to where it is installed.
> 
> Do I have to download the boehm gc separately then, or is it in the
> Gobo distribution?

You have to download it separately and install it.

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