ooc-compiler

Re: [ooc-compiler] Foreign module compilation

[Frank H. <fh...@ph...>]

Tim Teulings wrote:
> So you try to use your FOREIGN module as application main module? 
> Possibly oo2c canot handle it. Try to make a separate, "normal" module 
> that imports your FOREIGn module and use that as program module.

Did that and reduced all files to a minimum. Now my actual directory 
contains an executable module test.Mod which imports the foreign module 
Serial.Mod, the implementation of which is Serial.c:

test.Mod:
---------
MODULE test;
IMPORT Serial;
BEGIN Serial.Open ("1");
END test.

Serial.Mod:
-----------
MODULE Serial [FOREIGN "C"; LINK FILE "Serial.c" END];
PROCEDURE Open* (p:CHAR);
END Serial.

Serial.c:
---------
#include <Serial.oh>
/* run-time meta data */
static RT0__ModuleDesc _mid;
static RT0__ModuleDesc _mid = { (OOC_CHAR8*)"Serial", (RT0__Struct[]) { 
NULL } };
extern void OOC_Serial_init0() {
   RT0__RegisterModule(&_mid);
   OOC_Serial_init();
}
/* --- */
#include <__oo2c.h>
#include <setjmp.h>
#include <stdio.h>

void Serial__Open(OOC_CHAR8 p) {
   printf("Open!\n");
   return;
   ;
}

void OOC_Serial_init(void) {

   return;
   ;
}

/* --- */


"oo2c -AMv test.Mod" gets me:
------------------------------------
- /usr/local/lib/oo2c/pkginfo.xml
- sym/test.Sym
- /usr/local/lib/oo2c/sym/RT0.Sym
- /usr/local/lib/oo2c/sym/Object.Sym
- /usr/local/lib/oo2c/sym/HashCode.Sym
- /usr/local/lib/oo2c/sym/Exception.Sym
- sym/Serial.Sym
gcc -O2 -I/usr/local/include -DGC_WIN32_THREADS 
-I/usr/local/lib/oo2c/src -Iobj -I/usr/local/lib/oo2c/obj
-c /Documents and Settings/Frank/Documents/Test/Serial.c
-o obj/Serial.o
gcc: cannot specify -o with -c or -S and multiple compilations
-------------------------------------

I allways get such a gcc error message, whether I compile with or 
without -A, upon compilation of test.Mod as well as Serial.Mod.

Still any idea?
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA
Florianopolis, SC
88030-000
Brasil

Re: [ooc-compiler] Foreign module compilation

[Tim T. <Tim...@ma...>]

Hallo!

> I followed the steps for creating a Foreign module as described in
> OOCRef, except the last one, so the procedure bodies of the C file are
> still empty. Mod and C file (SerialIF.Mod, SerialIF.c) are in the same
> directory. Exection of
>=20
>   oo2c -M SerialIF.Mod
>=20
> from this directory results in
>=20
>   gcc: cannot specify -o with -c or -S and multiple compilations
>=20
> So: What options do I have to call oo2c with? Or do I have to compile
> the C file first with gcc? With what options?

So you try to use your FOREIGN module as application main module?=20
Possibly oo2c canot handle it. Try to make a separate, "normal" module=20
that imports your FOREIGn module and use that as program module.

--=20
Gru=DF...
        Tim.

[ooc-compiler] Foreign module compilation

[Frank H. <fh...@ph...>]

I followed the steps for creating a Foreign module as described in
OOCRef, except the last one, so the procedure bodies of the C file are
still empty. Mod and C file (SerialIF.Mod, SerialIF.c) are in the same
directory. Exection of

   oo2c -M SerialIF.Mod

from this directory results in

   gcc: cannot specify -o with -c or -S and multiple compilations

So: What options do I have to call oo2c with? Or do I have to compile
the C file first with gcc? With what options?

(My platform: Win32/MinGW; oo2c: 2.1.1)
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA
Florianopolis, SC
88030-000
Brasil




-- 
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA	email: fh...@ph...
Florianopolis, SC		WWW:   www.photonita.com.br
88030-000
Brasil

Re: [ooc-compiler] Oberon-2 standard

[Michael v. A. <Mic...@de...>]

"August" <fus...@sp...> writes:

> Concerning the posting from Gregory Gelfond and the answer from Michael van
> Acken
> 
> > ...
> > In general, the resemblance between the libraries of oo2c and the
> > original documentation of the Oberon System is superficial.
> > ...
> 
> Wouldn't it be (very) desirable to make OOC conform to the Oakwood
> guidelines at least when it comes to the basic libraries? As stated in the
> report:
> 
> "The intention is that all implementors should offer support for Oberon-2 to
> at least the ETH specification standard and also offer an implementation of
> the basic library modules."

I dropped the Oakwood modules from the compiler distribution 1.5 years
back and nobody seems to mind.  In all this time, you are the first to
raise that topic.

> I must say that even if the OOC version of the IO functionality etc. is more
> efficient, I find the idea of redefining the interface of some of those
> standard modules a bit strange (I don't think anyone would ship a C-compiler
> with a library header named `stdio.h' that differs from the standard ansi
> `stdio.h' specification).

Comparing the Oakwood guidelines to one of the ISO C standards is a
bit far fetched, isn't it?  Putting them side by side, even the
difference in sheer paper weight should be most impressive.  Don't get
too impressed with the word "standard".  Oberon (which was hardware,
operating system, and programming language in the beginning) was, and
probably still is, a vehicle for research and teaching -- but not for
"standards".

> Why not call the non-compatible modules OOCFiles, OOCIn etc or
> something completely different? One risk with the current modules is
> also that users may think they are using standard libraries since
> the names coincide. Another solution would be to make the OOC
> version of each of these modules a true superset of the
> corresponding standard module and then require a special compiler
> option to allow the extra functionality.

All programms I have seen that were both Oakwood compatible and
portable were either student exercises or toy programs.  To have a
program that runs both on the original Oberon System and in an
environment like Unix is a challenge.  Take for example command line
arguments, interactive input, and long running programs.  OS has no
command line, and it (and the Oakwood modules) has no idea of command
line arguments.  Interactive input is also a different thing in an
environment where modal dialog is the exception and contrary to the
basic design.  And long running programs either grab the system
completely or must arrange themselves with the OS task system (not
covered by Oakwood).

It is pretty safe to assume that there are very few users that program
for the Oakwood guidelines.  On the other hand, if you want to target
that particular niche of the Oberon crowd, you can always put together
a compiler distribution that offers only Oakwood modules with
appropriate names and functionality.  With the exception of a small
number of modules that essentially constitute the compiler's run-time
system, all modules that make up the basic library can be removed or
replaced.

-- mva

[ooc-compiler] Oberon-2 standard

[August <fus...@sp...>]

Concerning the posting from Gregory Gelfond and the answer from Michael van
Acken

> ...
> In general, the resemblance between the libraries of oo2c and the
> original documentation of the Oberon System is superficial.
> ...

Wouldn't it be (very) desirable to make OOC conform to the Oakwood
guidelines at least when it comes to the basic libraries? As stated in the
report:

"The intention is that all implementors should offer support for Oberon-2 to
at least the ETH specification standard and also offer an implementation of
the basic library modules."

I must say that even if the OOC version of the IO functionality etc. is more
efficient, I find the idea of redefining the interface of some of those
standard modules a bit strange (I don't think anyone would ship a C-compiler
with a library header named `stdio.h' that differs from the standard ansi
`stdio.h' specification). Why not call the non-compatible modules OOCFiles,
OOCIn etc or something completely different? One risk with the current
modules is also that users may think they are using standard libraries since
the names coincide. Another solution would be to make the OOC version of
each of these modules a true superset of the corresponding standard module
and then require a special compiler option to allow the extra functionality.

-- August


----- Original Message ----- 
From: "Michael van Acken" <Mic...@de...>
To: "Gregory Gelfond" <gre...@tt...>
Cc: "OOC Compiler List" <ooc...@li...>
Sent: Wednesday, May 26, 2004 9:47 PM
Subject: Re: [ooc-compiler] Help With I/O


> Gregory Gelfond <gre...@tt...> writes:
>
> > Hello All,
> >
> > I am completely new to Oberon, and am attempting to learn the language.
I
> > understand the basics of the language as described in Wirth's book, but
am
> > having some difficulty in learning the oo2c library.  I have the
following
> > program:
> >
> > MODULE DisplayFile;
> > [...]
> >
> > I have several difficulties running this program.  The program displays
the
> > contents of the file "HelloWorld.Mod", with the exception of the last
line.
> > How can I specify the termination condition of the loop to read "While
not
> > end of file do"?
>
> Using your program (plus fix), I see all the lines from the input file
> duplicated to stdout -- as expected.  "WHILE res=done DO" should
> definitely work.
>
> > Also, can someone explain the meaning of the third parameter 'res' of
the
> > Files.Old function call?
>
> Opening the file may file.  A "res#done" indicates an error.  This
> should be checked.  For example, when I started your program without
> providing the input file, I got a seg fault because `file' was NIL.
> `res' would indicate a "file not found" error.
>
> > Furthermore, in Wirth's book, the I/O functions that are described
differ
> > from those present in the oo2c library.  Am I correct in understanding
that
> > these are the ones defined in the Oakwood modules?  If so, what are the
> > benefits/drawbacks of one over the other?
>
> In general, the resemblance between the libraries of oo2c and the
> original documentation of the Oberon System is superficial.  By
> necessity, any I/O library put on top of the standard C/POSIX library
> needs to decide whether to implement its own view of the world, or to
> provide a faithful representation of the low-level functions of the
> operating system (or C library).  In a way, the Wirth I/O functions
> _are_ the operating system.  OOC leans more in the direction of the
> operating system it is using, which is represented by the I/O
> functions of C.  For example, the v2 compiler comes with a set of
> low-level IO modules (like IO:FileChannel and IO:SocketChannel) that
> are essentially one-to-one interfaces to C's open(), read(), write(),
> etc.
>
> As for Oakwood: The v1 compiler distribution has a set of Oak* modules
> that are closer to the original Oberon System modules.
>
> -- mva
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>
>

[ooc-compiler] Oberon-2 standard

[August <fus...@sp...>]

Concerning the posting from Gregory Gelfond and the answer from Michael van
Acken

> ...
> In general, the resemblance between the libraries of oo2c and the
> original documentation of the Oberon System is superficial.
> ...

Wouldn't it be (very) desirable to make OOC conform to the Oakwood
guidelines at least when it comes to the basic libraries? As stated in the
report:

"The intention is that all implementors should offer support for Oberon-2 to
at least the ETH specification standard and also offer an implementation of
the basic library modules."

I must say that even if the OOC version of the IO functionality etc. is more
efficient, I find the idea of redefining the interface of some of those
standard modules a bit strange (I don't think anyone would ship a C-compiler
with a library header named `stdio.h' that differs from the standard ansi
`stdio.h' specification). Why not call the non-compatible modules OOCFiles,
OOCIn etc or something completely different? One risk with the current
modules is also that users may think they are using standard libraries since
the names coincide. Another solution would be to make the OOC version of
each of these modules a true superset of the corresponding standard module
and then require a special compiler option to allow the extra functionality.

-- August


----- Original Message ----- 
From: "Michael van Acken" <Mic...@de...>
To: "Gregory Gelfond" <gre...@tt...>
Cc: "OOC Compiler List" <ooc...@li...>
Sent: Wednesday, May 26, 2004 9:47 PM
Subject: Re: [ooc-compiler] Help With I/O


> Gregory Gelfond <gre...@tt...> writes:
>
> > Hello All,
> >
> > I am completely new to Oberon, and am attempting to learn the language.
I
> > understand the basics of the language as described in Wirth's book, but
am
> > having some difficulty in learning the oo2c library.  I have the
following
> > program:
> >
> > MODULE DisplayFile;
> > [...]
> >
> > I have several difficulties running this program.  The program displays
the
> > contents of the file "HelloWorld.Mod", with the exception of the last
line.
> > How can I specify the termination condition of the loop to read "While
not
> > end of file do"?
>
> Using your program (plus fix), I see all the lines from the input file
> duplicated to stdout -- as expected.  "WHILE res=done DO" should
> definitely work.
>
> > Also, can someone explain the meaning of the third parameter 'res' of
the
> > Files.Old function call?
>
> Opening the file may file.  A "res#done" indicates an error.  This
> should be checked.  For example, when I started your program without
> providing the input file, I got a seg fault because `file' was NIL.
> `res' would indicate a "file not found" error.
>
> > Furthermore, in Wirth's book, the I/O functions that are described
differ
> > from those present in the oo2c library.  Am I correct in understanding
that
> > these are the ones defined in the Oakwood modules?  If so, what are the
> > benefits/drawbacks of one over the other?
>
> In general, the resemblance between the libraries of oo2c and the
> original documentation of the Oberon System is superficial.  By
> necessity, any I/O library put on top of the standard C/POSIX library
> needs to decide whether to implement its own view of the world, or to
> provide a faithful representation of the low-level functions of the
> operating system (or C library).  In a way, the Wirth I/O functions
> _are_ the operating system.  OOC leans more in the direction of the
> operating system it is using, which is represented by the I/O
> functions of C.  For example, the v2 compiler comes with a set of
> low-level IO modules (like IO:FileChannel and IO:SocketChannel) that
> are essentially one-to-one interfaces to C's open(), read(), write(),
> etc.
>
> As for Oakwood: The v1 compiler distribution has a set of Oak* modules
> that are closer to the original Oberon System modules.
>
> -- mva
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>
>

Re: [ooc-compiler] Help With I/O

[Michael v. A. <Mic...@de...>]

Gregory Gelfond <gre...@tt...> writes:

> Hello All,
> 
> I am completely new to Oberon, and am attempting to learn the language.  I
> understand the basics of the language as described in Wirth's book, but am
> having some difficulty in learning the oo2c library.  I have the following
> program:
> 
> MODULE DisplayFile;
> [...]
> 
> I have several difficulties running this program.  The program displays the
> contents of the file "HelloWorld.Mod", with the exception of the last line.
> How can I specify the termination condition of the loop to read "While not
> end of file do"?

Using your program (plus fix), I see all the lines from the input file
duplicated to stdout -- as expected.  "WHILE res=done DO" should
definitely work.

> Also, can someone explain the meaning of the third parameter 'res' of the
> Files.Old function call?

Opening the file may file.  A "res#done" indicates an error.  This
should be checked.  For example, when I started your program without
providing the input file, I got a seg fault because `file' was NIL.
`res' would indicate a "file not found" error.

> Furthermore, in Wirth's book, the I/O functions that are described differ
> from those present in the oo2c library.  Am I correct in understanding that
> these are the ones defined in the Oakwood modules?  If so, what are the
> benefits/drawbacks of one over the other?

In general, the resemblance between the libraries of oo2c and the
original documentation of the Oberon System is superficial.  By
necessity, any I/O library put on top of the standard C/POSIX library
needs to decide whether to implement its own view of the world, or to
provide a faithful representation of the low-level functions of the
operating system (or C library).  In a way, the Wirth I/O functions
_are_ the operating system.  OOC leans more in the direction of the
operating system it is using, which is represented by the I/O
functions of C.  For example, the v2 compiler comes with a set of
low-level IO modules (like IO:FileChannel and IO:SocketChannel) that
are essentially one-to-one interfaces to C's open(), read(), write(),
etc.

As for Oakwood: The v1 compiler distribution has a set of Oak* modules
that are closer to the original Oberon System modules.

-- mva

Re: [ooc-compiler] VisualOberon or not VisualOberon?

[Marco O. <Mar...@we...>]

Am Mittwoch, 26. Mai 2004 18:10 schrieb Frank Hrebabetzky:
> I am starting to use oo2c on Win32/MinGW.
>
> Why not POW? Because IMHO oo2c is (i) more portable, because it (ii)
> offers more functionality (libraries) and it (iii) is easier to use in a
> multilingual project (use of library and program source code written in C).
>
> I certainly will need GUIs, so should I use VisualOberon or another
> framework (Glade/Gtk, Qt, ...)?
>
> I know the Oberon look-and-feel from System 3 and I like it. And using
> the language Oberon for the GUI would make programming more comfortable
> using VisualOberon. On the other hand: VO (i) would have to be
> statically linked to my programs or be installed on the target
> platforms, whereas Gtk already might be there. (ii) More people are
> familiar with C and Gtk. And finally: (iii) for Gtk an interface builder
> is available (Glade). So I tend towards the latter solution.

It takes a some time to learn how to use VisualOberon. The
userinterfaces generated with VisualOberon are different from those
of the Oberon System. I think there are only a few minor points in
the interface, that may cause dissatisfaction.

>
> I am curious about your ideas out there, and especially about the
> objective opinion of Tim ;-)
> -----------------------------------------------------------
> Frank Hrebabetzky		Tel.:  +55/48/239-2258
> Photonita Ltda			Fax:   +55/48/239-2200
> Parque Tec. Alfa - Ed. CELTA
> Florianopolis, SC
> 88030-000
> Brasil
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler

[ooc-compiler] Quick change to my previous post

[Gregory G. <gre...@tt...>]

Sorry but I made a typo in my previous program:

I forgot to change the line:

    WHILE reader.res = Files.eof DO

Back to:

    WHILE reader.res = Files.done DO

[ooc-compiler] Help With I/O

[Gregory G. <gre...@tt...>]

Hello All,

I am completely new to Oberon, and am attempting to learn the language.  I
understand the basics of the language as described in Wirth's book, but am
having some difficulty in learning the oo2c library.  I have the following
program:

MODULE DisplayFile;

IMPORT Files, TextRider, Out, Msg;

VAR
    reader : TextRider.Reader;
    file : Files.File;
    string : ARRAY 256 OF CHAR;
    res : Msg.Msg;

BEGIN
    (* open the file "HelloWorld.Mod" for reading *)

    file := Files.Old("HelloWorld.Mod", {Files.read}, res);
    
    (* connect the reader to the file *)
    
    reader := TextRider.ConnectReader(file);
    
    reader.ReadLine(string);
    WHILE reader.res = Files.eof DO
        Out.String(string);
        Out.Ln;
        reader.ReadLine(string)
    END;
END DisplayFile.

I have several difficulties running this program.  The program displays the
contents of the file "HelloWorld.Mod", with the exception of the last line.
How can I specify the termination condition of the loop to read "While not
end of file do"?

Also, can someone explain the meaning of the third parameter 'res' of the
Files.Old function call?

Furthermore, in Wirth's book, the I/O functions that are described differ
from those present in the oo2c library.  Am I correct in understanding that
these are the ones defined in the Oakwood modules?  If so, what are the
benefits/drawbacks of one over the other?

Thank you kindly,
Gregory Gelfond

[ooc-compiler] VisualOberon or not VisualOberon?

[Frank H. <fh...@ph...>]

I am starting to use oo2c on Win32/MinGW.

Why not POW? Because IMHO oo2c is (i) more portable, because it (ii) 
offers more functionality (libraries) and it (iii) is easier to use in a 
multilingual project (use of library and program source code written in C).

I certainly will need GUIs, so should I use VisualOberon or another 
framework (Glade/Gtk, Qt, ...)?

I know the Oberon look-and-feel from System 3 and I like it. And using 
the language Oberon for the GUI would make programming more comfortable 
using VisualOberon. On the other hand: VO (i) would have to be 
statically linked to my programs or be installed on the target 
platforms, whereas Gtk already might be there. (ii) More people are 
familiar with C and Gtk. And finally: (iii) for Gtk an interface builder 
is available (Glade). So I tend towards the latter solution.

I am curious about your ideas out there, and especially about the 
objective opinion of Tim ;-)
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA
Florianopolis, SC		
88030-000
Brasil

Re: [ooc-compiler] Interface mod.: undef. ref. to win32 API proc.

[Frank H. <fh...@ph...>]

Tim Teulings wrote:
> Hallo!
> 
>> Doing my first steps with oo2c under MinGW, I wrote an interface 
>> module which begins like this:
>>
>>   MODULE IFserial [INTERFACE "C"; LINK LIB "kernel32" END];
>>
>> and which contains:
>>
>>   PROCEDURE CreateFile*
>>     (name:ARRAY OF LONGCHAR;
>>     accessMode,shareMode:SET;
>>         secAttr:lpSecAttr; create,attr:DWORD; template:HANDLE
>>     ): HANDLE;
>>
>> This module is imported by another one, "Serial.Mod". Both compile, 
>> but the linker produces an error message:
>>
>>   obj/Serial.o(.text+0x8d):Serial.c: undefined reference to `CreateFile'
> 
> 
> I'm not sure, that the function is contained in kernel32? What about 
> user32?

Win32-SDK-Help says it is in kernel32. I installed dumpbin and had a 
look at the exports of kernel32.dll and what I found is a procedure 
"CreateFileA". I made the changes and now it links. Nevertheless it is 
odd, because I did some tests before with mingw/gcc and from my C 
program I called "CreateFile" and it worked.
> 
> If you try to access Windows functions there is no need to write 
> interface modules for it, since VisualOberon already contains a 
> Windows.Mod that should contain most of the Window functions, structures 
> etc...

With respect to VisualOberon I have some questions but I guess it is 
better to open a separate thread. So hold on ...

> It module sequence starts with (note the "Pascal"):
> 
> MODULE Windows [ INTERFACE "Pascal";
>       LINK LIB "kernel32"; LIB "user32"; LIB "gdi32" END];
> 
> See VisualOberon homepage and CVS repository for details.
> 

-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA
Florianopolis, SC		
88030-000
Brasil

Re: [ooc-compiler] Strange config file result

[Michael v. A. <Mic...@de...>]

Frank Hrebabetzky <hr...@te...> writes:

> Platform: Win32 / MinGW
> 
> config file ('.oo2crc') content:
> 
>    PATHS
>    GET *.Mod FROM .;
>    GET *.c FROM obj;
>    END
> 
> 'oowhereis --config .oo2crc SerialIF' results in the following message:
> 
>    line=0, column=0
>    0: Expected element
>    line=0, column=0
>    0: Junk after document element
> 
>    ##
>    ## Runtime error in module OOC:Config:Repositories at pos 7720
>    ## Dereference of NIL
>    ##
> 
> Why?

The config file belongs to the v1 compiler, and the oowhereis program
to the v2 compiler.  The file format has changed completely between
versions.  (The crash is not nice, but I guess that is not a severe
problem right now.)

-- mva

[ooc-compiler] Strange config file result

[Frank H. <hr...@te...>]

Platform: Win32 / MinGW

config file ('.oo2crc') content:

   PATHS
   GET *.Mod FROM .;
   GET *.c FROM obj;
   END

'oowhereis --config .oo2crc SerialIF' results in the following message:

   line=0, column=0
   0: Expected element
   line=0, column=0
   0: Junk after document element

   ##
   ## Runtime error in module OOC:Config:Repositories at pos 7720
   ## Dereference of NIL
   ##

Why?
-- 
Frank Hrebabetzky		+55 / 48 / 235 1106
Florianopolis, Brazil

Re: [ooc-compiler] Interface mod.: undef. ref. to win32 API proc.

[Tim T. <ra...@ed...>]

Hallo!

> Doing my first steps with oo2c under MinGW, I wrote an interface module=
=20
> which begins like this:
>=20
>   MODULE IFserial [INTERFACE "C"; LINK LIB "kernel32" END];
>=20
> and which contains:
>=20
>   PROCEDURE CreateFile*
>     (name:ARRAY OF LONGCHAR;
>     accessMode,shareMode:SET;
>         secAttr:lpSecAttr; create,attr:DWORD; template:HANDLE
>     ): HANDLE;
>=20
> This module is imported by another one, "Serial.Mod". Both compile, but=
=20
> the linker produces an error message:
>=20
>   obj/Serial.o(.text+0x8d):Serial.c: undefined reference to `CreateFile=
'

I'm not sure, that the function is contained in kernel32? What about user=
32?

If you try to access Windows functions there is no need to write=20
interface modules for it, since VisualOberon already contains a=20
Windows.Mod that should contain most of the Window functions, structures =

etc...

It module sequence starts with (note the "Pascal"):

MODULE Windows [ INTERFACE "Pascal";
       LINK LIB "kernel32"; LIB "user32"; LIB "gdi32" END];

See VisualOberon homepage and CVS repository for details.

--=20
Gru=DF...
        Tim.

[ooc-compiler] Interface mod.: undef. ref. to win32 API proc.

[Frank H. <fh...@ph...>]

Doing my first steps with oo2c under MinGW, I wrote an interface module 
which begins like this:

   MODULE IFserial [INTERFACE "C"; LINK LIB "kernel32" END];

and which contains:

   PROCEDURE CreateFile*
	(name:ARRAY OF LONGCHAR;
	accessMode,shareMode:SET;
         secAttr:lpSecAttr; create,attr:DWORD; template:HANDLE
	): HANDLE;

This module is imported by another one, "Serial.Mod". Both compile, but 
the linker produces an error message:

   obj/Serial.o(.text+0x8d):Serial.c: undefined reference to `CreateFile'

I am somewhat overwhelmed by the amount of information contained in 
OOCRef, Win32-SDK-Help, MinGW and other documentation. So if someone 
could give me a hint.

-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA
Florianopolis, SC
88030-000
Brasil

Re: [ooc-compiler] Package creation

[Michael v. A. <Mic...@de...>]

"August" <fus...@sp...> writes:

> I have downloaded and installed `xsltproc' and when I run
> 
>     oo2c --build-pkg-doc PkgTest
> 
> from the repository folder I get the xml files in the `oocdoc/xml' folder,
> but the `oocdoc/html' folder is (still) empty. When I run
> 
>     xsltproc c:/usr/local/lib/oo2c/rsrc/OOC/xml/interface-description.xsl \
>         oocdoc/xml/SomeModule.xml
> 
> from the repository I get the expected html file `SomeModule.html'.

My guess is that the compiler doesn't know about the location of your
xsltproc.  configure searches for xsltproc and puts its path into the
compiler's configuration file <prefix>/lib/oo2c/oo2crc.xml
In the options section you should have an entry akin to

    <set name='xsltproc'>/usr/bin/xsltproc</set>

> [...]
> I also noticed that unlike Javadoc and many other documentation extraction
> utilities, `oo2c --build-pkg-doc' requires that documentation comments
> follow their corresponding definitions. A drawback with this style is that
> the distance between a procedure heading  and the rest of the procedure
> definition can become very large. An advantage is that it's allways clear
> which declaration a documentation comment belongs to. Of course this is much
> a question of personal taste, but I think the Javadoc style is just as
> common. Would it require much work to add an option to let the user choose
> between pre-comment and post-comment style? (From what I can remember the
> Oberon-2 report does not mention any prefered style for documentation
> comments.)

This is definitely a question of personal preference.  The last
discussion on this had proponents of the "before" and "after" style as
well.  Switching between different styles only works well if all
relevant users happen to use the same style.  Otherwise, people need
to switch context each time they read code using another style.  For
this reason I consider alternatives on this level as counterproductive.

> (By the way I must say that the html documentation looks really nice, very
> similar in style to what Javadoc produces.)

I haven't look at the HTML output in years.  I'm glad to hear it's
still usable.

-- mva

Re: [ooc-compiler] Package creation

[Enrico W. <we...@me...>]

* Michael van Acken <Mic...@de...> wrote:

Hi folks,

<snip>
> For this purpose, a very small pkginfo.xml file will do:
> 
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <package name="PkgT">
>   <version current="0" revision="0"/>
>   
>   <library name="LibT" main-module="T">
>     <version current="0" revision="0" age="0"/>
>   </library>
> </package>

BTW:

I'm doing some research on a new universal buildsystem, which models 
the structure of software instead of the build process. This model
should be able to cope w/ all common languages/paradigms, including 
code-generators (i.e.bison), resource files (i.e. .po, .xpm, ...).

The information feeded into the buildsystem should be abstract enough
to let it do the whole build process (also tracking dependencies
and interfaces, setting up pathes and compiler settings) up to 
customized installing + packaging completely by itself and make 
such misdesigns like autoconf obsolete.

It should even go further than current build tools and model abstract
and build-specific things separately, for example the concept of
modules vs. shared libraries: an module can be built into the main
binary, into some library or completely left out. (have a look at apache)

Since it organizes the whole project into a tree structure, I've 
called it "treebuild".

Probably someone here's interested in it.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     co...@me...
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------

Re: [ooc-compiler] Package creation

[Michael v. A. <Mic...@de...>]

"August" <fus...@sp...> writes:

> > Packages come into play if you want to distribute source archives to
> > other people, which in turn install the library or program into the
> > oo2c setup.  The "pkg" commands are usually triggered from a Makefile,
> > which in turn is provided with parameters from an autoconf-generated
> > configure script.
> 
> Ok. But the documentation extraction facility, `--build-pkg-doc', may be
> useful even if I'm not going to distribute source archives to other people.
> Can I create html documentation from sources without a  pkginfo.xml file?

For this purpose, a very small pkginfo.xml file will do:

<?xml version="1.0" encoding="ISO-8859-1"?>
<package name="PkgT">
  <version current="0" revision="0"/>
  
  <library name="LibT" main-module="T">
    <version current="0" revision="0" age="0"/>
  </library>
</package>

Assuming that module src/T.Mod imports all the modules (either
directly or indirectly) from the repository `-r .' you are interested
in, the command

  oo2c --build-pkg-doc PkgT

builds HTML files from the modules' public interfaces.  The files end
up in `oocdoc/html'.  You need xsltproc for the conversion from .xml
into .html files.

-- mva

Re: [ooc-compiler] Spaces in paths

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

Quoting Michael van Acken <Mic...@de...>:

> "fusionfive" <fus...@sp...> writes:
> 
> > Hi,
> > 
> > When I use paths with spaces I run into problems with oo2c version 2.1.1.
> > Arguments given to gcc are not quoted. Is there any way to fix this
> problem.
> > (In Windows home directories are found in `<driveletter>:\Documents and
> > settings'.)
> 
> This affects all shell commands, both compilation & linking via
> libtool or gcc.  None of code that puts them together deals with
> quoting of arguments.  
> 
> The only fix is to choose a working directory without any dangerous
> characters in the path.  Sorry for that.

There is an additional complexity under Windows. All of the compiler tools that 
come with the mingw (and cygwin) tools use a path virtualisation system to 
ensure that they only ever see valid unix path names. However, binaries built 
under mingw (including oo2c itself) see the raw paths, not virtualised paths. 
Therefore, you need to arrange your directory naming so that the same names 
work for both virtualised and raw paths. Be sure to check the OOC README.WIN32 
file for an explanation of the issues. 

Cheers,
  Stewart

Re: [ooc-compiler] Package creation

[Michael v. A. <Mic...@de...>]

"fusionfive" <fus...@sp...> writes:

> Hi,
> 
> What are the basic steps when working with oo2c version 2.1.1? I can't find
> any tutorial.
> 
> Let's say I will start working on a project comprising two source files,
> `Main.Mod' and `Test.Mod', where `Main.Mod' uses the module `Test.Mod'. If I
> got it right I start by choosing a working directory, say `test' and then
> create a subfolder named `src' where `Main.Mod' and `Test.Mod' are located.
> In order to compile the program I then run the command
> 
>     oo2c -M -r .. Main.Mod
> 
> from `test/src'. Now the compiled program can be found in
> `test/bin'.

The usual setup is to call 

  oo2c -M Main.Mod

from the working directory `test'.  This gets you the same result as
you describe above, since the repository `-r .' is included in the
search path by default.

> Some of the options of oo2c require a package name as
> e.g. `--build-pkg-doc'. As far as I know a package is defined in a
> file named pkginfo.xml. What is the format of that file?

Packages come into play if you want to distribute source archives to
other people, which in turn install the library or program into the
oo2c setup.  The "pkg" commands are usually triggered from a Makefile,
which in turn is provided with parameters from an autoconf-generated
configure script.

There is no documentation on the format of the pkginfo.xml file.
There are lots of examples of its use, though.  You might take a look
at the files included in the oo2c tarball, or existing libraries like

  http://cvs.sourceforge.net/viewcvs.py/ooc/libicu-2.4/
  http://cvs.sourceforge.net/viewcvs.py/ooc/libpobj/
  http://cvs.sourceforge.net/viewcvs.py/visualoberon/X11/
  http://cvs.sourceforge.net/viewcvs.py/visualoberon/VisualOberon/

-- mva

Re: [ooc-compiler] Spaces in paths

[Michael v. A. <Mic...@de...>]

"fusionfive" <fus...@sp...> writes:

> Hi,
> 
> When I use paths with spaces I run into problems with oo2c version 2.1.1.
> Arguments given to gcc are not quoted. Is there any way to fix this problem.
> (In Windows home directories are found in `<driveletter>:\Documents and
> settings'.)

This affects all shell commands, both compilation & linking via
libtool or gcc.  None of code that puts them together deals with
quoting of arguments.  

The only fix is to choose a working directory without any dangerous
characters in the path.  Sorry for that.

-- mva

[ooc-compiler] Spaces in paths

[fusionfive <fus...@sp...>]

Hi,

When I use paths with spaces I run into problems with oo2c version 2.1.1.
Arguments given to gcc are not quoted. Is there any way to fix this problem.
(In Windows home directories are found in `<driveletter>:\Documents and
settings'.)

Regards,
August

[ooc-compiler] Package creation

[fusionfive <fus...@sp...>]

Hi,

What are the basic steps when working with oo2c version 2.1.1? I can't find
any tutorial.

Let's say I will start working on a project comprising two source files,
`Main.Mod' and `Test.Mod', where `Main.Mod' uses the module `Test.Mod'. If I
got it right I start by choosing a working directory, say `test' and then
create a subfolder named `src' where `Main.Mod' and `Test.Mod' are located.
In order to compile the program I then run the command

    oo2c -M -r .. Main.Mod

from `test/src'. Now the compiled program can be found in `test/bin'. Some
of the options of oo2c require a package name as e.g. `--build-pkg-doc'. As
far as I know a package is defined in a file named pkginfo.xml. What is the
format of that file?

Regards,
August

[ooc-compiler] oo2c-2.1.1 released

[Michael v. A. <Mic...@de...>]

(oo2c) The "verbose" command line option `-v' has been revived.  If
set, then the compiler prints the names of files read and shell
commands.  This is the old behaviour of 2.x.  If not set, then only
errors and warnings are written to stdout.

(oo2c) The "fastcall" calling convention, as implemented by
Microsoft's C compiler as well as recent versions of GCC, has been
added.

(oo2c) Error checking has been improved for set types (#933554) and
initializer methods (#917211, #917202).

(library) A definition clash of "ssize_t" has been removed for MinGW
3.1.


In addition to this, two experimental variants of the FOR statement
have been added:

1) Iterating over Array

If x is an array value, then

  FOR v IN x DO
    ...
  END;

is equivalent to

  temp := 0;
  WHILE (temp # LEN(x)) DO
    v := x[temp];
    ...
    INC(temp);
  END;

2) Iterator Object

If x.Iter() produces a record pointer with a method Next() that has 
exactly one variable parameter and that returns a BOOLEAN value, then 

  FOR v IN x.Iter() DO
    ...
  END;

becomes

  temp := x.Iter();
  WHILE temp.Next(v) DO
    ...
  END;


-- mva