gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Bootstrap from CVS

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

Glenn Maughan wrote:
> 
> In addition to my last message, everything bootstraps fine using
> SmallEiffel. I had to get the latest beta version to build.

Yes, it works with SE -0.74b7 as well.

> Plenty of C compilation warnings of the form:
> 
>         "integral size mismatch in argument; conversion supplied"
> 
> using Visual C++ as the C compiler.

Yes, I get these warnings as well. It is definitely a problem
with the C code generated by the Eiffel compiler. I reported
that to D. Colnet 2 years ago, but with no success apparently.
Anyway, they are just warnings, the generated executable is OK.

> I get these with C code generated by ISE also.

Yes, with 5.0 new warnings appeared with the C code generated
by ISE.

But for these C compilation warnings (both from SE and ISE),
I think that it is an Eiffel compiler issue with the C code
they generate. There is nothing we can do from the Gobo Eiffel
code side.

BTW, did you find out whether there was another 'geyacc.exe'
in your path which was called during the bootstrap and was
causing the VCCH errors? With SmallEiffel you probably don't
get these errors because ... the compiler doesn't check them.

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

Re: [gobo-eiffel-develop] Bootstrap from CVS

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

Glenn Maughan wrote:
>  
> However, I received the following errors when trying to bootstrap using 'cl'
> and 'ise'. I'm using ISE Eiffel 5.0.34 and Visual C++ 6.0:

Did the bootstrap procedure correctly generate a 'geyacc.exe'
in $GOBO/bin? If so it looks like an old version of 'geyacc.exe'
(probably the one from the Gobo 2.0 delivery) is still in your
path before the one in $GOBO/bin.

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

RE: [gobo-eiffel-develop] Bootstrap from CVS

[Glenn M. <gle...@op...>]

Hi Eric,

In addition to my last message, everything bootstraps fine using
SmallEiffel. I had to get the latest beta version to build.

Plenty of C compilation warnings of the form:

	"integral size mismatch in argument; conversion supplied"

using Visual C++ as the C compiler. I get these with C code generated by ISE
also.

Glenn.

> -----Original Message-----
> From: gob...@li...
> [mailto:gob...@li...]On Behalf Of
> Glenn Maughan
> Sent: Sunday, 14 October 2001 11:13 AM
> To: gob...@li...
> Subject: RE: [gobo-eiffel-develop] Bootstrap from CVS
>
>
> (Sorry I meant to send this reply to the list not just Eric)
>
> Hi Eric,
>
> The bootstrap process looks really good. It will make keeping up with GOBO
> development much easier.
>
> However, I received the following errors when trying to bootstrap
> using 'cl'
> and 'ise'. I'm using ISE Eiffel 5.0.34 and Visual C++ 6.0:
>
> ------------------------------------------------------------------
> ----------
> ---
>
> Error code: VCCH(1)
> Error: class has deferred feature(s), but is not declared as deferred.
> What to do: make feature(s) effective, or include `deferred' before
>   `class' in Class_header.
>
> Class: LX_LEX_PARSER
> Deferred feature: token_name From: YY_PARSER_TOKENS
>
> ------------------------------------------------------------------
> ----------
> ---
>
> ------------------------------------------------------------------
> ----------
> ---
>
> Error code: VCCH(1)
> Error: class has deferred feature(s), but is not declared as deferred.
> What to do: make feature(s) effective, or include `deferred' before
>   `class' in Class_header.
>
> Class: GEPP_PARSER
> Deferred feature: token_name From: YY_PARSER_TOKENS
>
> ------------------------------------------------------------------
> ----------
> ---
>
> ------------------------------------------------------------------
> ----------
> ---
>
> Error code: VCCH(1)
> Error: class has deferred feature(s), but is not declared as deferred.
> What to do: make feature(s) effective, or include `deferred' before
>   `class' in Class_header.
>
> Class: XF_EVENT_PARSER
> Deferred feature: token_name From: YY_PARSER_TOKENS
>
> ------------------------------------------------------------------
> ----------
> ---
>
> ------------------------------------------------------------------
> ----------
> ---
>
> Error code: VCCH(1)
> Error: class has deferred feature(s), but is not declared as deferred.
> What to do: make feature(s) effective, or include `deferred' before
>   `class' in Class_header.
>
> Class: PR_YACC_PARSER
> Deferred feature: token_name From: YY_PARSER_TOKENS
>
> ------------------------------------------------------------------
> ----------
> ---
>
> Thanks.
> Glenn.
>
>
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Re: Re: [gobo-eiffel-develop] Re: Re: CDATA

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

er...@go... schrieb am 14.10.01:
> Sven Ehrke wrote:
> > 
> > > Actually at first I thought of writing:
> > >
> > >    <getest config="getest.cfg" compile="geant compile_ise >
> > > xcompile.log 2>&1"/>
> > >
> > > but when I looked at the XML parser code, it didn't seem
> > > to interpret entities like that. Does it?
> > 
> > I am not sure if I understood you correctly.
> 
> Of course you cannot understand: it seems that the entities
> that I put in my previous message have been interpreted
> either on my side or your side by the mail tool. Here is
> again what I wrote, in the hope that it will appear correctly
> this time:
> 
>    <getest config="getest.cfg"
>      compile="geant compile_ise > xcompile.log 2>&1"/>

Sorry for my stupidity but I still cannot see the
xml entity in the compile attribute.

  2>&1

is not an xml-entity. Examples for entities I can think of are:

  &copy;               for the copyright sign (c)
  &lt;                 for <

These are the entities like they are used in HTML for
example. Then one can define own entities like this:

<!ENTITY gobo "GOBO Eiffel">
This is &gobo;


So with the support of entities it probably would look like this
(I hope it comes through the mail proberly):

   <getest config="getest.cfg"
     compile="geant compile_ise &gt; xcompile.log 2&gt;&1"/>

Maybe the ampersand has to replaced by an entity as well (I cannot
remeber the symbol for it right now). But personally I find
the CDATA version more readable.

> 
> > If you are talking about
> > xml entities you are right: they are not handled.
> 
> But they should, no?

Yes, would be nice. But the current implementation does not support
many features of a professional XML parser. But we can add missing
features as we need them. So to solve the current problem I would
rather suggest to use CDATA.

- 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] Bootstrap from CVS

[Glenn M. <gle...@op...>]

(Sorry I meant to send this reply to the list not just Eric)

Hi Eric,

The bootstrap process looks really good. It will make keeping up with GOBO
development much easier.

However, I received the following errors when trying to bootstrap using 'cl'
and 'ise'. I'm using ISE Eiffel 5.0.34 and Visual C++ 6.0:

----------------------------------------------------------------------------
---

Error code: VCCH(1)
Error: class has deferred feature(s), but is not declared as deferred.
What to do: make feature(s) effective, or include `deferred' before
  `class' in Class_header.

Class: LX_LEX_PARSER
Deferred feature: token_name From: YY_PARSER_TOKENS

----------------------------------------------------------------------------
---

----------------------------------------------------------------------------
---

Error code: VCCH(1)
Error: class has deferred feature(s), but is not declared as deferred.
What to do: make feature(s) effective, or include `deferred' before
  `class' in Class_header.

Class: GEPP_PARSER
Deferred feature: token_name From: YY_PARSER_TOKENS

----------------------------------------------------------------------------
---

----------------------------------------------------------------------------
---

Error code: VCCH(1)
Error: class has deferred feature(s), but is not declared as deferred.
What to do: make feature(s) effective, or include `deferred' before
  `class' in Class_header.

Class: XF_EVENT_PARSER
Deferred feature: token_name From: YY_PARSER_TOKENS

----------------------------------------------------------------------------
---

----------------------------------------------------------------------------
---

Error code: VCCH(1)
Error: class has deferred feature(s), but is not declared as deferred.
What to do: make feature(s) effective, or include `deferred' before
  `class' in Class_header.

Class: PR_YACC_PARSER
Deferred feature: token_name From: YY_PARSER_TOKENS

----------------------------------------------------------------------------
---

Thanks.
Glenn.

Re: [gobo-eiffel-develop] Re: Re: CDATA

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

Sven Ehrke wrote:
> 
> > Actually at first I thought of writing:
> >
> >    <getest config="getest.cfg" compile="geant compile_ise >
> > xcompile.log 2>&1"/>
> >
> > but when I looked at the XML parser code, it didn't seem
> > to interpret entities like that. Does it?
> 
> I am not sure if I understood you correctly.

Of course you cannot understand: it seems that the entities
that I put in my previous message have been interpreted
either on my side or your side by the mail tool. Here is
again what I wrote, in the hope that it will appear correctly
this time:

   <getest config="getest.cfg"
     compile="geant compile_ise &gt; xcompile.log 2&gt;&amp;1"/>

> If you are talking about
> xml entities you are right: they are not handled.

But they should, no?

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

[gobo-eiffel-develop] Re: Re: CDATA

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

er...@go... schrieb am 13.10.01:
> > I just noticed that there is a problem with
> > 
> >   $GOBO/example/test/concat1/build.eant
> > 
> > On line 67, column 76
> > 
> >   <getest config="getest.cfg" compile="geant compile_ise > xcompile.log 2>&1"/>
> > 
> > is used.
> > 
> >   2>&1
> > 
> > is a problem for the xml parser.
> 
> Yes I know, I had to modify the parser to accept that.
> Are you saying that it is not correct XML? If it doesn't

Yes, I think so. If you try to load it into an XML editor
after having copied it from build.eant build.xml (or loading it
with netscape 6.1 as I do) you should get an error message.


> I would consider that as a flaw in the XML specification
> because in a string the XML special characters should
> not be special anymore. Look at Eiffel: special Eiffel
> characters (e.g. +, *, <, ...) are not special in strings.

Might be a flaw but that's how it is.

> 
> > A solution would be to make the xml parser capable of recognizing
> > CDATA sections (search for CDATA on www.zvon.org for more information).
> > This would turn the above statement into this one:
> > 
> >   <getest config="getest.cfg"
> >     compile="<![CDATA[geant compile_ise > xcompile.log 2>&1]]"/>
> 
> Actually at first I thought of writing:
> 
>    <getest config="getest.cfg" compile="geant compile_ise >
> xcompile.log 2>&1"/>
> 
> but when I looked at the XML parser code, it didn't seem
> to interpret entities like that. Does it?

I am not sure if I understood you correctly. If you are talking about
xml entities you are right: they are not handled.
If I remember correctly

  < would translate into &lt;
  > would translate into &gt;

and there are many others.

> 
> The XML Bible book says: "The only characters an attribute
> value may not contain are the angle brackets < and >, though
> these can be included using < and > entity references."
> As I said ealier, I don't understand why < and > are forbidden
> in strings. Anyway, wouldn't > and & be easier to
> implement than CDATA?

I think implementing CDATA would simply mean recognizing the token,
switching into a CDATA start condition, pass the text until
the end CDATA token to the parser and that's it (I hope).
It would also be useful for the description tag, if we would like
to place tokens there which are xlm tokens; e.g. when the
description contains xml examples.

- 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] Bootstrap from CVS

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

Berend de Boer wrote:
> 
> And perhaps you need geant (in your path)??

The bootstrap script should have created it (before actually
calling it) and copied it to $GOBO/bin. So this directory
should be in your PATH, yes.

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

Re: [gobo-eiffel-develop] gepp and line numbering

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

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

> I think that the best way to proceed in order to provide such
> neat functionality is to add a new command-line option to 'gepp',
> such as '-l' and '--line' for example.

Yes, smart idea btw.

-- 
Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Bootstrap from CVS

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

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

>   . Check out the source code of Gobo.
>   . Set the environment variable $GOBO.
>   . Run either:
> 
>       $GOBO/work/bootstrap/bootstrap.bat <c_compiler> <eiffel_compiler>
> 
>     or:
> 
>       $GOBO/work/bootstrap/bootstrap.sh <c_compiler> <eiffel_compiler>
> 
>     depending on your platform. To find out about the already
>     supported values for <c_compiler> and <eiffel_compiler>
>     run the same command with the option '-help'.

And perhaps you need geant (in your path)??

This is the message I got when executing this command:

# work/bootstrap/bootstrap.sh gcc se
work/bootstrap/bootstrap.sh: geant: command not found
mv: cannot stat `geant1': No such file or directory
work/bootstrap/bootstrap.sh: geant: command not found

-- 
Groetjes,

Berend. (-:

[gobo-eiffel-develop] gepp and line numbering

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

Hello,

This week Alexander Kogtenkov has suggested that 'gepp' should
preserve line numbers by inserting blank lines in place of the
deleted ones. Indeed I guess some of you already had the same
problem that I sometime have: the compiler tells you that there
is an error at a given line, and then you have to look at that
line in the generated .e file in order to find out by yourself
where this code might be located in the .ge original file. With
Alexander's suggestion we could directly look in the .ge file at
the given line number.

I think that the best way to proceed in order to provide such
neat functionality is to add a new command-line option to 'gepp',
such as '-l' and '--line' for example.

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

Re: [gobo-eiffel-develop] kernel/io

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

Following the discussions about IO classes, new-lines, etc. which
took place in this mailing list a few months ago, I updated the
design and implementation of the cluster $GOBO/library/kernel/io
in CVS in order to take your remarks and suggestions into account.
The source code is now ready for another session of public
scrutiny (although no doc nor examples are available yet). So
please feel free to have a look at it.

A test suite for these classes is available in $GOBO/test/kernel.
This is the first test suite using 'geant'. Just type:

  geant test_<compiler>

to run the test in optimized mode with <compiler> being either
'ise', 'se, 've' or 'hact' as usual. You can also run the test
with all assertions on:

  geant test_debug_<compiler>

I realize that the kernel/io cluster now contains a lot of classes
and it might be overwhelming at first to dive into this cluster, so
I shall write a doc any time soon in order to explain the current
design and how to use these classes in client code. Thank you for
your patience.

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

Re: [gobo-eiffel-develop] new mailing lists

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

So far I only got Franck's and Ian's opinion. Following their
remarks I have disabled the new mailing lists from:

  https://sourceforge.net/mail/?group_id=24591

and we will use the gobo-eiffel-develop mailing list for our
implementation discussions. It will still be possible in the
future to enable again some of the specialized mailing lists
if necessary.

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

[gobo-eiffel-develop] Bootstrap from CVS

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

Hi all,

It is now possible to bootstrap the Gobo tools from CVS.
The procedure is quite simple:

  . Check out the source code of Gobo.
  . Set the environment variable $GOBO.
  . Run either:

      $GOBO/work/bootstrap/bootstrap.bat <c_compiler> <eiffel_compiler>

    or:

      $GOBO/work/bootstrap/bootstrap.sh <c_compiler> <eiffel_compiler>

    depending on your platform. To find out about the already
    supported values for <c_compiler> and <eiffel_compiler>
    run the same command with the option '-help'.

For those who have already tried the bootstrap procedure
before, you would have noticed that there is no need to
set $GOBO_OS anymore (this variable still appears in some
geant build files, but it is internally interpreted by
'geant' -- in the same way 'gexace' can internally set the
value for $GOBO_EIFFEL).

There is not need for Makefiles anymore, and hence no cygwin
under Windows. However the directory $GOBO/test has not been
converted to geant build files yet. This will be done soon.

Later on, when you check out new classes or clusters, there
is usually no need to redo a full bootstrap again. Just
run:

  geant install

followed by:

  geant clean

in the root directory of the library these new classes or clusters
belong to. 'geant' actually finds its instructions in the file
'build.eant'. In order to know the possible command-line arguments
provided by a given build file, type:

  geant help

To come back to the bootstrap procedure, since not all C
compilers nor all platforms have been tested, you are welcome
to send patches and/or code to support other C compilers.

For what the Eiffel compiler is concerned, to run properly
the Gobo source code in CVS should be used with one of the
latest SmallEiffel beta releases, with at least ISE Eiffel 
5.0 (if you use ISE 4.5 you will have to copy 'es4.exe' to
'ec.exe' to have a chance to make it work), with Visual
Eiffel 3.3 (I think it doesn't work with VE 3.2 under Linux)
and with Halstenbach 4.0 (if you use ISS 3.0 you will have
at least to add DIRECTORY.create_dir to call `create' and
IO_MEDIUM.put_new_line to call `new_line' to have a chance 
to make it work).

Finally, note that the version of the Gobo package in CVS
is a development version and not an official release. The
bootstrap procedure is meant to be used by the Gobo developers
and by those who are interested in experiencing with new
functionalities at their own risk. In particular, people
willing to do code/design review, to beta test and/or to
submit patches/suggestions are welcome.

Enjoy!

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

Re: [gobo-eiffel-develop] new mailing lists

[Ian E. <ia...@no...>]

In message <3BC...@go...>, Eric Bezault
<er...@go...> writes
>So the question is: do you mind receiving messages about
>low level technical discussions of Gobo classes in
>'gobo-eiffel-develop'? Messages can be as interesting
>as discussing about the overall design of a cluster, or
>as borrowing as arguing how to indent an "if" instruction
>in a feature of a given class.
>
Fine by me. I am not in the Gobo team but I like to keep an eye on
what's going on - I can always skim stuff that's not of interest to me,

Regards, Ian Elliott

Re: [gobo-eiffel-develop] new mailing lists

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

fr...@ne... wrote:
> 
> >> So what I'm planing to
> >> do is to create one mailing list per Gobo library and tool:
> 
> I'm sorry I missed the original message so I'm commenting a bit
> too late,

I don't know if it's too late or not. I posted my initial
message a few days before actually creating the new mailing
lists but got no remarks, which I too quickly interpreted as
an unanimous agreement.

Now, no messages have been sent to these mailing lists yet,
and only a couple of people have already subscribed. So
even though I think that there is no way to delete a mailing
list, I'm still open to discussion and if people agree with
Franck, I can try to delete them (or we can leave them
inactive and I could notify the people when they accidentally
post to these mailing lists so that they repost their
message to 'gobo-eiffel-develop').

So the question is: do you mind receiving messages about
low level technical discussions of Gobo classes in
'gobo-eiffel-develop'? Messages can be as interesting
as discussing about the overall design of a cluster, or
as borrowing as arguing how to indent an "if" instruction
in a feature of a given class.

> If there's a need for segmentation, I'd rather see
> develop vs. user (questions about existing code, new
> user questions etc) rather than having so many lists.

I think that the purpose of SourceForge is to host
project developments. So I'm quite happy using the
already existing Yahoogroups Gobo mailing list:

  http://groups.yahoo.com/group/gobo-eiffel/

for user related discussions.

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

[gobo-eiffel-develop] new mailing lists

[<fr...@ne...>]

I did really miss the original message and I've just 
know checked the archive, so I've just seen the 
rationale:

> that most of the technical discussions about the
> development of 'geant' and 'gexace' have been done privately
> in the fear of flooding this mailing list with too many
> implementation details, even though some of you may have
> been interested in taking part into some of these discussions.

It's a good question, but personally I think it's much better to 
have that than the division while the volume is manageable (and 
I guess that even with all the private discussions thrown in 
it would remain OK). The user/develop division could also 
partly deal with the problem of too many implementation details 
for users.

-- 
Franck Arnaud ~ email: fr...@ne...

[gobo-eiffel-develop] new mailing lists

[<fr...@ne...>]

>> So what I'm planing to
>> do is to create one mailing list per Gobo library and tool:

I'm sorry I missed the original message so I'm commenting a bit 
too late, but is it really useful to have that many mailing lists? 
In my opinion, mailing lists generally should be divided when 
the volume on one is too big.

To me Gobo is a whole and I think people interested in Gobo 
are normally interested in it as a whole, even if they don't 
actively take part in all areas. It's interesting to see what 
happens in other areas even if you don't develop them, and 
you can throw in the odd comment in other areas or catch 
general threads which just drift to the general from something 
specific. By dividing the structure, people will only 
subscribe to what they're explicitely interested in and miss 
half the interesting discussions which inevitably will be 
in the 'wrong' list. Plus it undermines the project spirit 
as people won't know what the others are doing.

It's also a bit odd to have more mailing lists than active 
developers.

If there's a need for segmentation, I'd rather see 
develop vs. user (questions about existing code, new 
user questions etc) rather than having so many lists.

-- 
Franck Arnaud ~ email: fr...@ne...

Re: [gobo-eiffel-develop] New mailing lists

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

Eric Bezault wrote:
> 
> So what I'm planing to
> do is to create one mailing list per Gobo library and tool:
> 
>   gobo-eiffel-kernel
>   gobo-eiffel-lexical
>   gobo-eiffel-structure
>   gobo-eiffel-xml
>   ...
>   gobo-eiffel-geyacc
>   gobo-eiffel-gexace
>   gobo-eiffel-geant
>   ...

These new mailing lists have now been created. The complete
list is available at:

   https://sourceforge.net/mail/?group_id=24591

for anyone who wants to subscribe.

Unfortunately I didn't manage to create 'gobo-eiffel-xml'
because SourceForge wouldn't let me create a mailing list
with a name made up of less than 4 characters. So I created
'gobo-eiffel-xml-lib' instead.

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

[gobo-eiffel-develop] New mailing lists

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

Hi all,

As you may have noticed, there hasn't been that much traffic
in this mailing list during the past months. The unfortunate
reason is that most of the technical discussions about the
development of 'geant' and 'gexace' have been done privately
in the fear of flooding this mailing list with too many
implementation details, even though some of you may have
been interested in taking part into some of these discussions.
During the past few days some effort has been made to move
the discussions back to the mailing list for public scrutiny,
but I realize that some of you may be put off by too many
implementation detail discussions. So what I'm planing to
do is to create one mailing list per Gobo library and tool:

  gobo-eiffel-kernel
  gobo-eiffel-lexical
  gobo-eiffel-structure
  gobo-eiffel-xml
  ...
  gobo-eiffel-geyacc
  gobo-eiffel-gexace
  gobo-eiffel-geant
  ...

That way implementation details can be discussed in these
lists, people other than the developers of these tools
and libraries being also welcome to subscribe and take part
to the discussions. And the mailing list gobo-eiffel-develop
would still be there for more general discussions which are
not directly linked to one of the libraries or tools (e.g.
discussions about style guidelines, releases, bootstrap
from CVS, future of Gobo, etc.). I will start creating
these new mailing lists in the next few days, so watch out
the list of Gobo mailing lists in:

  https://sourceforge.net/mail/?group_id=24591

if you are interested in subscribing to some of them.

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

RE: [gobo-eiffel-develop] gexace --build --xml

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

> Done, and committed in CVS. I'll let you test it now...
> 
> Please note that in order to work properly, you will have
> either to set the environment variable $GOBO_EIFFEL or
> use the command-line option '--define' as follows:
> 
>   gexace --define="GOBO_EIFFEL=se" --build --xml

Perfect as usual !

Many thanks again.

- 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] KL_DIRECTORY.recursive_create_directory

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

Sven Ehrke wrote:
> 
> Am I doing something wrong?

You need to convert the pathname received by 'geant'
(which is of the Unix pathname convention) to the
pathname convention of the current operating system:

        make is
                local
                        a_directory: KL_DIRECTORY
                        a_name, a_parent: STRING
                do
                        a_name := clone ("parent/child")
			a_name := file_system.pathname_from_file_system (a_name,
unix_file_system)
                        !! a_directory.make (a_name)
                        a_directory.recursive_create_directory
                end

Alternatively, you can do that:

        make is
                local
                        a_directory: KL_DIRECTORY
                        a_name, a_parent: STRING
                do
                        a_name := file_system.pathname ("parent",
"child")
                        !! a_directory.make (a_name)
                        a_directory.recursive_create_directory
                end

but this will not be of any help with 'geant' since the pathnames
are already built (with the Unix pathname convention) when they
are processed by 'geant'.

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

[gobo-eiffel-develop] KL_DIRECTORY.recursive_create_directory

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

Hello Eric,

for the geant <mkdir> task I am working on replacing

  file_system.create_directory (directory)

with

  a_directory.recursive_create_directory

like this:
________________________________________________________________
	execute is
			-- Execute command.
		local
			a_directory: KI_DIRECTORY
		do
			log ("  [mkdir] " + directory + "%N")
--			file_system.create_directory (directory)
			! KL_DIRECTORY ! a_directory.make (directory)
			a_directory.recursive_create_directory
		end
________________________________________________________________

Using "parent/child" as `directory' does not seem to work.

Then I made a small test:
________________________________________________________________
	make is
		local
			a_directory: KL_DIRECTORY
			a_name, a_parent: STRING
		do
			a_name := clone ("parent/child")
			!! a_directory.make (a_name)
			a_directory.recursive_create_directory
		end

________________________________________________________________

which does not create the directories either.
Am I doing something wrong?

When I set

  a_name := clone ("parent")

the directory "parent" gets created.

- 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] gexace --build --xml

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

Sven Ehrke wrote:
> 
> > 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

Done, and committed in CVS. I'll let you test it now...

Please note that in order to work properly, you will have
either to set the environment variable $GOBO_EIFFEL or
use the command-line option '--define' as follows:

  gexace --define="GOBO_EIFFEL=se" --build --xml

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

Re: [gobo-eiffel-develop] <no subject>

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

On Wed, Oct 03, 2001 at 10:07:36AM +0200, Sven Ehrke wrote:
> > 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.

Right, I remember you said, you are willing to prototype it. Sorry for the confusion. As Eric pointed out your todo list is quite big and you do a lot for GOBO already. So if you don't find the time, ...

Andreas