gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] <no subject>

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

> Yes, it is just adding a class ET_XACE_XML_GENERATOR in
> library/tools/xace/generator. Sven, if you are happy doing
> the modifications in the code of 'gexace', go ahead. Otherwise
> you can ask me for some help or I can do it if you don't want
> to dive into the code of 'gexace' or too busy doing something
> else. Just let me know.
> 
Thanks for this offer !
If you have time to do it that would be great. It did not look into
the gexace code yet so you might be faster than me as well.

It is not of urgent need for me but I think it would be really useful
to have the --xml

- Sven

______________________________________________________________________________
Ferienklick.de - Urlaub ist schoen!
Hier geht's zum Traumstrand: http://ferienklick.de/?PP=2-5-100-105-13

[gobo-eiffel-develop] <no subject>

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

> PS: I think we reached consensous. Sven I am looking forward 
> to your contribution - if you still volunter for the task. 
> The change to gexace should be trivial, the XSL part I don't know

I cannot remember having said that but I will have a look at your code.

- Sven

______________________________________________________________________________
Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1

Re: [gobo-eiffel-develop] suggestions for gexace

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

Andreas Leitner wrote:
> 
> I think we reached consensous. Sven I am looking forward to your
> contribution - if you still volunter for the task. The change
> to gexace should be trivial,

Yes, it is just adding a class ET_XACE_XML_GENERATOR in
library/tools/xace/generator. Sven, if you are happy doing
the modifications in the code of 'gexace', go ahead. Otherwise
you can ask me for some help or I can do it if you don't want
to dive into the code of 'gexace' or too busy doing something
else. Just let me know.

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

Re: [gobo-eiffel-develop] suggestions for gexace

[Andreas L. <no...@sb...>]

On Tue, Oct 02, 2001 at 10:44:59AM +0200, Eric Bezault wrote:
> Sven Ehrke wrote:
> > 
> > The drawback is that we would have to deliver
> > some non Eiffel stuff as part of gobo: the xsl libraries (xalan). So far it has been an optional addon which one
> > could use or not. If we would go the XSL way (and only that way) it becomes a mandatory part of GOBO.
> > I am not sure if this is acceptable or not.
> 
> I agree that having a --xml option would make 'gexace' more
> flexible, but I think that we should keep the --se, --ise,
> --hact and --ve options just for the reason you stated above:
> if people are happy with the Ace files generated by these
> 4 options and don't need more flexibility, they should not
> have to download and use Xalan. So I think that we should 
> keep the already existing options, and add the --xml option
> for advanced users.

Now I start seeing the light. Would mean, if we ever have our own XSLT tool, we can drop the "--hact, --ise, ..." part from gexace. That option makes the suggestion much more acceptable to me. It is kind of my way of thinking: if we don't archive the perfect solution right now, it's cool - but only as long as we make sure there is a way to "upgrade" to the perfect solution later (;

> PS: I know that I already asked this question and Alexander
> said that there is not need to reinvent the wheel, but is
> anybody interested in writing a XSLT tool in Eiffel using
> the Gobo XML library? I'm sure this would be an interesting
> project to work on.

I'd like to second that (;

Andreas
PS: I think we reached consensous. Sven I am looking forward to your contribution - if you still volunter for the task. The change to gexace should be trivial, the XSL part I don't know

Re: [gobo-eiffel-develop] suggestions for gexace

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

Sven Ehrke wrote:
> 
> At the moment I am still busy with the filesetf for geant (which
> should be finished this week). Then I have started to work
> on some classes similar to jDOM's API (www.jdom.org)
> )which I'd like to finish first. And of course there's bonbon.

Note that this was not necessarily a request for you. I know
that you already have plenty of things in your TODO list.
But if some Eiffel programmers are looking for a new project
to work on, this might be a good suggestion for them.

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

RE: Re: [gobo-eiffel-develop] suggestions for gexace

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

> -----Original Message-----
> From: ericb [mailto:er...@go...]
> Sent: Tuesday, October 02, 2001 10:45 AM
> To: gobo-eiffel-develop
> Cc: ericb
> Subject: Re: [gobo-eiffel-develop] suggestions for gexace
> 
> 
> Sven Ehrke wrote:
> > 
> > The drawback is that we would have to deliver
> > some non Eiffel stuff as part of gobo: the xsl libraries 
> (xalan). So far it has been an optional addon which one
> > could use or not. If we would go the XSL way (and only that 
> way) it becomes a mandatory part of GOBO.
> > I am not sure if this is acceptable or not.
> 
> I agree that having a --xml option would make 'gexace' more
> flexible, but I think that we should keep the --se, --ise,
> --hact and --ve options just for the reason you stated above:
> if people are happy with the Ace files generated by these
> 4 options and don't need more flexibility, they should not
> have to download and use Xalan. So I think that we should 
> keep the already existing options, and add the --xml option
> for advanced users.

I prefer this as well, even if we have more than one way then.

> 
> PS: I know that I already asked this question and Alexander
> said that there is not need to reinvent the wheel, but is
> anybody interested in writing a XSLT tool in Eiffel using
> the Gobo XML library? I'm sure this would be an interesting
> project to work on.

It would be a big one.
But we could start with XPath. Having gelex and geyacc it should
not be too complicated having a first version which would not
support everything but would be very useful even without the XSLT
support.
At the moment I am still busy with the filesetf for geant (which
should be finished this week). Then I have started to work
on some classes similar to jDOM's API (www.jdom.org)
)which I'd like to finish first. And of course there's bonbon.
But if we continue with this speed we might have the xsl stuff
next year ;-)

- Sven


_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

Re: [gobo-eiffel-develop] suggestions for gexace

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

Sven Ehrke wrote:
> 
> The drawback is that we would have to deliver
> some non Eiffel stuff as part of gobo: the xsl libraries (xalan). So far it has been an optional addon which one
> could use or not. If we would go the XSL way (and only that way) it becomes a mandatory part of GOBO.
> I am not sure if this is acceptable or not.

I agree that having a --xml option would make 'gexace' more
flexible, but I think that we should keep the --se, --ise,
--hact and --ve options just for the reason you stated above:
if people are happy with the Ace files generated by these
4 options and don't need more flexibility, they should not
have to download and use Xalan. So I think that we should 
keep the already existing options, and add the --xml option
for advanced users.

PS: I know that I already asked this question and Alexander
said that there is not need to reinvent the wheel, but is
anybody interested in writing a XSLT tool in Eiffel using
the Gobo XML library? I'm sure this would be an interesting
project to work on.

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

[gobo-eiffel-develop] Re: Re: suggestions for gexace

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

Andreas Leitner <no...@sb...> schrieb am 28.09.01:
> On Fri, Sep 28, 2001 at 01:26:56AM +0200, Sven Ehrke wrote:
> > Say we would have in addition to the --hact --ise --se --ve commandline options
> > a --xml commandline option. When specified it would produce an xml file
> > instead of an ace/esd file for the specific compilers.
> > On this xml file an xsl transformation could be run applying specific xsl files
> > like hact.xsl, ise.xsl, se.xsl, ve.xsl, special_se.xsl, ... . The output
> > would be ace/esd files for the specific compilers (of course it could produce
> > other things as well).
> > This would allow application developers to customize the form of the produced
> > output file. For elj applications for example I currently cut and paste certain
> > areas into the produced se.ace file. What has to done by hand could then
> > be done within the xsl. Using the <xsl:import> facility it would even be possible for a elj_se.xsl to "inherit" from the se.xsl and just
> > redefining the special things.
> > geant's <xslt> task could be used to apply the xsl transformation in a
> > convenient and automated way.
> > 
> > What do you think?
> 
> Could you please give examples of what such a transformation should do. My first though was to generalize the tasks and add the resulting features to gexace firectly.

Well if you look at the produced ace files we have a cluster list
containing items like:

  kernel_misc: "${GOBO}/library/kernel/misc";

Instead of the ace file the produced xml file
could contain (among other things) the cluster list in xml form:

  <cluster_list>
    <cluster name="kernel_misc" location="${GOBO}/library/kernel/misc"/>
  </cluster_list>

Above and below there can be additional information which gexace found
during the xace parse process. We could also (if we find it makes sense)
insert some "hook" tags to make it easier for the xsl to replace
them with certain customizable things.
Actually I think the xsl's would be really small and easy to understand
and besides that much more flexible than hard wiring it into gexace.
If you look at Eric's xsl's you can see what is possible with xslt.
Compared to those these would be really easy I think.

The production of the xml file should be really easy for gexace since
it has all the information already.

- Sven

______________________________________________________________________________
Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1

[gobo-eiffel-develop] Re: Re: suggestions for gexace

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

Andreas Leitner <no...@sb...> schrieb am 02.10.01:
> On Fri, Sep 28, 2001 at 11:20:03PM +0200, Sven Ehrke wrote:
> > Andreas Leitner <no...@sb...> schrieb am 28.09.01:
> > > On Fri, Sep 28, 2001 at 01:26:56AM +0200, Sven Ehrke wrote:
> > > 
> > > Could you please give examples of what such a transformation should do. My first though was to generalize the tasks and add the resulting features to gexace firectly.
> > 
> > Well if you look at the produced ace files we have a cluster list
> > containing items like:
> > 
> >   kernel_misc: "${GOBO}/library/kernel/misc";
> > 
> > Instead of the ace file the produced xml file
> > could contain (among other things) the cluster list in xml form:
> > 
> >   <cluster_list>
> >     <cluster name="kernel_misc" location="${GOBO}/library/kernel/misc"/>
> >   </cluster_list>
> > 
> > Above and below there can be additional information which gexace found
> > during the xace parse process. We could also (if we find it makes sense)
> > insert some "hook" tags to make it easier for the xsl to replace
> > them with certain customizable things.
> > Actually I think the xsl's would be really small and easy to understand
> > and besides that much more flexible than hard wiring it into gexace.
> > If you look at Eric's xsl's you can see what is possible with xslt.
> > Compared to those these would be really easy I think.
> > 
> > The production of the xml file should be really easy for gexace since
> > it has all the information already.
> 
> I have yet to take a closer look at XSL. I can see a point in your request, although I also see a problem. That does not neccesarily mean the problem is in your request, it may as well reside be the current architecture of gexace:
> 
> If we add a XACE->more-specific-XACE transformation and the provide a XSL to transform the more-specific-XACE into ACE files we basically provide two mechanisms to do the same thing:
> 
> a) use gexace to do the whole job
> b) use gexace plus xsl transformations
> 
> Eiffel has a long tradition of providing only one reasonable mechanism to archive one goal. And I think this is a good tradition. Providing multiple mechanisms results in confusion on the devopers side as to what is the best way to do a thing.
> 
> This is not an argument against the xsl approach it is an argument agains having both aproaches in GOBO. If we really go for the XSL way, it should be the only one.

I agree here. But remember that with a XML document produced by gexace people could do with it whatever they
would like to. Since it is XML they can use all the tools and libraries available. Gexace at the moment is really doing
two things at once:
1) reading the xace files and gathering all the information within them.
2) produce an ace file which contains that information in another format.

Having a separate module for each of these steps would increase reusablity.
So from a purists point of view I would support the XSL approach.
The drawback is that we would have to deliver
some non Eiffel stuff as part of gobo: the xsl libraries (xalan). So far it has been an optional addon which one
could use or not. If we would go the XSL way (and only that way) it becomes a mandatory part of GOBO.
I am not sure if this is acceptable or not.

> 
> My understanding of what would be a typical task for gexace and what for XSL is still somewhat fuzzy - maybe you can help me understand the issue better (;

gexace would then just produce a single flat XML out of the individual xace files.
Producing ace files from that XML is then the job of an XSL.
But remember: producing an ace file from that XML is just a special case of application (although the most important
at the moment). But one cannot foresee what ideas people have in future and having the information in XML
would be certainly very useful then.
I can setup a small example consisting of a XML and a XSL file if I find the time this week.

- Sven


______________________________________________________________________________
Ferienklick.de - Urlaub ist schoen!
Hier geht's zum Traumstrand: http://ferienklick.de/?PP=2-5-100-105-13

[gobo-eiffel-develop] suggestions for gexace

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

Say we would have in addition to the --hact --ise --se --ve commandline options
 a --xml commandline option. When specified it would produce an xml file
instead of an ace/esd file for the specific compilers.
On this xml file an xsl transformation could be run applying specific xsl files
like hact.xsl, ise.xsl, se.xsl, ve.xsl, special_se.xsl, ... . The output
would be ace/esd files for the specific compilers (of course it could produce
other things as well).
This would allow application developers to customize the form of the produced
output file. For elj applications for example I currently cut and paste certain
areas into the produced se.ace file. What has to done by hand could then
be done within the xsl. Using the facility it would even be possible for a elj_se.xsl to
"inherit" from the se.xsl and just
redefining the special things.
geant's task could be used to apply the xsl transformation in a
convenient and automated way.

What do you think?

- Sven

________________________________________________________________
Flug.de - Beste Verbindungen in alle Welt
http://flug.de/sb/?PP=0-5-100-105-15

Re: [gobo-eiffel-develop] big fixed in eiffel xml

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

Andreas Leitner wrote:
> 
> PS: Is there a policy about commit messages in the new GOBO project?
> Should I send them to the exml list, to gobo-eiffel-develop, or both?

I think that only milestone modifications (like the one
you just described in your previous message) should be
sent to the gobo-eiffel-develop mailing list and/or to
more specialized mailing lists such as the exml list
in your case.

Otherwise all the logs of the modifications in the Gobo
CVS repository are automatically sent to the
gobo-eiffel-commits mailing list for those who want to
follow every single character modification in CVS.
Probably nobody apart from me will ever subscribe to
this mailing list, but it's nice to be able to have a
look at its archive from time to time.

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

[gobo-eiffel-develop] big fixed in eiffel xml

[Andreas L. <no...@sb...>]

Just a quick note that I commited a patch from Cyril Adrian to
XT_ELEMENT.
Before the patch SE would trigger an invariant exception, because of
the order in which the objects got initialized.


Andreas
PS: Is there a policy about commit messages in the new GOBO project?
Should I send them to the exml list, to gobo-eiffel-develop, or both?

[gobo-eiffel-develop] found a way to customize emacs for gobo formating

[Andreas L. <no...@sb...>]

Hi list,

I found a way to customize the emacs-eiffel mode according to the
gobo-eiffel guidelines. Actually all the customization does, is that it
uses tabs instead of spaces for indenting.

Put the following in your .emacs file. You may need to remove your
.emacs.elc file in order for these changes to take effect. I have tried
this hack with some basic eiffel files and it seems to work, although it
could be that I have overseen some complex cases where indenting is
still wrong. (Actually I have no idea what the values stand for, all I
did was trial&error :)

--
(setq indent-tabs-mode t)
(custom-set-variables
 '(eif-rescue-keyword-indent -4)
 '(eif-feature-level-kw-indent 2)
 '(eif-extra-then-indent 0)
 '(eif-feature-level-indent 1)
 '(eif-continuation-indent 4)
 '(eif-inherit-level-kw-indent 4)
 '(eif-feature-level-comment-indent 4)
 '(eif-indent-increment 4))
(setq-default tab-width 4)
--

If you write new code, it will use tabs only, if you want to convert old
code, mark all code and execute indent-region and afterwards tabify.

hope this helps,
Andreas
PS: Thanks to Markus Schwenke, the maintainer of the eiffel-mode, for
his help.

Re: [gobo-eiffel-develop] Handling end of line stuff.

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

[Cc:ed to SmallEiffel mailing list.]

Berend de Boer wrote:
> 
> Christian Couder <chc...@cl...> writes:
> 
> > In my opinion, the compilers shouldn't cconvert "%R%N" to "%N" when
> > reading from a file and then back from "%N" to "%R%N" when writing to a
> > file.
> 
> You have the choice: use a text file if you want conversion, use
> binary if you don't want to.

I wish there was a binary file class which worked with
both C and JVM in SmallEiffel's lib_std. Is that something
that we could expect in future releases of SmallEiffel?

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

Re: [gobo-eiffel-develop] Handling end of line stuff.

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

Christian Couder <chc...@cl...> writes:

> In my opinion, the compilers shouldn't cconvert "%R%N" to "%N" when
> reading from a file and then back from "%N" to "%R%N" when writing to a
> file.

You have the choice: use a text file if you want conversion, use
binary if you don't want to.

And remember, this only occurs on Windows systems, for POSIX systems
there's no distinction between text and binary files.


-- 
Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Handling end of line stuff.

[Christian C. <chc...@cl...>]

Eric Bezault wrote :
> 
> Christian Couder wrote:
> >
> > If what you say is true, perhaps it could still be possible to define
> > the meaning of "eof" depending both on the target platform and the
> > compiler.
> > So that for example eof would always be "%N" if SmallEiffel is used, and
> > it would be "%N" on Unix or "%R%N" on Windows if another compiler is
> > used.
> 
> And then:
> 
> > For example if you want to set a multi-line message in a message box,
> > you can use one of the following :
> >
> > 1)
> >
> > msg_box.set_msg(error_header + eol + error_msg + eol + help_msg)
> 
> These two suggestions seem incompatible to be.
> Under Windows with some Eiffel compilers 'eol' will be
> %N just to make sure that %R%N (and not %R%R%N) is actually
> written to files, but then in your message box you really
> want 'eol' to be %R%N because you are now dealing with
> strings and not files anymore and the compilers do special
> treatments for %N only in files and standard files, not
> in strings.

In my opinion, the compilers shouldn't cconvert "%R%N" to "%N" when
reading from a file and then back from "%N" to "%R%N" when writing to a
file.
I think there are many good reasons why using something like "eol" would
be better for them than doing this.
First it's faster not to convert anything. Then it's also less
disturbing for the user to see that when he reads a file into a string
then the size of the string is the same as the size of the file he read.

Now if they prefer to do convert, then library developers should also,
if needed, convert back and forth in features like set_msg and get_msg,
which is another reason why converting is bad.

Regards,
Christian.

Re: [gobo-eiffel-develop] Handling end of line stuff.

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

Christian Couder wrote:
> 
> msg_box.set_msg(error_header + eol + error_msg + eol + help_msg)

This assumes that the line separators for files and
message boxes on the underlying platform are the
same. This needs to be proven...

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

Re: [gobo-eiffel-develop] Handling end of line stuff.

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

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

> Hmmm, actually I think it works! 

Didn't look at the implementation, but this is great of course :-)

-- 
Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Handling end of line stuff.

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

Christian Couder wrote:
> 
> If what you say is true, perhaps it could still be possible to define
> the meaning of "eof" depending both on the target platform and the
> compiler.
> So that for example eof would always be "%N" if SmallEiffel is used, and
> it would be "%N" on Unix or "%R%N" on Windows if another compiler is
> used.

And then:

> For example if you want to set a multi-line message in a message box,
> you can use one of the following :
> 
> 1)
> 
> msg_box.set_msg(error_header + eol + error_msg + eol + help_msg)

These two suggestions seem incompatible to be.
Under Windows with some Eiffel compilers 'eol' will be
%N just to make sure that %R%N (and not %R%R%N) is actually
written to files, but then in your message box you really
want 'eol' to be %R%N because you are now dealing with
strings and not files anymore and the compilers do special
treatments for %N only in files and standard files, not
in strings.

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

Re: [gobo-eiffel-develop] Handling end of line stuff.

[Christian C. <chc...@cl...>]

Eric Bezault wrote:
> 
> And apparently your 'eol' is part of ANY, so I think that
> this should rather be discussed in NICE and be adopted by
> the Eiffel compilers since they have better ways to handle
> platform-dependent functionalities than library writers.

Ok, perhaps I will suggest this when the class ANY will be reviewed.

Regards,
Christian.

Re: [gobo-eiffel-develop] Handling end of line stuff.

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

Christian Couder wrote:
> 
> Ok, so I agree with you that put_line features are a good thing, but I
> don't think they solve the whole problem.
> 
> For example if you want to set a multi-line message in a message box,
> you can use one of the following :
> 
> 1)
> 
> msg_box.set_msg(error_header + eol + error_msg + eol + help_msg)
> 
> 2)
> 
> msg_box.set_msg(error_header + "%N" + error_msg + "%N" + help_msg)
> 
> 3)
> 
> my_msg.append_line(error_header)
> my_msg.append_line(error_msg)
> my_msg.append_string(help_msg)
> msg_box.set_msg(my_msg)
> 
> >From this example you can see that 1) is both very short and likely to
> be portable, while 2) is not likely to be portable and 3) is not short.

But I would rather use 3) anyway: I don't want to have
to create zillion objects just to display a message.

And apparently your 'eol' is part of ANY, so I think that
this should rather be discussed in NICE and be adopted by
the Eiffel compilers since they have better ways to handle
platform-dependent functionalities than library writers.

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

Re: [gobo-eiffel-develop] Handling end of line stuff.

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

Christian Couder wrote:
> 
> Would the "%R%N" be converted to a "%N" when reading the file and then
> to "%R%N" again when writing the file ?

Yes. As far as I know they all do that under Windows
except Visual Eiffel.

> If what you say is true, perhaps it could still be possible to define
> the meaning of "eof" depending both on the target platform and the
> compiler.
> So that for example eof would always be "%N" if SmallEiffel is used, and
> it would be "%N" on Unix or "%R%N" on Windows if another compiler is
> used.

But I don't think that it is a Gobo issue. Platform-dependent
behavior should be handled by the compiler in my opinion. I
don't want to have to provide different versions of the same
class for the different Eiffel compilers and yet again different
versions for all supported platforms.

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

Re: [gobo-eiffel-develop] Handling end of line stuff.

[Christian C. <chc...@cl...>]

Eric Bezault wrote :
> 
> Christian Couder wrote:
> >
> > It solves the typing problem because it's shorter, but it doesn't solve
> > the problem that you will in many cases have to create 2 features in
> > many classes instead of only one
> 
> The routine should be define once and for all in the
> ancestor class.

Ok, so I agree with you that put_line features are a good thing, but I
don't think they solve the whole problem.

For example if you want to set a multi-line message in a message box,
you can use one of the following :

1) 

msg_box.set_msg(error_header + eol + error_msg + eol + help_msg)

2)

msg_box.set_msg(error_header + "%N" + error_msg + "%N" + help_msg)

3)

my_msg.append_line(error_header)
my_msg.append_line(error_msg)
my_msg.append_string(help_msg)
msg_box.set_msg(my_msg)


From this example you can see that 1) is both very short and likely to
be portable, while 2) is not likely to be portable and 3) is not short.

Regards,
Christian.

Re: [gobo-eiffel-develop] Handling end of line stuff.

[Christian C. <chc...@cl...>]

Eric Bezault wrote:
> 
> Considering that 'eol' is "%R%N" under Windows, I don't think
> that this will work with what some of the Eiffel compilers
> currently provide us since it is likely that you will end
> up with:
> 
> Hello world!%R%R%N
> 
> in your file, the %N (second character in 'eol') being
> automatically converted to %R%N. 

I don't use Windows any more so I cannot easily test.
But perhaps you are right, perhaps some compiler blindly convert all %N
to %R%N without checking if there is already a %R before.
It would be strange anyway because what would happen if you read a whole
text file into a string and then just write the string back to another
file ?
Would the "%R%N" be converted to a "%N" when reading the file and then
to "%R%N" again when writing the file ?
Could someone test ?

If what you say is true, perhaps it could still be possible to define
the meaning of "eof" depending both on the target platform and the
compiler.
So that for example eof would always be "%N" if SmallEiffel is used, and
it would be "%N" on Unix or "%R%N" on Windows if another compiler is
used.

Regards,
Christian.

Re: [gobo-eiffel-develop] Handling end of line stuff.

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

Christian Couder wrote:
> 
> Yes it is slower to use a +, but if you really want speed you can always
> use
> 
> put_string("Hello world !")
> put_string(eol)

Considering that 'eol' is "%R%N" under Windows, I don't think
that this will work with what some of the Eiffel compilers
currently provide us since it is likely that you will end
up with:

Hello world!%R%R%N

in your file, the %N (second character in 'eol') being
automatically converted to %R%N. To avoid this I would
have to use binary files instead of text files to 
implement the KL_*_FILE classes, but I don't think that
SmallEiffel has a binary file class in its lib_std, and
it would not work with the std files (which are text
files) anyway.

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