gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

Eric Bezault wrote:
> Colin Paul Adams wrote:
>>>> gestalt_test_driver49.c:1920: warning: initialization from 
>>>> incompatible pointer type
>>
>>> Can you send me the C code of the corresponding function
>>> and indicate which line is #1920?
>>
>> Line 1920 looks like this:
>>
>>
>> {0, 1912, EIF_FALSE, &T1912f40},
> 
> Is T1912 an expanded type? (See its Eiffel name in the .h file.)
> If not, can you send me the signature of the C function T1912f40?

Also, do you compile with the option "trace"?

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

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

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

    Eric> Colin Paul Adams wrote:
    >>>> gestalt_test_driver49.c:1920: warning: initialization from
    >>>> incompatible pointer type
    >> 
    >>> Can you send me the C code of the corresponding function and
    >>> indicate which line is #1920?
    >> 
    >> Line 1920 looks like this:
    >> 
    >> 
    >> {0, 1912, EIF_FALSE, &T1912f40},

    Eric> Is T1912 an expanded type? (See its Eiffel name in the .h
    Eric> file.)  If not, can you send me the signature of the C
    Eric> function T1912f40?

/* STDC_TEMPORARY_FILE.dispose */
extern void T1912f40(GE_call* ac, T0* C);


and:
	
<option name="trace" value="false"/>

-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] Conformance of literals to attached arguments

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

I just came across this:

Error code: VUAR(2)
Type error: non-conforming actual argument in feature call. 
What to do: make sure that type of actual argument conforms to type
  of corresponding formal argument. 

Class: ST_TEST_ST_STRING
Feature: test_substring
Called feature: make_from_string (a_string: !STRING_GENERAL) from ST_STRING
Argument name: a_string
Argument position: 1
Actual argument type: STRING_8
Formal argument type: !STRING_GENERAL
Line: 57
      do
->      create l_32.make_from_string ("A test string")

ISE 6.1.

It astonishes me. Why doesn't a literal of type STRING_8 conform to
!STRING_GENERAL ?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

Eric Bezault wrote:
> Eric Bezault wrote:
>> Colin Paul Adams wrote:
>>>>> gestalt_test_driver49.c:1920: warning: initialization from 
>>>>> incompatible pointer type
>>>
>>>> Can you send me the C code of the corresponding function
>>>> and indicate which line is #1920?
>>>
>>> Line 1920 looks like this:
>>>
>>>
>>> {0, 1912, EIF_FALSE, &T1912f40},
>>
>> Is T1912 an expanded type? (See its Eiffel name in the .h file.)
>> If not, can you send me the signature of the C function T1912f40?
> 
> Also, do you compile with the option "trace"?

I meant "exception_trace".

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

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

Colin Paul Adams wrote:
>>> gestalt_test_driver49.c:1920: warning: initialization from incompatible pointer type
> 
>> Can you send me the C code of the corresponding function
>> and indicate which line is #1920?
> 
> Line 1920 looks like this:
> 
> 
> {0, 1912, EIF_FALSE, &T1912f40},

Is T1912 an expanded type? (See its Eiffel name in the .h file.)
If not, can you send me the signature of the C function T1912f40?

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

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

>> gestalt_test_driver49.c:1920: warning: initialization from incompatible pointer type

>Can you send me the C code of the corresponding function
>and indicate which line is #1920?

Line 1920 looks like this:


{0, 1912, EIF_FALSE, &T1912f40},


This is part of a huge static array:

EIF_TYPE GE_types[2384] = {


The other occurrences of the warning are all of the same pattern, for
instance:

{0, 174, EIF_FALSE, 0},
{0, 175, EIF_FALSE, &T175f12},

there is a warning generated for the second of the two above lines,
but not the first.
-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com


-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Eric Bezault wrote:
>     >> Colin Paul Adams wrote:
>>> Can you do anything to stop these warning messages:
>     >>> 
>     >>> gestalt_test_driver31.c:3409: warning: passing argument 1 of
>     >>> GE_check_void' discards qualifiers from pointer target type
>     >>> 
>     >>> I get a lot of them.
> 
>     Eric> I added the type casts. Can you try to recompile gec and
>     Eric> give it a try?
> 
> That is a great improvement.
> 
> Now I just get one warning (repeated about a dozen times) in one C file:
> 
> gestalt_test_driver49.c:1920: warning: initialization from incompatible pointer type

Can you send me the C code of the corresponding function
and indicate which line is #1920?

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

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

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

    Eric> Eric Bezault wrote:
    >> Colin Paul Adams wrote:
>> Can you do anything to stop these warning messages:
    >>> 
    >>> gestalt_test_driver31.c:3409: warning: passing argument 1 of
    >>> GE_check_void' discards qualifiers from pointer target type
    >>> 
    >>> I get a lot of them.

    Eric> I added the type casts. Can you try to recompile gec and
    Eric> give it a try?

That is a great improvement.

Now I just get one warning (repeated about a dozen times) in one C file:

gestalt_test_driver49.c:1920: warning: initialization from incompatible pointer type

-- 
Colin Adams
Preston Lancashire

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

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

Daniel Tuser wrote:
> Eric Bezault wrote:
>> I tried to compiled it with the very latest version of gec
>> and it compiled. So I guess the problem has been fixed since
>> you last tried it.
>>
> 
> I gave you the wrong class, with that class. With that class and the 
> previous version of the binary search tree implementation you get the 
> compile error with gec and not problem with the compiler of Eiffel 
> Software. The reason for that problem seams to be a different 
> interpretation of anchored types. My intuition tells me that gec is 
> correct, but I didn't check it in the ECMA specification.

I guess you were referring to these errors:

----
[VJAR] class DS_RED_BLACK_TREE (DS_COMMON_BINARY_SEARCH_TREE,285,18): 
the source of the assignment (of type 'DS_BINARY_SEARCH_TREE_NODE 
[INTEGER, INTEGER]') does not conform nor convert to its target entity 
(of type 'DS_RED_BLACK_TREE_NODE [INTEGER, INTEGER]').
----
[VJAR] class DS_AVL_TREE (DS_COMMON_BINARY_SEARCH_TREE,285,18): the 
source of the assignment (of type 'DS_BINARY_SEARCH_TREE_NODE [INTEGER, 
INTEGER]') does not conform nor convert to its target entity (of type 
'DS_AVL_TREE_NODE [INTEGER, INTEGER]').
----
[VJAR] class DS_BINARY_SEARCH_TREE_SET 
(DS_COMMON_BINARY_SEARCH_TREE,285,18): the source of the assignment (of 
type 'DS_COMMON_BINARY_SEARCH_TREE_NODE [INTEGER, INTEGER]') does not 
conform nor convert to its target entity (of type 
'DS_BINARY_SEARCH_TREE_SET_NODE [INTEGER]').
----
[VJAR] class DS_RED_BLACK_TREE_SET 
(DS_COMMON_BINARY_SEARCH_TREE,285,18): the source of the assignment (of 
type 'DS_COMMON_BINARY_SEARCH_TREE_NODE [INTEGER, INTEGER]') does not 
conform nor convert to its target entity (of type 
'DS_RED_BLACK_TREE_SET_NODE [INTEGER]').
----
[VJAR] class DS_AVL_TREE_SET (DS_COMMON_BINARY_SEARCH_TREE,285,18): the 
source of the assignment (of type 'DS_COMMON_BINARY_SEARCH_TREE_NODE 
[INTEGER, INTEGER]') does not conform nor convert to its target entity 
(of type 'DS_AVL_TREE_SET_NODE [INTEGER]').
----

These are what I call flat Degree 3 errors. I think that gec is
indeed correct in reporting these errors because it is part of
ECMA. As for the compatibility with ISE EiffelStudio, I think that
these errors will also be reported if you add the option
"full_class_checking" in your ECF file.

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

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

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

Eric Bezault wrote:
> I tried to compiled it with the very latest version of gec
> and it compiled. So I guess the problem has been fixed since
> you last tried it.
>

I gave you the wrong class, with that class. With that class and the 
previous version of the binary search tree implementation you get the 
compile error with gec and not problem with the compiler of Eiffel 
Software. The reason for that problem seams to be a different 
interpretation of anchored types. My intuition tells me that gec is 
correct, but I didn't check it in the ECMA specification.
test.e is the class that shows the difference and there is a newer 
version of the binary search tree, that does not have the 
incompatibility, but there is still at least one bug.

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

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

Eric Bezault wrote:
> Daniel Tuser wrote:
>> I just found a problem related to gec. I know that you try to make 
>> gec compatible to the compiler of Eiffel Software. The following 
>> class works with EiffelStudio but does not compile with gec. I didn't 
>> have time to have a closer look at the inheritance problem, so I just 
>> show you the problem as you are preparing a release. You certainly 
>> need the binary search tree classes from the previous post to compile 
>> the test.
>>
>> class TEST_1
>> ...
>
> I tried to compiled it with the very latest version of gec
> and it compiled. So I guess the problem has been fixed since
> you last tried it.
I used the svn version and made a bootstrap to get the latest version of 
gec. But maybe I somehow mixed two variants of the binary search tree 
implementation. I tried to avoid that, but probably I missed something. 
Maybe I can reproduce it, but it is not very likely.

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

Eric Bezault wrote:
> Colin Paul Adams wrote:
>> Can you do anything to stop these warning messages:
>>
>> gestalt_test_driver31.c:3409: warning: passing argument 1 of 
>> `GE_check_void' discards qualifiers from pointer target type
>>
>> I get a lot of them.
> 
> Does it look like this bug:
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=1961462&group_id=24591&atid=381937 
> 
> 
> If so, I guess I will have to add explicit type casts.

I added the type casts. Can you try to recompile gec and
give it a try?

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

Re: [gobo-eiffel-develop] Memory allocation overhead

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

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

    Colin> The implementation is UTF-32, and
    Colin> substring operations result in two objects sharing the same
    Colin> SPECIAL [INTEGER_32].

That should have read NATURAL_32.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory allocation overhead

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

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

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

    >>> Another possibility is to avoid OO techniques. For instance, I
    >>> know from last weekend's profiling that there is a VERY large
    >>> number of XM_XPATH_UNTYPED_ATOMIC_VALUE objects created by
    >>> conversion from XM_XPATH_STRING_VALUE. Untyped-atomic is
    >>> XPath's coercible data type. Although untyped-atomic does not
    >>> inherit from xs:string in the XPath type hierarchy, I have
    >>> implemented XM_XPATH_UNTYPED_ATOMIC_VALUE as inheriting from
    >>> XM_XPATH_STRING_VALUE for convenience, as they are nearly
    >>> identical excpet for the coercing behaviour. So a clear saving
    >>> could be made by merging the two classes with a BOOLEAN to
    >>> indicate which type is actualy meant. Then the coercion to
    >>> xs:string is simply implemented by flipping the BOOLEAN. I
    >>> suspect this is going to be a big saving, but it is very
    >>> anti-OO.

    Eric> This might be the kind of things I could use indeed.

    Colin> It helped, although not as dramatically as eliminating my
    Colin> ARRAY [BOOLEAN]s. Eliminating these 4 arrays takes the time
    Colin> down from 71 minutes to 30 minutes. This change to the
    Colin> untyped atomic values brings it further down to 22 minutes.

I decided to take it out in the end. Aliasing meant that I kept having
to add bodges to get round bugs, and I couldn't be sure another one
wasn't going to keep springing up. The runtime is now back up to 31 minutes.

I may take another look at this possibility again in the future, but
only after I have implemented my next plan. 
I have written a class (provisionally named ST_STRING) for fast
read-only Unicode strings, plus an accompanying class
ST_STRING_BUILDER.
The implementation is UTF-32, and substring operations result in two
objects sharing the same SPECIAL [INTEGER_32].

It will take me a long time, but I am going to convert the
XPath/XPointer/XSLT libraries to use this class (the Unicode regular
expression stuff has been on hold since February, and will continue to
be so until I finish this). I expect it will make a very significant
difference. If it does, I will post the two classes here for review,
prior to any check-ins.

What would be nice would be to have a common interface between this
class and STRING_GENERAL, so as to reduce the amount of duplication of
interface routines in the rest of the string library (named
READABLE_STRING, perhaps). But I don't know if it will be practical yet. 
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

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

    Eric> Colin Paul Adams wrote:
    >> Can you do anything to stop these warning messages:
    >> 
    >> gestalt_test_driver31.c:3409: warning: passing argument 1 of
    >> `GE_check_void' discards qualifiers from pointer target type
    >> 
    >> I get a lot of them.

    Eric> Does it look like this bug:

    Eric> https://sourceforge.net/tracker/index.php?func=detail&aid=1961462&group_id=24591&atid=381937

    Eric> If so, I guess I will have to add explicit type casts.

Maybe.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] GCC warnings when compiling with GEC

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

Colin Paul Adams wrote:
> Can you do anything to stop these warning messages:
> 
> gestalt_test_driver31.c:3409: warning: passing argument 1 of `GE_check_void' discards qualifiers from pointer target type
> 
> I get a lot of them.

Does it look like this bug:

https://sourceforge.net/tracker/index.php?func=detail&aid=1961462&group_id=24591&atid=381937

If so, I guess I will have to add explicit type casts.

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

[gobo-eiffel-develop] GCC warnings when compiling with GEC

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

Eric,

Can you do anything to stop these warning messages:

gestalt_test_driver31.c:3409: warning: passing argument 1 of `GE_check_void' discards qualifiers from pointer target type

I get a lot of them.
-- 
Colin Adams
Preston Lancashire

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

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric>       $GOBO/install.sh gcc
> 
>     Eric> under Unix/Linux in order to generate the binary files of
>     Eric> the Gobo tools in the directory $GOBO/bin.
> 
> Hm.
> That is what I did (as instructed) in order to build the binary
> packages for Linux.
> 
> But when I saw the file sizes for all the binary releases, it occurred
> to me to try stripping the executables. This reduces their size by
> about 10%, so perhaps you should add the steps:
> 
> cd $GOBO/bin
> strip *

I updated the script in SVN.

-- 
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] New release: Gobo 3.8

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

Hello,

A new release of Gobo is available from the usual location:

      https://sourceforge.net/projects/gobo-eiffel/

This version should work with the forthcoming release of
ISE's EiffelStudio 6.2.

In order to avoid binary file incompatibilities between
operating systems, the Gobo package does not contain executables
anymore. Instead of that, the directory $GOBO/bin contains the
C files of the Gobo Eiffel compiler which will be used by a script
to populate this directory with the binary files for your platform.
When installing the Gobo package, you will now have to run either:

      %GOBO%\install.bat msc

under Windows, or:

      $GOBO/install.sh gcc

under Unix/Linux in order to generate the binary files
of the Gobo tools in the directory $GOBO/bin.

For more details about this new release of Gobo, please
read the Readme file and the online documentation:

      http://gobo-eiffel.sf.net/gobo/Readme.txt
      http://gobo-eiffel.sf.net/gobo/index.html

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

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

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

Daniel Tuser wrote:
> I just found a problem related to gec. I know that you try to make gec 
> compatible to the compiler of Eiffel Software. The following class works 
> with EiffelStudio but does not compile with gec. I didn't have time to 
> have a closer look at the inheritance problem, so I just show you the 
> problem as you are preparing a release. You certainly need the binary 
> search tree classes from the previous post to compile the test.
> 
> class TEST_1
> 
> create
> 
>    make
> 
> feature {NONE}
> 
>    make is
>           -- Creation procedure.
>       local
>          l_comparator: DS_COMPARABLE_COMPARATOR [STRING]
>       do
>          create l_comparator.make
>          create tree.make (l_comparator)
>       end
> 
>    tree: DS_AVL_TREE_SET [STRING]
> 
> end

I tried to compiled it with the very latest version of gec
and it compiled. So I guess the problem has been fixed since
you last tried it.

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

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] Binary search tree

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

Eric Bezault wrote:
> Daniel Tuser wrote:
>> Just to make it clear, the binary search tree implementation is still 
>> not finished. There is still at least one bug and I didn't test it 
>> extensively.
>
> In that case, I suggest that I release a new version of Gobo
> first. Then I will have more time to review your code and see
> how to best integrate it with the existing classes.
>
Yes. We have enough time :-).

I just found a problem related to gec. I know that you try to make gec 
compatible to the compiler of Eiffel Software. The following class works 
with EiffelStudio but does not compile with gec. I didn't have time to 
have a closer look at the inheritance problem, so I just show you the 
problem as you are preparing a release. You certainly need the binary 
search tree classes from the previous post to compile the test.

class TEST_1

create

    make

feature {NONE}

    make is
           -- Creation procedure.
       local
          l_comparator: DS_COMPARABLE_COMPARATOR [STRING]
       do
          create l_comparator.make
          create tree.make (l_comparator)
       end

    tree: DS_AVL_TREE_SET [STRING]

end

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] Binary search tree

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

Daniel Tuser wrote:
> Just to make it clear, the binary search tree implementation is still 
> not finished. There is still at least one bug and I didn't test it 
> extensively.

In that case, I suggest that I release a new version of Gobo
first. Then I will have more time to review your code and see
how to best integrate it with the existing classes.

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