Bug in gec ?

6 Messages Forum Options Options
Permalink
Howard Thomson
Bug in gec ?
Reply Threaded More
Print post
Permalink
Hi all,

I managed to confuse myself, and the compiler, by trying to compile
a class set, as below, which had non-corresponding class filenames
vs the contained class names.

Would someone care to compile the following (trivial) class set
and see whether 'gec' compiles it [it shouldn't !] and whether you
get any error messages that explain the problem ?

Howard Thomson
--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein

==================================================

file main.e:

class MAIN

create
        make

feature

        parent: PARENT

        make is
                do
                        create {CHILD} parent.make
                end

end
=======================

file: child.e:

deferred class PARENT

feature -- Creation

        make is
                do
                end

end
======================

file parent.e:

class CHILD

inherit
        PARENT

create

        make

feature -- Creation

        make_x is
                do
                end

end


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
gobo-eiffel-develop@...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
Eric Bezault
Re: Bug in gec ?
Reply Threaded More
Print post
Permalink
Howard Thomson wrote:
> Hi all,
>
> I managed to confuse myself, and the compiler, by trying to compile
> a class set, as below, which had non-corresponding class filenames
> vs the contained class names.
>
> Would someone care to compile the following (trivial) class set
> and see whether 'gec' compiles it [it shouldn't !] and whether you
> get any error messages that explain the problem ?

I think that gec detects a compilation error because
no C code is generated. However it fails to display
an error message. I'll fix that.

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
gobo-eiffel-develop@...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
Eric Bezault
Re: Bug in gec ?
Reply Threaded More
Print post
Permalink
Eric Bezault wrote:

> Howard Thomson wrote:
>> Hi all,
>>
>> I managed to confuse myself, and the compiler, by trying to compile
>> a class set, as below, which had non-corresponding class filenames
>> vs the contained class names.
>>
>> Would someone care to compile the following (trivial) class set
>> and see whether 'gec' compiles it [it shouldn't !] and whether you
>> get any error messages that explain the problem ?
>
> I think that gec detects a compilation error because
> no C code is generated. However it fails to display
> an error message. I'll fix that.

It's now fixed. gec displays this message:

----
[GVSCN-1] class CHILD (1,16): file '.\child.e' contains class PARENT
instead of the expected class CHILD.
----

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
gobo-eiffel-develop@...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
Howard Thomson
Re: Bug in gec ?
Reply Threaded More
Print post
Permalink
Thanks Eric for the fix as below.

I am continuing to develop my custom Garbage Collector for gec, with
four outstanding routines needed before stress testing.

1/ mark the stack, and I have basically worked out how I am going to
accurately mark references values on the stack [subject to testing ! ]

2/ make available to the GC a reference to the root object

3/ dispatch routine to call dynamic-type mark routine per id field

4/ [less urgent] work for expanded class attribute(s) that recursively
contain reference containing expanded class attribute(s)

Stress testing of the core C routines for memory allocation, random de-reference,
mark, scan and free is now working reliably with about 50/55 percent bytes-requested
vs bytes-allocated [I think from memory]. It is currently Linux specific, but with only
one smallish routine being platform specific [mmap dependent code].

I am also working on a class ET_ELF_X86_64_CODE_GENERATOR to generate a
Linux ELF X86_64 file, using a set of classes based loosely on the concepts in the
LLVM project, but that has a long way to go.

Regards,

Howard

On Thursday 24 Jul 2008, you wrote:

> Eric Bezault wrote:
> > Howard Thomson wrote:
> >> Hi all,
> >>
> >> I managed to confuse myself, and the compiler, by trying to compile
> >> a class set, as below, which had non-corresponding class filenames
> >> vs the contained class names.
> >>
> >> Would someone care to compile the following (trivial) class set
> >> and see whether 'gec' compiles it [it shouldn't !] and whether you
> >> get any error messages that explain the problem ?
> >
> > I think that gec detects a compilation error because
> > no C code is generated. However it fails to display
> > an error message. I'll fix that.
>
> It's now fixed. gec displays this message:
>
> ----
> [GVSCN-1] class CHILD (1,16): file '.\child.e' contains class PARENT
> instead of the expected class CHILD.
> ----
>



--
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
gobo-eiffel-develop@...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
Lothar Scholz
Re: Bug in gec ?
Reply Threaded More
Print post
Permalink
Hello Howard,

Thursday, July 24, 2008, 11:00:52 PM, you wrote:

HT> Thanks Eric for the fix as below.

HT> I am continuing to develop my custom Garbage Collector for gec, with
HT> four outstanding routines needed before stress testing.

Is this a conservative or an exact garbage collector.
Sometimes i dream about a precise concurrent compacting garbage collector.

--
Best regards,
 Lothar                            mailto:llothar@...


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
gobo-eiffel-develop@...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
Howard Thomson
Re: Bug in gec ?
Reply Threaded More
Print post
Permalink
Hi Lothar,

This is an exact / precise collector.

The primary requirement, above all else, is that it be reliable and to
that end I have been including vast [it seems] numbers of assertions
in the C implementation.

It is not yet either compacting or generational. Until I can reliably
demonstrate that marking the stack is a precise process, anything
else is superfluous.

A derivative of the primary requirement is that I must be able to understand
it (!), which will also help once I put it out for others to use in the fairly
near future, subject to it working correctly when integrated with gec.

I want to be able to implement long running daemon programs using gec,
[my variant of it] with multi-threading, and I while I am happy that Boehm et al
works in a single thread system, I am not convinced that it would work the
way I want it to for my planned systems.

Regards,

Howard

On Friday 25 Jul 2008, Lothar Scholz wrote:

> Hello Howard,
>
> Thursday, July 24, 2008, 11:00:52 PM, you wrote:
>
> HT> Thanks Eric for the fix as below.
>
> HT> I am continuing to develop my custom Garbage Collector for gec, with
> HT> four outstanding routines needed before stress testing.
>
> Is this a conservative or an exact garbage collector.
> Sometimes i dream about a precise concurrent compacting garbage collector.
>



--
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
gobo-eiffel-develop@...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop