gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Change in export status to exceptions?

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Colin Paul Adams wrote:
>     >> After updaing Gobo today, I can no longer compile gestalt. I
>     >> get:
>     >> 
>     >> 
>     >> Class: EPX_FTP_URI_RESOLVER Feature: retrieve_file Feature:
>     >> exception Class: KL_EXCEPTIONS Version from: EXCEPTIONS Not
>     >> exported to class EPX_FTP_URI_RESOLVER Line: 321 else
>     -> set_local_error ("An attempt to retrieve a file by ftp resulted
>     -> in exception code " + Exceptions.exception.out)
>     >> end
> 
>     Eric> It should be fixed now.
> 
> I'm afraid not.
> 
> I got an update for KI_EXCEPTIONS, but I still get the same error. (I
> did a goat install).

I don't understand, `exception' should now be exported.

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

Re: [gobo-eiffel-develop] Change in export status to exceptions?

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

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

    Eric> Colin Paul Adams wrote:
    >> After updaing Gobo today, I can no longer compile gestalt. I
    >> get:
    >> 
    >> 
    >> Class: EPX_FTP_URI_RESOLVER Feature: retrieve_file Feature:
    >> exception Class: KL_EXCEPTIONS Version from: EXCEPTIONS Not
    >> exported to class EPX_FTP_URI_RESOLVER Line: 321 else
    -> set_local_error ("An attempt to retrieve a file by ftp resulted
    -> in exception code " + Exceptions.exception.out)
    >> end

    Eric> It should be fixed now.

I'm afraid not.

I got an update for KI_EXCEPTIONS, but I still get the same error. (I
did a goat install).
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Change in export status to exceptions?

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

Colin Paul Adams wrote:
> After updaing Gobo today, I can no longer compile gestalt. I get:
> 
> 
> Class: EPX_FTP_URI_RESOLVER
> Feature: retrieve_file
> Feature: exception Class: KL_EXCEPTIONS Version from: EXCEPTIONS
> Not exported to class EPX_FTP_URI_RESOLVER
> Line: 321
>         else
> ->        set_local_error ("An attempt to retrieve a file by ftp resulted in exception code " + Exceptions.exception.out)
>         end

It should be fixed now.

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

Re: [gobo-eiffel-develop] Bug in parsing decimals?

[CRISMER Paul-G. <Pau...@gr...>]

Just a typo...
Sorry for that.

Paul G. Crismer

-----Original Message-----
From: gob...@li... [mailto:gob...@li...] On Behalf Of Colin Paul Adams
Sent: vendredi 15 février 2008 13:25
To: gob...@li...
Subject: [gobo-eiffel-develop] Bug in parsing decimals?

I found a bug in Gexslt, which was due to not enough digits in an MA_DECIMAL.

So I changed from using {MA_DECIMAL_TEXT_PARSER}.parse to {MA_DECIMAL_TEXT_PARSER}.parse_ctx, supplying a context created using:

create l_ctx.make (a_priority_attribute.count, round_half_up)

(a_priority_attribute) is the string I want to parse as a decimal, so this sounds like a safe way of not losing any information from the string.

However, I still get the same bug. When i started to debug, I find that

{MA_DECIMAL_TEXT_PARSER}.parse_ctx

is ignoring the passed context and just using the shared decimal context.

I'm assuming that was just a copy-and-paste error?
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
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

***** Disclaimer *****
http://www.groupes.be/1_mail-disclaimer.htm

Re: [gobo-eiffel-develop] Bug in parsing decimals?

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

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

    Colin> I found a bug in Gexslt, which was due to not enough digits
    Colin> in an MA_DECIMAL.

    Colin> So I changed from using {MA_DECIMAL_TEXT_PARSER}.parse to
    Colin> {MA_DECIMAL_TEXT_PARSER}.parse_ctx, supplying a context
    Colin> created using:

    Colin> create l_ctx.make (a_priority_attribute.count,
    Colin> round_half_up)

    Colin> (a_priority_attribute) is the string I want to parse as a
    Colin> decimal, so this sounds like a safe way of not losing any
    Colin> information from the string.

    Colin> However, I still get the same bug. When i started to debug,
    Colin> I find that

    Colin> {MA_DECIMAL_TEXT_PARSER}.parse_ctx

    Colin> is ignoring the passed context and just using the shared
    Colin> decimal context.

    Colin> I'm assuming that was just a copy-and-paste error?


I changed it so that it now reads:

	parse_ctx (s: STRING; ctx: MA_DECIMAL_CONTEXT; parse_comma_as_decimal_point: BOOLEAN) is
			-- Parse `s' using `ctx' wrt `parse_comma_as_decimal_point'.
		require
			s_not_void: s /= Void
			s_not_empty: not s.is_empty
		local
			old_allowed: BOOLEAN
		do
			old_allowed := is_comma_allowed
			is_comma_allowed := parse_comma_as_decimal_point
			parse_and_create_last_decimal (s, ctx)
			is_comma_allowed := old_allowed
		ensure
			no_mode_change: is_comma_allowed = old is_comma_allowed
			last_parsed_string_affected: last_parsed = s
			last_decimal_not_void_when_no_error: not error implies last_decimal /= Void
		end

and that fixes my bug in gexslt.

May I commit this change?
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] Bug in parsing decimals?

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

I found a bug in Gexslt, which was due to not enough digits in an
MA_DECIMAL.

So I changed from using {MA_DECIMAL_TEXT_PARSER}.parse to
{MA_DECIMAL_TEXT_PARSER}.parse_ctx, supplying a context created using:

create l_ctx.make (a_priority_attribute.count, round_half_up)

(a_priority_attribute) is the string I want to parse as a decimal, so
this sounds like a safe way of not losing any information from the
string.

However, I still get the same bug. When i started to debug, I find
that

{MA_DECIMAL_TEXT_PARSER}.parse_ctx

is ignoring the passed context and just using the shared decimal
context.

I'm assuming that was just a copy-and-paste error?
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] Change in export status to exceptions?

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

After updaing Gobo today, I can no longer compile gestalt. I get:


Class: EPX_FTP_URI_RESOLVER
Feature: retrieve_file
Feature: exception Class: KL_EXCEPTIONS Version from: EXCEPTIONS
Not exported to class EPX_FTP_URI_RESOLVER
Line: 321
        else
->        set_local_error ("An attempt to retrieve a file by ftp resulted in exception code " + Exceptions.exception.out)
        end

-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] geant: notion of local variables

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

Jocelyn wrote:
>  > So far we didn't use branches in Gobo. Personally I think that
>  > the best way to experiment with your changes and to find out
>  > whether they break something or not it to commit them in the
>  > trunk.
> 
> Ok, in this case, a big commit is about to come.

When committing new functionalities, you have to make sure to
update the file $GOBO/History.txt as well. Thanks.

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

[gobo-eiffel-develop] wiki page: geant

[Jocelyn <li...@dj...>]

I added the following wiki page on sourceforge:
    http://gobo-eiffel.wiki.sourceforge.net/Tool_Geant

Almost empty for now, but we could drop some idea on it to improve 
collaboration on geant's source code.

-- Jocelyn

Re: [gobo-eiffel-develop] geant: make builtin variables readonly

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

Sven Ehrke wrote:
> one thing I have on my list is to make builtin variables readonly
> (maybe issuing a warning only in a first phase).
> 
> I started to implement this and then noticed that in misc/eiffel.eant
> the variable 'exe' is set:
> 
>     <target name="init_windows" if="${GOBO_OS}=windows">
>         <set name="exe" value=".exe"/>
>     </target>
> 
>     <target name="init_unix" unless="${GOBO_OS}=windows">
>         <set name="exe" value=""/>
>     </target>
> 
> I think this is from the time when the builtin variable 'exe' did not
> exist yet and now could be removed (it is initialized in `{GEANT_SHARED_PROPERTIES}.Default_builtin_variables':
> 
>   ...
>   Result.set_variable_value ("exe", file_system.exe_extension)
>   ...
> 
> Or do you see a reason to keep these two <set>s ?

No, I guess we can remove them.

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

Re: [gobo-eiffel-develop] geant: notion of local variables

[Sven E. <sve...@we...>]

Jocelyn wrote:
> You are right, there are now added and committed.
> 
> Sorry for the inconvenience,
> Jocelyn
> ps: let me know if this is ok now ...

Yes. Compiles fine now. Thanks.

- Sven

Re: [gobo-eiffel-develop] geant: notion of local variables

[Jocelyn <li...@dj...>]

You are right, there are now added and committed.

Sorry for the inconvenience,
Jocelyn
ps: let me know if this is ok now ...

On 2/11/2008 19:16 PM, Sven Ehrke wrote:
> Jocelyn wrote:
>   
>> Ok, in this case, a big commit is about to come.
>>     
>
> It seems to me that you forgot to add GEANT_LOCAL_ELEMENT and GEANT_GLOBAL_ELEMENT
> to svn.
>
> - Sven
>
>
>
> -------------------------------------------------------------------------
> 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] geant: make builtin variables readonly

[Sven E. <sve...@we...>]

Eric,

one thing I have on my list is to make builtin variables readonly
(maybe issuing a warning only in a first phase).

I started to implement this and then noticed that in misc/eiffel.eant
the variable 'exe' is set:

    <target name="init_windows" if="${GOBO_OS}=windows">
        <set name="exe" value=".exe"/>
    </target>

    <target name="init_unix" unless="${GOBO_OS}=windows">
        <set name="exe" value=""/>
    </target>

I think this is from the time when the builtin variable 'exe' did not
exist yet and now could be removed (it is initialized in `{GEANT_SHARED_PROPERTIES}.Default_builtin_variables':

  ...
  Result.set_variable_value ("exe", file_system.exe_extension)
  ...

Or do you see a reason to keep these two <set>s ?
We could keep the two targets in case we need to do other platform specific initializations in the future.

- Sven

Re: [gobo-eiffel-develop] geant: notion of local variables

[Sven E. <sve...@we...>]

Jocelyn wrote:
> Ok, in this case, a big commit is about to come.

It seems to me that you forgot to add GEANT_LOCAL_ELEMENT and GEANT_GLOBAL_ELEMENT
to svn.

- Sven

Re: [gobo-eiffel-develop] geant: notion of local variables

[Sven E. <sve...@we...>]

Jocelyn wrote:
> I first did that, adding a field  {GEANT_TARGET}.locals: GEANT_VARIABLES
> but this doesn't work, since GEANT_TARGET holds static data, when we 
> need execution data.
> 
> I mean, if you call recursively the same target, then you'll have the 
> locals messed up, since you share the same list of locals for the 2 
> executions of the same target.
> Do you see what I mean ?

Right. Now I remember that I had the same issue when I implemented argument support.
Somehow I had the feeling that a new target object is created when <geant> calls
a target which is not the case and this causes the problem.

> In fact, what would be nicer is to have a GEANT_TARGET_STACK .. which 
> would hold the arguments, and locals stacks.

I agree.

- Sven

Re: [gobo-eiffel-develop] geant: notion of local variables

[Sven E. <sve...@we...>]

Eric Bezault wrote:
> Sven Ehrke wrote:
>> I know it is a bit late now (just saw your commit) but I have mixed feelings about <group>.
>> What is again the advantage over calling another target?
> 
> One advantage I could see is with local variables. With
> another target we would have to pass them as arguments,

Right. Especially when there are many which need to be accessed this would be annoying.

> and they would be read-only I guess.

Good point. I obviously did not think enough about this one. This means that the idea
of slowly going away from globals to locals will not work since we cannot return values.

So I make another suggestion which I had in mind since a long time. So far I thought it is
overkill for geant but just to mention the idea:
We could extend the OO view of geant scripts (similar to a Eiffel class) by
providing the possibility to add attributes to a script so that it becomes stateful.
This way targets (like features in Eiffel) could modify the values of these attributes.
It would be necessary to able to create new "objects" of these "scripts" and pass them as
arguments for example. This way we could get rid of the globals. But it is certainly some
effort involved to implement this.

- Sven

Re: [gobo-eiffel-develop] geant: notion of local variables

[Jocelyn <li...@dj...>]

I first did that, adding a field  {GEANT_TARGET}.locals: GEANT_VARIABLES
but this doesn't work, since GEANT_TARGET holds static data, when we 
need execution data.

I mean, if you call recursively the same target, then you'll have the 
locals messed up, since you share the same list of locals for the 2 
executions of the same target.
Do you see what I mean ?
for instance

    <target name="loc">
       <argument name="arg" />
       <local name="foo" />
       <set name="foo" value="$arg$arg" />
       <echo message="1) foo=$foo" />      
       <geant name="loc" arguments="$foo" unless="$arg=aaaa"
       <echo message="2) foo=$foo" />      
    </target>

doing the solution with locals attached to the instance of GEANT_TARGET, 
you would get as output for:
<geant target="loc" arguments="a" />
1) foo=aa
1) foo=aaaa
2) foo=aaaa
2) foo=aaaa

when you expect
1) foo=aa
1) foo=aaaa
2) foo=aaaa
2) foo=aa

In fact, what would be nicer is to have a GEANT_TARGET_STACK .. which 
would hold the arguments, and locals stacks.

-- Jocelyn.


On 2/11/2008 18:11 PM, Sven Ehrke wrote:
> Jocelyn wrote:
>   
>> I would say avoid to have zillions of fake targets
>>     
>
> OK, I understand now. Thanks for the explanation.
>
>   
>> I hope my commit is still welcome.
>>     
>
> Yes, very welcome. I am just checking out the diff. I am not
> finished yet but one thing which I thought could be done
> is to attach the local variables directly to it's target instead
> of having to maintain two stacks (one for the targets and the other
> one for the locals). Then only the target stack would be needed.
> What do you think?
>
> - Sven
>
>
>
>
> -------------------------------------------------------------------------
> 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
>
>
>   

Re: [gobo-eiffel-develop] geant: notion of local variables

[Sven E. <sve...@we...>]

Jocelyn wrote:
> I would say avoid to have zillions of fake targets

OK, I understand now. Thanks for the explanation.

> I hope my commit is still welcome.

Yes, very welcome. I am just checking out the diff. I am not
finished yet but one thing which I thought could be done
is to attach the local variables directly to it's target instead
of having to maintain two stacks (one for the targets and the other
one for the locals). Then only the target stack would be needed.
What do you think?

- Sven

Re: [gobo-eiffel-develop] geant: notion of local variables

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

Sven Ehrke wrote:
> I know it is a bit late now (just saw your commit) but I have mixed feelings about <group>.
> What is again the advantage over calling another target?

One advantage I could see is with local variables. With
another target we would have to pass them as arguments,
and they would be read-only I guess.

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

Re: [gobo-eiffel-develop] geant: notion of local variables

[Sven E. <sve...@we...>]

I know it is a bit late now (just saw your commit) but I have mixed feelings about <group>.
What is again the advantage over calling another target?


Jocelyn wrote:
>> So far we didn't use branches in Gobo. Personally I think that
>> the best way to experiment with your changes and to find out
>> whether they break something or not it to commit them in the > trunk.
> 
> Ok, in this case, a big commit is about to come.
> It includes    - internal changes to create TASK faster (no more huge if
> elseif elseif ...on string comparison)
>    - <local  /> to declare a variable as local
>       for instance:   <local name="foo" />  or even by providing a value
> right away <local name="foo" value="bar" />
> 
>    - <global /> to declare a variable as global (this is currently the
> default behavior)
>       for instance:   <global name="foo" />  or even by providing aEric Bezault <er...@go...>
> value right away <global name="foo" value="bar" />
> 
>    - <group /> to group set of tasks
>        for instance:
>          <target name="test" >
>                <available resource="$file" variable="file_available" />
>                <group if="$file_available=true">
>                         <echo message="..." />
>                         <copy file="$file" to_file="${file}.bak" />
>                         <exec executable="echo > $file" />
>                </group>
>          </target>
>       You can use the if="..", unless=".." and even dir=".."  attribute
> on <group />
> 
>       You can also have nested groups, and so on ...
> 
>          <target name="test" >
>                <argument name="backup_dir" />
>                <argument name="file" />
>                <global variable="backup_enabled" /><!-- not necessary
> for now -->
>                <local variable="file_available" />
> 
>                <available resource="$file" variable="file_available" />
>                <group if="$file_available=true">
>                         <group if="$backup_enabled=true" dir="$backup_dir">
>                             <description>Backup file in $backup_dir
> folder.</description>
>                             <echo message="backup $file" />
>                             <copy file="$file" to_file="${file}.bak" />
>                             <echo message="Copied $file to ${file}.bak" />
>                         </group>
>                         <exec executable="echo new content > $file" />
>                </group>
>                <!-- no need to unset `file_available' since it is a
> local -->
>          </target>
> 
> 
> And this will make geant' scripts cleaner (I hope)
> I started the work, to have "locals" as default instead of "globals",
> but not yet complete.
> 
> Any feedback, comment, bug report will be welcome.
> -- Jocelyn
> 
> 
>  
> 

Re: [gobo-eiffel-develop] geant: notion of local variables

[Jocelyn <ei...@dj...>]

 > So far we didn't use branches in Gobo. Personally I think that
 > the best way to experiment with your changes and to find out
 > whether they break something or not it to commit them in the 
 > trunk.

Ok, in this case, a big commit is about to come.
It includes 
    - internal changes to create TASK faster (no more huge if elseif 
elseif ...on string comparison)
    - <local  /> to declare a variable as local
       for instance:   <local name="foo" />  or even by providing a 
value right away <local name="foo" value="bar" />

    - <global /> to declare a variable as global (this is currently the 
default behavior)
       for instance:   <global name="foo" />  or even by providing a 
value right away <global name="foo" value="bar" />

    - <group /> to group set of tasks
        for instance:
          <target name="test" >
                <available resource="$file" variable="file_available" />
                <group if="$file_available=true">
                         <echo message="..." />
                         <copy file="$file" to_file="${file}.bak" />
                         <exec executable="echo > $file" />
                </group>
          </target>
       You can use the if="..", unless=".." and even dir=".."  attribute 
on <group />

       You can also have nested groups, and so on ...

          <target name="test" >
                <argument name="backup_dir" />
                <argument name="file" />
                <global variable="backup_enabled" /><!-- not necessary 
for now -->
                <local variable="file_available" />

                <available resource="$file" variable="file_available" />
                <group if="$file_available=true">
                         <group if="$backup_enabled=true" dir="$backup_dir">
                             <description>Backup file in $backup_dir 
folder.</description>
                             <echo message="backup $file" />
                             <copy file="$file" to_file="${file}.bak" />
                             <echo message="Copied $file to ${file}.bak" />
                         </group>
                         <exec executable="echo new content > $file" />
                </group>
                <!-- no need to unset `file_available' since it is a 
local -->
          </target>


And this will make geant' scripts cleaner (I hope)
I started the work, to have "locals" as default instead of "globals", 
but not yet complete.

Any feedback, comment, bug report will be welcome.
-- Jocelyn


   

Re: [gobo-eiffel-develop] geant task 'geant' can now handle execution result

[Sven E. <sve...@we...>]

Jocelyn wrote:

> I was wondering, what about the
>    accept_errors="true|false"
> It seems to be required when used with nested fileset, I think task
> geant can be used with nested fileset too
> however I don't really see the point of having "exit_code_variable" and
> "accept_errors"
> Can't we just have "exit_code_variable"  ?

Yes, 'exit_code_variable' should be sufficient and that is the reason
why I did not implement 'accept_errors' (it is obsolete in <exec> for exactly
that reason).
When nested filesets are used it gets more difficult. When you
look into the documentation of the <exec> task it says for 'exit_code_variable':

  ...this attribute can only be used when no fileset is used as nested argument

and for 'accept_errors'

  ...Use this attribute only if a nested fileset is specified...

'accept_erros' can work with filesets since one cannot query the
exit code anyway so non-zero exit codes will simply be ignored and the loop
will be continued.

With 'exit_code_variable' it is more complicated though:
should the first non-zero exit code iteration abort the loop or continue?
I don't know and that is the reason this attribute is not supported when
nested filesets are used. But maybe someone has a good idea on what to do
in this situation?
One possibility I can think of is supporting 'exit_code_variable' also for
filesets and setting it to the last (or first?) non-zero result of an iteration
(and if no iteration fails it would be set to zero of course).

- Sven


> 
> What about tasks  copy, move, delete, mkdir, .. ?
> I think we can always encapsulate such calls in "target", this was we
> use the exit_code_variable as a kind of "rescue"
> 
> -- Jocelyn
> 
> On 2/10/2008 22:01 PM, Sven Ehrke wrote:
>> As requested the task 'geant' now is able to handle (or ignore) the
>> execution result by specifying the attribute 'exit_code_variable' (as
>> it is done in task 'exec').
>>
>> To ignore the result (e.g. for running several unittests) use it like
>> this for example:
>>
>>   ...
>>   <geant file="build.eant" target="${target}" dir="argument"
>> exit_code_variable="dummy"/>
>>   ...
>>
>> Having introduced an artificial bug in one of the tests for the
>> argument library to test
>> the new behavior the output looks as follows:
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ...
>>
>> # PASSED:     531 tests
>> # Failed:     0 test
>> # Aborted:    0 test
>> # Total:      531 tests (1836 assertions)
>>
>> Testing xargument...
>> Preparing Test Cases
>> Compiling Test Cases
>> Running Test Cases
>>
>> Test Summary for xargument
>>
>> # Passed:     12 tests
>> # FAILED:     1 test
>> # Aborted:    0 test
>> # Total:      13 tests (74 assertions)
>>
>> Test Results:
>> FAIL:  [AP_TEST_PARSER.test_make] has_no_options_in_basic
>>    expected: 9
>>    but  got: 0
>>
>> BUILD FAILED!
>>
>> Testing xlexical...
>> Preparing Test Cases
>> Compiling Test Cases
>> Running Test Cases
>>
>> ...
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> As you can see there still is a BUILD FAILED message but the script
>> continues it's
>> execution.
>>
>> - Sven
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>>   
> 
> 
> 

Re: [gobo-eiffel-develop] geant task 'geant' can now handle execution result

[Jocelyn <li...@dj...>]

Hi,

This addition will be appreciated :)

I was wondering, what about the
    accept_errors="true|false" 

It seems to be required when used with nested fileset, I think task 
geant can be used with nested fileset too
however I don't really see the point of having "exit_code_variable" and 
"accept_errors"
Can't we just have "exit_code_variable"  ?

What about tasks  copy, move, delete, mkdir, .. ?
I think we can always encapsulate such calls in "target", this was we 
use the exit_code_variable as a kind of "rescue"

-- Jocelyn

On 2/10/2008 22:01 PM, Sven Ehrke wrote:
> As requested the task 'geant' now is able to handle (or ignore) the
> execution result by specifying the attribute 'exit_code_variable' (as it is done in task 'exec').
>
> To ignore the result (e.g. for running several unittests) use it like this for example:
>
>   ...
>   <geant file="build.eant" target="${target}" dir="argument" exit_code_variable="dummy"/>
>   ...
>
> Having introduced an artificial bug in one of the tests for the argument library to test
> the new behavior the output looks as follows:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...
>
> # PASSED:     531 tests
> # Failed:     0 test
> # Aborted:    0 test
> # Total:      531 tests (1836 assertions)
>
> Testing xargument...
> Preparing Test Cases
> Compiling Test Cases
> Running Test Cases
>
> Test Summary for xargument
>
> # Passed:     12 tests
> # FAILED:     1 test
> # Aborted:    0 test
> # Total:      13 tests (74 assertions)
>
> Test Results:
> FAIL:  [AP_TEST_PARSER.test_make] has_no_options_in_basic
>    expected: 9
>    but  got: 0
>
> BUILD FAILED!
>
> Testing xlexical...
> Preparing Test Cases
> Compiling Test Cases
> Running Test Cases
>
> ...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> As you can see there still is a BUILD FAILED message but the script continues it's
> execution.
>
> - Sven
>
>
> -------------------------------------------------------------------------
> 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
>
>
>   

Re: [gobo-eiffel-develop] MA_DECIMAL_CONSTANTS.zero

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

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

    Eric> It does not make sense to me. In your implementation you have
    Eric> a recursive call to the once function to define it.

    Eric> I think that what Berend meant was something like:

	zero: MA_DECIMAL is
			-- Neutral element for "+" and "-"
		once
			create Result.make_zero
		ensure
			zero_not_void: Result /= Void
		end

    Eric> As far as I can tell we don't create a million objects and the
    Eric> implementation of `zero' is not recursive anymore.

Exactly.

-- 
Cheers,

Berend de Boer

[gobo-eiffel-develop] geant task 'geant' can now handle execution result

[Sven E. <sve...@we...>]

As requested the task 'geant' now is able to handle (or ignore) the
execution result by specifying the attribute 'exit_code_variable' (as it is done in task 'exec').

To ignore the result (e.g. for running several unittests) use it like this for example:

  ...
  <geant file="build.eant" target="${target}" dir="argument" exit_code_variable="dummy"/>
  ...

Having introduced an artificial bug in one of the tests for the argument library to test
the new behavior the output looks as follows:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

# PASSED:     531 tests
# Failed:     0 test
# Aborted:    0 test
# Total:      531 tests (1836 assertions)

Testing xargument...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

Test Summary for xargument

# Passed:     12 tests
# FAILED:     1 test
# Aborted:    0 test
# Total:      13 tests (74 assertions)

Test Results:
FAIL:  [AP_TEST_PARSER.test_make] has_no_options_in_basic
   expected: 9
   but  got: 0

BUILD FAILED!

Testing xlexical...
Preparing Test Cases
Compiling Test Cases
Running Test Cases

...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As you can see there still is a BUILD FAILED message but the script continues it's
execution.

- Sven