gobo-eiffel-develop Mailing List for Gobo Eiffel Project (Page 54)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

We have fixed the MA_DECIMAL stuff in our repository, we are looking at the
other issues.

Manu

On 1/23/07, Eric Bezault <er...@go...> wrote:
> Paul Cohen wrote:
> >> Nevertheless I will follow your suggestion and have:
> >>
> >>       gobo/trunk
> >>       gobo/branches    <-- empty until used.
> >>       gobo/tags/GE_3_0
> >>       ...
> >>       gobo/tags/GE_3_5
> >>
> >
> > Sounds fine with me. Out of curiosity why not use labels "gobo-3.0" etc?
>
> GE_3_0 etc. are the tags currently in CVS. If I remember correctly
> CVS (or at least WinCVS) didn't let me choose tags with non-alphanumeric
> characters (no dots for example). Do you think I should rename them
> when migrating to SVN?

Labels like "gobo-3.0" do work fine in Subversion and I just think
it's more readable. We use the following naming convention for our
libraries/tools/components:

   <name>-M.N.P

Where <name> is the name of the library, M is the major version
number, N is the minor version number and P is the patch level number.
We use exactly the same name for our (internal) releases too as well
as in our issue tracking system so we can maintain a consistent naming
policy everywhere.

I have no strong view on this. It could be nice to keep your CVS
labeling tradition out of respect for Gobo's history! :-)

/Paul

Paul Cohen wrote:
>> Nevertheless I will follow your suggestion and have:
>>
>>       gobo/trunk
>>       gobo/branches    <-- empty until used.
>>       gobo/tags/GE_3_0
>>       ...
>>       gobo/tags/GE_3_5
>>
> 
> Sounds fine with me. Out of curiosity why not use labels "gobo-3.0" etc?

GE_3_0 etc. are the tags currently in CVS. If I remember correctly
CVS (or at least WinCVS) didn't let me choose tags with non-alphanumeric
characters (no dots for example). Do you think I should rename them
when migrating to SVN?

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

On 1/23/07, Eric Bezault <er...@go...> wrote:
> Paul Cohen wrote:
> > 2. A developer wants to fix a bug in a previous release (say Gobo 3.5)
> > but knows it might take a few days or a week to do. She creates a
> > branch from the GE_3_5 tree and fixes the bug. Fixing the bug in a
> > separate branch makes it easy for a co-developer to quickly get his
> > own copy of the code she's working on if neccessary. Eventually when
> > she is done she merges back the bugfix into the GE_3_5 tree.
>
> Hmm, I don't think that it should be merged, but rather tagged
> as GE_3_5_1 or something like that. We should keep some track of
> the original version of 3.5, and that's what the tag GE_3_5 is
> for, no?

Well, yes you are right. By convention tags are just used as a way to
create a named snapshot of a Subversion tree at a given point in time.
However, I see "tags" as release branches (one can always recreate the
pristine GE_3_5 state by its unique revision number). For subsequent
release patches to Gobo 3.5 I would release them as 3.5.1 (svn
revision 4598), 3.5.2 (svn revision 4923), etc. It avoids creating
lots of tags just for patch releases. Global revision numbering is
good.

However, the convention is to use trees under the "tags" directory
only as snapshots, like you say. And it's probably better to follow
standard Subversion conventions.

> When I suggested the directory structure above, for me the label
> (I don't call it tag here to avoid confusion) for the release
> 3.5 was the root (the version from which the branch started)
> of the branch GE_3_5. From what you described, it looks like
> SVN (or users of SVN) is not that smart and we should have a
> special tag in /tags to keep track of the root of the branch.
>

Preventing commits to trees under "tags" is achieved either a) by
making sure everyone knows that they shouldn't do commits to trees
under "tags" or b) enforcing an access control policy via Subversions
event hook mechanism that prevents commits being made. I'd suggest the
latter.

So I'd suggest the following for doing patches in 3.5:

1. Create a new branch GE_3_5_patches under "branches" from GE_3_5.
2. Do bug fixes and commits to the GE_3_5_patches branch.
3. When ready, create a new tag GE_3_5_1 under "tags" and copy the
tree from the GE_3_5_patches branch.
4. Do more bug fixes and commits to the GE_3_5_patches branch.
5. When ready, create a new tag GE_3_5_2 under "tags" and copy the
tree from the GE_3_5_patches branch.
6. .. etc.

> Also, what I don't like with tags in SVN is that they have the
> same behavior as branches (they are not labels, but modifiable
> copies of the repository like branches are) and it is all based
> on the user's discipline to make sure that they keep a tag behavior.

True. (I assume you meant label behaviour in the last line)

> Nevertheless I will follow your suggestion and have:
>
>       gobo/trunk
>       gobo/branches    <-- empty until used.
>       gobo/tags/GE_3_0
>       ...
>       gobo/tags/GE_3_5
>

Sounds fine with me. Out of curiosity why not use labels "gobo-3.0" etc?

/Paul

Hello,

The long awaited new release of the Gobo package is now
available from the usual locations:

    http://www.gobosoft.com/
    https://sourceforge.net/projects/gobo-eiffel/

It contains many new libraries and tools since the last release,
among which:

    * An Eiffel library for command-line argument parsing.
    * An XSLT processor entirely written in Eiffel using
      the Gobo Eiffel XML Library.
    * An Eiffel compiler, still under development but already
      able to compile all the Eiffel code contained in the
      Gobo package.

For more details, please read the Readme file and the online
documentation:

    http://www.gobosoft.com/eiffel/gobo/Readme.txt
    http://www.gobosoft.com/eiffel/gobo/index.html

The Gobo package supports most Eiffel compilers:

    * GEC: the Gobo Eiffel compiler, of course.

    * ISE: note that although it has been successfully
      tested with versions 5.7/6.0, I want to boycott
      this version of the compiler in protest against
      ECF and the way ISE introduced it. Therefore
      Gobo 3.5 does not officially support 5.7/6.0.
      Because ECF has also caused many problems to some
      users of Gobo who were not able to switch to ISE 5.7,
      Gobo will still support ISE 5.6 for the time being.

    * SE: only the 1.2 development branch of this compiler
      is supported. SE 2.* is not supported anymore because
      it implements another language than the one supported
      in Gobo.

    * VE: it's probably the last release of Gobo that
      supports Visual Eiffel. The problem is that there
      has been no activity on the VE mailing list and
      SourceForge repository for almost 2 years. This
      is a big issue for Gobo because we cannot use some
      Eiffel constructs implemented for a long time in
      other compilers such as Agents for example which
      are still missing in VE.

Finally, note that following a discussion at NICE a
few months ago, the next version of Gobo will be
released under the MIT license.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

    Eric> SE triggers a precondition violation when there is an
    Eric> overflow in the integer operators.

This brings up another point. Sometimes you really want to have
overflow and sometimes you don't. For example I have a set of MD5
routines (which I hope something Gobo will get one day) which depend
on overflow. They compile fine with ISE but with SE only with overflow
turned off.

So if this precondition is useful, adding overflow safe arithmetic to
KL_INTEGER_ROUTINES can be a solution useful for more projects.

- -- 
All the best,

Berend de Boer

PS: This email has been digitally signed if you wonder what the strange
characters are that your outdated email client displays.
PGP public key: http://www.pobox.com/~berend/berend-public-key.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFFtnZRIyuuaiRyjTYRAvUbAJ9L3eVpNTQjyUQjlv5+34Go1UkWawCffM9x
1xE6sPw9VO2hJznnGXxvsP8=
=8bdQ
-----END PGP SIGNATURE-----

Paul Cohen wrote:
> On 1/23/07, Eric Bezault <er...@go...> wrote:
>> For the migration to SVN, I plan to have the directories as follows:
>>
>>     gobo/trunk
>>     gobo/tags         <--- I'm not sure how useful this is.
>>     gobo/branches/GE_3_0
>>     ...
>>     gobo/branches/GE_3_5
>>
>> (GE_3_0, ... GE_3_5 were the tags I put in CVS for each release).
>>
> 
> The Subversion convention is to use the tags directory for
> labeled/tagged releases and the branches tag for temporary developer
> branches outside the main development, ie typically the trunk. In
> theory branches are used for a limited amount of time but tags are
> used as long as the tagged release in question is supported.
> 
> Two cases where branches are useful:
> 
> 1. One or a few developers want to rewrite a part of gelint but know
> that it might take a few weeks before the rewriting is stable enough
> to merge back into the main trunk. They create a branch from the trunk
> and work in that tree. Eventually when they are done and finished
> testing it they can merge all changes back on the trunk. The branch
> then becomes obsolete and can be removed.
> 
> 2. A developer wants to fix a bug in a previous release (say Gobo 3.5)
> but knows it might take a few days or a week to do. She creates a
> branch from the GE_3_5 tree and fixes the bug. Fixing the bug in a
> separate branch makes it easy for a co-developer to quickly get his
> own copy of the code she's working on if neccessary. Eventually when
> she is done she merges back the bugfix into the GE_3_5 tree.

Hmm, I don't think that it should be merged, but rather tagged
as GE_3_5_1 or something like that. We should keep some track of
the original version of 3.5, and that's what the tag GE_3_5 is
for, no?

When I suggested the directory structure above, for me the label
(I don't call it tag here to avoid confusion) for the release
3.5 was the root (the version from which the branch started)
of the branch GE_3_5. From what you described, it looks like
SVN (or users of SVN) is not that smart and we should have a
special tag in /tags to keep track of the root of the branch.

Also, what I don't like with tags in SVN is that they have the
same behavior as branches (they are not labels, but modifiable
copies of the repository like branches are) and it is all based
on the user's discipline to make sure that they keep a tag behavior.

Nevertheless I will follow your suggestion and have:

      gobo/trunk
      gobo/branches    <-- empty until used.
      gobo/tags/GE_3_0
      ...
      gobo/tags/GE_3_5

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

Forwarded to the list.

Franck Arnaud wrote:
>> uclint tool developed by Franck. I'm not sure how useful this
>> tool is. Should it be moved to SVN? 
> 
> It aims at checking that all uses of STRING are UC_STRING-safe, that is
> only the polymorphically-safe routines of STRING are used in the linted
> program. My little hack probably doesn't work anymore, and I'm happy for
> it not to be migrated to SVN.

OK.

> That sort of functionality perhaps should be a feature of gelint. A way
> to generalise would be to have 'typecheck A as B' option, that is you
> typecheck a program as if A was defined by B, and uclint is where
> A=STRING and B a version of KS_STRING without all the 'Note: use
> STRING_. version when UC_STRING involved' routines.

That's indeed an interesting possible extension of gelint.

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

> uclint tool developed by Franck. I'm not sure how useful this
> tool is. Should it be moved to SVN? 

It aims at checking that all uses of STRING are UC_STRING-safe, that is
only the polymorphically-safe routines of STRING are used in the linted
program. My little hack probably doesn't work anymore, and I'm happy for
it not to be migrated to SVN.

That sort of functionality perhaps should be a feature of gelint. A way
to generalise would be to have 'typecheck A as B' option, that is you
typecheck a program as if A was defined by B, and uclint is where
A=STRING and B a version of KS_STRING without all the 'Note: use
STRING_. version when UC_STRING involved' routines.

One of the limitation of the tool is that it didn't detect and discard
safe cases like 
  a_string.append_string ("hello") -- or same with manifest constant
  string
but that's harder to generalise.

For the migration to SVN, I plan to have the directories as follows:

    gobo/trunk
    gobo/tags         <--- I'm not sure how useful this is.
    gobo/branches/GE_3_0
    ...
    gobo/branches/GE_3_5

(GE_3_0, ... GE_3_5 were the tags I put in CVS for each release).

I'm not sure what should be the fate of the experiement directory.
Is this directory really useful? Should it we part of Subversion?
I see two things in there: an argument library developed by
Christian Couder (now superceded by Bernd's library), and the
uclint tool developed by Franck. I'm not sure how useful this
tool is. Should it be moved to SVN? If yes, should we keep an
experiment section for it, or should it go to gobo/trunk/src,
or to gobo/trunk/work (next to geuc)?

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

On Tue, 23 Jan 2007 15:37:23 +0100, Jocelyn <li...@dj...> wrote:

> For instance, let's imagine a project using recent features of geant
> (replace task for instance).

Dear Jocelyn,

I fully see your point. It is just my personal experience that it is  
better to solve problems when they occur. There are just too many 'if's  
here. Should the need for an interim release arise, raised by a specific  
project or developer, then we will find a suitable solution. Currently,  
creating more versions of GOBO is not necessary and creates work that  
could be spent somewhere else.

I kicked off the initial demand for a GOBO release. But the demand for a  
new release of GOBO is supported by concrete needs we have for a couple of  
projects and teaching duties that GOBO 3.4 cannot provide. All these needs  
are satisfied by bi-anual releases.

Regards,
Bernd

> We have enough confusion with a "stable" and a "svn" versions. I
> cannot see who would be the target audience for "dev" versions,
> considering the Eiffel community is so small.
For instance, let's imagine a project using recent features of geant
(replace task for instance).
For now it may be based on the trunk of the repository (CVS) ... which
is dependent on daily changes.
So 3 solutions:
    - the project depends on GoboEiffel : HEAD of the CVS repository ...
which may not safe convenient because of daily changes
    - this project checkout a version of gobo, and integrate it into its
repository, this is possible but then it make its repository growing fast
       especially if this project need frequent update of the gobo
source code
    - or it uses either interim release, branch version, or with
subversion  repository revision (hopefully gobo will be using subversion
very soon, and thanks to svn:externals this will be great for dependent
projects)

But waiting for the official Gobo Eiffel release might not be a
solution. Thus using a numbered/tagged dev version of GoboEiffel may help.

In this case, interim releases could be nice.
But I agree ... this might be waste of time/resource/disk space... for
now concerning the GoboEiffel team (but also a gain of time for Gobo
Eiffel users who doesn't want to waste time struggling to keep their
code works with HEAD of repository).

-- Jocelyn.

On Tue, 23 Jan 2007 14:13:55 +0100, Jocelyn <li...@dj...> wrote:

> However, what about interim releases ? Maybe one a month for example.
> Those releases would have "dev" status, and then not officially as safe
> as official releases.

We have enough confusion with a "stable" and a "svn" versions. I cannot  
see who would be the target audience for "dev" versions, considering the  
Eiffel community is so small.

Bernd

Personally I think 2 releases a year is fine, more can be a waste of
precious time, and less is annoying for other projects depending on Gobo
and waiting for new features, or bug fixes.

However, what about interim releases ? Maybe one a month for example.
Those releases would have "dev" status, and then not officially as safe
as official releases.
If the "delivery" process is just a matter of running a script, this
would be easy to get,
and then people without access to CVS, or SVN could still benefit recent
changes from the dev version.

About splitting Gobo into  core and other, this could be nice, but as
mentioned before this is time consuming.
If adopted, then Gobo Eiffel project should be a GoboEiffelCore + a kind
of CPAN but for (Gobo)Eiffel, with libraries specifying their dependencies.

-- Jocelyn

On 1/23/2007 13:38 PM, Paul Cohen wrote:
> Given the size of Gobo, releases twice a year is fine with me.
> Compiling against the CVS/Subversion repository can always be done by
> those in need of bleeding edge stuff. I still think that breaking up
> the project into subprojects/components with separate release
> schedules would enable more frequent releases.
>
> We are developing a product with a planned release schedule and we are
> also supporting older releases of the product for specific customers.
> We *definitely* want to compile with a well-defined releases of Gobo.
> Either an official Gobo-release, eg 3.4, or a update from the Gobo
> CVS/Subversion repository from a given date and of which we have own
> labeled copy in our own repository. For obvious reasons it's better to
> rely on official releases than interim uploads from the Gobo
> repository.
>
> I don't know if you've previously used the branching facilities of CVS
> in Gobo but branching is definitely easier in Subversion. Using
> branches intelligently would enable bug fixes and minor feature
> add-ons to be done in a released version in parallell with the
> revolutionary and ground-breaking work on the next release.
>
> /Paul
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>
>   

SE triggers a precondition violation when there is an
overflow in the integer operators. This is what happens
in one of the decimal test cases which computes hash_codes.
The problem occurs in one of these last lines of
MA_DECIMAL.hash_code (actually when calling '+' on the
line marked with an arrow):

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     Result := Result + INTEGER_.bit_shift_left (Result, 3)
     Result := INTEGER_.bit_xor (Result, INTEGER_.bit_shift_right 
(Result, 11))
--> Result := Result + INTEGER_.bit_shift_left (Result, 15)
     Result := INTEGER_.bit_and (Result, Platform.Maximum_integer)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now I wonder what is the usefulness of these lines.
The last line guarantees that the hash_code is
not negative, but the others will always give the
same result for a given value of 'Result' as input.
So it does not really help to get different values
for different decimal objects. I understand that it
allows to have hash_code values using the whole
spectrum of integer values. Do we really need that?
(Note that I didn't read the URL provided at the
beginning of this routine. Perhaps the explanation
is somewhere in this page.)

I'm reporting this problem here for the record. It works
fine when compiled with assertions turned off, so it can
wait until after the release before having a closer
look at it.

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

Given the size of Gobo, releases twice a year is fine with me.
Compiling against the CVS/Subversion repository can always be done by
those in need of bleeding edge stuff. I still think that breaking up
the project into subprojects/components with separate release
schedules would enable more frequent releases.

We are developing a product with a planned release schedule and we are
also supporting older releases of the product for specific customers.
We *definitely* want to compile with a well-defined releases of Gobo.
Either an official Gobo-release, eg 3.4, or a update from the Gobo
CVS/Subversion repository from a given date and of which we have own
labeled copy in our own repository. For obvious reasons it's better to
rely on official releases than interim uploads from the Gobo
repository.

I don't know if you've previously used the branching facilities of CVS
in Gobo but branching is definitely easier in Subversion. Using
branches intelligently would enable bug fixes and minor feature
add-ons to be done in a released version in parallell with the
revolutionary and ground-breaking work on the next release.

/Paul

When using SE 1.2r7 with assertions turned on I get
the following errors:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Testing xslt...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

Test Summary for xslt

# Passed:     73 tests
# Failed:     0 test
# ABORTED:    10 tests
# Total:      83 tests (296 assertions)

Test Results:
ABORT:  [XM_XSLT_TEST_BOOKS.test_transform] Eiffel exception
ABORT: 
[XM_XSLT_TEST_FOR_EACH_GROUP.test_grouping_nodes_based_on_common_values]
  Eiffel exception
ABORT:  [XM_XSLT_TEST_FOR_EACH_GROUP.test_grouping_starting_with] Eiffel 
excepti
on
ABORT:  [XM_XSLT_TEST_FOR_EACH_GROUP.test_current_grouping_key] Eiffel 
exception

ABORT:  [XM_XSLT_TEST_FOR_EACH_GROUP.test_group_adjacent] Eiffel exception
ABORT:  [XM_XSLT_TEST_FOR_EACH_GROUP.test_group_ending_with] Eiffel 
exception
ABORT:  [XM_XSLT_TEST_RESULT_DOCUMENT.test_splitting_xhtml_document] 
Eiffel exce
ption
ABORT: 
[XM_XSLT_TEST_RESULT_DOCUMENT.test_implicit_duplicate_destination_error]
  Eiffel exception
ABORT:  [XM_XSLT_TEST_RESULT_DOCUMENT.test_duplicate_destination_error] 
Eiffel e
xception
ABORT:  [XM_XSLT_TEST_STYLESHEET_BUILDER.test_simple] Eiffel exception

BUILD FAILED!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I didn't try to get an exception trace but I think that this is
because assertion checking with SE is more greedy than with
other compilers. Everything works fine when assertions are turned
off. So I will not stop the release for that, but I wanted to
report this problem here for the record, so that we can have a
look at it after the release.

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

When compiling the test cases of Gobo decimal classes
with Eiffel for .NET 6.0.65740 I get the following
errors:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Testing xacceptance...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

Test Summary for xacceptance

# Passed:     14 tests
# FAILED:     11 tests
# Aborted:    0 test
# Total:      25 tests (41808 assertions)

Test Results:
FAIL:  [MA_TEST_DECIMAL.test_add_dectest] addx228
    expected: 123456790
    but  got: 123456789
FAIL:  [MA_TEST_DECIMAL.test_base_dectest] bsrx419
    expected: 1.2346
    but  got: 1.2345
FAIL:  [MA_TEST_DECIMAL.test_divide_dectest] divx008
    expected: 0.666666667
    but  got: 0.666666666
FAIL:  [MA_TEST_DECIMAL.test_inexact_dectest] inx207
    expected: 166.7
    but  got: 166.6
FAIL:  [MA_TEST_DECIMAL.test_multiply_dectest] mulx807
    expected: 2E-1003
    but  got: 1E-1003
FAIL:  [MA_TEST_DECIMAL.test_randombound32_dectest] divx3001
    expected: 2.262681764507965005284080800438E-787
    but  got: 2.262681764507965005284080800437E-787
FAIL:  [MA_TEST_DECIMAL.test_randomdouble_dectest] divx2002
    expected: -8.91436999016088142631492413949740E+880
    but  got: -8.91436999016088142631492413949739E+880
FAIL:  [MA_TEST_DECIMAL.test_randoms_dectest] xdiv002
    expected: -0.00655620358
    but  got: -0.00655620357
FAIL:  [MA_TEST_DECIMAL.test_randomsingle_dectest] divx1003
    expected: -3.96127088410624E-779
    but  got: -3.96127088410623E-779
FAIL:  [MA_TEST_DECIMAL.test_rounding_dectest] radx140
    expected: 12345
    but  got: 12344
FAIL:  [MA_TEST_DECIMAL.test_subtract_dectest] subx521
    expected: 123456789
    but  got: 123456788

BUILD FAILED!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There is no such problem when compiling in classic Eiffel
or with Eiffel for .NET 5.6.1218.

I also get this error with Eiffel for .NET 6.0.65740 but not
with Eiffel for .NET 5.6.1218:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Testing xtranscoder...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

Test Summary for xtranscoder

# Passed:     0 test
# FAILED:     2 tests
# Aborted:    0 test
# Total:      2 tests (8 assertions)

Test Results:
FAIL:  [UT_TEST_BASE64_DECODING.test_decoding] decoded
FAIL:  [UT_TEST_BASE64_DECODING.test_encoding_decoding_numerals] 
original_string
_matches_round_trip
    expected: 1
    but  got:

BUILD FAILED!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On the other hand I get this error with Eiffel for .NET 5.6.1218
and not with Eiffel for .NET 6.0.65740:

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

Test Summary for xpath

# Passed:     272 tests
# Failed:     0 test
# ABORTED:    3 tests
# Total:      275 tests (1829 assertions)

Test Results:
ABORT:  [XM_XPATH_TEST_DOC.test_collection_on_data_directory] Eiffel 
exception
ABORT:  [XM_XPATH_TEST_MATCHES.test_matches_four_chinese] Eiffel exception
ABORT:  [XM_XPATH_TEST_MATCHES.test_matches_five_chinese] Eiffel exception

BUILD FAILED!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Finally I get a slightly different error with Eiffel for .NET 6.0.65740:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Test Summary for xslt

# Passed:     77 tests
# FAILED:     6 tests
# Aborted:    0 test
# Total:      83 tests (439 assertions)

Test Results:
FAIL: 
[XM_XSLT_TEST_FOR_EACH_GROUP.test_grouping_nodes_based_on_common_values]
Correct result
    expected: <?xml version="1.0" 
encoding="UTF-8"?><table><tr><th>Position</th><
th>Country</th><th>City 
List</th><th>Population</th></tr><tr><td>1</td><td>Itali
a</td><td>Milano, 
Venezia</td><td>6</td></tr><tr><td>2</td><td>France</td><td>Pa
ris, 
Lyon</td><td>9</td></tr><tr><td>3</td><td>Deutschland</td><td>M%/252/nchen<
/td><td>4</td></tr></table>
    but  got: <?xml version="1.0" 
encoding="UTF-8"?><table><tr><th>Position</th><
th>Country</th><th>City 
List</th><th>Population</th></tr><tr><td>1</td><td>Itali
a</td><td>Milano, 
Venezia</td><td>6</td></tr><tr><td>2</td><td>France</td><td>Pa
ris, 
Lyon</td><td>9</td></tr><tr><td>3</td><td>Deutschland</td><td>Mnnchen</td><
td>4</td></tr></table>
FAIL:  [XM_XSLT_TEST_GOBO2HTML.test_transform2html] Results same as test 
file
FAIL:  [XM_XSLT_TEST_GOBO2HTML.test_transform2xml] Results same as test file
FAIL:  [XM_XSLT_TEST_GOBO2HTML.test_transform2xhtml] Results same as 
test file
FAIL:  [XM_XSLT_TEST_SCHEMATRON.test_schematron_basic] Results same as 
test file

FAIL:  [XM_XSLT_TEST_STRIPPER.test_stripper] Results same as test file

BUILD FAILED!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and with Eiffel for .NET 5.6.1218:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Testing xslt...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

Test Summary for xslt

# Passed:     78 tests
# FAILED:     5 tests
# Aborted:    0 test
# Total:      83 tests (439 assertions)

Test Results:
FAIL:  [XM_XSLT_TEST_GOBO2HTML.test_transform2html] Results same as test 
file
FAIL:  [XM_XSLT_TEST_GOBO2HTML.test_transform2xml] Results same as test file
FAIL:  [XM_XSLT_TEST_GOBO2HTML.test_transform2xhtml] Results same as 
test file
FAIL:  [XM_XSLT_TEST_SCHEMATRON.test_schematron_basic] Results same as 
test file

FAIL:  [XM_XSLT_TEST_STRIPPER.test_stripper] Results same as test file

BUILD FAILED!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

None of the errors above occur when compile with classic Eiffel.
I'm not sure Eiffel for .NET is robust enough yet.

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

Just for the record: I am fully aware that I am using unsupported
classes and do not blame anybody for breakages. That aside frequent
releases of course would help me. I think more than twice a year is
overkill though.

Andreas

Bernd Schoeller wrote:
> No, I do not. My point was: should somebody have the need for a faster 
> update cycle, then they can always switch to SVN. I do not see the need 
> to do this if you are not actively developing on GOBO, as progress is 
> GOBO is slow, and a release once per year might even be enough.

The problem that you raised (Autotest, etc. which do not
compile with the last release of Gobo but only with CVS)
is that these projects use classes that are under development.
It was made clear that these classes can be changed in a
non-compatible manner without notice. Nevertheless these
projects want to take advantage of the new developments
in Gobo. So the situation that triggered the release of
Gobo 3.5 will happen again and again in the future if the
frequency of the releases is not high enough.

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

>From: Eric Bezault <er...@go...>

>Bernd Schoeller wrote:
> > In the end,
> > there is always the possibility to follow the SVN trunk repository.
>
>But you don't want students and other Gobo users to have to do that!

Maybe it would be a good idea to ask on the gobo users list for opinions. We 
may be a rather
atypical sample on this list.

I don't think I EVER compiled against the Gobo 3.4 distribution, so my 
opinion on the best release frequency must be worth very little. All I can 
go on would be how often I want to see a release of eposix, which is 
influenced by the gobo release rate.

_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.  
http://www.msn.txt4content.com/

Bernd Schoeller wrote:
> In the end, 
> there is always the possibility to follow the SVN trunk repository.

But you don't want students and other Gobo users to have to do that!

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

Berend de Boer wrote:
> It's pretty stable. And it is still the compiler I use most often. But
> perhaps gec is more stable now. Once gec works for me I'll probably
> switch to that, but on the other hand 1.2r7 has been a very stable
> release.

I didn't say it was not stable. The problem is that it is not
evolving to provide some functionalities that have been asked
by Gobo developers/users.

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

On Mon, 22 Jan 2007 22:58:46 +0100, Eric Bezault <er...@go...>  
wrote:

> Eric Bezault wrote:
>> The CVS repository is currently frozen to allow the
>> release of Gobo 3.5. Following is what I suggest
>> about what should happen after the release.
>
> Also, what would be a good frequency for Gobo releases.
> I guess that everybody thinks that 2 years is too long.
> Should it be a release every quarter? Every 2 months?
> Every ...?

I am for a release twice a year, which is already fast enough. Two other  
major project that I follow, OpenBSD and Ubuntu, release also twice a  
year, and I have enough trouble following updates there. In the end, there  
is always the possibility to follow the SVN trunk repository.

Bernd

2001	Jan	Feb	Mar	Apr	May (80)	Jun (71)	Jul (34)	Aug (58)	Sep	Oct (220)	Nov (146)	Dec (36)
2002	Jan (28)	Feb (152)	Mar (293)	Apr (213)	May (158)	Jun (96)	Jul (78)	Aug (39)	Sep (169)	Oct (128)	Nov (83)	Dec (149)
2003	Jan (155)	Feb (14)	Mar (60)	Apr (86)	May (92)	Jun (109)	Jul (25)	Aug (44)	Sep (10)	Oct (39)	Nov (37)	Dec (128)
2004	Jan (71)	Feb (199)	Mar (192)	Apr (360)	May (93)	Jun (75)	Jul (51)	Aug (195)	Sep (390)	Oct (186)	Nov (173)	Dec (331)
2005	Jan (102)	Feb (154)	Mar (160)	Apr (88)	May (79)	Jun (78)	Jul (126)	Aug (94)	Sep (110)	Oct (187)	Nov (188)	Dec (31)
2006	Jan (12)	Feb (40)	Mar (123)	Apr (102)	May (62)	Jun (36)	Jul (19)	Aug (31)	Sep (59)	Oct (67)	Nov (57)	Dec (35)
2007	Jan (153)	Feb (53)	Mar (27)	Apr (11)	May (49)	Jun (3)	Jul (56)	Aug (58)	Sep (30)	Oct (57)	Nov (47)	Dec (155)
2008	Jan (71)	Feb (68)	Mar (79)	Apr (72)	May (82)	Jun (10)	Jul (19)	Aug (25)	Sep (17)	Oct (10)	Nov (32)	Dec (9)
2009	Jan (26)	Feb (1)	Mar (1)	Apr (12)	May (16)	Jun (7)	Jul (12)	Aug (22)	Sep (21)	Oct	Nov (7)	Dec
2010	Jan (3)	Feb (3)	Mar (1)	Apr	May (5)	Jun (5)	Jul	Aug	Sep (4)	Oct (2)	Nov	Dec (6)
2011	Jan (3)	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep (8)	Oct	Nov	Dec
2012	Jan	Feb	Mar	Apr	May (8)	Jun	Jul (3)	Aug	Sep	Oct	Nov	Dec
2013	Jan	Feb (11)	Mar (1)	Apr (4)	May	Jun	Jul (2)	Aug (2)	Sep	Oct	Nov	Dec
2014	Jan (5)	Feb	Mar	Apr (3)	May	Jun	Jul	Aug	Sep	Oct (3)	Nov (2)	Dec (1)
2015	Jan (2)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (6)
2016	Jan (8)	Feb	Mar	Apr	May (3)	Jun	Jul	Aug	Sep	Oct	Nov (3)	Dec
2017	Jan (3)	Feb	Mar	Apr (1)	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec (1)
2018	Jan (1)	Feb	Mar (4)	Apr	May	Jun	Jul	Aug	Sep	Oct (4)	Nov	Dec
2021	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (2)
2022	Jan (3)	Feb	Mar	Apr	May	Jun	Jul	Aug (2)	Sep	Oct	Nov	Dec
2023	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

gobo-eiffel-develop Mailing List for Gobo Eiffel Project (Page 54)

gobo-eiffel-develop — Development discussions