gobo-eiffel-develop — Development discussions

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

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

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

    Eric> The Gobo compiler does not take the Xace 'garbage_collector'
    Eric> option yet into account. What you have to do to use the
    Eric> Boehm GC is to use the gec command-line option --gc=boehm
    Eric> (and make sure that the environment variable $BOEHM_GC
    Eric> points to where it is installed.

Do I have to download the boehm gc separately then, or is it in the
Gobo distribution?
-- 
Colin Adams
Preston Lancashire

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

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

Colin Paul Adams wrote:
> What do you specify in the xace file when compiling with gec to have
> your application use the boehm garbage collector?
> 
> I have:
> 
> <option name="garbage_collector" value="internal"/>
> 
> for both gexslt and gestalt - that's for use with SE. Yet it seems to
> work with gec, although 
> 
> <option name="garbage_collector" value="boehm"/>
> 
> would seem more logical. I'm guessing both mean the same thing.

The Gobo compiler does not take the Xace 'garbage_collector' option
yet into account. What you have to do to use the Boehm GC is to use
the gec command-line option --gc=boehm (and make sure that the
environment variable $BOEHM_GC points to where it is installed.
This works fine under Windows when using msc. See the config file
$GOBO/tool/gec/config/msc.cfg. I didn't specify the proper config
options in the file $GOBO/tool/gec/config/gcc.cfg yet, but it should
be easy to do just by looking at what is done in the msc.cfg file.
I will try to make gec aware of the Xace 'garbage_collector' option
(in addition to the command-line option) in the near future.

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

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

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

What do you specify in the xace file when compiling with gec to have
your application use the boehm garbage collector?

I have:

<option name="garbage_collector" value="internal"/>

for both gexslt and gestalt - that's for use with SE. Yet it seems to
work with gec, although 

<option name="garbage_collector" value="boehm"/>

would seem more logical. I'm guessing both mean the same thing.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] UNIX_FILE_INFO

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

Colin Paul Adams wrote:
> No news and no reply from Daniel.
> 
> I think we have to assume that SE 1.2 won't be moving in the necessary
> direction.
> 
> So I will use UNIX_FILE_INFO for now. (We can always back-track later
> - I will only be using it in one class for now).
> 
> So, starting with a file name, I could simply call {FILE}.make and
> then file_info. Or do ypu want to add the facility into KI_FILE?

No, go ahead.

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

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

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

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

Colin Paul Adams wrote:
>     Eric> OK. Just to double-check, can you try to remove the "b"s anyway
>     Eric> in function 'file_open_mode' in
>     Eric> $GOBO/tool/gec/runtime/c/eif_file.c and recompile your
>     Eric> program (no need to recompile gec itself)?  Perhaps the
>     Eric> "compatibility" goes up to the point where filenames are
>     Eric> considered case-insensitive. Who knows.
> 
> To my surprise, it does the trick.
> Shall I check it in? 
> If the answer is yes, which tests do I need to run?

I'll check it in because I'm also currently modifying this file to
raise exceptions like ISE does.

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

Re: [gobo-eiffel-develop] [smarteiffel] Re: UNIX_FILE_INFO

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

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

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

    Eric> Colin Paul Adams wrote:
    >>> Is there a way to get the information provided from this class
    >>> within Gobo? I want to be able to use the functionality in the
    >>> XPath library.
    >>> 
    >>> Initial searching suggests the answer is no.
    >>> 
    >>> But SE has FILE_INFORMATION - I should think it will be easy
    >>> to add a class in Gobo unifying the two.  I can do this if it
    >>> is needed.

    Eric> Perhaps we should decide first what to do with SE.  I
    Eric> suggest that we wait until the end of the month to see if
    Eric> Daniel resumes his work on SE 1.2 or not.  Or we could ask
    Eric> him now what his current plans are.

No news and no reply from Daniel.

I think we have to assume that SE 1.2 won't be moving in the necessary
direction.

So I will use UNIX_FILE_INFO for now. (We can always back-track later
- I will only be using it in one class for now).

So, starting with a file name, I could simply call {FILE}.make and
then file_info. Or do ypu want to add the facility into KI_FILE?
-- 
Colin Adams
Preston Lancashire

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

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

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

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    >> 
    >> 
    Eric> I can see one difference between ISE and Gobo when opening
    Eric> the file under Linux/Unix. When opening a binary file, Gobo
    Eric> does "rb" (same as Windows) whereas ISE does "r" for the
    Eric> mode. I guess this is the problem. I will fix that and we
    Eric> will see how it goes. In the meantime I'd be interested if
    Eric> you could have a look at the manpage for fopen() on Linux
    Eric> and see if there is anything specified for "rb" (like "open
    Eric> the file in case-insensitive mode" ;-)).
    >> 
    >> It says:
    >> 
    >> " The mode string can also include the letter b either as a
    >> last character or as a character between the characters in any
    >> of the two- character strings described above.  This is
    >> strictly for compatibility with C89 and has no effect; the b is
    >> ignored on all POSIX conform- ing systems, including Linux.
    >> (Other systems may treat text files and binary files
    >> differently, and adding the b may be a good idea if you do I/O
    >> to a binary file and expect that your program may be ported to
    >> non-Unix environments.)  "
    >> 


    Eric> OK. Just to double-check, can you try to remove the "b"s anyway
    Eric> in function 'file_open_mode' in
    Eric> $GOBO/tool/gec/runtime/c/eif_file.c and recompile your
    Eric> program (no need to recompile gec itself)?  Perhaps the
    Eric> "compatibility" goes up to the point where filenames are
    Eric> considered case-insensitive. Who knows.

To my surprise, it does the trick.
Shall I check it in? 
If the answer is yes, which tests do I need to run?
-- 
Colin Adams
Preston Lancashire

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

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

Ber...@in... wrote:
> Sure. I forgot the smiley.

I still think that it would give a great competitive advantage to Origo.

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

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

[<Ber...@in...>]

Sure. I forgot the smiley.

-- BM

> Of course that's not what I meant.

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

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

Ber...@in... wrote:
>> However I'm not sure they have enough resources and skills in
> 
> Right. Not only are we next to destitute, we're kind of dumb as well.

Of course that's not what I meant. If SourceForge stopped providing
this offer, it's because it took them much effort to maintain these
system up and running, with constant system administration knowledge
on many different operating systems to keep these machines uptodate.
If Origo can provide such service to the open source community, then
that would be great. When this offer will be available, I will probably
be the first one to use it. Note that in the sentence above I used
"When" and not "If", because from what I understand from your answer,
this should happen in the near future. So I cannot wait any longer.

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

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

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
> 
>     Eric> I can see one difference between ISE and Gobo when opening
>     Eric> the file under Linux/Unix. When opening a binary file, Gobo
>     Eric> does "rb" (same as Windows) whereas ISE does "r" for the
>     Eric> mode. I guess this is the problem. I will fix that and we
>     Eric> will see how it goes. In the meantime I'd be interested if
>     Eric> you could have a look at the manpage for fopen() on Linux
>     Eric> and see if there is anything specified for "rb" (like "open
>     Eric> the file in case-insensitive mode" ;-)).
> 
> It says:
> 
> "       The  mode  string  can  also  include the letter b either as a last
>        character or as a character between the characters in any of  the  two-
>        character  strings described above.  This is strictly for compatibility
>        with C89 and has no effect; the b is ignored on all POSIX  conform-
>        ing  systems, including Linux.  (Other systems may treat text files and
>        binary files differently, and adding the b may be a  good  idea  if
>        you  do I/O to a binary file and expect that your program may be ported
>        to non-Unix environments.)
> "
> 

OK. Just to double-check, can you try to remove the "b"s anyway
in function 'file_open_mode' in $GOBO/tool/gec/runtime/c/eif_file.c
and recompile your program (no need to recompile gec itself)?
Perhaps the "compatibility" goes up to the point where filenames
are considered case-insensitive. Who knows.

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

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

[<Ber...@in...>]

> However I'm not sure they have enough resources and skills in

Right. Not only are we next to destitute, we're kind of dumb as well.

-- BM

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

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> I have no idea why it manages to open the
>     Eric> file. And I can't try it on a small example since I don't
>     Eric> have access to a Linux or other case-sensitive operating
>     Eric> system. It's too bad that SourceForge does not offer its
>     Eric> compile-farm anymore.
> 
> It doesn't? That's a blow. I was hoping to use it to create MacOSX
> executables.

http://en.wikipedia.org/wiki/Compile_farm
https://sourceforge.net/forum/forum.php?forum_id=665363|

If you find another compile farm as good as SourceForge was,
I'm interested to know.

If Orgigo really wants to have a competitive advantage over other
hosts, I think that it would be a great addition to their offer.
However I'm not sure they have enough resources and skills in
so many different operating systems.

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

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

[Emmanuel S. [ES] <ma...@ei...>]

use strace on linux to see the system calls.

Manu 

> -----Original Message-----
> From: gob...@li... 
> [mailto:gob...@li...] On 
> Behalf Of Eric Bezault
> Sent: Saturday, December 08, 2007 6:42 AM
> To: Colin Paul Adams
> Cc: gob...@li...
> Subject: Re: [gobo-eiffel-develop] Perverse bug with gec?
> 
> Eric Bezault wrote:
> > Colin Paul Adams wrote:
> >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> >>
> >>     Eric> If you were using files the Gobo way, you would 
> get "False"
> >>     Eric> with the following code:
> >>
> >>     Eric>   local l_file: KL_TEXT_INPUT_FILE do create l_file.make
> >>     Eric> ("dummy") l_file.open_read print (l_file.is_open_read)
> >>
> >>     Eric> However, using files the ISE way, you will not get the
> >>     Eric> exception as expected.
> >>
> >> I don't really understand any of that:
> >>
> >> 1) This is all Gobo code, using the file resolver.
> >> 2) How is gec managing to open the upper-case file in the first 
> >> place, when it has a lower-case name?
> > 
> > Ah, you said that you didn't get the error message, but I didn't 
> > realize that it meant that it was actually able to read the file. I 
> > have no idea why it manages to open the file. And I can't 
> try it on a 
> > small example since I don't have access to a Linux or other 
> > case-sensitive operating system. It's too bad that SourceForge does 
> > not offer its compile-farm anymore. As far as I can see, 
> the code ends 
> > up calling fopen(). I don't know if there is an option to make it 
> > case-insensitive or case_sensitive at will.
> 
> I can see one difference between ISE and Gobo when opening 
> the file under Linux/Unix. When opening a binary file, Gobo 
> does "rb" (same as Windows) whereas ISE does "r"
> for the mode. I guess this is the problem. I will fix that 
> and we will see how it goes. In the meantime I'd be 
> interested if you could have a look at the manpage for 
> fopen() on Linux and see if there is anything specified for 
> "rb" (like "open the file in case-insensitive mode" ;-)).
> 
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
> 
> --------------------------------------------------------------
> -----------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for just about 
> anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 

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

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

Eric Bezault wrote:
> Colin Paul Adams wrote:
>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>
>>     Eric> If you were using files the Gobo way, you would get "False"
>>     Eric> with the following code:
>>
>>     Eric>   local l_file: KL_TEXT_INPUT_FILE do create l_file.make
>>     Eric> ("dummy") l_file.open_read print (l_file.is_open_read)
>>
>>     Eric> However, using files the ISE way, you will not get the
>>     Eric> exception as expected.
>>
>> I don't really understand any of that:
>>
>> 1) This is all Gobo code, using the file resolver.
>> 2) How is gec managing to open the upper-case file in the first place,
>> when it has a lower-case name?
> 
> Ah, you said that you didn't get the error message, but
> I didn't realize that it meant that it was actually able
> to read the file. I have no idea why it manages to open
> the file. And I can't try it on a small example since I
> don't have access to a Linux or other case-sensitive
> operating system. It's too bad that SourceForge does not
> offer its compile-farm anymore. As far as I can see, the
> code ends up calling fopen(). I don't know if there is
> an option to make it case-insensitive or case_sensitive
> at will.

I can see one difference between ISE and Gobo when opening
the file under Linux/Unix. When opening a binary file,
Gobo does "rb" (same as Windows) whereas ISE does "r"
for the mode. I guess this is the problem. I will fix that
and we will see how it goes. In the meantime I'd be interested
if you could have a look at the manpage for fopen() on Linux
and see if there is anything specified for "rb" (like "open
the file in case-insensitive mode" ;-)).

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

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

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> If you were using files the Gobo way, you would get "False"
>     Eric> with the following code:
> 
>     Eric>   local l_file: KL_TEXT_INPUT_FILE do create l_file.make
>     Eric> ("dummy") l_file.open_read print (l_file.is_open_read)
> 
>     Eric> However, using files the ISE way, you will not get the
>     Eric> exception as expected.
> 
> I don't really understand any of that:
> 
> 1) This is all Gobo code, using the file resolver.
> 2) How is gec managing to open the upper-case file in the first place,
> when it has a lower-case name?

Ah, you said that you didn't get the error message, but
I didn't realize that it meant that it was actually able
to read the file. I have no idea why it manages to open
the file. And I can't try it on a small example since I
don't have access to a Linux or other case-sensitive
operating system. It's too bad that SourceForge does not
offer its compile-farm anymore. As far as I can see, the
code ends up calling fopen(). I don't know if there is
an option to make it case-insensitive or case_sensitive
at will.

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

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

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

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

    Eric> If you were using files the Gobo way, you would get "False"
    Eric> with the following code:

    Eric>   local l_file: KL_TEXT_INPUT_FILE do create l_file.make
    Eric> ("dummy") l_file.open_read print (l_file.is_open_read)

    Eric> However, using files the ISE way, you will not get the
    Eric> exception as expected.

I don't really understand any of that:

1) This is all Gobo code, using the file resolver.
2) How is gec managing to open the upper-case file in the first place,
when it has a lower-case name?
-- 
Colin Adams
Preston Lancashire

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

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

Colin Paul Adams wrote:
> This is a bit odd.
> 
> When testing one of the W3C XSLT test cases, I was getting an error
> from the XML parser when using ISE 6.1, but not when using gec.
> 
> The error is that it was unable to open an xml file - the reason,
> because the URI has the file name in lower case, but the actual file
> name is in upper case. And I'm running on Linux where file names are
> (for worse or for worse - even Microsoft can't get it wrong EVERY
> time) case sensitive.
> 
> I shall be reporting the error in the test case to the W3C, but I
> don't understand why when compiled with gec there is no error.

If you were using files the Gobo way, you would get "False" with
the following code:

   local
      l_file: KL_TEXT_INPUT_FILE
   do
      create l_file.make ("dummy")
      l_file.open_read
      print (l_file.is_open_read)

However, using files the ISE way, you will not get the exception as
expected. This is because when I implemented FILE in gec, there was
no support for exception yet. Now, it is possible to raise an exception
and rescue it in gec, so I guess I should change the implementation
class FILE to raise an exception in order to be more compatible with ISE.

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

Re: [gobo-eiffel-develop] [eposix] Problem in the http client/URI resolver

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

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

    Colin> I agree with almost everything there.  Empty string IS a path
    Colin> (from RFC 2986):

Is this the correct rfc number?


    Colin> So I think EPX_HTTP_10_CLIENT SHOULD accept empty
    Colin> string. After all, what is one supposed to do if an HTTP
    Colin> server were actually to distinguish between the two requests
    Colin> (as far as I can see from reading RFC 2616, this is
    Colin> legitimate)?=20

No, because it says:

  - An empty abs_path is equivalent to an abs_path of "/".

    Colin> In any case I think you ought to explicitly document this
    Colin> behaviour.

It sort of is: it doesn't except empty strings. Which should be it
should accept valid paths. But I like to be able to distinguish between
Void and empty strings which are almost always invalid, i.e. input
errors, instead of doing something that the user might not intended.

But an additional explicit comment might be in order.

=2D-=20
Cheers,

Berend de Boer

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

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

This is a bit odd.

When testing one of the W3C XSLT test cases, I was getting an error
from the XML parser when using ISE 6.1, but not when using gec.

The error is that it was unable to open an xml file - the reason,
because the URI has the file name in lower case, but the actual file
name is in upper case. And I'm running on Linux where file names are
(for worse or for worse - even Microsoft can't get it wrong EVERY
time) case sensitive.

I shall be reporting the error in the test case to the W3C, but I
don't understand why when compiled with gec there is no error.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] [eposix] Problem in the http client/URI resolver

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

>>>>> "Berend" == Berend de Boer <be...@po...> writes:

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
    Colin> In the HTTP URI resolver, I am passing {UT_URI}.path to
    Colin> {EPX_HTTP_10_CLIENT}.get.

    Colin> Who is wrong here? Is it the implementation of
    Colin> {UT_URI}.path, or should the HTTP resolver be checking for
    Colin> an empty path, and passing "/" in that case?

    Berend> Looks to me a job for the resolver. You could make it a
    Berend> convention, but I think the EPX_HTTP_10_CLIENT expects a
    Berend> path. Empty string isn't a path. You could go for
    Berend> convention in that case, but in the case of Eiffel I'm
    Berend> usually not fond of conventions, rather have explicit
    Berend> instructions.

I agree with almost everything there.
Empty string IS a path (from RFC 2986):

path          = path-abempty    ; begins with "/" or is empty
                / path-absolute   ; begins with "/" but not "//"
                / path-noscheme   ; begins with a non-colon segment
                / path-rootless   ; begins with a segment
                / path-empty      ; zero characters

So I think EPX_HTTP_10_CLIENT SHOULD accept empty string. After all,
what is one supposed to do if an HTTP server were actually to
distinguish between the two requests (as far as I can see from reading
RFC 2616, this is legitimate)? In any case
I think you ought to explicitly document this behaviour.

Anyway, I will alter the http resolver to change "" to "/" (we must have an
absolute URI here, so the change is safe providing the server doesn't
distinguish between them) for now, and the same for the ftp resolver,
and send you the patches.

 
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] [eposix] Problem in the http client/URI resolver

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

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

    Colin> In the HTTP URI resolver, I am passing {UT_URI}.path to
    Colin> {EPX_HTTP_10_CLIENT}.get.

    Colin> Who is wrong here? Is it the implementation of {UT_URI}.path,
    Colin> or should the HTTP resolver be checking for an empty path,
    Colin> and passing "/" in that case?

Looks to me a job for the resolver. You could make it a convention, but
I think the EPX_HTTP_10_CLIENT expects a path. Empty string isn't a
path. You could go for convention in that case, but in the case of
Eiffel I'm usually not fond of conventions, rather have explicit
instructions.

=2D-=20
Cheers,

Berend de Boer

[gobo-eiffel-develop] Problem in the http client/URI resolver

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

I just managed to build Gestalt with gec (using the new eposix
alpha build), and I did a few tests, but when I tried an
identity transformation of http://www.w3.org (a good source for
guarent5eed wel-formed xhtml), I get:

Fatal error:
http://www.gobosoft.com/eiffel/gobo/gexslt/extension#BUILD_ERROR:
?:1:1:URI http://www.w3.org PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

which to me looks like a failure to parse the DOCTYPE statement
correctly.

If I view the page in Firefox, and then select View Source, the first
two lines are:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

which certainly contains a good ExternalID.

So I saved the text to disk, and repeated the transformation, this
time using a file: URI to my saved local copy - this worked OK.

I then tried compiling with ISE 6.1 in workbench mode and repeated the
test.

It turns out that the problem is due to the missing / on the end of
the URI:
precondition violated - path not empty in {EPX_HTTP_10_CLIENT}.get

This seems a reasonable precondition to me. If the / is presnt, then a
path of / gets passed to get and all is well.

In the HTTP URI resolver, I am passing {UT_URI}.path to
{EPX_HTTP_10_CLIENT}.get.

Who is wrong here? Is it the implementation of {UT_URI}.path, or
should the HTTP resolver be checking for an empty path, and passing
"/" in that case?

Franck?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Does Gexace support 'supplier_precondition' setting ?

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

CRISMER Paul-Georges wrote:
> EiffelStudio provides a 'supplier_precondition' option.
> 
> Is Gexace capable of generating such a 'supplier_precondition' option?

Since gexace does not generate ECF files, it does not support
'supplier_precondition'. I would look weird to me that EiffelStudio
support this option for Ace files as well?

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

[gobo-eiffel-develop] Does Gexace support 'supplier_precondition' setting ?

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

Hello,

EiffelStudio provides a 'supplier_precondition' option.

Is Gexace capable of generating such a 'supplier_precondition' option?

Thanks for the support,

Best regards,

Paul G. Crismer

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