Hi all.

I would like to use GOBO package with SE 2.2. I need to know all kind of
problems SE 2.2 has with GOBO (besides this legendary "upper/lowercase"
problem)? Maybe strange inheritance? ANY is not ANY? Did somebody
investigate this problem deeply?

Thnx for quick and exact answer.

Damian

Hi all.

I've tried to compile Gutentag project which uses extensively Eiffel
parser cluster from Gobo 3.4.
I used ISE Eiffel 5.6 and obtained:

"""
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: ET_EIFFEL_PARSER
Deferred feature: yyfinal From: YY_PARSER_SKELETON
"""

Best regards,
Damian

On Thu, 2005-11-24 at 11:10 +0100, Damian DobroczyƄski wrote:
> Hi all.
>
> I've tried to compile Gutentag project which uses extensively Eiffel
> parser cluster from Gobo 3.4.
> I used ISE Eiffel 5.6 and obtained:
>
> """
> 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: ET_EIFFEL_PARSER
> Deferred feature: yyfinal From: YY_PARSER_SKELETON
> """

Please note that Gutentag requires Gobo CVS to compile correctly.
However, the problem I get when compiling Gutentag with Gobo 3.4 is:
---
Error code: VEEN
Error: unknown identifier.
What to do: make sure that identifier, if needed, is final name of
   feature of class, or local entity or formal argument of routine.

Class: TAG_EMACS_GENERATOR
Feature: generate_class
Identifier: queries
Taking no argument
Line: 81
           from
->          features := a_class.queries
             i := 1
---
This is of course a different error from yours and I can perfectly
explain mine. As for yours I believe there were some changes in the way
geyacc  generates code, but not between 3.4 and CVS, but 3.3 and 3.4
(IIRC). So I am a little surprised to see this error.

Andreas

>>>>> "Damian" == Damian Dobroczyński <damian@...> writes:

     Damian> Hi all.  I would like to use GOBO package with SE 2.2. I
     Damian> need to know all kind of problems SE 2.2 has with GOBO
     Damian> (besides this legendary "upper/lowercase" problem)? Maybe
     Damian> strange inheritance? ANY is not ANY? Did somebody
     Damian> investigate this problem deeply?

     Damian> Thnx for quick and exact answer.

Coming up:

Gobo is an Eiffel library.
SE 2.2 (beta 3 onwards) is a compiler for an Eiffel-like language, but
not Eiffel.

The case problem is the biggest one - it is overwhelming because
attributes with names such as STRING_ (used very extensively
throughout the Gobo libraries) are syntax errors in the language
supported by SE 2.2.

Stick to Eiffel.
--
Colin Adams
Preston Lancashire

Colin Paul Adams napisaƂ(a):

>>>>>>"Damian" == Damian Dobroczyñski <damian@...> writes:
>>>>>>
>>>>>>
>
>    Damian> Hi all.  I would like to use GOBO package with SE 2.2. I
>    Damian> need to know all kind of problems SE 2.2 has with GOBO
>    Damian> (besides this legendary "upper/lowercase" problem)? Maybe
>    Damian> strange inheritance? ANY is not ANY? Did somebody
>    Damian> investigate this problem deeply?
>
>    Damian> Thnx for quick and exact answer.
>
>Coming up:
>
>Gobo is an Eiffel library.
>SE 2.2 (beta 3 onwards) is a compiler for an Eiffel-like language, but
>not Eiffel.
>
>The case problem is the biggest one - it is overwhelming because
>attributes with names such as STRING_ (used very extensively
>throughout the Gobo libraries) are syntax errors in the language
>supported by SE 2.2.
>
>
>
Well, I've written a Python script that tried to transform *all* of the
upper case identifier to lower case (for features only of course). Of
course, it will not work for many cases like constant identifiers used
in parse and lexer clusters but ... after 2 hours I've managed to
compile the simplest program using ET_EIFFEL_PARSER. So, the main proble
is the case problem.
I've also found a problem with multiple feature definition in the
inheritance tree but it's easy to fix. I've found "deferred class"
problem while compiling with ISE Eiffel 5.6 but this is described in my
second post. I've also found non-consistent feature names for the same
feature (written in mixed upper/lower case in different places). I've
also experienced VE failure with GEANT compilation. As you see it is not
so simple to be sticked to Eiffel.

When developing a software I find it very reasonable to try to find
*common* *denominator* for the broadest set of compilers I know. That
what I've done when working with C++ language. This "case" problem I've
found in Eiffel community is radiculus to me. The solution is simple.
Find the *common* *denominator* for all compilers. The number of them
(compilers) is 3 (three). Not too many. As a fact, there are only three
C++ compilers mainly used by programmers: VC, GCC and Watcom. You see:
3.  Of course, there are a lot of them on the market and believe me:
It's a big pain to write portable software. But people do this inspite
of many problems with compilers. Nobody offended.

Back to Eiffel: if "STRING_" is compiled by two of them but the last one
failed then use "string_" which will be perfectly compiled by all of the
compilers. Am I right? That is the best solution for the community if
one of the compilers vendors refuses to make the compiler conformant
with our dreams and standards. It happens. It happens all of the time...

>Stick to Eiffel.
>
>
I would like to.

B.regards.

Damian

Hi all.

I would like to re-compile GEANT in GOBO 3.4 and after problems with SE
and ISE (with ET_EIFEEL_CLASS) I've taken VE on my desk. The result is:

------------   Compiler Messages   ------------

--- File :
/home/damian/tmp/gobo/library/lexical/lex/lx_lex_parser_skeleton.e
------ Cluster : lx_lex
--------- Class : LX_LEX_PARSER_SKELETON
Error VEVAL289: (VDRD-2, VNCS-1) Attribute or function 'yy_do_action' does
  not conform to procedure 'yy_do_action' from class 'YY_PARSER_SKELETON'
Error VEVAL262: (VMCN-3, VMRC-1) Name clash for feature 'yy_dummy' from
  classes 'YY_PARSER_SKELETON' and 'YY_SCANNER_SKELETON'.
Error VEVAL292: (VDRD-2, VNCS-1) Routine 'yy_do_action' with 0 argument(s)
  does not conform to routine 'yy_do_action' from class
  'YY_PARSER_SKELETON' with 1 argument(s)
-----------------------------------------------

Thanx for an advice. Maybe I'm a kind of misfortune? Maybe I do not
understand the simplest things?

B.regards,
Damian

>>>>> "Damian" == Damian Dobroczyäski <damian@...> writes:

     Damian> When developing a software I find it very reasonable to
     Damian> try to find *common* *denominator* for the broadest set of
     Damian> compilers I know.

While I only think it is reasonable to do this for compilers of the
same language.
The SE team have publicly announced a divergence from the Eiffel
language. Therefore it is not an Eiffel compiler anymore, so it is not
reasonable to attempt to support it. Note that case-insensitivity has
always been part of the definition of the Eiffel language.

Your attempts to work round the problems will become increasing
difficult over time, as the languages continue to diverge.
--
Colin Adams
Preston Lancashire

Damian Dobroczyński napisał(a):

>Hi all.
>
>I would like to re-compile GEANT in GOBO 3.4 and after problems with SE
>and ISE (with ET_EIFEEL_CLASS) I've taken VE on my desk. The result is:
>
>------------   Compiler Messages   ------------
>
>--- File :
>/home/damian/tmp/gobo/library/lexical/lex/lx_lex_parser_skeleton.e
>------ Cluster : lx_lex
>--------- Class : LX_LEX_PARSER_SKELETON
>Error VEVAL289: (VDRD-2, VNCS-1) Attribute or function 'yy_do_action' does
> not conform to procedure 'yy_do_action' from class 'YY_PARSER_SKELETON'
>Error VEVAL262: (VMCN-3, VMRC-1) Name clash for feature 'yy_dummy' from
> classes 'YY_PARSER_SKELETON' and 'YY_SCANNER_SKELETON'.
>Error VEVAL292: (VDRD-2, VNCS-1) Routine 'yy_do_action' with 0 argument(s)
> does not conform to routine 'yy_do_action' from class
> 'YY_PARSER_SKELETON' with 1 argument(s)
>-----------------------------------------------
>
>Thanx for an advice. Maybe I'm a kind of misfortune? Maybe I do not
>understand the simplest things?
>
>B.regards,
>Damian
>
>
>
Ok. This message is not longer valid. I used slightly different sources
of GOBO. Now, after downloading vanilla GOBO 3.4 and re-compiling geant
and other tools with VE I've got:

------------   Compiler Messages   ------------
Error VELIB510: It is necessary to resolve conflict for class GEANT
  Clusters geant, geant_ve
-----------------------------------------------

Looking at "ve.xace" I've found:
--
<cluster name="geant_ve" location="."/>
<cluster name="geant" location="${GOBO}/src/geant">
                 <cluster name="command"/>
                 <cluster name="task"/>
                 <cluster name="parser"/>
</cluster>
--
Sorry for the previous alarm,
Damian

Colin Paul Adams napisaƂ(a):

>>>>>>"Damian" == Damian DobroczyÀski <damian@...> writes:
>>>>>>
>>>>>>
>
>    Damian> When developing a software I find it very reasonable to
>    Damian> try to find *common* *denominator* for the broadest set of
>    Damian> compilers I know.
>
>While I only think it is reasonable to do this for compilers of the
>same language.
>The SE team have publicly announced a divergence from the Eiffel
>language. Therefore it is not an Eiffel compiler anymore, so it is not
>reasonable to attempt to support it. Note that case-insensitivity has
>always been part of the definition of the Eiffel language.
>
>Your attempts to work round the problems will become increasing
>difficult over time, as the languages continue to diverge.
>
>
Ok. VE conforms with the Eiffel language?

Damian

Damian Dobroczyński wrote:
> Ok. This message is not longer valid. I used slightly different sources
> of GOBO. Now, after downloading vanilla GOBO 3.4 and re-compiling geant
> and other tools with VE I've got:
>
> ------------   Compiler Messages   ------------
> Error VELIB510: It is necessary to resolve conflict for class GEANT
>  Clusters geant, geant_ve
> -----------------------------------------------

You need to clean up your Visual Eiffel universe as it probably
still refers to your old project using different sources of Gobo.
Just type:

    vec -eu -y

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

Eric Bezault napisaƂ(a):

>Damian Dobroczyñski wrote:
>
>
>>Ok. This message is not longer valid. I used slightly different sources
>>of GOBO. Now, after downloading vanilla GOBO 3.4 and re-compiling geant
>>and other tools with VE I've got:
>>
>>------------   Compiler Messages   ------------
>>Error VELIB510: It is necessary to resolve conflict for class GEANT
>> Clusters geant, geant_ve
>>-----------------------------------------------
>>
>>
>
>You need to clean up your Visual Eiffel universe as it probably
>still refers to your old project using different sources of Gobo.
>Just type:
>
>   vec -eu -y
>
>
>
Thanx for advice. I've clean it. I still have errors but this time the
compiler has troubles like:

------------   Compiler Messages   ------------
Error VESYS439: There is no such path '' .
Error VESYS439: There is no such path
  '/usr/local/lib/V_Eiffel/lib/kernel/eCluster' .
-----------------------------------------------

So, it is something wrong with this version of VE. Ok. I will not go
further.

B.regards,
Damian

P.S. If you'd have a smart tool which converts GOBO sources changing
mixed and upper case feature names to lower case, would you do it? So
that SE-case-sensitive users may a chance to compile it without a
special compiler switch? Would you?

Damian DobroczyƄski wrote:

> This "case" problem I've found in Eiffel community is radiculus to me.

The Eiffel community doesn't have a case problem. Eiffel is case-
insensitive. If the compiler is case-sensitive, then it isn't an
Eiffel compiler. ;-)

- Peter Gummer

Damian Dobroczyn'ski wrote:
> When developing a software I find it very reasonable to try to find
> *common* *denominator* for the broadest set of compilers I know. That
> what I've done when working with C++ language. This "case" problem I've
> found in Eiffel community is radiculus to me. The solution is simple.
> Find the *common* *denominator* for all compilers.

That's what I've done during almost 10 years with the Gobo
project. And it was still the case when Gobo 3.4 was released.
However it is now a waste of time to have to modify the code
of Gobo each time SE releases a new version. With SE clearly
announcing that their language is not Eiffel anymore I now
prefer to spend my time developing an Gobo Eiffel compiler
compatible with ISE and ECMA rather than being unproductive
like I did during the past year trying to support a compiler
that is diverging from the language implemented by others.

>>Stick to Eiffel.
>
> I would like to.

Colin's advice was: stop using compilers whose language looks
like Eiffel but are diverging from it every day, making not
only Gobo's code but even your code not compilable between
each new version. It is very reasonable to try to find the
common denominator between all Eiffel compilers. It is not
reasonable to support a compiler which claims not supporting
Eiffel anymore and is breaking existing code at each release.
So, to make Colin's advice clearer, I would say that if you
want to use Eiffel, don't use SE. SE's team clearly said that
Eiffel and SmartEiffel are too different languages. They started
to be two different dialects but are really becoming two
different languages every day. So, don't be fooled by the word
"Eiffel" in SmartEiffel, it's history.

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

Damian Dobroczyn'ski wrote:
> P.S. If you'd have a smart tool which converts GOBO sources changing
> mixed and upper case feature names to lower case, would you do it? So
> that SE-case-sensitive users may a chance to compile it without a
> special compiler switch? Would you?

No. As I already said, each release of SE is breaking existing
code. Solving this particular problem (which is not about case-
sensitivity -- Gobo supported SE's case-sensitivity for a long
time -- but about not accepting some identifiers to be of a
given letter case) is just the tree that hides the forest. I
already did this kind of changes in the past. Again, Gobo 3.4
was compiling with SE when it was released. So today we fix
this problem, and tomorrow there will be a new version of SE
breaking existing code in a different way. That's enough.
Gobo always made its best to support compilers that claimed
to support Eiffel. SE said that they are not Eiffel anymore.
End of story .. and a lot of time saved to do other more interesting
things than trying to fix broken code at each version of SE.

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

Eric Bezault napisaƂ(a):

>With SE clearly
>announcing that their language is not Eiffel anymore I now
>prefer to spend my time developing an Gobo Eiffel compiler
>compatible with ISE and ECMA rather than (...)
>
>
What is the status of your compiler? ($5000 for ISE equals to my annual
income. I have family ;))

Damian.

Damian Dobroczyn'ski wrote:
> Eric Bezault napisaƂ(a):
>
>
>>With SE clearly
>>announcing that their language is not Eiffel anymore I now
>>prefer to spend my time developing an Gobo Eiffel compiler
>>compatible with ISE and ECMA rather than (...)
>>
>>
>
> What is the status of your compiler? ($5000 for ISE equals to my annual
> income. I have family ;))

Currently it is in a stage that it can compile itself.
And it is the only Eiffel compiler whose code can be
compiled with other Eiffel compilers (including SE up
to the version supported by Gobo 3.4). You can read
this message for the current status:

     https://sourceforge.net/mailarchive/message.php?msg_id=13691581

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

Eric Bezault napisaƂ(a):

>Damian Dobroczyn'ski wrote:
>
>
>>Eric Bezault napisał(a):
>>
>>
>>
>>
>>>With SE clearly
>>>announcing that their language is not Eiffel anymore I now
>>>prefer to spend my time developing an Gobo Eiffel compiler
>>>compatible with ISE and ECMA rather than (...)
>>>
>>>
>>>
>>>
>>What is the status of your compiler? ($5000 for ISE equals to my annual
>>income. I have family ;))
>>
>>
>
>Currently it is in a stage that it can compile itself.
>And it is the only Eiffel compiler whose code can be
>compiled with other Eiffel compilers (including SE up
>to the version supported by Gobo 3.4). You can read
>this message for the current status:
>
>    https://sourceforge.net/mailarchive/message.php?msg_id=13691581
>
>
>
Thanx for help. Have a nice day,
Damian

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

Eric Bezault <ericb@...> writes:

> So, to make Colin's advice clearer, I would say that if you
> want to use Eiffel, don't use SE.

I suppose we still support SE 1.x and the compiler based upon the 1.2x
releases? Within the constraints of course (it must at least be
Eiffel, and secondly it must produce correct code).

- --
Live long and prosper,

Berend de Boer
(PGP public key: http://www.pobox.com/~berend/berend-public-key.txt)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD4DBQFDh2VnIyuuaiRyjTYRAhXRAJ4ipi36xmRVX0sN8xGfkiPsZc181gCY2o7Z
KOfofi9s3PNvojkNT5g60g==
=qnjb
-----END PGP SIGNATURE-----

>>>>> "Berend" == Berend de Boer <berend@...> writes:

     Berend> Eric Bezault <ericb@...> writes:
     >> So, to make Colin's advice clearer, I would say that if you
     >> want to use Eiffel, don't use SE.

     Berend> I suppose we still support SE 1.x and the compiler based
     Berend> upon the 1.2x releases? Within the constraints of course
     Berend> (it must at least be Eiffel, and secondly it must produce
     Berend> correct code).

Well neither 1.0 nor 1.2 always produces correct code in boost mode (a
counter-example being gexslt). And 1.1 is hopeless in that respect.

  But this was the case for 3.4 anyway.
--
Colin Adams
Preston Lancashire

Hi Eric,

Have you already created an open-source project (e.g. on sourceforge)
for yor new ECMA Eiffel compiler?  I would like to help with
development and testing, and I'm sure there are others who would like
to help as well.

I'm especially interested in ensuring that the compiler can be used
to generate code compatible with several mobile phone platforms.
After the release of SE 1.0 I worked on a branch (MobileEiffel:
https://sourceforge.net/projects/mobeiffel) that generated C and Java
code runnable on several major mobile device targets. This worked
reasonably well, but I had to strip some thread-unsafe features.  The
thread safety issue remains in SE 2.x, along with new problems you've
already pointed out, and SE still provides no support for
SCOOP/"separate", which is a major issue on mobile device platforms.

Anyhow, it'd be great to see a more open process for creating a new
compiler than we've seen in the past with SE, which unfortunately
seems to be one of the most insular open source development groups
I've experienced.

cheers,

Todd

--- In gobo-eiffel@yahoogroups.com, Eric Bezault <ericb@g...> wrote:
>
> Damian Dobroczyn'ski wrote:
> > Eric Bezault napisaƂ(a):
> >
> >
> >>With SE clearly
> >>announcing that their language is not Eiffel anymore I now
> >>prefer to spend my time developing an Gobo Eiffel compiler
> >>compatible with ISE and ECMA rather than (...)
> >>
> >>
> >
> > What is the status of your compiler? ($5000 for ISE equals to my
annual
> > income. I have family ;))
>
> Currently it is in a stage that it can compile itself.
> And it is the only Eiffel compiler whose code can be
> compiled with other Eiffel compilers (including SE up
> to the version supported by Gobo 3.4). You can read
> this message for the current status:
>
>     https://sourceforge.net/mailarchive/message.php?msg_id=13691581
>
> --
> Eric Bezault
> mailto:ericb@g...
> http://www.gobosoft.com
>

Hi Todd

Todd Courtois Stellanova wrote:
> Have you already created an open-source project (e.g. on sourceforge)
> for yor new ECMA Eiffel compiler?  I would like to help with
> development and testing, and I'm sure there are others who would like
> to help as well.

The compiler is part of the Gobo Eiffel project which is hosted here:

     https://sourceforge.net/projects/gobo-eiffel/

You'll need to "bootstrap" the project by following the instructions in
$GOBO/work/bootstrap/Readme.txt. Then the compiler root class is in
$GOBO/src/gec, and most of its source code is part of the library
$GOBO/library/tools.

As I already said in other messages, the compiler is in its early state.
Currently it can already compile itself, but I need to finish the work
on the kernel classes in order to make it more usable.

I plan to proceed as follows. First I want to finish the core of the
compiler and make it able to compile the whole Gobo package. I will
not ask help before reaching this state because I would end up spending
more time explaining why things do not work yet rather than implementing
them. When the core of the compiler will be ready, then it will be a
good time to receive some feedback from the first users as well as some
contributions from other developers.

> I'm especially interested in ensuring that the compiler can be used
> to generate code compatible with several mobile phone platforms.
> After the release of SE 1.0 I worked on a branch (MobileEiffel:
> https://sourceforge.net/projects/mobeiffel)  that generated C and Java
> code runnable on several major mobile device targets. This worked
> reasonably well, but I had to strip some thread-unsafe features.  The
> thread safety issue remains in SE 2.x, along with new problems you've
> already pointed out, and SE still provides no support for
> SCOOP/"separate", which is a major issue on mobile device platforms.

I don't plan to implement multithreading or SCOOP in the first versions
of the compiler, but this is definitely something that could be taken
care of by people who would like to add this functionalities to the
compiler. There are other things for which I would need help, such as
debugging and profiling support. But for that to be productive, I
think that I need to finish the core of the compiler first.

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

Dear List,

I would like to recompile a single class (from a text string) again
and again to see if it contains bugs.

The current way that I have implemented it is:

   parse is
       -- Parse the code and generate an AST.
     local
       fn: STRING
       a_file: KL_STRING_INPUT_STREAM
       root_class: ET_CLASS
     do
       create a_file.make (document.text)
       fn := "unnamed.e"
       my_universe.parse_file (a_file, fn, 0, my_cluster)
       if my_universe.classes_by_cluster (my_cluster).count > 1 then
         document.record_error ("More than one class defined", 1, 1)
       end
       if my_universe.classes_by_cluster (my_cluster).count < 1 then
         document.record_error ("No class defined", 1, 1)
       end
       parse_was_successful := not document.has_errors
       if parse_was_successful then
         root_class := my_universe.classes_by_cluster (my_cluster).first
         my_universe.set_root_class (root_class.name)
         my_universe.reset_classes
         my_universe.parse_system
       end
     end

Unfortunately, this code only generates the AST, but does not check
correct typing or any other checks beyond parsing. I had thought the
"parse_system" would implement this.

What would I need to change to have parsing of a text include all
system validity checks?

Bernd

Bernd Schoeller wrote:
> Unfortunately, this code only generates the AST, but does not check
> correct typing or any other checks beyond parsing. I had thought the
> "parse_system" would implement this.
>
> What would I need to change to have parsing of a text include all
> system validity checks?

You should call `compile_system' instead of `parse_system' in order
to check validity rules.

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

Hi,

I'm running Windows XP and VS.NET 2005. Checked out GOBO CVS
tonight, dropped to dos, and ran vcvars32.bat. Ran boostrap msc ise
and it failed. Can't find inttypes.h. I'm not familiar with MS C. Any
ideas on getting this built?

C:\eiffel\gobo\work\bootstrap>"c:\Program Files\Microsoft Visual
Studio 8\vc\bin
\vcvars32.bat"

C:\eiffel\gobo\work\bootstrap>"C:\Program Files\Microsoft Visual
Studio 8\Common
7\Tools\vsvars32.bat"
Setting environment for using Microsoft Visual Studio 2005 x86 tools.

C:\eiffel\gobo\work\bootstrap>bootstrap msc ise
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
gexace.c
c:\eiffel\gobo\work\bootstrap\gexace.h(114) : fatal error C1083:
Cannot open inc
lude file: 'inttypes.h': No such file or directory
Could Not Find C:\eiffel\gobo\work\bootstrap\gexace.obj
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
geant.c
c:\eiffel\gobo\work\bootstrap\geant.h(114) : fatal error C1083: Cannot
open incl
ude file: 'inttypes.h': No such file or directory
Could Not Find C:\eiffel\gobo\work\bootstrap\geant.obj
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
gelex.c
c:\eiffel\gobo\work\bootstrap\gelex.h(114) : fatal error C1083: Cannot
open incl
ude file: 'inttypes.h': No such file or directory
Could Not Find C:\eiffel\gobo\work\bootstrap\gelex.obj
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
geyacc.c
c:\eiffel\gobo\work\bootstrap\geyacc.h(114) : fatal error C1083:
Cannot open inc
lude file: 'inttypes.h': No such file or directory
Could Not Find C:\eiffel\gobo\work\bootstrap\geyacc.obj
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
gepp.c
c:\eiffel\gobo\work\bootstrap\gepp.h(114) : fatal error C1083: Cannot
open inclu
de file: 'inttypes.h': No such file or directory
Could Not Find C:\eiffel\gobo\work\bootstrap\gepp.obj
The system cannot find the file specified.
'geant1' is not recognized as an internal or external command,
operable program or batch file.

grantrettke wrote:
> I'm running Windows XP and VS.NET 2005. Checked out GOBO CVS
> tonight, dropped to dos, and ran vcvars32.bat. Ran boostrap msc ise
> and it failed. Can't find inttypes.h. I'm not familiar with MS C. Any
> ideas on getting this built?

It works fine with me with  VS.NET 2003. I don't have VS.NET 2005
but after some investigation I think I found the problem. These
C files used in Gobo's bootstrap have been generated with SmartEiffel
and it seems that there is a bug in SE's C code generation. In
the .h files we can read:

#if defined(_MSC_VER) && (_MSC_VER < 1400) /* MSVC older than v8 */

but your bug report seems to imply that it should actually be:

#if defined(_MSC_VER) /* MSVC */

I made this modification in Gobo CVS. Can you please do a 'cvs update'
of the files in gobo\work\bootstrap and try again?

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

Hello list !

On Thursday 23 February 2006 12:39, Eric Bezault wrote:
> grantrettke wrote:
> > I'm running Windows XP and VS.NET 2005. Checked out GOBO CVS
> > tonight, dropped to dos, and ran vcvars32.bat. Ran boostrap msc ise
> > and it failed. Can't find inttypes.h. I'm not familiar with MS C. Any
> > ideas on getting this built?
>
> It works fine with me with  VS.NET 2003. I don't have VS.NET 2005
> but after some investigation I think I found the problem. These
> C files used in Gobo's bootstrap have been generated with SmartEiffel
> and it seems that there is a bug in SE's C code generation. In
> the .h files we can read:
>
> #if defined(_MSC_VER) && (_MSC_VER < 1400) /* MSVC older than v8 */
>
> but your bug report seems to imply that it should actually be:
>
> #if defined(_MSC_VER) /* MSVC */

Actually that code is included but that's not important. What's funny is that
I fixed that test in SmartEiffel just days ago. You may also want to add the
following code at the beginning of the .h files to avoid being flooded with
obnoxious warnings from cl

#if defined(_MSC_VER) && (_MSC_VER >= 1400)       // VC8+
# ifndef _CRT_SECURE_NO_DEPRECATE
#  define _CRT_SECURE_NO_DEPRECATE
# endif
# ifndef _CRT_NONSTDC_NO_DEPRECATE
#  define _CRT_NONSTDC_NO_DEPRECATE
# endif
#endif   // VC8+

Good luck
--
Frederic Merizen

Recently I needed to re-install SE 1.0. I used Visual Studio Express
Edition and found the same problem (can't find inttypes.h) I tried the
exact suggestion you gave and I found that this is not sufficient to
install SE. Therefore it may not be sufficient for your needs either.

After I made the alteration you suggested and installed SE 1.0 I got the
following compile errors (among others):

cl -O2 -nologo -c compile_to_c15.c
compile_to_c15.c
compile_to_c15.c(573) : error C4980: '__value' : use of this keyword
requires /c
lr:oldSyntax command line option
compile_to_c15.c(573) : error C2059: syntax error : '__value'
compile_to_c15.c(573) : error C2513: 'char' : no variable declared
before '='
compile_to_c15.c(575) : error C2059: syntax error : ';'

I finally installed the Visual C++ Toolkit 2003. I use that for
SmartEiffel and Visual Studio Express 2005 for ISE.

Brian

-----Original Message-----
From: gobo-eiffel@yahoogroups.com [mailto:gobo-eiffel@yahoogroups.com]
On Behalf Of Eric Bezault
Sent: Thursday, February 23, 2006 6:39 AM
To: gobo-eiffel@yahoogroups.com
Cc: grettke@...
Subject: Re: [gobo-eiffel] Has anyone bootstrapped GOBO CVS using VS.NET
2005?

grantrettke wrote:
> I'm running Windows XP and VS.NET 2005. Checked out GOBO CVS tonight,
> dropped to dos, and ran vcvars32.bat. Ran boostrap msc ise and it
> failed. Can't find inttypes.h. I'm not familiar with MS C. Any ideas
> on getting this built?

It works fine with me with  VS.NET 2003. I don't have VS.NET 2005 but
after some investigation I think I found the problem. These C files used
in Gobo's bootstrap have been generated with SmartEiffel and it seems
that there is a bug in SE's C code generation. In the .h files we can
read:

#if defined(_MSC_VER) && (_MSC_VER < 1400) /* MSVC older than v8 */

but your bug report seems to imply that it should actually be:

#if defined(_MSC_VER) /* MSVC */

I made this modification in Gobo CVS. Can you please do a 'cvs update'
of the files in gobo\work\bootstrap and try again?

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



To Post a message, send it to:   gobo-eiffel@eGroups.com
To Unsubscribe, send a blank message to:
gobo-eiffel-unsubscribe@eGroups.com
Yahoo! Groups Links






************************************
This e-mail and any files transmitted with it are proprietary and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this e-mail in error please notify the sender. Please note
that any views or opinions presented in this e-mail are solely those of the
author and do not necessarily represent those of ITT Industries, Inc. The
recipient should check this e-mail and any attachments for the presence of
viruses. ITT Industries accepts no liability for any damage caused by any virus
transmitted by this e-mail.
************************************

> It works fine with me with  VS.NET 2003.

It worked fine for me with VS.NET 2003, also.

> I made this modification in Gobo CVS. Can you please do a 'cvs update'
> of the files in gobo\work\bootstrap and try again?

I just did a get and performed the following steps. The build appears
to have failed.

==================


C:\eiffel\gobo\work\bootstrap>"c:\Program Files\Microsoft Visual
Studio 8\vc\bin
\vcvars32.bat"

C:\eiffel\gobo\work\bootstrap>"C:\Program Files\Microsoft Visual
Studio 8\Common
7\Tools\vsvars32.bat"
Setting environment for using Microsoft Visual Studio 2005 x86 tools.

C:\eiffel\gobo\work\bootstrap>bootstrap msc ise
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
gexace.c
gexace.c(2921) : error C4980: '__value' : use of this keyword requires
/clr:oldS
yntax command line option
gexace.c(2921) : error C2059: syntax error : '__value'
gexace.c(2921) : error C2513: 'int32_t' : no variable declared before '='
gexace.c(2923) : error C2059: syntax error : 'type'
gexace.c(2997) : error C2059: syntax error : 'type'
gexace.c(2999) : error C2059: syntax error : 'type'
gexace.c(3010) : error C2143: syntax error : missing '{' before '*'
gexace.c(3010) : error C2371: 'r488key' : redefinition; different
basic types
         c:\eiffel\gobo\work\bootstrap\gexace.h(1414) : see declaration
of 'r488k
ey'
gexace.c(72540) : error C2059: syntax error : 'type'
gexace.c(72542) : error C2059: syntax error : 'type'
gexace.c(72551) : error C2059: syntax error : 'type'
gexace.c(72553) : error C2059: syntax error : 'type'
gexace.c(72562) : error C2059: syntax error : 'type'
gexace.c(72564) : error C2059: syntax error : 'type'
gexace.c(72573) : error C2059: syntax error : 'type'
gexace.c(72575) : error C2059: syntax error : 'type'
gexace.c(72584) : error C2059: syntax error : 'type'
gexace.c(72586) : error C2059: syntax error : 'type'
gexace.c(72595) : error C2059: syntax error : 'type'
gexace.c(72597) : error C2059: syntax error : 'type'
gexace.c(72606) : error C2059: syntax error : 'type'
gexace.c(72608) : error C2059: syntax error : 'type'
gexace.c(72617) : error C2059: syntax error : 'type'
gexace.c(72619) : error C2059: syntax error : 'type'
gexace.c(72628) : error C2059: syntax error : 'type'
gexace.c(72630) : error C2059: syntax error : 'type'
gexace.c(72639) : error C2059: syntax error : '__value'
gexace.c(72639) : error C2513: 'char' : no variable declared before '='
gexace.c(72641) : error C2059: syntax error : ';'
gexace.c(72650) : error C2059: syntax error : 'type'
gexace.c(72652) : error C2059: syntax error : 'type'
Could Not Find C:\eiffel\gobo\work\bootstrap\gexace.obj
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
geant.c
geant.c(3736) : error C4980: '__value' : use of this keyword requires
/clr:oldSy
ntax command line option
geant.c(3736) : error C2059: syntax error : 'type'
geant.c(3738) : error C2059: syntax error : 'type'
geant.c(3749) : error C2061: syntax error : identifier 'r281count'
geant.c(3749) : error C2059: syntax error : ';'
geant.c(3749) : error C2059: syntax error : 'type'
geant.c(3784) : error C2059: syntax error : '__value'
geant.c(3784) : error C2513: 'int32_t' : no variable declared before '='
geant.c(3786) : error C2059: syntax error : 'type'
geant.c(3825) : error C2059: syntax error : 'type'
geant.c(3827) : error C2059: syntax error : 'type'
geant.c(3838) : error C2143: syntax error : missing '{' before '*'
geant.c(3838) : error C2371: 'r774item' : redefinition; different
basic types
         c:\eiffel\gobo\work\bootstrap\geant.h(1948) : see declaration
of 'r774it
em'
geant.c(3880) : error C2059: syntax error : '__value'
geant.c(3880) : error C2513: 'char' : no variable declared before '='
geant.c(3882) : error C2059: syntax error : ';'
geant.c(3992) : error C2059: syntax error : 'type'
geant.c(3994) : error C2059: syntax error : 'type'
geant.c(4116) : error C2059: syntax error : 'type'
geant.c(4118) : error C2059: syntax error : 'type'
geant.c(4129) : error C2061: syntax error : identifier 'r234valid_cursor'
geant.c(4129) : error C2059: syntax error : ';'
geant.c(4129) : error C2059: syntax error : 'type'
geant.c(16470) : error C2059: syntax error : '__value'
geant.c(16470) : error C2513: 'char' : no variable declared before '='
geant.c(16472) : error C2059: syntax error : ';'
geant.c(72543) : error C2059: syntax error : 'type'
geant.c(72545) : error C2059: syntax error : 'type'
geant.c(72554) : error C2059: syntax error : 'type'
geant.c(72556) : error C2059: syntax error : 'type'
geant.c(72565) : error C2059: syntax error : 'type'
geant.c(72567) : error C2059: syntax error : 'type'
geant.c(72576) : error C2059: syntax error : 'type'
geant.c(72578) : error C2059: syntax error : 'type'
geant.c(72587) : error C2059: syntax error : 'type'
geant.c(72589) : error C2059: syntax error : 'type'
geant.c(72598) : error C2059: syntax error : 'type'
geant.c(72600) : error C2059: syntax error : 'type'
geant.c(72609) : error C2059: syntax error : 'type'
geant.c(72611) : error C2059: syntax error : 'type'
geant.c(72620) : error C2059: syntax error : 'type'
geant.c(72622) : error C2059: syntax error : 'type'
geant.c(72631) : error C2059: syntax error : 'type'
geant.c(72633) : error C2059: syntax error : 'type'
geant.c(72642) : error C2059: syntax error : '__value'
geant.c(72642) : error C2513: 'char' : no variable declared before '='
geant.c(72644) : error C2059: syntax error : ';'
geant.c(72653) : error C2059: syntax error : 'type'
geant.c(72655) : error C2059: syntax error : 'type'
geant.c(129579) : error C2059: syntax error : 'type'
geant.c(129581) : error C2059: syntax error : 'type'
geant.c(129590) : error C2059: syntax error : '__value'
geant.c(129590) : error C2513: 'int32_t' : no variable declared before '='
geant.c(129592) : error C2059: syntax error : 'type'
geant.c(129601) : error C2059: syntax error : 'type'
geant.c(129603) : error C2059: syntax error : 'type'
geant.c(129612) : error C2059: syntax error : 'type'
geant.c(129614) : error C2059: syntax error : 'type'
geant.c(129623) : error C2059: syntax error : 'type'
geant.c(129625) : error C2059: syntax error : 'type'
geant.c(129632) : error C2143: syntax error : missing '{' before '*'
geant.c(129632) : error C2371: 'oBC269yy_nxt_template' : redefinition;
different
  basic types
         c:\eiffel\gobo\work\bootstrap\geant.h(7561) : see declaration
of 'oBC269
yy_nxt_template'
Could Not Find C:\eiffel\gobo\work\bootstrap\geant.obj
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
gelex.c
gelex.c(2163) : error C4980: '__value' : use of this keyword requires
/clr:oldSy
ntax command line option
gelex.c(2163) : error C2059: syntax error : 'type'
gelex.c(2165) : error C2059: syntax error : 'type'
gelex.c(2176) : error C2061: syntax error : identifier 'r88count'
gelex.c(2176) : error C2059: syntax error : ';'
gelex.c(2176) : error C2059: syntax error : 'type'
gelex.c(2211) : error C2059: syntax error : '__value'
gelex.c(2211) : error C2513: 'int32_t' : no variable declared before '='
gelex.c(2213) : error C2059: syntax error : 'type'
gelex.c(2341) : error C2059: syntax error : 'type'
gelex.c(2343) : error C2059: syntax error : 'type'
gelex.c(2354) : error C2143: syntax error : missing '{' before '*'
gelex.c(2354) : error C2371: 'r85twin' : redefinition; different basic
types
         c:\eiffel\gobo\work\bootstrap\gelex.h(1137) : see declaration
of 'r85twi
n'
gelex.c(2391) : error C2059: syntax error : '__value'
gelex.c(2391) : error C2513: 'char' : no variable declared before '='
gelex.c(2393) : error C2059: syntax error : ';'
gelex.c(2467) : error C2059: syntax error : 'type'
gelex.c(2469) : error C2059: syntax error : 'type'
gelex.c(2480) : error C2061: syntax error : identifier 'r118count'
gelex.c(2480) : error C2059: syntax error : ';'
gelex.c(2480) : error C2059: syntax error : 'type'
gelex.c(2515) : error C2059: syntax error : 'type'
gelex.c(2517) : error C2059: syntax error : 'type'
gelex.c(6852) : error C2059: syntax error : '__value'
gelex.c(6852) : error C2513: 'char' : no variable declared before '='
gelex.c(6854) : error C2059: syntax error : ';'
gelex.c(22173) : error C2059: syntax error : 'type'
gelex.c(22175) : error C2059: syntax error : 'type'
gelex.c(22184) : error C2059: syntax error : 'type'
gelex.c(22186) : error C2059: syntax error : 'type'
gelex.c(22195) : error C2059: syntax error : '__value'
gelex.c(22195) : error C2513: 'int32_t' : no variable declared before '='
gelex.c(22197) : error C2059: syntax error : 'type'
gelex.c(22206) : error C2059: syntax error : 'type'
gelex.c(22208) : error C2059: syntax error : 'type'
gelex.c(22217) : error C2059: syntax error : 'type'
gelex.c(22219) : error C2059: syntax error : 'type'
gelex.c(22226) : error C2143: syntax error : missing '{' before '*'
gelex.c(22226) : error C2371: 'oBC385yy_nxt_template' : redefinition;
different
basic types
         c:\eiffel\gobo\work\bootstrap\gelex.h(2600) : see declaration
of 'oBC385
yy_nxt_template'
Could Not Find C:\eiffel\gobo\work\bootstrap\gelex.obj
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
geyacc.c
geyacc.c(2447) : error C4980: '__value' : use of this keyword requires
/clr:oldS
yntax command line option
geyacc.c(2447) : error C2059: syntax error : '__value'
geyacc.c(2447) : error C2513: 'int32_t' : no variable declared before '='
geyacc.c(2449) : error C2059: syntax error : 'type'
geyacc.c(2551) : error C2059: syntax error : 'type'
geyacc.c(2553) : error C2059: syntax error : 'type'
geyacc.c(2564) : error C2143: syntax error : missing '{' before '*'
geyacc.c(2564) : error C2371: 'r244item' : redefinition; different
basic types
         c:\eiffel\gobo\work\bootstrap\geyacc.h(1256) : see declaration
of 'r244i
tem'
geyacc.c(2592) : error C2059: syntax error : 'type'
geyacc.c(2594) : error C2059: syntax error : 'type'
geyacc.c(2605) : error C2143: syntax error : missing '{' before '*'
geyacc.c(2605) : error C2371: 'r650item' : redefinition; different
basic types
         c:\eiffel\gobo\work\bootstrap\geyacc.h(1262) : see declaration
of 'r650i
tem'
geyacc.c(2661) : error C2059: syntax error : 'type'
geyacc.c(2663) : error C2059: syntax error : 'type'
geyacc.c(2674) : error C2143: syntax error : missing '{' before '*'
geyacc.c(2674) : error C2371: 'r203item' : redefinition; different
basic types
         c:\eiffel\gobo\work\bootstrap\geyacc.h(1274) : see declaration
of 'r203i
tem'
geyacc.c(2702) : error C2059: syntax error : 'type'
geyacc.c(2704) : error C2059: syntax error : 'type'
geyacc.c(2715) : error C2143: syntax error : missing '{' before '*'
geyacc.c(2715) : error C2371: 'r135make' : redefinition; different
basic types
         c:\eiffel\gobo\work\bootstrap\geyacc.h(1280) : see declaration
of 'r135m
ake'
geyacc.c(21001) : error C2059: syntax error : 'type'
geyacc.c(21003) : error C2059: syntax error : 'type'
geyacc.c(21012) : error C2059: syntax error : 'type'
geyacc.c(21014) : error C2059: syntax error : 'type'
geyacc.c(21023) : error C2059: syntax error : '__value'
geyacc.c(21023) : error C2513: 'int32_t' : no variable declared before '='
geyacc.c(21025) : error C2059: syntax error : 'type'
geyacc.c(21034) : error C2059: syntax error : 'type'
geyacc.c(21036) : error C2059: syntax error : 'type'
geyacc.c(21045) : error C2059: syntax error : 'type'
geyacc.c(21047) : error C2059: syntax error : 'type'
geyacc.c(21056) : error C2059: syntax error : 'type'
geyacc.c(21058) : error C2059: syntax error : 'type'
geyacc.c(21065) : error C2143: syntax error : missing '{' before '*'
geyacc.c(21065) : error C2371: 'oBC502yy_nxt_template' : redefinition;
different
  basic types
         c:\eiffel\gobo\work\bootstrap\geyacc.h(2953) : see declaration
of 'oBC50
2yy_nxt_template'
Could Not Find C:\eiffel\gobo\work\bootstrap\geyacc.obj
cl : Command line warning D9035 : option 'o' has been deprecated and
will be rem
oved in a future release
gepp.c
gepp.c(2228) : error C4980: '__value' : use of this keyword requires
/clr:oldSyn
tax command line option
gepp.c(2228) : error C2059: syntax error : 'type'
gepp.c(2230) : error C2059: syntax error : 'type'
gepp.c(5709) : error C2059: syntax error : 'type'
gepp.c(5711) : error C2059: syntax error : 'type'
gepp.c(5720) : error C2059: syntax error : 'type'
gepp.c(5722) : error C2059: syntax error : 'type'
gepp.c(5731) : error C2059: syntax error : '__value'
gepp.c(5731) : error C2513: 'char' : no variable declared before '='
gepp.c(5733) : error C2059: syntax error : ';'
gepp.c(5740) : error C2143: syntax error : missing '{' before '*'
gepp.c(5740) : error C2371: 'oBC58yy_nxt_template' : redefinition;
different bas
ic types
         c:\eiffel\gobo\work\bootstrap\gepp.h(1034) : see declaration
of 'oBC58yy
_nxt_template'
Could Not Find C:\eiffel\gobo\work\bootstrap\gepp.obj
The system cannot find the file specified.
'geant1' is not recognized as an internal or external command,
operable program or batch file.

C:\eiffel\gobo>

Hi,

is there a standard way to calculate the type of an ET_EXPRESSION
within the gobo eiffel tools, assuming that I have already compiled
the system?

Bernd

grantrettke wrote:
> I just did a get and performed the following steps. The build appears
> to have failed.

These errors look similar to what Brian described in his
message yesterday. I don't know if Frederic's patch:

#if defined(_MSC_VER) && (_MSC_VER >= 1400)       // VC8+
# ifndef _CRT_SECURE_NO_DEPRECATE
#  define _CRT_SECURE_NO_DEPRECATE
# endif
# ifndef _CRT_NONSTDC_NO_DEPRECATE
#  define _CRT_NONSTDC_NO_DEPRECATE
# endif
#endif   // VC8+

was intended to address this problem. I applied it to the
bootstrap C files in Gobo CVS just in case. Can you give
it a try?

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