ooc-compiler

[ooc-compiler] Fw: Fw: Problems bootsrapping OO2C under MinGW/MSYS

[Bernhard T. <Bd...@wi...>]

Hi Stewart,

[...]
> > I suggest that you first try to bootstrap the system without using
> > libtool. This means using "./configure --disable-libs" so that you get
> > static linking, rather than trying to build shared libraries. AFAIK,
> > oo2c+libtool is untested under mingw/msys. At least in recent releases,
> > oo2c should not be bothered by Windows path names, and neither should
> > gcc. Can't say the same for libtool though...
> >
> >  From README.WIN32, the full configure command for msys looks something
> > like this:
> >    env
> >      "INSTALL=c:/msys/1.0/bin/install.exe"
> >      LDFLAGS=-L/usr/local/lib
> >      CFLAGS=-O2
> >      "CPPFLAGS=-I/usr/local/include -DGC_WIN32_THREADS"
> >      ./configure --disable-libs
> >

I tried that, but it did not work out. The bootstrapping dos not get beyond
the same
point, this time with different error messages (second try to "make"):

$ make
stage0/oo2c --config oo2crc-install.xml -v -r lib -r .  --build-package
liboo2c
- D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/pkginfo.xml
- D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/pkginfo.xml
- lib/sym/liboo2c.Sym
- lib/sym/liboo2c.Doc
- lib/sym/RT0.Sym

... more stuff from the lib ...

- lib/sym/Codec/Latin1.Doc
- lib/sym/Codec/UU.Sym
- lib/sym/Codec/UU.Doc
- lib/sym/Codec/YEnc.Sym
- lib/sym/Codec/YEnc.Doc
gcc -O2 -I/usr/local/include -DGC_WIN32_THREADS -Ilib/src -Iobj -Ilib/obj -I
/usr/src/OO2C/oo2c_32-2.1.10/obj -I/usr/src/OO2C/oo2c_32-2.1.10/lib/obj -c
D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/src/RT0.c -o lib/obj/RT0.o
D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/src/RT0.c:19:21: gc/gc.h:
No such file or directory
D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/src/RT0.c:86: error:
syntax error before "ptr"
D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/src/RT0.c: In function
`HandleFinalize':
D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/src/RT0.c:88: error: `ptr'
undeclared (first use in this function)

... more compiler error messages ...

make: *** [lib/obj/liboo2c.la] Error 1

Bernhard@JANUS /src/OO2C/oo2c_32-2.1.10
$ ll /usr/local/include/gc/gc.h
-rw-r--r--    1 Bernhard Administ    44551 Jun 22 19:29
/usr/local/include/gc/gc.h

strange enough /usr/local/include/gc/gc.h is available, but gcc does not
find it despite having
the correct path ...

I still don't have any clue.

regards and thanks so far

    Bernhard

Re: [ooc-compiler] Problems bootsrapping OO2C under MinGW/MSYS

[Bernhard T. <Bd...@wi...>]

Hi Stewart,

> These are explained at length in README.WIN32.

in the meantime I've found them, but it did not help me very much.

> 
> I suggest that you first try to bootstrap the system without using 
> libtool. This means using "./configure --disable-libs" so that you get 

I'll try that.

> static linking, rather than trying to build shared libraries. AFAIK, 
> oo2c+libtool is untested under mingw/msys. At least in recent releases, 
> oo2c should not be bothered by Windows path names, and neither should 
> gcc. Can't say the same for libtool though...
> 

hmm, it gets installed :-)

>  From README.WIN32, the full configure command for msys looks something 
> like this:
>    env \
>      "INSTALL=c:/msys/1.0/bin/install.exe" \
>      LDFLAGS=-L/usr/local/lib \
>      CFLAGS=-O2 \
>      "CPPFLAGS=-I/usr/local/include -DGC_WIN32_THREADS" \
>      ./configure --disable-libs
> 
> Hope this helps.
> 
I'll keep  you informed ...

regards & thanks

    Bernhard

Re: [ooc-compiler] Problems bootsrapping OO2C under MinGW/MSYS

[Stewart G. <sgr...@us...>]

Hi Bernhard,

There are a few issues with the configuration of oo2c under Windows. 
These are explained at length in README.WIN32.

I suggest that you first try to bootstrap the system without using 
libtool. This means using "./configure --disable-libs" so that you get 
static linking, rather than trying to build shared libraries. AFAIK, 
oo2c+libtool is untested under mingw/msys. At least in recent releases, 
oo2c should not be bothered by Windows path names, and neither should 
gcc. Can't say the same for libtool though...

 From README.WIN32, the full configure command for msys looks something 
like this:
   env \
     "INSTALL=c:/msys/1.0/bin/install.exe" \
     LDFLAGS=-L/usr/local/lib \
     CFLAGS=-O2 \
     "CPPFLAGS=-I/usr/local/include -DGC_WIN32_THREADS" \
     ./configure --disable-libs

Hope this helps.

Cheers,
   Stewart

Bernhard Treutwein wrote:
> Dear OO2C users,
> 
> I am trying to bootstrap OO2C under MinGW/MSYS,
> 
> I successfully compiled the current gc.
> 
> ./configure had no apparent problems.
> 
> but make fails in the last steps of stage0 (at least
> I have the impression). Somehow it gets an windows-like
> path specification (D:/Programme/Msys/...),
> see below. Does anybody have an idea how to correct that.
> 
> regard & thanks in advance
> 
> --
> Bernhard Treutwein
> Bernhard.Treutwein(at)verwaltung uni-muenchen de (work)
> BdT(at)wildwein de (home)
> 
> PS: The complete log is available, but I hope that I extracted the relevant
> parts:
> 
> Bernhard@JANUS /usr/src/OO2C
> $ cd oo2c_32-2.1.10
> 
> Bernhard@JANUS /usr/src/OO2C/oo2c_32-2.1.10
> $ ./configure
> checking for gcc... gcc
> 
> ... no apparent errors ...
> 
> Bernhard@JANUS /usr/src/OO2C/oo2c_32-2.1.10
> $ make
> make -C stage0 -f Makefile.ext setup-src oo2c
> make[1]: Entering directory `/usr/src/OO2C/oo2c_32-2.1.10/stage0'
> test -h src || (rm -Rf src lib/src; cp -R ../src .; cp -R ../lib/src lib)
> gcc -g -O2  -Ilib/src -I./obj -I./lib/obj -c ./lib/obj/ADT/ArrayList.c -o
> ./lib/obj/ADT/ArrayList.o
> 
> ... some warnings ...
> 
> make[1]: Leaving directory `/usr/src/OO2C/oo2c_32-2.1.10/stage0'
> sed -e 's?%libdir%?/usr/local/lib?g' \
>     -e 's?%oocdir%?/usr/local/lib/oo2c?g' \
>     -e 's?%bindir%?/usr/local/bin?g' \
>     -e 's?%INSTALL%?/bin/install -c?g' \
>     -e 's?%INSTALL_PROGRAM%?/bin/install -c?g' \
>     -e 's?%INSTALL_DATA%?/bin/install -c -m 644?g' \
> /usr/src/OO2C/oo2c_32-2.1.10/rsrc/OOC/oo2crc.xml.mk
> 
>>/usr/src/OO2C/oo2c_32-2.1.10/rsrc/OOC/oo2crc.xml
> 
> sed -e 's:<file-system>:<!--:g' \
> -e 's:</file-system>:-->:g' \
> -e
> 's:<repositories>:<repositories><file-system>/usr/src/OO2C/oo2c_32-2.1.10/li
> b
> </file-system><file-system>/usr/src/OO2C/oo2c_32-2.1.10</file-system>:' \
>  /usr/src/OO2C/oo2c_32-2.1.10/rsrc/OOC/oo2crc.xml
> 
>>/usr/src/OO2C/oo2c_32-2.1.10/oo2crc-install.xml
> 
> stage0/oo2c --config oo2crc-install.xml -v -r lib -r .  --build-package
> liboo2c
> - D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/pkginfo.xml
> - D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/pkginfo.xml
> - lib/src/liboo2c.Mod
> 
> ... no apparent errors ...
> 
> - lib/sym/liboo2c.Doc
> /bin/libtool --tag=CXX --mode=compile gcc -g -O2  -Ilib/src -Iobj -Ilib/obj
> -I/usr/src/OO2C/oo2c_32-2.1.10/obj -I/usr/src/OO2C/oo2c_32-2.1.10/lib/obj -c
> D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/src/RT0.c -o
> lib/obj/RT0.lo
> make: *** [lib/obj/liboo2c.la] Error 1
> 
> 
> Bernhard@JANUS /usr/src/OO2C/oo2c_32-2.1.10
> $ libtool --version
> ltmain.sh (GNU libtool) 1.4e (1.1162 2002/11/22 22:36:25)
> 
> Copyright 1996, 1997, 1998, 1999, 2000, 2001
> Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> Bernhard@JANUS /usr/src/OO2C/oo2c_32-2.1.10
> $ gcc --version
> gcc.exe (GCC) 3.4.2 (mingw-special)
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
> 

[ooc-compiler] Problems bootsrapping OO2C under MinGW/MSYS

[Bernhard T. <Bd...@wi...>]

Dear OO2C users,

I am trying to bootstrap OO2C under MinGW/MSYS,

I successfully compiled the current gc.

./configure had no apparent problems.

but make fails in the last steps of stage0 (at least
I have the impression). Somehow it gets an windows-like
path specification (D:/Programme/Msys/...),
see below. Does anybody have an idea how to correct that.

regard & thanks in advance

--
Bernhard Treutwein
Bernhard.Treutwein(at)verwaltung uni-muenchen de (work)
BdT(at)wildwein de (home)

PS: The complete log is available, but I hope that I extracted the relevant
parts:

Bernhard@JANUS /usr/src/OO2C
$ cd oo2c_32-2.1.10

Bernhard@JANUS /usr/src/OO2C/oo2c_32-2.1.10
$ ./configure
checking for gcc... gcc

... no apparent errors ...

Bernhard@JANUS /usr/src/OO2C/oo2c_32-2.1.10
$ make
make -C stage0 -f Makefile.ext setup-src oo2c
make[1]: Entering directory `/usr/src/OO2C/oo2c_32-2.1.10/stage0'
test -h src || (rm -Rf src lib/src; cp -R ../src .; cp -R ../lib/src lib)
gcc -g -O2  -Ilib/src -I./obj -I./lib/obj -c ./lib/obj/ADT/ArrayList.c -o
./lib/obj/ADT/ArrayList.o

... some warnings ...

make[1]: Leaving directory `/usr/src/OO2C/oo2c_32-2.1.10/stage0'
sed -e 's?%libdir%?/usr/local/lib?g' \
    -e 's?%oocdir%?/usr/local/lib/oo2c?g' \
    -e 's?%bindir%?/usr/local/bin?g' \
    -e 's?%INSTALL%?/bin/install -c?g' \
    -e 's?%INSTALL_PROGRAM%?/bin/install -c?g' \
    -e 's?%INSTALL_DATA%?/bin/install -c -m 644?g' \
/usr/src/OO2C/oo2c_32-2.1.10/rsrc/OOC/oo2crc.xml.mk
>/usr/src/OO2C/oo2c_32-2.1.10/rsrc/OOC/oo2crc.xml
sed -e 's:<file-system>:<!--:g' \
-e 's:</file-system>:-->:g' \
-e
's:<repositories>:<repositories><file-system>/usr/src/OO2C/oo2c_32-2.1.10/li
b
</file-system><file-system>/usr/src/OO2C/oo2c_32-2.1.10</file-system>:' \
 /usr/src/OO2C/oo2c_32-2.1.10/rsrc/OOC/oo2crc.xml
>/usr/src/OO2C/oo2c_32-2.1.10/oo2crc-install.xml
stage0/oo2c --config oo2crc-install.xml -v -r lib -r .  --build-package
liboo2c
- D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/pkginfo.xml
- D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/pkginfo.xml
- lib/src/liboo2c.Mod

... no apparent errors ...

- lib/sym/liboo2c.Doc
/bin/libtool --tag=CXX --mode=compile gcc -g -O2  -Ilib/src -Iobj -Ilib/obj
-I/usr/src/OO2C/oo2c_32-2.1.10/obj -I/usr/src/OO2C/oo2c_32-2.1.10/lib/obj -c
D:/Programme/Msys/1.0/src/OO2C/oo2c_32-2.1.10/lib/src/RT0.c -o
lib/obj/RT0.lo
make: *** [lib/obj/liboo2c.la] Error 1


Bernhard@JANUS /usr/src/OO2C/oo2c_32-2.1.10
$ libtool --version
ltmain.sh (GNU libtool) 1.4e (1.1162 2002/11/22 22:36:25)

Copyright 1996, 1997, 1998, 1999, 2000, 2001
Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Bernhard@JANUS /usr/src/OO2C/oo2c_32-2.1.10
$ gcc --version
gcc.exe (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[ooc-compiler] Fwd: SourceForge.net: CVS service offering changes

[Michael v. A. <mic...@gm...>]

For the people using SF CVS, either anonymous pserver or ssh:

---------- Forwarded message ----------
From: SourceForge.net Team <no...@so...>
Date: 12-May-2006 01:17
Subject: SUBJECT: SourceForge.net: CVS service offering changes
To: mic...@gm...

Greetings,

You are receiving this mail because you are a project admin for
a SourceForge.net-hosted project. One of our primary services,
CVS, suffered a series of interrelated, critical hardware failures
in recent weeks. We understand how frustrating this CVS outage
must be to you and your users; however, our top priority remains
preservation of the integrity of your data.

The series of CVS hardware failures prompted us to expedite the
deployment of planed improvements to our CVS infrastructure,
drawing upon much of the knowledge that we gained from our
Subversion deployment. Our improved CVS service architecture,
which we plan to deploy tomorrow afternoon (2006-05-12), will
offer greater performance and stability and will eliminate several
single points of failure.

The Site Status page (https://www.sf.net/docs/A04) will be
updated as soon as the new infrastructure is rolled out. In the
interim, please read the important information provided below
to learn about how these changes will affect your project.


Summary of changes, effective 2006-05-12:


1. Hostname for CVS service

Old: cvs.sourceforge.net

New: PROJECT_UNIX_NAME.cvs.sourceforge.net

This change will require new working copies to be checked out of all
repositories (so control files in the working copy will point to the
right place). We will be updating the instructions we supply, but
instructions that your team has written within documentation, etc. will
need to be updated.

cvs -d:pserver:ano...@cv...:/cvsroot/gaim co gaim

would be changed to

cvs -d:pserver:ano...@ga...:/cvsroot/gaim co gaim



2. ViewCVS

We are moving from ViewCVS to its successor, ViewVC. ViewVC is
currently in use for our Subversion service.



3. Sync delay

Old: CVS pserver, tarballs and ViewCVS provided against a separate
server which is a minimum of three hours behind developer CVS.

New: ViewVC will be provided against developer CVS (it will be current).
CVS pserver will be provided against a secondary server (not developer
server) with a maximum expected delay of two hours.

Follow-up work is planned (this infrastructure takes us 80% of the way)
to essentially eliminate the sync delay.



4. Read-only rsync service

As a new service offering, we are now providing read-only rsync access
against developer CVS. This allows projects to efficiently make
on-demand backups of their entire CVS repository.

All projects should be making regular backups of their CVS repository
contents using this service.



5. Nightly tarball service

Nightly tarball service is being dropped in lieu of read-only rsync
service. Projects which currently depend on nightly tarballs for
repository backups will need to begin using rsync to make a backup copy
of their repository contents.

We see this as a major functional improvement. For a number of reasons,
tarballs have fallen out of sync with the data in the repository at
times in the past few years. Tarballs required a substantial amount of
additional disk, and I/O to generate. The move to read-only rsync
allows backups to be produced on-demand, with an update frequency chosen
by the project.



6. Points of failure

In the past, developer CVS service for all projects was provided from a
single host. CVS pserver service was provided from individual backend
heads based on a split of the data.

Under our new design, developer CVS and most of our CVS-related services
are provided from one of ten CVS hosts (count subject to increase with
growth). Each host is independent, and makes a backup copy of the
repository data of another host (which is used to provide the pserver
CVS service).

Failure of a single host will impact only the availability of data on
that host. Since the data is split among a larger number of hosts, the
size of data impacted by an individual host outage is substantially
smaller, and the time required for us to restore service will be
substantially shorter.

This rapid architecture change has been made possible specifically using
the research we performed for our recent launch of Subversion service.
We've applied our best practices, produced a substantial amount of
internal documentation, and kept an eye toward maintainability.
This effort has allowed us to deploy this new architecture quickly
once hardware was received, and will permit us to quickly scale
this service horizontally as growth and demand requires.



Many other minor improvements have also been made to improve the service
offering and make it less trouble-prone. The most important of which are
listed above. For a full description of the new service offering, and
for information on how to use the services described above, please refer
to the site documentation for the CVS service after the service has been
launched: https://www.sf.net/docs/E04


Thank you,

The SourceForge.net Team

.

Re: [ooc-compiler] FOR Loops And Structured Variables

[August K. <fus...@co...>]

Frank Copeland wrote:
> August Karlstrom wrote:
> 
>> Why doesn't the following module compile?
>>
>>    MODULE Test;
>>       VAR a: ARRAY 1 OF LONGINT;
>>    BEGIN
>>       FOR a[0] := 0 TO 1 DO END
>>    END Test.
>>
>> I've read that in Modula, loop variables in FOR loops cannot come from 
>> structured variables, but I can't find that restriction in the 
>> Oberon-2 report. Anyway, what's the motivation for the restriction?
> 
> 
>  From the Oberon-2 Report:
> 
>     ForStatement = FOR ident ":=" Expression TO Expression
>                    [BY ConstExpression] DO StatementSequence END.
> 
> and 'ident' is defined as:
> 
>   1. Identifiers are sequences of letters and digits. The first character
>   must be a letter.
> 
>     ident = letter {letter | digit}.
> 
>   Examples:     x     Scan     Oberon2     GetSymbol     firstLetter
> 
> This obviously excludes structured variables as loop variables.

Yes of course, thanks.

> Motivation? You would have to ask Wirth or Gutnecht about that, but my 
> guess would be disbelief that anyone sensible would use anything other 
> than a simple integer variable as a loop variable.

OK.


Thanks,

August

Re: [ooc-compiler] FOR Loops And Structured Variables

[Frank C. <fj...@th...>]

August Karlstrom wrote:

> Why doesn't the following module compile?
> 
>    MODULE Test;
>       VAR a: ARRAY 1 OF LONGINT;
>    BEGIN
>       FOR a[0] := 0 TO 1 DO END
>    END Test.
> 
> I've read that in Modula, loop variables in FOR loops cannot come from 
> structured variables, but I can't find that restriction in the Oberon-2 
> report. Anyway, what's the motivation for the restriction?

 From the Oberon-2 Report:

     ForStatement = FOR ident ":=" Expression TO Expression
                    [BY ConstExpression] DO StatementSequence END.

and 'ident' is defined as:

   1. Identifiers are sequences of letters and digits. The first character
   must be a letter.

     ident = letter {letter | digit}.

   Examples:     x     Scan     Oberon2     GetSymbol     firstLetter

This obviously excludes structured variables as loop variables.

Motivation? You would have to ask Wirth or Gutnecht about that, but my guess 
would be disbelief that anyone sensible would use anything other than a 
simple integer variable as a loop variable.

-- 

TONY RANDALL!  Is YOUR life a PATIO of FUN??

[ooc-compiler] FOR Loops And Structured Variables

[August K. <fus...@co...>]

Hi,

Why doesn't the following module compile?

    MODULE Test;
       VAR a: ARRAY 1 OF LONGINT;
    BEGIN
       FOR a[0] := 0 TO 1 DO END
    END Test.

I've read that in Modula, loop variables in FOR loops cannot come from 
structured variables, but I can't find that restriction in the Oberon-2 
report. Anyway, what's the motivation for the restriction?


Regards,

August

Re: [ooc-compiler] H20 bugs

[Stewart G. <sgr...@ii...>]

Hi Frank,

> The glib library headers use an idiom that looks like this:
> 
>   typedef struct _GStaticMutex GStaticMutex;
>   struct _GStaticMutex
>   {
>     struct _GMutex *runtime_mutex;
>     union {
>       char   pad[24];
>       double dummy_double;
>       void  *dummy_pointer;
>       long   dummy_long;
>     } static_mutex;
>   };
> 
> As far as I can tell from the documentation, the leading underscore 
> means the _GStaticMutex type is meant to be "opaque", presumably meaning 
> its record fields should not be exported. However, this is simply a 
> matter of convention and is not the real problem.

I think its done to ensure that the names used in structs and typedefs 
don't collide. From memory, I think the C spec requires separate 
name-spaces, but there may be compilers that don't do this. There 
doesn't seem to be a consistent convention. In WIN32, structure tags are 
prefixed with "tag", rather than "_".

> The code produced by TestH2O looks like this:
> 
> TYPE
>   _GStaticMutex_tag* = RECORD
>     runtime_mutex* : POINTER TO _GMutex_tag;
>     static_mutex* : RECORD [UNION]
>       pad* : ARRAY 24 OF CHAR;
>       dummy_double* : LONGREAL;
>       dummy_pointer* : SYSTEM.PTR;
>       dummy_long* : LONGINT;
>     END;
>   END;
>   _GMutex_tag* = RECORD END;
>   _GStaticMutex_tag* = RECORD END;
>   GStaticMutex* = RECORD END;
> 
> Naturally this doesn't compile.

Yes, that looks like H2O has got something wrong. In your code, struct 
_GMutex is opaque but there is an error in the declaration of 
GStaticMutex. When GStaticMutex is declared, _GStaticMutex is opaque but 
that should not matter. It should have output just:
   GStaticMutex* = _GStaticMutex_tag;

I'll take a look at what's wrong. Thanks too for your patch, which I'll 
add to the CVS version.

Cheers,
   Stewart

[ooc-compiler] H20 bugs

[Frank C. <fj...@th...>]

I'd offer a patch for this but I can't get my head around the source well 
enough to understand what's going on.

The glib library headers use an idiom that looks like this:

   typedef struct _GStaticMutex GStaticMutex;
   struct _GStaticMutex
   {
     struct _GMutex *runtime_mutex;
     union {
       char   pad[24];
       double dummy_double;
       void  *dummy_pointer;
       long   dummy_long;
     } static_mutex;
   };

As far as I can tell from the documentation, the leading underscore means 
the _GStaticMutex type is meant to be "opaque", presumably meaning its 
record fields should not be exported. However, this is simply a matter of 
convention and is not the real problem.

The code produced by TestH2O looks like this:

TYPE
   _GStaticMutex_tag* = RECORD
     runtime_mutex* : POINTER TO _GMutex_tag;
     static_mutex* : RECORD [UNION]
       pad* : ARRAY 24 OF CHAR;
       dummy_double* : LONGREAL;
       dummy_pointer* : SYSTEM.PTR;
       dummy_long* : LONGINT;
     END;
   END;
   _GMutex_tag* = RECORD END;
   _GStaticMutex_tag* = RECORD END;
   GStaticMutex* = RECORD END;

Naturally this doesn't compile.

-- 

Do not open shrink-wrap until you have read and agreed to the conditions
contained within.

[ooc-compiler] H20 patch

[Frank C. <fj...@th...>]

I'd submit this through sourceforge but I can't work out how. Bugzilla has 
always confused me...

The attached patch addresses two issues:

* Adds "/usr/include" and "/usr/local/include" to the default search paths
* Treats single-character strings as strings instead of characters unless 
they are delimited by the "'" character. This is still not even close to 
standard C definitions of string and character constants.

-- 

Freedom of the press is for those who happen to own one.

Re: AW: [ooc-compiler] CVS access problem

[Frank C. <fj...@th...>]

tim...@ma... wrote:

> In such cases you should look at 
> 
> http://sourceforge.net/docs/A04/
> 
> ,too. Since there are regular downtimes. In this cases everything seems to
> be OK, however :-/

Been there already.

> I can also assure that I was able to access my repository around 4 hours
> ago.

I've succeeded in updating now, but only after several attempts. Persistance 
seems to be the key.

-- 

Better to use medicines at the outset than at the last moment.

AW: [ooc-compiler] CVS access problem

[<tim...@ma...>]

Hallo!

In such cases you should look at=20

http://sourceforge.net/docs/A04/

,too. Since there are regular downtimes. In this cases everything seems =
to
be OK, however :-/

I can also assure that I was able to access my repository around 4 =
hours
ago.

--=20
Gru=C3=9F...=20
       Tim.

[ooc-compiler] CVS access problem

[Frank C. <fj...@th...>]

I've been trying to update from CVS all day and keep getting this error message:

fjc@wossname:~/dev/oberon/ooc2/cvs/ooc2$ cvs update -dP
cvs [update aborted]: end of file from server (consult above messages if any)

fjc@wossname:~/dev/oberon/ooc2/cvs/ooc2$ cat CVS/Root
:pserver:ano...@cv...:/cvsroot/ooc

fjc@wossname:~/dev/oberon/ooc2/cvs/ooc2$ cat ~/.cvspass | grep ooc
:pserver:ano...@cv...:/cvsroot/ooc A

Do I just wait until sourceforge fixes whatever is causing it?

-- 

<doogie> cat /dev/random | perl ?
<shaleh> doogie: it is also a valid sendmail.cf
<doogie> :)
* knghtbrd hands doogie a senseless-use-of-cat award
* shaleh wants to try it but is afraid

Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Stewart G. <sgr...@ii...>]

Michael van Acken wrote:
>[...]
> All checkins beneath the new directory only affect the branch,
> not the CVS head.
> 
> For more information on CVS and branching I recommend the
> "CVS Branch and Tag Primer" at
> http://www.psc.edu/~semke/cvs_branches.html

Thanks. I'll give it a try.

Cheers,
   Stewart

Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Michael v. A. <mic...@gm...>]

On 19/01/06, Stewart Greenhill <sgr...@ii...> wrote:
>
> [...] OK. Please go ahead with it. That name is fine with me.


I've done a

  cvs tag -b oo2c-branch-cpp ooc2


You need to do

  cvs co -r oo2c-branch-cpp ooc2

to get a working copy in the (new) directory ooc2 that is "tuned"
to this branch.  You can recognize it by its "Tag" file:

$ cat ooc2/CVS/Tag
Too2c-branch-cpp

All checkins beneath the new directory only affect the branch,
not the CVS head.

For more information on CVS and branching I recommend the
"CVS Branch and Tag Primer" at
http://www.psc.edu/~semke/cvs_branches.html

-- mva

Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Frank C. <fj...@th...>]

Stewart Greenhill wrote:

>>> I'm interested in being able to use existing C++ APIs from Oberon-2.
>>
>>
>> It would certainly broaden the options available. There are some C++ 
>> APIs I have an interest in.
> 
> 
> Did you have anything special in mind? I'm particularly interested in 
> GUI/application toolkits. There are lots of these around for C++ (eg. 
> wxWidgets, FLTK, Qt, JUCE), but only relatively few for C.

GUI/application stuff to a certain extent, although gtk+ looks like a pretty 
solid option in C. I'm also interested in 3D rendering engines which are 
mostly (but not all) C++.

-- 

Volley Theory:
	It is better to have lobbed and lost than never to have lobbed at all.

Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Stewart G. <sgr...@ii...>]

Stewart Greenhill wrote:
>> Would it not be simpler to have OOC mangle the symbol names the same 
>> way as the C++ compiler? I realise that is compiler-dependant and I 
>> believe g++ broke ABI recently by changing the mangling algorithm. 
>> Even so the algorithms should be reasonably easy to discover 
>> (especially for g++). There would remain the issue of telling OOC 
>> which algorithm to use.
> 
> 
> I suppose that might work. Within the current oo2c implementation it 
> would need to be possible to access the mangled symbols from C code. I'm 
> not sure if that's possible - presumably the compiler writers take steps 
> to prevent the mangled names colliding with the mangled symbols. 

Ooops! What I meant was that the compiler should prevent "C" names 
colliding with the mangled symbols.

> Certainly, it would be possible at the asm/linker level.

Looks like for GCC it is possible from "C". Given this definition:

class Test {
	int add(int a, int b);
};

int Test::add(int a, int b) {
	return a + b;
}

The compiler generates a symbol named "__ZN1T3addEii". With the 
appropriate definition, this can be called from "C":

#include <stdio.h>

extern int _ZN1T3addEii(void * obj, int a, int b);

int main(int argc, char ** argv) {
	printf("test -> %d\n", _ZN1T3addEii(NULL, 2, 3));
}

Some compiler mangle the names using symbols that are not valid within C 
identifiers, which would prevent this approach from working. See some 
examples here:
http://en.wikipedia.org/wiki/Name_mangling#How_different_compilers_mangle_the_same_functions

Cheers,
   Stewart

Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Stewart G. <sgr...@ii...>]

Hi Michael,

Michael van Acken wrote:
> On 18/01/06, Stewart Greenhill <sgr...@ii...> wrote:
>>Michael van Acken wrote:
>>>[...]
>>>My suggestion is that we create a branch in the oo2c CVS that
>>>incorporates your changes and that serves as a public meeting
>>>point for work on the extension.
>>
>>That sounds like a good approach, since I'll probably have to change
>>quite a few things to get it working. I haven't used CVS branches
>>before. Do you know how it works at sourceforge? Can anyone create a
>>branch, or does one have to be the admin?
> 
> In theory, everyone should be able to do this.  But having created
> quite some branches lately, let me have a go.  I need a name for
> the beast, though.  Is "oo2c-branch-cpp" ok with you?  Or would
> you prefer something more descriptive?

OK. Please go ahead with it. That name is fine with me.

Cheers,
   Stewart

Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Michael v. A. <mic...@gm...>]

On 18/01/06, Stewart Greenhill <sgr...@ii...> wrote:
>
> Michael van Acken wrote:
>
> > [...]
> > My suggestion is that we create a branch in the oo2c CVS that
> > incorporates your changes and that serves as a public meeting
> > point for work on the extension.
>
> That sounds like a good approach, since I'll probably have to change
> quite a few things to get it working. I haven't used CVS branches
> before. Do you know how it works at sourceforge? Can anyone create a
> branch, or does one have to be the admin?



In theory, everyone should be able to do this.  But having created
quite some branches lately, let me have a go.  I need a name for
the beast, though.  Is "oo2c-branch-cpp" ok with you?  Or would
you prefer something more descriptive?

-- mva

Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Stewart G. <sgr...@ii...>]

Hi Frank,

>> I'm interested in being able to use existing C++ APIs from Oberon-2.
> 
> It would certainly broaden the options available. There are some C++ 
> APIs I have an interest in.

Did you have anything special in mind? I'm particularly interested in 
GUI/application toolkits. There are lots of these around for C++ (eg. 
wxWidgets, FLTK, Qt, JUCE), but only relatively few for C.

>> Currently, oo2c has a limited ability to call methods of C++ objects. 
>> When one declares a record with the VTABLE flag, oo2c builds a 
>> C++-style virtual method table for all instantiated objects, and calls 
>> methods of that object via VTABLE dispatch. This means (for example) 
>> that you can call methods of COM interfaces, and even implement your 
>> own COM objects.
>>
>> This is fine if one follows a design methodology like COM, which 
>> ensures that there is a language-independent binary interface to your 
>> API. COM uses abstract interfaces and VTABLE method dispatch. It also 
>> has a language-independent type mechanism (ie. 
>> IUnknown::QueryInterface). Unfortunately, most C++ coders seem 
>> completely uninterested in language interoperability. The biggest 
>> obstacle with existing C++ APIs is the use of static (ie. non-virtual) 
>> methods. Its only really possible to call these methods from a C++ 
>> compiler, since the symbol names are mangled to include type information.
>>
>> The approach that I'm proposing is to:
>>
>> 1) Introduce a [STATIC] method flag. This causes calls to methods to 
>> be dispatched statically, rather than using type-descriptor lookup.
>>
>> 2) Write (by hand, or automatically) a FOREIGN implementation that can 
>> be processed by the C++ compiler. This dispatches method calls to the 
>> C++ objects.
> 
> 
> Would it not be simpler to have OOC mangle the symbol names the same way 
> as the C++ compiler? I realise that is compiler-dependant and I believe 
> g++ broke ABI recently by changing the mangling algorithm. Even so the 
> algorithms should be reasonably easy to discover (especially for g++). 
> There would remain the issue of telling OOC which algorithm to use.

I suppose that might work. Within the current oo2c implementation it 
would need to be possible to access the mangled symbols from C code. I'm 
not sure if that's possible - presumably the compiler writers take steps 
to prevent the mangled names colliding with the mangled symbols. 
Certainly, it would be possible at the asm/linker level.

There's another advantage of the wrapper approach, which is that one 
does not need to know about the calling conventions of the wrapped 
function in order to call it from client modules. At least under 
Windows, there are different calling conventions possible (eg. stdcall, 
cdecl, fastcall). It should even work for macros and functions that 
would normally be "inlined".

There are a few other issues that I think could also be addressed within 
the same wrapper framework. One problem that I've hit before is that 
many APIs (even "C" APIs) pass small records by value. For example, GSL 
does this for complex numbers, and OpenCV does it for image dimensions. 
In the past I've solved this by manually writing a wrapper function that 
accepts a record by reference, and then dereferences the pointer in the 
function call. It would be nice to get an easier solution to this 
problem too.

Cheers,
   Stewart

Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Stewart G. <sgr...@ii...>]

Michael van Acken wrote:

> [...]
> My suggestion is that we create a branch in the oo2c CVS that
> incorporates your changes and that serves as a public meeting
> point for work on the extension.

That sounds like a good approach, since I'll probably have to change 
quite a few things to get it working. I haven't used CVS branches 
before. Do you know how it works at sourceforge? Can anyone create a 
branch, or does one have to be the admin?

Cheers,
   Stewart

Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods

[Michael v. A. <mic...@gm...>]

On 12/01/06, Stewart Greenhill <sgr...@ii...> wrote:
>
> Hi Folks,
>
> I'm interested in being able to use existing C++ APIs from Oberon-2.

[...]

Because I am still a C++ illiterate, I cannot comment on the merits
of your proposal.

My suggestion is that we create a branch in the oo2c CVS that
incorporates your changes and that serves as a public meeting
point for work on the extension.

-- mva

[Fwd: Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods]

[Frank C. <fj...@th...>]

-------- Original Message --------
Subject: Re: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods
Date: Tue, 17 Jan 2006 21:31:08 +1100
From: Frank Copeland <fj...@th...>
To: Stewart Greenhill <sgr...@ii...>
References: <43C...@ii...>

Stewart Greenhill wrote:

> I'm interested in being able to use existing C++ APIs from Oberon-2.

It would certainly broaden the options available. There are some C++ APIs I
have an interest in.

> Currently, oo2c has a limited ability to call methods of C++ objects. 
> When one declares a record with the VTABLE flag, oo2c builds a C++-style 
> virtual method table for all instantiated objects, and calls methods of 
> that object via VTABLE dispatch. This means (for example) that you can 
> call methods of COM interfaces, and even implement your own COM objects.
> 
> This is fine if one follows a design methodology like COM, which ensures 
> that there is a language-independent binary interface to your API. COM 
> uses abstract interfaces and VTABLE method dispatch. It also has a 
> language-independent type mechanism (ie. IUnknown::QueryInterface). 
> Unfortunately, most C++ coders seem completely uninterested in language 
> interoperability. The biggest obstacle with existing C++ APIs is the use 
> of static (ie. non-virtual) methods. Its only really possible to call 
> these methods from a C++ compiler, since the symbol names are mangled to 
> include type information.
> 
> The approach that I'm proposing is to:
> 
> 1) Introduce a [STATIC] method flag. This causes calls to methods to be 
> dispatched statically, rather than using type-descriptor lookup.
> 
> 2) Write (by hand, or automatically) a FOREIGN implementation that can 
> be processed by the C++ compiler. This dispatches method calls to the 
> C++ objects.

Would it not be simpler to have OOC mangle the symbol names the same way as
the C++ compiler? I realise that is compiler-dependant and I believe g++
broke ABI recently by changing the mangling algorithm. Even so the
algorithms should be reasonably easy to discover (especially for g++). There
would remain the issue of telling OOC which algorithm to use.

-- 

This sentence contradicts itself -- no actually it doesn't.
		-- Douglas Hofstadter

-- 

Politics are almost as exciting as war, and quite as dangerous.  In war,
you can only be killed once.
		-- Winston Churchill

[ooc-compiler] Re: ooc-compiler digest, Vol 1 #249 - 1 msg

[Michael G. <mg...@co...>]

ooc...@li... wrote:

>Send ooc-compiler mailing list submissions to
>	ooc...@li...
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>or, via email, send a message with subject or body 'help' to
>	ooc...@li...
>
>You can reach the person managing the list at
>	ooc...@li...
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of ooc-compiler digest..."
>
>
>Today's Topics:
>
>   1. PROPOSAL: Interface to C++ objects and methods (Stewart Greenhill)
>
>--__--__--
>
>Message: 1
>Date: Thu, 12 Jan 2006 17:10:09 +0800
>From: Stewart Greenhill <sgr...@ii...>
>To:  ooc...@li...
>Subject: [ooc-compiler] PROPOSAL: Interface to C++ objects and methods
>
>Hi Folks,
>
>I'm interested in being able to use existing C++ APIs from Oberon-2.
>
>Currently, oo2c has a limited ability to call methods of C++ objects. 
>When one declares a record with the VTABLE flag, oo2c builds a C++-style 
>virtual method table for all instantiated objects, and calls methods of 
>that object via VTABLE dispatch. This means (for example) that you can 
>call methods of COM interfaces, and even implement your own COM objects.
>
>This is fine if one follows a design methodology like COM, which ensures 
>that there is a language-independent binary interface to your API. COM 
>uses abstract interfaces and VTABLE method dispatch. It also has a 
>language-independent type mechanism (ie. IUnknown::QueryInterface). 
>Unfortunately, most C++ coders seem completely uninterested in language 
>interoperability. The biggest obstacle with existing C++ APIs is the use 
>of static (ie. non-virtual) methods. Its only really possible to call 
>these methods from a C++ compiler, since the symbol names are mangled to 
>include type information.
>
>The approach that I'm proposing is to:
>
>1) Introduce a [STATIC] method flag. This causes calls to methods to be 
>dispatched statically, rather than using type-descriptor lookup.
>
>2) Write (by hand, or automatically) a FOREIGN implementation that can 
>be processed by the C++ compiler. This dispatches method calls to the 
>C++ objects.
>
>I'll try to illustrate this by means of an example. Suppose we have a 
>simple C++ library:
>
>-- Foreign.h --
>class T {
>public:
>	virtual void Virtual(void);
>	void Static(void);
>};
>-- end Foreign.h --
>
>-- Foreign.cpp --
>#include <stdio.h>
>#include "Foreign.h"
>
>void T::Virtual(void) {
>	printf("T::Virtual\n");
>}
>
>void T::Static(void) {
>	printf("T::Static\n");
>}
>-- end Foreign.cpp --
>
>Using a VTABLE declaration, I can call method "Virtual", but not method 
>"Static". Now OOC already has a concept of static methods. A method is 
>called statically (ie. without using a type-descriptor method lookup) if 
>it is known not to be overridden, or if it is a special predefined 
>method like INIT. I'm proposing to add a "STATIC" procedure flag, which 
>specifies that a method is to be treated as a static method (ie. it has 
>procClass = staticMethod) rather than a virtual method. The address of 
>the method is always based on an objects static type.
>
>This allows us to write:
>
>-- ForeignStatic.Mod --
>MODULE ForeignStatic [ FOREIGN "C"; LINK FILE "ForeignStatic.cpp"; LIB 
>"foreign"; LIB "stdc++" END ];
>
>TYPE
>   TDesc* = RECORD [VTABLE] END;
>   T* = POINTER TO TDesc;
>
>PROCEDURE (t : T) Virtual*;
>
>PROCEDURE (t : T) [STATIC] Static*;
>
>PROCEDURE NewT* () : T;
>
>END ForeignStatic.
>-- end ForeignStatic.Mod --
>
>Now to make things work, we need the FOREIGN implementation. For the 
>above library, it looks like this:
>
>-- ForeignStatic.cpp --
>#include "Foreign.h"
>extern "C" {
>#include <ForeignStatic.d>
>#include <__oo2c.h>
>#include <setjmp.h>
>
>void ForeignStatic__TDesc_Virtual(ForeignStatic__T t) {
>   ((T*) t)->Virtual();
>}
>
>void ForeignStatic__TDesc_Static(ForeignStatic__T t) {
>   ((T*) t)->Static();
>}
>
>void OOC_ForeignStatic_init(void) {
>
>   return;
>   ;
>}
>
>void OOC_ForeignStatic_destroy(void) {
>}
>
>ForeignStatic__TDesc* ForeignStatic__NewT(void) { return 
>(ForeignStatic__TDesc *) new T(); }
>
>}
>/* --- */
>-- end ForeignStatic.cpp --
>
>To generate this, I compiled a "stub" module using oo2c, and manually 
>inserted a few things.
>- Included the header for the C++ library.
>- The "extern C" is necessary so that the C++ compiler does not mangle 
>the symbol names.
>- Inserted dispatch statements in any methods that are to be called 
>statically. Actually, "Virtual" is alreadly dispatched by OOC through 
>the VTABLE, but I could have allowed C++ to do the virtual dispatch here 
>by declaring it STATIC.
>- Inserted a constructor.
>
>This allows one to do this sort of thing:
>
>-- TestForeignStatic.Mod --
>MODULE TestForeignStatic;
>
>IMPORT ForeignStatic;
>
>PROCEDURE TestForeignStatic1;
>VAR t : ForeignStatic.T;
>BEGIN
>   t := ForeignStatic.NewT();
>   t.Virtual;
>   t.Static;
>END TestForeignStatic1;
>
>BEGIN
>   TestForeignStatic1;
>END TestForeignStatic.
>-- end TestForeignStatic.Mod --
>
>That is, I can call virtual or static methods of objects as if they are 
>native objects. Note that I don't need to change the calling conventions 
>used within OOC. It already handles virtual and static dispatch. The 
>wrapper functions simply redirect the method dispatch using the host 
>compiler.
>
>Anyway, with a bit of fiddling I managed to get it to work. The STATIC 
>flag was easy to implement, but it would be nice if this process could 
>be streamlined somehow. Ideally, the FOREIGN wrapper implementation 
>should be generated automatically by OO2C. This should not be hard to do 
>- If we can get some consensus regarding how it should work I'm willing 
>to have a go at it. Since the wrapper requires the use of 
>implementation-specific symbol names and structures it would make sense 
>for the compiler to provide this feature, rather than an external tool.
>
>1) There would need to be a declaration that this is a special type of 
>FOREIGN module (eg. "WRAPPER", or "PROXY"?). Records declared within are 
>assumed to have no type descriptors. Stub procedures are generated that 
>dispatch methods in the host ("C++") language.
>
>2) There should be a list of headers to include at the top of the object 
>file.
>
>3) For each record type, we need an optional "link name" saying what the 
>proxy C++ type is called. This would be used to generate the type casts 
>in the wrapper methods.
>
>4) For each method, we need an optional "link name" saying what the 
>method of the proxy C++ type is called. In the case of an overloaded 
>method, there will be multiple Oberon-2 names that map to the same C++ name.
>
>5) There would need to be a way of declaring constructors which would be 
>dispatched via new().
>
>What do people think about these issues? Any suggestions, or violent 
>objections? ;-)
>
>Cheers,
>   Stewart
>
>  
>
Nice concept.  I was thinking about a C++ interface at one point but 
didn't get very far since I didn't know much about the C++ name 
mangling.  Your approach look like it would solve this problem.

Michael G.