ooc-compiler

Re: [ooc-compiler] C interface problems

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

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

> [...]
> I also skimmed through your GL.Mod file and noticed that literal
> values are defined for (macro) constants. Isn't it possible for the
> OOC compiler to get the values from the C header file?

We do not include arbitrary header files as a rule.  The Oberon code
cannot use the definitions in the header files, while it can use a
constant definition from an INTERFACE file.

> Moreover I tend
> to dislike all but the absolutely necessary Oberon-2 extensions*, so I
> would prefer to rename all identifiers to valid Oberon-2 identifiers
> (no underscores) that follows the standard naming scheme and keep the
> definitions in three different modules: GL.Mod, Glu.Mod and
> Glut.Mod. The conversion rules are very regular (thanks to the
> regularity of the OpenGL interface):

The hardest part of interfacing to an external library is to use it
correctly from within a foreign programming language with foreign
ideas about procedure signatures.  For example, an ARRAY OF X in
Oberon is something different than an X[] in C, and certain uses of
pointer parameters in C cannot be expressed in Oberon-2 at all.  To
widen the distance between the original C interface and the translated
Oberon interface by changing the naming convention would make things
harder still: the C programmers (who know the interface) would need to
learn the new names, and the Oberon-2 programmers (who need to learn
the interface) would need to translate every name they find in the C
documentation to the one used in the Oberon-2 modules.

The one exception I would make to the rule of keeping names as close
as possible is to strip out a common prefix into a module name.  That
is, if a name is "Prefix_Foo", then I would recommend to make it
available to client code as "Prefix.Foo", instead of
"Prefix.Prefix_Foo".

-- mva

Re: [ooc-compiler] C interface problems

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

> What standard naming scheme? Nothing about Oberon is standardised.

I had the ETH recommendations in mind. The report "The Programming 
Language Oberon-2" together with "The Oakwood Guidelines for Oberon-2 
Compiler Developers" is the available standard (although not fully 
complete).

> The restriction on valid identifiers is one of the more irritating 
> quirks
> of the Oberon family of languages. Restrictions in Oberon are 
> usually
> justified on the grounds of simplicity or efficiency, but neither 
> applies in
> this case. The modifications to the compiler to permit C-style 
> identifiers
> are absolutely trivial. The effort required to translate C-style 
> identifiers
> into restricted Oberon identifiers is not.


This is only a (potential) problem when you want to port a library to 
Oberon and keep the names intact. Even if underscore is included we 
still cannot use e.g. Lisp identifiers, where hyphens are allowed etc. 
In my experience, allowing only letters and digits in identifiers 
doesn't limit the expressiveness in any significant way.

>> The conversion rules are very regular (thanks to the regularity of 
>> the
>> OpenGL interface):
>
> Not all C APIs have such regularity.

No, and that's not what I'm saying either. I'm discussing how to make 
an OpenGL port for Oberon-2.

>> *If we want Oberon-2 with lots of extensions then we might as well
>> turn to Eiffel.
>
> All the Oberon languages are the products of academic research 
> projects and
> cannot be considered complete general purpose programming languages 
> outside
> of the scope of the various Oberon operating systems. Extensions are
> inevitable and necessary.

Which ones? The beauty and uniqueness of Oberon-2 is its smallness and 
simplicity. By adding a lot of extensions these values are lost and 
there are "better" alternative languages.

-- August 

Re: [ooc-compiler] C interface problems

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

On Fri, Nov 05, 2004 at 02:13:02AM +0100, August wrote:

> Moreover I tend to dislike all but the absolutely necessary Oberon-2
> extensions*, so I would prefer to rename all identifiers to valid Oberon-2
> identifiers (no underscores) that follows the standard naming scheme and
> keep the definitions in three different modules: GL.Mod, Glu.Mod and
> Glut.Mod.

What standard naming scheme? Nothing about Oberon is standardised.

The restriction on valid identifiers is one of the more irritating quirks
of the Oberon family of languages. Restrictions in Oberon are usually
justified on the grounds of simplicity or efficiency, but neither applies in
this case. The modifications to the compiler to permit C-style identifiers
are absolutely trivial. The effort required to translate C-style identifiers
into restricted Oberon identifiers is not.

> The conversion rules are very regular (thanks to the regularity of the 
> OpenGL interface):

Not all C APIs have such regularity. These rules can and do produce
identifier clashes and even illegal identifiers in other APIs. It took me
five minutes to find several examples in one module of the Oberon interfaces
for AmigaOS 3.0:

MEMF_CLEAR => clear (memClear used instead)
CMD_CLEAR  => clear
MEMF_24BITDMA => 24BitDMA (mem24BitDMA used instead)

Note that if the value of clear is used in place of memClear in an AmigaOS
memory allocation function call the most likely result is 'a visit from the
Guru' otherwise known as a total system crash. A programmer blindly applying
the conversion rules to C code taken from API documentation or example code
is highly likely to make this error.

Converting identifiers is therefore not only tedious and error-prone, it can
lead to the introduction of serious bugs.

> *If we want Oberon-2 with lots of extensions then we might as well 
> turn to Eiffel.

All the Oberon languages are the products of academic research projects and
cannot be considered complete general purpose programming languages outside
of the scope of the various Oberon operating systems. Extensions are
inevitable and necessary.

I do think there is an argument that the extended language implemented by
the OOC compiler is at least as far from the base Oberon-2 as Component
Pascal and so deserves a name of its own.

Frank Copeland
-- 
Stamp out philately.

Re: [ooc-compiler] C interface problems

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

Hi August,

> Yes, it worked! Thank you. (Not so obvious to use Pascal calling 
> convention with a C library).

No, its not obvious. However, Pascal (or "stdcall") conventions are the 
norm for almost every public API under Windows. I think this was 
originally done to reduce the code size. Having the callee remove the 
stack frame reduces the size of a procedure call sequence, but 
disallows "C"-style variable parameter lists. Only in situations where 
variable parameters are required does Win32 (eg. wsprintf, etc.) use 
"C" conventions.

> I also skimmed through your GL.Mod file and noticed that literal 
> values are defined for (macro) constants. Isn't it possible for the 
> OOC compiler to get the values from the C header file?

This would require OOC to incorporate the front-end of a C compiler 
(ie. the preprocessor and declaration parser). Technically, it could be 
done but the problem is that there is no unique mapping from C types to 
Oberon-2 types. For example, if you see "char * p" in a parameter list, 
it could mean "VAR p : CHAR", "p : POINTER TO ARRAY OF CHAR", "p : 
ARRAY OF CHAR", "VAR p : ARRAY OF CHAR", or "POINTER TO CHAR" (this one 
exists in "C" but has no equivalent in Oberon-2). Different rules apply 
for different APIs, so the approach I have used is to have a separate 
translator that that processes the "C" files but allows one to do the 
relevant tweaks on the generated interfaces. Another issue is that 
Oberon-2 disallows type constructors in procedure parameter lists, so 
these have to be "rewritten" to use new or existing types. Again, there 
are different rules for controlling how this works.

>  Moreover I tend to dislike all but the absolutely necessary Oberon-2 
> extensions*, so I would prefer to rename all identifiers to valid 
> Oberon-2 identifiers (no underscores) that follows the standard naming 
> scheme and keep the definitions in three different modules: GL.Mod, 
> Glu.Mod and Glut.Mod. The conversion rules are very regular (thanks to 
> the regularity of the OpenGL interface):

I agree that separate modules would be a good idea. In the case of 
OpenGL things are pretty clear. In general, the difficulty is that the 
"C" language has no concept of modules, so its necessary to infer the 
module structure and dependencies from analysing the declarations. 
Sometimes (eg. Win32) there are hundreds of modules and its 
semantically simpler to translate the whole thing as a single module. 
For Win32, users normally just do "#include <windows.h>", and are not 
aware of which functions come from which modules. Therefore there needs 
to be options to control which declarations appear as separate modules, 
and which are merged.

It should be possible to rename the identifiers. Potentially, it might 
surprise users to find that the names have changed - they would have to 
mentally do the translation while coding for the API.

> Constants - Remove the prefix, lower case the first word, capitalize 
> the following words (if any) and remove the underscores, e.g. 
> GL_COLOR_BUFFER_BIT becomes colorBufferBit. There also exists a 
> tradition to use Pascal case (rather than camel case) with exported 
> variables and constants. Have not decided which is the best choice.

This might work, providing that it does not introduce a name clash as a 
result.

> Types - Remove the prefix and capitalize, e.g. GLclampf becomes Clampf.
>
> Variables - (No exported variables, right?)
>
> Functions - Just remove the prefix, e.g. glutSwapBuffers becomes 
> SwapBuffers.

Yes, again its a case of imposing a module namespace where "C" has no 
such concept. This should not be a problem. I'll take a look at it.

> *If we want Oberon-2 with lots of extensions then we might as well 
> turn to Eiffel.

I guess that depends what you're trying to do. Plain Oberon-2 has a 
number of deficiencies which the extensions are designed to fix. I find 
them useful, but of course everyone is entitled to use them or not as 
they wish. Some of the extensions are source-level compatible with 
Oberon-2 (eg. abstract types). If you want interoperability with other 
Oberon-2 compilers then you would need to stay clear of certain ones 
(eg. exception handling, parameteric types).

I don't know Eiffel well, but it does have some nice concepts in there. 
Same goes for Modula-3.

Cheers,
   Stewart

>
> ----- Original Message ----- From: "Stewart Greenhill" 
> <sgr...@ii...>
> To: "August" <fus...@te...>
> Cc: <ooc...@li...>
> Sent: Thursday, November 04, 2004 1:20 PM
> Subject: Re: [ooc-compiler] C interface problems
>
>
>> Hi August,
>>
>>> One potential problem: the glut functions are defined as "APIENTRY", 
>>> which under Windows means that they use the "stdcall" calling 
>>> convention rather than "cdecl". Therefore, you should probably 
>>> specify "Pascal" rather than "C" as your interface type. That is:
>>>   MODULE Glut [INTERFACE "Pascal"; LINK LIB "glut32"; LIB 
>>> "opengl32"; END];
>>> I think the same goes for the other GL modules. Presuming that the 
>>> linker knows the procedure attributes, that may be why it is giving 
>>> the error (ie. the procedure name matches, but the attributes are 
>>> wrong).
>>
>> I ran a quick check, and it looks like this is indeed what happens. 
>> The following should compile and link fine. It also runs OK, opening 
>> a window and correctly calling the display procedure.
>>
>> MODULE Test;
>>   IMPORT C, Glut;
>>   VAR w: C.int;
>>   PROCEDURE Display ["Pascal"];
>>   END Display;
>> BEGIN
>>   w := Glut.CreateWindow("OpenGL Test");
>>   Glut.DisplayFunc(Display);
>>   Glut.MainLoop
>> END Test.
>>
>> MODULE Glut [INTERFACE "Pascal"; LINK LIB "glut32"; LIB "opengl32"; 
>> END];
>>   IMPORT C;
>> TYPE
>>   DisplayCallback = PROCEDURE;
>>
>>   PROCEDURE ["glutCreateWindow"] CreateWindow*(title: ARRAY OF 
>> C.char): C.int;
>>   PROCEDURE ["glutDisplayFunc"] DisplayFunc*(p: DisplayCallback);
>>   PROCEDURE ["glutMainLoop"] MainLoop*;
>> END Glut.
>>
>> Hope this helps.
>>
>> Cheers,
>>   Stewart
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] C interface problems

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

Hello Stewart,

Yes, it worked! Thank you. (Not so obvious to use Pascal calling 
convention with a C library).

I also skimmed through your GL.Mod file and noticed that literal 
values are defined for (macro) constants. Isn't it possible for the 
OOC compiler to get the values from the C header file? Moreover I tend 
to dislike all but the absolutely necessary Oberon-2 extensions*, so I 
would prefer to rename all identifiers to valid Oberon-2 identifiers 
(no underscores) that follows the standard naming scheme and keep the 
definitions in three different modules: GL.Mod, Glu.Mod and Glut.Mod. 
The conversion rules are very regular (thanks to the regularity of the 
OpenGL interface):

Constants - Remove the prefix, lower case the first word, capitalize 
the following words (if any) and remove the underscores, e.g. 
GL_COLOR_BUFFER_BIT becomes colorBufferBit. There also exists a 
tradition to use Pascal case (rather than camel case) with exported 
variables and constants. Have not decided which is the best choice.

Types - Remove the prefix and capitalize, e.g. GLclampf becomes 
Clampf.

Variables - (No exported variables, right?)

Functions - Just remove the prefix, e.g. glutSwapBuffers becomes 
SwapBuffers.

-- August

*If we want Oberon-2 with lots of extensions then we might as well 
turn to Eiffel.

----- Original Message ----- 
From: "Stewart Greenhill" <sgr...@ii...>
To: "August" <fus...@te...>
Cc: <ooc...@li...>
Sent: Thursday, November 04, 2004 1:20 PM
Subject: Re: [ooc-compiler] C interface problems


> Hi August,
>
>> One potential problem: the glut functions are defined as 
>> "APIENTRY", which under Windows means that they use the "stdcall" 
>> calling convention rather than "cdecl". Therefore, you should 
>> probably specify "Pascal" rather than "C" as your interface type. 
>> That is:
>>   MODULE Glut [INTERFACE "Pascal"; LINK LIB "glut32"; LIB 
>> "opengl32"; END];
>> I think the same goes for the other GL modules. Presuming that the 
>> linker knows the procedure attributes, that may be why it is giving 
>> the error (ie. the procedure name matches, but the attributes are 
>> wrong).
>
> I ran a quick check, and it looks like this is indeed what happens. 
> The following should compile and link fine. It also runs OK, opening 
> a window and correctly calling the display procedure.
>
> MODULE Test;
>   IMPORT C, Glut;
>   VAR w: C.int;
>   PROCEDURE Display ["Pascal"];
>   END Display;
> BEGIN
>   w := Glut.CreateWindow("OpenGL Test");
>   Glut.DisplayFunc(Display);
>   Glut.MainLoop
> END Test.
>
> MODULE Glut [INTERFACE "Pascal"; LINK LIB "glut32"; LIB "opengl32"; 
> END];
>   IMPORT C;
> TYPE
>   DisplayCallback = PROCEDURE;
>
>   PROCEDURE ["glutCreateWindow"] CreateWindow*(title: ARRAY OF 
> C.char): C.int;
>   PROCEDURE ["glutDisplayFunc"] DisplayFunc*(p: DisplayCallback);
>   PROCEDURE ["glutMainLoop"] MainLoop*;
> END Glut.
>
> Hope this helps.
>
> Cheers,
>   Stewart
> 

Re: [ooc-compiler] C interface problems

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

Hi August,

> One potential problem: the glut functions are defined as "APIENTRY", 
> which under Windows means that they use the "stdcall" calling 
> convention rather than "cdecl". Therefore, you should probably specify 
> "Pascal" rather than "C" as your interface type. That is:
>   MODULE Glut [INTERFACE "Pascal"; LINK LIB "glut32"; LIB "opengl32"; 
> END];
> I think the same goes for the other GL modules. Presuming that the 
> linker knows the procedure attributes, that may be why it is giving 
> the error (ie. the procedure name matches, but the attributes are 
> wrong).

I ran a quick check, and it looks like this is indeed what happens. The 
following should compile and link fine. It also runs OK, opening a 
window and correctly calling the display procedure.

MODULE Test;
   IMPORT C, Glut;
   VAR w: C.int;
   PROCEDURE Display ["Pascal"];
   END Display;
BEGIN
   w := Glut.CreateWindow("OpenGL Test");
   Glut.DisplayFunc(Display);
   Glut.MainLoop
END Test.

MODULE Glut [INTERFACE "Pascal"; LINK LIB "glut32"; LIB "opengl32"; 
END];
   IMPORT C;
TYPE
   DisplayCallback = PROCEDURE;

   PROCEDURE ["glutCreateWindow"] CreateWindow*(title: ARRAY OF C.char): 
C.int;
   PROCEDURE ["glutDisplayFunc"] DisplayFunc*(p: DisplayCallback);
   PROCEDURE ["glutMainLoop"] MainLoop*;
END Glut.

Hope this helps.

Cheers,
   Stewart

Re: [ooc-compiler] Bug? MAX without argument

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

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

> When I compile
> 
> MODULE Test;
>    VAR x: LONGINT;
> BEGIN x := MAX;
> END Test.
> 
> with oo2c version 2.1.5 i get
> 
> ##
> ## Runtime error in module OOC:IR at pos 100165
> ## Assertion failed, code 127
> ##
> make: *** [test] Error 127
> 
> Compilation exited abnormally with code 2 at Thu Nov 04 04:35:09
> 
> rather than the error message "Expression not compatible with variable
> type `LONGINT'".

The special nature of predefined functions is tripping up the type
checker here.  This looks an excellent new test case for the
compiler :-) Thank you!

-- mva

[ooc-compiler] Bug? MAX without argument

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

When I compile

MODULE Test;
   VAR x: LONGINT;
BEGIN x := MAX;
END Test.

with oo2c version 2.1.5 i get

##
## Runtime error in module OOC:IR at pos 100165
## Assertion failed, code 127
##
make: *** [test] Error 127

Compilation exited abnormally with code 2 at Thu Nov 04 04:35:09

rather than the error message "Expression not compatible with variable 
type `LONGINT'".

-- August 

Re: [ooc-compiler] C interface problems

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

Hi August,

What you've done looks more-or-less OK to me.

One potential problem: the glut functions are defined as "APIENTRY", 
which under Windows means that they use the "stdcall" calling 
convention rather than "cdecl". Therefore, you should probably specify 
"Pascal" rather than "C" as your interface type. That is:
   MODULE Glut [INTERFACE "Pascal"; LINK LIB "glut32"; LIB "opengl32"; 
END];
I think the same goes for the other GL modules. Presuming that the 
linker knows the procedure attributes, that may be why it is giving the 
error (ie. the procedure name matches, but the attributes are wrong).

Please give this a try and let me know whether it fixes the problem.

Regarding the OpenGL interface: I didn't look at the GLUT functions, 
but in principle it should not be hard to translate these as well. To 
make a usable package probably requires a translation of gl.h, glu.h, 
as well as glut.h. If I get some time I'll take a look at this.

Cheers,
   Stewart

On Thursday, November 4, 2004, at 04:17  AM, August wrote:

> Hi everyone,
>
> I'm trying to use OOC to compile a minimal OpenGL test program with
> GLUT. I emailed the list about the subject a couple of months ago but
> I never got it to work. S. Greenhill mentioned his OpenGL interface,
> but unfortunately it lacks the GLUT definitions (moreover I prefer to
> rename the identifiers by removing the prefix).
>
> In C the code (not the generated code) is:
>
> #include <GL/glut.h>
> int w;
> void Display(void) {}
> int main(void)
> {
>   w = glutCreateWindow("OpenGL Test");
>   glutDisplayFunc(Display);
>   glutMainLoop();
>   return 0;
> }
>
> It can be compiled and linked with the command ` gcc -o test
> test.c -lopengl32 -lglut32'. When I run the program it successfully
> displays an empty window.
>
> Now to the Oberon-2 counterpart. I have a module named Glut.Mod which
> contains:
>
> MODULE Glut [INTERFACE "C"; LINK LIB "glut32"; LIB "opengl32"; END];
>   IMPORT C;
>   PROCEDURE ["glutCreateWindow"] CreateWindow*(title: ARRAY OF
> C.char): C.int;
>   PROCEDURE ["glutDisplayFunc"] DisplayFunc*(p: PROCEDURE);
>   PROCEDURE ["glutMainLoop"] MainLoop*;
> END Glut.
>
> The test program is:
>
> MODULE Test;
>   IMPORT C, Glut;
>   VAR w: C.int;
>   PROCEDURE Display;
>   END Display;
> BEGIN
>   w := Glut.CreateWindow("OpenGL Test");
>   Glut.DisplayFunc(Display);
>   Glut.MainLoop
> END Test.
>
> When I execute `oo2c -M -v -r .. Test.Mod' I get the following output:
>
> cd e:/home/ob2/c-interface/src/
> oo2c -M -v -r .. Test.Mod
> - /usr/local/lib/oo2c/pkginfo.xml
> - /home/ob2/c-interface/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
> - /usr/local/lib/oo2c/sym/C.Sym
> - /home/ob2/c-interface/src/Glut.Mod
> - /home/ob2/c-interface/src/Glut.Mod
> + /home/ob2/c-interface/obj/Glut.d
> + /home/ob2/c-interface/obj/Glut.oh
> + /home/ob2/c-interface/sym/Glut.Doc
> + /home/ob2/c-interface/sym/Glut.Sym
> - /home/ob2/c-interface/sym/Glut.Sym
> + /home/ob2/c-interface/obj/Test_.c
> gcc -O2 -I/usr/local/include -DGC_WIN32_THREADS 
> -I/usr/local/lib/oo2c/src
> -I/home/ob2/c-interface/obj -Iobj -I/usr/local/lib/oo2c/obj -c
> /home/ob2/c-interface/obj/Test_.c -o /home/ob2/c-interface/obj/Test_.o
> gcc -o /home/ob2/c-interface/bin/Test -L/usr/local/lib
> /usr/local/lib/oo2c/obj/RT0.o /usr/local/lib/oo2c/obj/HashCode.o
> /usr/local/lib/oo2c/obj/Object.o /usr/local/lib/oo2c/obj/Exception.o
> /home/ob2/c-interface/obj/Test.o
> /home/ob2/c-interface/obj/Test_.o -lopengl32 -lglut32 -L/usr/local/lib
> /home/ob2/c-interface/obj/Test.o(.text+0x5c):Test.c: undefined
> reference to `glutCreateWindow'
> /home/ob2/c-interface/obj/Test.o(.text+0x6d):Test.c: undefined
> reference to `glutDisplayFunc'
> /home/ob2/c-interface/obj/Test.o(.text+0x78):Test.c: undefined
> reference to `glutMainLoop'
>
> Compilation exited abnormally with code 1 at Tue Nov 02 03:14:32
>
> What am I doing wrong? Note that both `-lopengl32' and `-lglut32'
> appears in the output (in the correct relative order).
>
> Regards,
> August
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

[ooc-compiler] C interface problems

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

Hi everyone,

I'm trying to use OOC to compile a minimal OpenGL test program with
GLUT. I emailed the list about the subject a couple of months ago but
I never got it to work. S. Greenhill mentioned his OpenGL interface,
but unfortunately it lacks the GLUT definitions (moreover I prefer to
rename the identifiers by removing the prefix).

In C the code (not the generated code) is:

#include <GL/glut.h>
int w;
void Display(void) {}
int main(void)
{
   w = glutCreateWindow("OpenGL Test");
   glutDisplayFunc(Display);
   glutMainLoop();
   return 0;
}

It can be compiled and linked with the command ` gcc -o test
test.c -lopengl32 -lglut32'. When I run the program it successfully
displays an empty window.

Now to the Oberon-2 counterpart. I have a module named Glut.Mod which
contains:

MODULE Glut [INTERFACE "C"; LINK LIB "glut32"; LIB "opengl32"; END];
   IMPORT C;
   PROCEDURE ["glutCreateWindow"] CreateWindow*(title: ARRAY OF
C.char): C.int;
   PROCEDURE ["glutDisplayFunc"] DisplayFunc*(p: PROCEDURE);
   PROCEDURE ["glutMainLoop"] MainLoop*;
END Glut.

The test program is:

MODULE Test;
   IMPORT C, Glut;
   VAR w: C.int;
   PROCEDURE Display;
   END Display;
BEGIN
   w := Glut.CreateWindow("OpenGL Test");
   Glut.DisplayFunc(Display);
   Glut.MainLoop
END Test.

When I execute `oo2c -M -v -r .. Test.Mod' I get the following output:

cd e:/home/ob2/c-interface/src/
oo2c -M -v -r .. Test.Mod
- /usr/local/lib/oo2c/pkginfo.xml
- /home/ob2/c-interface/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
- /usr/local/lib/oo2c/sym/C.Sym
- /home/ob2/c-interface/src/Glut.Mod
- /home/ob2/c-interface/src/Glut.Mod
+ /home/ob2/c-interface/obj/Glut.d
+ /home/ob2/c-interface/obj/Glut.oh
+ /home/ob2/c-interface/sym/Glut.Doc
+ /home/ob2/c-interface/sym/Glut.Sym
- /home/ob2/c-interface/sym/Glut.Sym
+ /home/ob2/c-interface/obj/Test_.c
gcc -O2 -I/usr/local/include -DGC_WIN32_THREADS -I/usr/local/lib/oo2c/src
 -I/home/ob2/c-interface/obj -Iobj -I/usr/local/lib/oo2c/obj -c
/home/ob2/c-interface/obj/Test_.c -o /home/ob2/c-interface/obj/Test_.o
gcc -o /home/ob2/c-interface/bin/Test -L/usr/local/lib
/usr/local/lib/oo2c/obj/RT0.o /usr/local/lib/oo2c/obj/HashCode.o
/usr/local/lib/oo2c/obj/Object.o /usr/local/lib/oo2c/obj/Exception.o
/home/ob2/c-interface/obj/Test.o
/home/ob2/c-interface/obj/Test_.o -lopengl32 -lglut32 -L/usr/local/lib
/home/ob2/c-interface/obj/Test.o(.text+0x5c):Test.c: undefined
reference to `glutCreateWindow'
/home/ob2/c-interface/obj/Test.o(.text+0x6d):Test.c: undefined
reference to `glutDisplayFunc'
/home/ob2/c-interface/obj/Test.o(.text+0x78):Test.c: undefined
reference to `glutMainLoop'

Compilation exited abnormally with code 1 at Tue Nov 02 03:14:32

What am I doing wrong? Note that both `-lopengl32' and `-lglut32'
appears in the output (in the correct relative order).

Regards,
August

[ooc-compiler] oo2c-2.1.5 released

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

(oo2c) Fix C output if a module defines an array of procedures
variables.  Previously, procedure variables were not covered by the
run-time type information at all.

(oo2c) Fix C output for an exported variable of record type.  Such an
anonymous record caused a double definition in the header file and in
the code file.

(PROBLEMS) Add description of a workaround if the xsltproc binary is
present, but crashes on the XML interface documents.

(oberon2.el) Comment out old compatibility hack that seems to cause
problems with Emacs 21.3.1.

-- mva

[ooc-compiler] C interface problems

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

Hi everyone,

I'm trying to use OOC to compile a minimal OpenGL test program with 
GLUT. I emailed the list about the subject a couple of months ago but 
I never got it to work. S. Greenhill mentioned his OpenGL interface, 
but unfortunately it lacks the GLUT definitions (moreover I prefer to 
rename the identifiers by removing the prefix).

In C the code (not the generated code) is:

#include <GL/glut.h>
int w;
void Display(void) {}
int main(void)
{
   w = glutCreateWindow("OpenGL Test");
   glutDisplayFunc(Display);
   glutMainLoop();
   return 0;
}

It can be compiled and linked with the command ` gcc -o test 
test.c -lopengl32 -lglut32'. When I run the program it successfully 
displays an empty window.

Now to the Oberon-2 counterpart. I have a module named Glut.Mod which 
contains:

MODULE Glut [INTERFACE "C"; LINK LIB "glut32"; LIB "opengl32"; END];
   IMPORT C;
   PROCEDURE ["glutCreateWindow"] CreateWindow*(title: ARRAY OF 
C.char): C.int;
   PROCEDURE ["glutDisplayFunc"] DisplayFunc*(p: PROCEDURE);
   PROCEDURE ["glutMainLoop"] MainLoop*;
END Glut.

The test program is:

MODULE Test;
   IMPORT C, Glut;
   VAR w: C.int;
   PROCEDURE Display;
   END Display;
BEGIN
   w := Glut.CreateWindow("OpenGL Test");
   Glut.DisplayFunc(Display);
   Glut.MainLoop
END Test.

When I execute `oo2c -M -v -r .. Test.Mod' I get the following output:

cd e:/home/ob2/c-interface/src/
oo2c -M -v -r .. Test.Mod
- /usr/local/lib/oo2c/pkginfo.xml
- /home/ob2/c-interface/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
- /usr/local/lib/oo2c/sym/C.Sym
- /home/ob2/c-interface/src/Glut.Mod
- /home/ob2/c-interface/src/Glut.Mod
+ /home/ob2/c-interface/obj/Glut.d
+ /home/ob2/c-interface/obj/Glut.oh
+ /home/ob2/c-interface/sym/Glut.Doc
+ /home/ob2/c-interface/sym/Glut.Sym
- /home/ob2/c-interface/sym/Glut.Sym
+ /home/ob2/c-interface/obj/Test_.c
gcc -O2 -I/usr/local/include -DGC_WIN32_THREADS -I/usr/local/lib/oo2c/src 
 -I/home/ob2/c-interface/obj -Iobj -I/usr/local/lib/oo2c/obj -c 
/home/ob2/c-interface/obj/Test_.c -o /home/ob2/c-interface/obj/Test_.o
gcc -o /home/ob2/c-interface/bin/Test -L/usr/local/lib 
/usr/local/lib/oo2c/obj/RT0.o /usr/local/lib/oo2c/obj/HashCode.o 
/usr/local/lib/oo2c/obj/Object.o /usr/local/lib/oo2c/obj/Exception.o 
/home/ob2/c-interface/obj/Test.o 
/home/ob2/c-interface/obj/Test_.o -lopengl32 -lglut32 -L/usr/local/lib
/home/ob2/c-interface/obj/Test.o(.text+0x5c):Test.c: undefined 
reference to `glutCreateWindow'
/home/ob2/c-interface/obj/Test.o(.text+0x6d):Test.c: undefined 
reference to `glutDisplayFunc'
/home/ob2/c-interface/obj/Test.o(.text+0x78):Test.c: undefined 
reference to `glutMainLoop'

Compilation exited abnormally with code 1 at Tue Nov 02 03:14:32

What am I doing wrong? Note that both `-lopengl32' and `-lglut32' 
appears in the output (in the correct relative order).

Regards,
August 

[ooc-compiler] Announcing libpobj

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

Introduction
============

   Persistent Objects for OOC is a framework for storing object data
in a RDBMS.  Or, if one starts with a database, a framework that
presents relational data as a set of objects.  It consists of a thin
library ("thin" because aspects of RDBMS shine through in parts) and a
code generator that provides the glue code bridging the gap from
internal to external data representation.  For the most part, the
"glue" are get and set methods on otherwise hidden record fields
within classes representing table rows.

   A number of basic assumptions guide the design and implementation of
the persistence layer:

* The goal is to make the use of persistent objects in a program as
  convenient as possible.  Developers should be able to operate on
  persistent objects similar to normal objects.

* Referential integrity between table rows is preserved in memory.
  That is, all foreign key references to a particular row in the
  relational database are mapped to pointers to a single object in
  memory, and vice versa.

* Access is provided to table data, views, and arbitrary selects.  The
  API provides a similar interface for all of these variants.  A
  subset of SQL is made available to the application as a simple query
  language.  Depending on the type of application, the scope of this
  subset is powerful enough to cover a large part of the queries it
  needs to run.  If an application manipulates symbolic data, then all
  of its queries can typically formulated in this simple language.  On
  the other hand, for an application including number crunching, the
  aggregation of data must be done with manually crafted SQL selects.

* The framework offers sufficient flexibility to tune the tradeoff
  between convenience and performance.  For example, the running time
  of most applications is determined by the number of interactions
  between client program and database server.  Accordingly, the
  library offers ability to change from fine grained access to single
  objects to coarse grained data access internalizing thousands of
  objects with a single `select' statement.

* libpobj does not provide an object oriented view on *any* SQL
  database schema.  The persistence layer supports a limited number of
  mappings between relational data and objects.

* For the persistence mechanism to work, classes must be explicitly
  programmed for it.  That is, the library is not a mechanism that
  magically allows to store existing classes in a database.  Instead,
  the persistence capable classes must be derived from a common base
  class, `PObj.Object'.

* Not all aspects of persistence are hidden from the developer.
  Persistent objects differ in some details from normal objects.  For
  example, concurrency is not an issue if an object is under the full
  control of a program, but becomes very important if object data is
  serialized in a database, where several applications and users may
  access it simultaneously.  The persistence layer exposes details of
  the lower level database access if these details cannot be
  abstracted away without loss of control.  Most notably, the
  application must deal with transactions.

Basic Concepts
==============

   Three basic concepts summarize the operation of the persistent
object abstraction layer:

  1. Every table corresponds to a class.

  2. Every table row corresponds to an instance of the table's class.

  3. Every attribute in a table row corresponds to a member of the
     table's class.

   As far as the application is concerned, the database is a container
of objects

   * from which it can retrieve objects that were made persistent
     earlier,

   * where it can create new objects or can make changes to objects
     persistent, and

   * which it can query for lists of objects satisfying a given set of
     criteria.

   The authoritative source of persistent data is always the database.
In general, it must be assumed that multiple processes are reading and
writing to the same database at the same time.  This means, that all
objects and their state held locally be the application are only
copies of the original data, and may become out of date immediately
after they were taken from the database.  (This is another aspect of a
shared database that is _not_ abstracted away by libpobj, although
some features of its implementation try to lessen the impact of this
fact.)

   As far as possible, data items from the database are presented to the
application in a format suitable for easy access by the programming
language.  For example, a table attribute like `VARCHAR(n)' is mapped
onto string objects, while a foreign key constraint is translated into
a object reference (aka pointer) representing the row of the key's
target table.


Examples
========

The most basic example assumes a table representing a person.  It has
two data columns, `firstName' and `lastName', both of type string.
Additionally, it has an integer primary key column (implicitly named
`id') that is fed from a database sequence `Seq_Person'.

Class definition in the meta-data file:

    <class name="Person">
      <idField sequenceName="Seq_Person"/>
      <field name="firstName" schemaName="first_name">
	<string size="128"/>
      </field>
      <field name="lastName" schemaName="last_name">
	<string size="128"/>
      </field>
    </class>

The table definition for our RDBMS system (Postgres in this case)
looks like this:

    CREATE SEQUENCE Seq_Person;
    CREATE TABLE Person (
      id INTEGER CONSTRAINT nn_Person_id NOT NULL,
	CONSTRAINT pk_Person PRIMARY KEY(id),
      first_name VARCHAR(64) CONSTRAINT nn_Person_first_name NOT NULL,
      last_name VARCHAR(64) CONSTRAINT nn_Person_last_name NOT NULL
    );

Now to application's view on this table and its rows.  First, create
our object container `cnt' on top of the database connection `conn'
and start a transaction:

    cnt := NEW(PostgresContainer.Container, conn);
    cnt.BeginTransaction();

Add an object to the database table `Person':

    person := NEW(DB.Person, "Michael", "van Acken");
    cnt.MakePersistent(person);
    person.Store();

Retrieve all `Person' objects from the corresponding table:

    q := cnt.NewQuery();
    q.AddTableExpr(DB.person, FALSE);
    res := q.Execute();

At this place, `res[0,0]' holds the first object, `res[1,0]' the
second, and so on.  To retrieve a subset of all persons matching a
particular pattern, one needs to add a filter predicate to the query:

    q := cnt.NewQuery();
    q.AddTableExpr(DB.person, FALSE);
    q.AddConj(PObj.Like(PObj.Member1(0, DB.personFirstName),
                        NEW(PObj.Literal, "Mich%")));
    res := q.Execute();

This returns all `Person' objects whose first name begins with `Mich'.
Removing a table row:

    person.Delete();
    Store();

And finally, closing the transaction:

    cnt.CommitTransaction();

--------

The text above can also be found in the project's README file at 
http://cvs.sourceforge.net/viewcvs.py/ooc/libpobj/

One might ask why I am going to the trouble of announcing this
particular library.  After all, this project is more than a year old,
as an inspection of the CVS repository does confirm.

The reason for this is that I may be able to improve and to add to
this project in the next time, due to some synergies between this
Oberon-2 library and tools and my payed job.

To take full advantage of this, the library needs more people that
actively use it.  There are a lot of different kinds of applications
out there, all with their own particular view on their data.  I am
able to provide one or two different kinds of applications with
persistent data (and libpobj is perfectly suited to serve these
applications as it is :-), but experience shows that this is not
enough to get to a design that is both simple and powerful for a wide
range of applications.

This mail is a poll to find out if there are people on this mailing
list who are able and willing to actively use this library, and to
make sure that it covers a wide range of needs.  Without such
participation, I can do without such tedious things like
documentation, examples, tutorial, automated tests, versioning,
releases and the like, making things vastly simpler for me and saving
lots and lots of time :-)

-- mva

[ooc-compiler] Calling GTK from Oberon

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

For quite a time I have been missing the tools for real-world programs
in Oberon. With 'real-world' I mean:
1. Result is an executable for a widely used OS
2. Has a GUI

The drawbacks of the existing systems are:
- user groups even smaller than the Oberon community as a whole, so
   existence/continuity and help depend on very few people (e.g. Visual
   Oberon)
- Restricted set of GUI elements and little or no development activities
   in this respect (e.g. Blackbox)

So I tried to call GTK functions from an Oberon program using the ooc
compiler, and with the valuable help of Stewart Greenhill it worked
pretty well.

Some positive and negative points:

+ GTK and ooc are available for Windows and Unix
+ GTK is very complete with a huge community behind
+ ooc doesn't allow only access to GTK, but to other libraries as well
+ GUI builder available: With Glade, the GUI can be laid out
   graphically. It can generate (among others) C source code which has
   to be translated manually to Oberon. This is still much less work
   if you do not know GTK very well.

- If it is for the first time, installation of all the packages (ooc, gc
   (garbage collector), GTK, ...) will take some time. This is specially
   true for Windows, where GTK installation is a little more complicated
   and which requires some additional packages (mingw, msys).
- GTK is somewhat clumsy, especially if you compare it with the elegance
   of 'Gadgets' (OS Oberon).
- Access of libraries means 'unsafe'. (But the modularity of Oberon lets
   you cleanly separate safe from unsafe parts.)

If you are interested in my example, I can send it to you. Write to
hreba then there is an 'at', then comes
terra followed by a dot, then
com another dot and finally
br

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

[ooc-compiler] Bug (?)

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

I think I found a small bug: trying to make an executable from the two 
modules
--
MODULE client;
VAR v*: RECORD a*,b*: INTEGER
         END;
END client.
--
MODULE main;
IMPORT client;
BEGIN
   client.v.a:=1;  client.v.b:=2
END main.
--
yields the following error message:
   In file included from obj/client.c:1:
   obj/client.d:5: conflicting types for `client__v'
   obj/client.oh:12: previous declaration of `client__v'

I don't need a fix for it; just to let you know.

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

Re: [ooc-compiler] Installationproblem

[vedmed <ve...@in...>]

Hello Marco,

Thursday, September 30, 2004, 3:45:44 AM, you wrote:

MO> I wanted to install oo2c 2.1.4 on a new machine today and I failed.
MO> I did not find help in PROBLEMS, INSTALL or README.

MO> I installed gc 6.3 alpha 6. Then ./configure in oo2c's directory works fine.
MO> I use enable-threads parameter. make leads to "undefined reference to '__compound_literal.7"
MO> and similar messages in stage0. The same happens with oo2c 2.1.3.

MO> The computer is a Via Mini-ITX based one. So this may be a reason.
MO> I installed SuSE 9.1 with gcc 3.3.3 and libtool 1.5.2. Kernel is 2.6.5.

MO> Does anyone have a clue?

I have the same problem on same system. gcc 3.3.3 fail to build oo2c
with -O2 try -O1 optimization as workaround.

gcc 3.3.3 on SuSE 9.1 can not build programs like following:

#include <stdio.h>

typedef struct StrDesc *Str;
typedef struct StrDesc {
  Str *list;
} StrDesc;

static StrDesc str_a = 
{ 
  (Str[])
  {
    NULL
  }
};

static StrDesc str_b =
{
  (Str[])
  {
    &str_a
  }
};

void dummy_mod(Str md)
{

};

void dummy() {
  dummy_mod(&str_b);
}

int main()
{
  return 0;
}

-- 
Best regards,
 vedmed                            mailto:ve...@in...

[ooc-compiler] Installationproblem

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

Hello!

I wanted to install oo2c 2.1.4 on a new machine today and I failed.
I did not find help in PROBLEMS, INSTALL or README.

I installed gc 6.3 alpha 6. Then ./configure in oo2c's directory works fine.
I use enable-threads parameter. make leads to "undefined reference to '__compound_literal.7"
and similar messages in stage0. The same happens with oo2c 2.1.3.

The computer is a Via Mini-ITX based one. So this may be a reason.
I installed SuSE 9.1 with gcc 3.3.3 and libtool 1.5.2. Kernel is 2.6.5.

Does anyone have a clue?

Greetings,
 Marco

Re: [ooc-compiler] make error after libxml2 update on FC1

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

Stewart Greenhill <sgr...@ii...> writes:

> Hi,
> 
> I've also had this problem under FC1. It seems to ship with a broken
> xsltproc. At least, for some files generated by OOC xsltproc will
> segfault. I think the bug is in libxml. You can verify this using gdb
> (see below). I was unable to fix this problem, even after reinstalling
> the libraries from source.
> 
> One workaround is to disable xsltproc. From memory, you can do this by
> setting:
>    XSLTPROC=no
> before you run configure.
> 
> Actually, I think this issue needs a statement in the installation
> documentation. Without an XSLT processor, oo2c will not generate
> documentation for the included modules. If the XSLT processor is there
> but is broken, it needs to be disabled before oo2c will build.

Unfortunately it is a little bit more complicated.  I have added this
entry to PROBLEMS:

  (xsltproc) If the xsltproc binary is present but chokes on the
  documentation XML written by the compiler, then building the compiler
  fails.  A workaround is to do disable xsltproc manually.
  To do this, change the xsltproc entry in rsrc/OOC/oo2crc.xml.mk to 

    <set name='xsltproc'>no</set>

  _after_ running configure, but _before_ running make.

-- mva

Re: [ooc-compiler] argv available?

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

Frank Hrebabetzky <fh...@ph...> writes:

> It seems I have a configuration problem on WinXP/MingW/oo2c:
> 'oob RTO' yields 'cannot locate module RTO'.
> If I 'cd c:/usr/local/lib/oo2c' and 'oob RTO.Sym', it says 'No such
> file or directory: sym/RTO.Sym'. But it is there. I see it.

This looks like O vs 0.  You need RT-zero-.

-- mva

Re: [ooc-compiler] argv available?

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

It seems I have a configuration problem on WinXP/MingW/oo2c:
'oob RTO' yields 'cannot locate module RTO'.
If I 'cd c:/usr/local/lib/oo2c' and 'oob RTO.Sym', it says 'No such file 
or directory: sym/RTO.Sym'. But it is there. I see it.

Any idea?
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Brasil



Stewart Greenhill wrote:
> These are declared in RT0. Do "oob RT0" and you will find:
>   ...
>   argc-: LONGINT;
>   argv-: POINTER TO ARRAY OF POINTER TO ARRAY OF CHAR;

Re: [ooc-compiler] make error after libxml2 update on FC1

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

Hi,

I've also had this problem under FC1. It seems to ship with a broken  
xsltproc. At least, for some files generated by OOC xsltproc will  
segfault. I think the bug is in libxml. You can verify this using gdb  
(see below). I was unable to fix this problem, even after reinstalling  
the libraries from source.

One workaround is to disable xsltproc. From memory, you can do this by  
setting:
   XSLTPROC=no
before you run configure.

Actually, I think this issue needs a statement in the installation  
documentation. Without an XSLT processor, oo2c will not generate  
documentation for the included modules. If the XSLT processor is there  
but is broken, it needs to be disabled before oo2c will build.

Cheers,
   Stewart

% gdb /usr/bin/xsltproc
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "i386-redhat-linux-gnu"...
(no debugging symbols found)...Using host libthread_db library  
"/lib/libthread_db.so.1".

(gdb) run -o oocdoc/html/X11/X11.html  
/usr/project/stewartg/local/lib/oo2c/rsrc/OOC/xml/interface- 
description.xsl oocdoc/xml/X11/X11.xml
Starting program: /usr/bin/xsltproc -o oocdoc/html/X11/X11.html  
/usr/project/stewartg/local/lib/oo2c/rsrc/OOC/xml/interface- 
description.xsl oocdoc/xml/X11/X11.xml
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 9372)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9372)]
0x44d6f582 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
(gdb) backtrace
#0  0x44d6f582 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
#1  0x44b3db3d in free () from /lib/i686/libc.so.6
#2  0x45997c4c in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#3  0x45997b80 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#4  0x45997b80 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#5  0x4599544d in xmlFreeDoc () from /usr/lib/libxml2.so.2
#6  0x001233a8 in xsltFreeStylesheet (sheet=0x80581a8) at xslt.c:484
#7  0x08049f92 in main ()
(gdb)

> After I updated libxml2 package on Fedora Core 1, I could not make and  
> install oo2c_32-2.1.4.
> However, with the previous versions of libxml2 and oo2c  everyting was  
> fine.
>
> The libxml2 packages were updated to:
>    libxml2-2.6.6-3.i386.rpm
>    libxml2-devel-2.6.6-3.i386.rpm
>    libxml2-python-2.6.6-3.i386.rpm
>
> $ ./configure :  gives no error.
> $ make : gives the following error at the end.
>
> Thanks for any help,
>
> Necati.
>
>
> ***** Make error ***
> ....
> /Builder/ParserProtocol.o lib/obj/XML/UnicodeCodec/UTF8.o  
> lib/obj/XML/EntityResolver.o lib/obj/XML/Builder/Namespaces.o  
> lib/obj/XML/Regexp.o lib/obj/XML/UnicodeCodec/UTF16.o  
> lib/obj/XML/Parser.o lib/obj/XML/Builder/Validation.o  
> lib/obj/XML/UnicodeCodec/ASCII.o lib/obj/XML/UnicodeCodec/Latin1.o  
> lib/obj/XML/UnicodeCodec/ImportAll.o lib/obj/XML/Basic/Element.o  
> lib/obj/XML/Basic/Parser.o lib/obj/XML/Basic/DataType.o  
> lib/obj/libxml.o lib/obj/Codec.o lib/obj/Codec/Ascii.o  
> lib/obj/Codec/Latin1.o lib/obj/liboo2c.o
> ranlib lib/obj/.libs/liboo2c.a
> creating lib/obj/liboo2c.la
> (cd lib/obj/.libs && rm -f liboo2c.la && ln -s ../liboo2c.la  
> liboo2c.la)
> + lib/oocdoc/xml/RT0.xml
> /usr/bin/xsltproc -o lib/oocdoc/html/RT0.html  
> /home/necati/oo2c_32-2.1.4/rsrc/OOC/xml/interface-description.xsl  
> lib/oocdoc/xml/RT0.xml
> make: *** [lib/obj/liboo2c.la] Error 1
>
> ******************
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] argv available?

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

Hi Frank.

These are declared in RT0. Do "oob RT0" and you will find:
   ...
   argc-: LONGINT;
   argv-: POINTER TO ARRAY OF POINTER TO ARRAY OF CHAR;
   ...

Cheers,
   Stewart

On Wednesday, September 1, 2004, at 04:34  AM, Frank Hrebabetzky wrote:

> I want to translate a little C program to Oberon which contains the 
> line
>     gtk_init (&argc, &argv);
> Now how do I get argv? Do I have to construct a pointer to an array of 
> pointers to caracter arrays from what module ProgramArgs gives me, or 
> is it somewhere directly available?
> -- 
> Frank Hrebabetzky		Tel.:  +55/48/239-2258
> Brasil
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

[ooc-compiler] argv available?

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

I want to translate a little C program to Oberon which contains the line
     gtk_init (&argc, &argv);
Now how do I get argv? Do I have to construct a pointer to an array of 
pointers to caracter arrays from what module ProgramArgs gives me, or is 
it somewhere directly available?
-- 
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Brasil

[ooc-compiler] make error after libxml2 update on FC1

[Necati E. <fn...@gy...>]

Hi,

After I updated libxml2 package on Fedora Core 1, I could not make and 
install oo2c_32-2.1.4.
However, with the previous versions of libxml2 and oo2c  everyting was fine.

 The libxml2 packages were updated to:
    libxml2-2.6.6-3.i386.rpm
    libxml2-devel-2.6.6-3.i386.rpm
    libxml2-python-2.6.6-3.i386.rpm

$ ./configure :  gives no error.
$ make : gives the following error at the end.

Thanks for any help,

Necati.


***** Make error ***
....
/Builder/ParserProtocol.o lib/obj/XML/UnicodeCodec/UTF8.o 
lib/obj/XML/EntityResolver.o lib/obj/XML/Builder/Namespaces.o 
lib/obj/XML/Regexp.o lib/obj/XML/UnicodeCodec/UTF16.o 
lib/obj/XML/Parser.o lib/obj/XML/Builder/Validation.o 
lib/obj/XML/UnicodeCodec/ASCII.o lib/obj/XML/UnicodeCodec/Latin1.o 
lib/obj/XML/UnicodeCodec/ImportAll.o lib/obj/XML/Basic/Element.o 
lib/obj/XML/Basic/Parser.o lib/obj/XML/Basic/DataType.o lib/obj/libxml.o 
lib/obj/Codec.o lib/obj/Codec/Ascii.o lib/obj/Codec/Latin1.o 
lib/obj/liboo2c.o
ranlib lib/obj/.libs/liboo2c.a
creating lib/obj/liboo2c.la
(cd lib/obj/.libs && rm -f liboo2c.la && ln -s ../liboo2c.la liboo2c.la)
+ lib/oocdoc/xml/RT0.xml
/usr/bin/xsltproc -o lib/oocdoc/html/RT0.html 
/home/necati/oo2c_32-2.1.4/rsrc/OOC/xml/interface-description.xsl 
lib/oocdoc/xml/RT0.xml
make: *** [lib/obj/liboo2c.la] Error 1

******************

[ooc-compiler] oo2c-2.1.4 released

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

Changes:

(oo2c) Fix size computation for local copy of array value parameter if
the array has more than one open dimension.

(oo2c) Don't crash if the source value of a non-scalar assignment is a
SYSTEM.VAL().

(oo2c) Fix type glitch when doing type conversion on character
constants.

-- mva