ooc-compiler

Re: [ooc-compiler] Position of runtime error

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

Marco Oetken wrote:
> Just pipe the output to ooef. As you
> can see below ooef finds line number and column for each
> source file with error or warning.  I have oo2c 2.1.4
> installed, but it should work also with current version.
> 
> bash> oo2c -M ExtractPopNeu |ooef
> src/SimpleDB/Collection.Mod:335:13: Warning: Variable may be undefined
> src/SimpleDB/Collection.Mod:335:13: Warning: Variable may be undefined
> src/ExtractPopNeu.Mod:76:25: Undeclared identifier
> src/ExtractPopNeu.Mod:80:25: Undeclared identifier
> src/ExtractPopNeu.Mod:89:25: Undeclared identifier
> src/ExtractPopNeu.Mod:92:25: Undeclared identifier

This is the kind of output I get by default from oo2c 2.1.8 without 
using ooef (not sure if ooef has any effect in this case). It's the 
runtime errors I'm talking about, not compilation errors. Thanks anyway.

-- 
August

Re: [ooc-compiler] Position of runtime error

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

Hello!

I have been working too little with oo2c in recent months
so I did not even remember "ooef" before Stewart Greenhill
mentioned it. But after that I even remembered how I used
and I tried it again. Just pipe the output to ooef. As you
can see below ooef finds line number and column for each
source file with error or warning.  I have oo2c 2.1.4
installed, but it should work also with current version.

bash> oo2c -M ExtractPopNeu |ooef
src/SimpleDB/Collection.Mod:335:13: Warning: Variable may be undefined
src/SimpleDB/Collection.Mod:335:13: Warning: Variable may be undefined
src/ExtractPopNeu.Mod:76:25: Undeclared identifier
src/ExtractPopNeu.Mod:80:25: Undeclared identifier
src/ExtractPopNeu.Mod:89:25: Undeclared identifier
src/ExtractPopNeu.Mod:92:25: Undeclared identifier

Greetings,
 Marco

----- Original Message ----- 
From: "Stewart Greenhill" <sgr...@ii...>
To: "August Karlstrom" <fus...@co...>
Cc: <ooc...@li...>
Sent: Friday, May 13, 2005 4:13 PM
Subject: Re: [ooc-compiler] Position of runtime error


> Hi August,
> 
>> In runtime error messages, OOC outputs the position where the error 
>> occurred but no info on line (or column) number, for instance:
>>
>> ##
>> ## Runtime error in module Test at pos 171
>> ## Dereference of NIL
>> ##
>>
>> It's kind of hard to find the position in an editor that lacks Emacs' 
>> `goto-char' function and even for Emacs users it would be more 
>> convenient with a line (and a column) number.
> [...]
> 
> You can get this information using the 'ooef' utility.
> 
> For example,
>   ooef src/Test.Mod 171
> 
> This gives you the source code context (the default behaviour, also 
> available via the --context switch). If you just want to know the line 
> and column you can do:
>   ooef --linecol src/Test.Mod 171
> 
> Hope this helps.
> 
> Cheers,
>   Stewart
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] Position of runtime error

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

Hi August,

> In runtime error messages, OOC outputs the position where the error 
> occurred but no info on line (or column) number, for instance:
>
> ##
> ## Runtime error in module Test at pos 171
> ## Dereference of NIL
> ##
>
> It's kind of hard to find the position in an editor that lacks Emacs' 
> `goto-char' function and even for Emacs users it would be more 
> convenient with a line (and a column) number.
[...]

You can get this information using the 'ooef' utility.

For example,
   ooef src/Test.Mod 171

This gives you the source code context (the default behaviour, also 
available via the --context switch). If you just want to know the line 
and column you can do:
   ooef --linecol src/Test.Mod 171

Hope this helps.

Cheers,
   Stewart

[ooc-compiler] Position of runtime error

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

Hello all,

In runtime error messages, OOC outputs the position where the error 
occurred but no info on line (or column) number, for instance:

##
## Runtime error in module Test at pos 171
## Dereference of NIL
##

It's kind of hard to find the position in an editor that lacks Emacs' 
`goto-char' function and even for Emacs users it would be more 
convenient with a line (and a column) number.

If the function _runtime_error in lib/src/RT0.c made a call to the 
function GetLineAndColumn below the error message could be output as for 
instance:

##
## Runtime error in module Test at pos 171 (line 11, column 3)
## Dereference of NIL
##

Comments?


Regards,
August


(I suspect that there may be some library function somewhere that does 
the same thing as GetLineAndColumn)

/*
  * GetLineAndColumn(f, p, &ln, &c) calculates line number ln and
  * column number c corresponding to position p in file f .
  *
  * precondition: p > 0
  *
  * postcondition: ln > 0 and c >= 0
  */

static void GetLineAndColumn(const char *filename, int pos,
                              /*@out@*/ int *line, /*@out@*/ int *column)
{
    FILE *f;
    int i, c, ret;

    assert(pos > 0);
    f = fopen(filename, "r");
    if (f == NULL) { perror(__func__); exit(EXIT_FAILURE); }
    *line = 1;
    *column = 0;
    for (i = 1; i < pos; i++) {
       c = fgetc(f);
       if (ferror(f)) {
          perror(__func__); exit(EXIT_FAILURE);
       } else if (feof(f)) {
          fprintf(stderr, "%s: Reached end of file\n", __func__);
          exit(EXIT_FAILURE);
       } else if (c == '\n') {
          (*line)++; *column = 0;
       } else {
          (*column)++;
       }
    }
    ret = fclose(f);
    if (ret == EOF) { perror(__func__); exit(EXIT_FAILURE); }
    assert((*line > 0) && (*column >= 0));
}

Re: [ooc-compiler] Bug?

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

August <fus...@co...> writes:

> oo2c 2.1.8 have problems with the module below. The outcommented EXIT
> statement seems to cause the problem (of course, this makes it a useless
> procedure).

Thanks.  I can reproduce this and will look into it.  The module that
has the failed ASSERT is rather tricky, though.  I can't even guess
how long it will take to resolve this.

-- mva


> 
> MODULE Test;
> 
>    PROCEDURE Index*(VAR (*in*) s: ARRAY OF CHAR; c: CHAR): LONGINT;
>       VAR i: LONGINT; d: CHAR;
>    BEGIN
>       i := 0;
>       LOOP
>          d := s[i];
>          IF (s[i] = 0X) OR (s[i] = c) THEN (* EXIT *) END;
>          INC(i)
>       END;
>       IF d = 0X THEN RETURN -1 ELSE RETURN i END
>    END Index;
> 
> END Test.
> 
> $ oo2c -M -r .. Test.Mod
> 
> ## 
> ## Runtime error in module OOC:SSA:Allocator at pos 28952
> ## Assertion failed, code 127
> ## 
> 0: /usr/local/lib/liboo2c.so.3 [0xbd2037]
> 1: /usr/local/lib/liboo2c.so.3(_runtime_error+0x3a) [0xbd20c6]
> 2: /usr/local/lib/liboo2c.so.3(RT0__Halt+0) [0xbd26b8]
> 3: oo2c [0x811b265]
> 4: oo2c [0x811b1fd]
> 5: oo2c [0x811b1fd]
> 6: oo2c [0x811c4a6]
> 7: oo2c [0x811cb95]
> 8: oo2c [0x8126d9a]
> 9: oo2c [0x80ec85c]
> 10: oo2c [0x80ecd98]
> 11: oo2c [0x80ed486]
> 12: oo2c [0x814a4e7]
> 13: oo2c [0x814a82e]
> 14: oo2c [0x814c86f]
> 15: oo2c [0x814bfd9]
> 16: oo2c [0x814c77b]
> 17: oo2c [0x81504c9]
> 18: oo2c [0x8150886]
> 19: oo2c [0x81508bb]
> 20: /lib/tls/libc.so.6(__libc_start_main+0xe3) [0x16ae33]
> make: *** [Test] Error 127
> 
> -- 
> August
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler

[ooc-compiler] Bug?

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

oo2c 2.1.8 have problems with the module below. The outcommented EXIT
statement seems to cause the problem (of course, this makes it a useless
procedure).

MODULE Test;

   PROCEDURE Index*(VAR (*in*) s: ARRAY OF CHAR; c: CHAR): LONGINT;
      VAR i: LONGINT; d: CHAR;
   BEGIN
      i := 0;
      LOOP
         d := s[i];
         IF (s[i] = 0X) OR (s[i] = c) THEN (* EXIT *) END;
         INC(i)
      END;
      IF d = 0X THEN RETURN -1 ELSE RETURN i END
   END Index;

END Test.

$ oo2c -M -r .. Test.Mod

## 
## Runtime error in module OOC:SSA:Allocator at pos 28952
## Assertion failed, code 127
## 
0: /usr/local/lib/liboo2c.so.3 [0xbd2037]
1: /usr/local/lib/liboo2c.so.3(_runtime_error+0x3a) [0xbd20c6]
2: /usr/local/lib/liboo2c.so.3(RT0__Halt+0) [0xbd26b8]
3: oo2c [0x811b265]
4: oo2c [0x811b1fd]
5: oo2c [0x811b1fd]
6: oo2c [0x811c4a6]
7: oo2c [0x811cb95]
8: oo2c [0x8126d9a]
9: oo2c [0x80ec85c]
10: oo2c [0x80ecd98]
11: oo2c [0x80ed486]
12: oo2c [0x814a4e7]
13: oo2c [0x814a82e]
14: oo2c [0x814c86f]
15: oo2c [0x814bfd9]
16: oo2c [0x814c77b]
17: oo2c [0x81504c9]
18: oo2c [0x8150886]
19: oo2c [0x81508bb]
20: /lib/tls/libc.so.6(__libc_start_main+0xe3) [0x16ae33]
make: *** [Test] Error 127

-- 
August

[ooc-compiler] oo2c-2.1.8 released

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

(IO:TextRider) Apply patch from Michael Mokeev to ReadLn: ReadChar
sees LF when called after a ReadLn.

(Object:BigInt) Syntax error now returns NIL.

(Logger) Report() should write to debug log even if the report log is
disabled.

There are also many enhancements to the C header to Oberon converter
H2O.  The tar ball contains the current sources from CVS, but the tool
is not build by default.

-- mva

Re: [ooc-compiler] Handling C "in" parameters

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

On fre, 2005-02-18 at 17:02 +0800, Stewart Greenhill wrote:
> If you like, I can 
> e-mail you the generated files. It needs a little work to be properly 
> usable, but may save you some time over doing manual translation.

Yes, that would be great. Thanks.

-- 
August

Re: [ooc-compiler] SYSTEM module documentation

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

On fre, 2005-02-18 at 07:56 +0100, Michael van Acken wrote:
> Cast the BYTE to CHAR first: SYSTEM.VAL(CHAR,x)

Thanks for the info. Perhaps it's best to use CHAR after all.

-- 
August

Re: [ooc-compiler] Handling C "in" parameters

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

Hi August,

>> I suggest that you do something like this:
>>
>> PROCEDURE ["SDL_PollEvent"] PollEvent*(VAR event: Event): C.int;
>
> Yes, this is the ideal solution. I didn't know that VAR parameters and
> pointers were compatible in this case.

In this context, a VAR parameter is a kind of "enhanced" pointer since 
it can point to an object on the stack or the heap. For Oberon-2 
RECORDS, the compiler passes the pointer and an additional hidden 
argument which is its type descriptor. For heap-based records, it uses 
the type descriptor from the heap object. For stack-based records it 
uses the descriptor for the (static) type of the record.

For foreign "C" records, there is of course no type information. You 
can declare "VAR event [NIL_COMPAT]" which allows you to pass NIL as 
the reference for a VAR parameter.

> By the way, I have heard of a C header to Oberon-2 conversion tool
> called H2O. Do you know where I can get it?

Its in the CVS repository. Check this message for some details:
   http://sourceforge.net/mailarchive/message.php?msg_id=10766629

Since I'm also interested, I tried compiling the libsdl headers. The 
current CVS version of H2O handles version 1.2.7 of libsdl. By that, I 
mean that it compiles the "C" code, and produces compilable Oberon-2 
modules (with a couple of small manual changes). If you like, I can 
e-mail you the generated files. It needs a little work to be properly 
usable, but may save you some time over doing manual translation.

Cheers,
   Stewart

Re: [ooc-compiler] SYSTEM module documentation

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

August <fus...@co...> writes:

> On fre, 2005-02-18 at 10:30 +0800, Stewart Greenhill wrote:
> > The module SYSTEM is documented in the Oberon-2 language report. 
> 
> The procedures BIT, CC and GET does not seem to be present (The March
> 1995 ed. of the language report also mentions GETREG and PUTREG and
> these are not present either). 

Only a subset of the original Oberon system's SYSTEM functions is
available.  With oo2c, some of them cannot be provided at all, and
others are too painful in the long run.

> If I have a CHAR I can e.g. inspect the
> second rightmost bit with:
> 
> x: CHAR;
> ...
> IF ODD(ORD(SYSTEM.LSH(x, -1)) THEN ... ELSE ... END
> 
> but how do I do that with a BYTE?

Cast the BYTE to CHAR first: SYSTEM.VAL(CHAR,x)

-- mva

Re: [ooc-compiler] SYSTEM module documentation

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

On fre, 2005-02-18 at 10:30 +0800, Stewart Greenhill wrote:
> The module SYSTEM is documented in the Oberon-2 language report. 

The procedures BIT, CC and GET does not seem to be present (The March
1995 ed. of the language report also mentions GETREG and PUTREG and
these are not present either). If I have a CHAR I can e.g. inspect the
second rightmost bit with:

x: CHAR;
...
IF ODD(ORD(SYSTEM.LSH(x, -1)) THEN ... ELSE ... END

but how do I do that with a BYTE?

-- 
August

Re: [ooc-compiler] Handling C "in" parameters

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

On fre, 2005-02-18 at 10:09 +0800, Stewart Greenhill wrote:
> I suggest that you do something like this:
> 
> PROCEDURE ["SDL_PollEvent"] PollEvent*(VAR event: Event): C.int;

Yes, this is the ideal solution. I didn't know that VAR parameters and
pointers were compatible in this case.

By the way, I have heard of a C header to Oberon-2 conversion tool
called H2O. Do you know where I can get it?

Thanks,
August

Re: [ooc-compiler] SYSTEM module documentation

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

Hi August,

> Where Is the SYSTEM module documented?

The module SYSTEM is documented in the Oberon-2 language report. It 
would be nice to be able to do "oob SYSTEM", but unfortunately this 
does not work (I often do this absentmindedly when I've forgotten the 
order of arguments to SYSTEM.MOVE, or SYSTEM.VAL). The SYSTEM functions 
and types are built into the compiler so they don't have external 
symbol files or documentation.

You can find the Oberon-2 report on the web. For example, here:
   http://www.oberon.ethz.ch/oreport.html#SYSTEM
Otherwise, there is a texinfo version in the OOC CVS repository under 
"doc/language/oberon2.texi".

Cheers,
   Stewart

Re: [ooc-compiler] Handling C "in" parameters

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

Hi August,

> In my program I want to use some functionality from the SDL (Simple
> Directmedia Layer) C library. The API contains the function:
>
> int SDL_PollEvent(SDL_Event *event)
>
> where `SDL_Event' is a union type. In the interface file I have the
> definitions:
>
> EventPtr* = POINTER TO Event;
> Event* = RECORD [UNION] ... END;
>
> PROCEDURE ["SDL_PollEvent"] PollEvent*(event: EventPtr): C.int;
>
> If the client code contains:
>
> event: EventPtr
> ...
> NEW(event)
>
> I get an error about `_td_Sdl__EventPtr' being undeclared. How do I
> use/port this function?

You can't use NEW to allocate a non-Oberon record type, not foreign "C" 
types. I think the compiler should have given you a more intelligent 
error message (ie. at the NEW() statement), but the problem is 
occurring later because the record has no type descriptor. If you 
really need to allocate the record on the heap use RT0.NewBlock, but I 
think it is OK to just allocate the event as a local variable.

I suggest that you do something like this:

PROCEDURE ["SDL_PollEvent"] PollEvent*(VAR event: Event): C.int;

Then you can use it like:

PROCEDURE HandleEvents;
VAR
   e : SDL.Event;
BEGIN
   ...
   WHILE SDL.PollEvent(e) # 0 DO
     CASE e.type OF
       SDL.KEYDOWN:

Another option is wrapping the event in an Oberon-2 RECORD. This might 
be useful if (for example) you want to queue the events for later 
processing.

TYPE
   Event = RECORD
     event : SDL.Event;
   END:
   PtrEvent = POINTER TO Event;

PROCEDURE HandleEvents;
VAR
   se : SDL.Event;
   e : PtrEvent;
BEGIN
   ...
   WHILE SDL.PollEvent(se) # 0 DO
     NEW(e);
     e.event := se;
     Enqueue(e);
   END;

Hope this helps.

Cheers,
   Stewart

[ooc-compiler] SYSTEM module documentation

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

Where Is the SYSTEM module documented?

-- 
August

[ooc-compiler] Handling C "in" parameters

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

Hello all,

In my program I want to use some functionality from the SDL (Simple
Directmedia Layer) C library. The API contains the function:

int SDL_PollEvent(SDL_Event *event)

where `SDL_Event' is a union type. In the interface file I have the
definitions:

EventPtr* = POINTER TO Event;
Event* = RECORD [UNION] ... END;

PROCEDURE ["SDL_PollEvent"] PollEvent*(event: EventPtr): C.int;

If the client code contains:

event: EventPtr
...
NEW(event)

I get an error about `_td_Sdl__EventPtr' being undeclared. How do I
use/port this function?

-- 
August

Re: [ooc-compiler] New OpenGL bindings available

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

Hi Frank,

[...]

> On that note I would recommend using the C naming convention for the 
> the
> modules/header files, which is lowercase. Not that it matters that 
> much when
> porting; the most efficient way of doing it is with search/replace 
> which
> doesn't care (much) about case in identifiers.

The default behaviour is to use the header file name as the module 
name. Therefore, if you do:
   #include <OpenGL/gl.h>
the module will be called "gl.Mod". I tried to use an "Oberon-ish" 
convention by capitalising the first letter of the module name. 
Actually, you can call the module whatever you want by using the 
OutputName module attribute:
   MODULE "gl" {
     OutputName = "Gl";
     StripPrefix = "gl", "GL_", "GL";
   }
The StripPrefix attribute removes the specified prefixes from symbols 
in the defined module.

>> The new version is a complete rewrite of the old tool. The C front end
>> is missing some features that are in version 1 (eg. support for 
>> calling
>> conventions, record alignment) but the overall structure is cleaner 
>> and
>> more flexible. For example, the processor can now split an API into
>> component modules, and there are user-definable rules for controlling
>> the mapping from C to Oberon-2 where the original definitions are
>> ambiguous (eg. for pointers in procedure parameter lists). Once all of
>> the core features are in (and properly documented) I plan to add
>> support for some C++ constructs such as references, classes, and
>> namespaces.
>
> Kewl. At some point I'll build it and see how it copes with gl/glx.h.

Don't know much about that file, but I think it should work OK.

> I'm working my way through the 3rd edition of "OpenGL Superbible", 
> porting
> selected examples[1]. I can confirm that examples using GLUT timer 
> functions
> instead of the idle function don't have the same CPU impact.

Good to hear.

> One issue I've encountered is with the *ub variants of OpenGL 
> functions,
> specifically glColor3ub(). The parameters are of type Gl.ubyte which is
> aliased to CHAR. This means that a call like:
>
>   glColor3ub (255, 255, 0);
>
> has to be converted to:
>
>   Gl.Color3ub (CHR (255), CHR (255), CHR (0));
>
> Unfortunately this sort of abuse of the Oberon type system is 
> inevitable as
> long as the Oberon languages fail to properly[2] support unsigned 
> integer
> types.

Yes, this is a major pain in the neck. You could use SHORTINT instead 
of CHAR, but that doesn't really help since any integer in the range 
128..255 is not a legal SHORTINT constant. You would have to convert it 
to the equivalent negative number, which really does not help the 
readability of your code. From this standpoint, I think the CHR 
approach is probably better. OOC version 1 previously allowed large 
positive constants to be passed as integer arguments, but version 2 is 
more strict. Another option is to use Gl.Color3s, which is probably not 
much different in terms of performance. Fortunately, the API allows 
pretty much any integer size to be used - most APIs are not this 
flexible.

> [1] I would put the ported examples on my web server, but they don't 
> have a
> licence that permits distribution of derived works. They don't appear 
> to
> have a licence at all so by default copyright law prevents 
> distribution of
> derived works. 10 years ago I wouldn't have bothered about it but
> $cientology, RIAA and MPAA have between them made me far more cautious 
> these
> days.

Perhaps you could contact the author or the publisher to obtain 
permission. Suggest that it improves the examples by making them usable 
to more developers. People are usually OK about this sort of thing so 
long as appropriate credit is given.

There is some nice OpenGL tutorial code by Neon-Helium Productions:
   http://nehe.gamedev.net
That has been translated to at least a dozen languages, so it might be 
a good choice if you just want to try some stuff and see how it works. 
Of course, the book examples are in sync with the text so they're 
probably much more useful for the learning process.

Cheers,
   Stewart

Re: [ooc-compiler] New OpenGL bindings available

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

On Mon, Feb 07, 2005 at 09:52:09AM +0800, Stewart Greenhill wrote  :

> >Gl.Mod: MODULE Gl [ INTERFACE "C"; LINK LIB "GL" END ];
> >Glu.Mod: MODULE Glu [ INTERFACE "C"; LINK LIB "GLU" END ];
> >Glut.Mod: MODULE Glut [ INTERFACE "C"; LINK LIB "glut" END ];
> 
> Thanks for confirming that. I think every platform (Linux, Mac, 
> Windows) uses different names for these libraries.

On that note I would recommend using the C naming convention for the the
modules/header files, which is lowercase. Not that it matters that much when
porting; the most efficient way of doing it is with search/replace which
doesn't care (much) about case in identifiers.

> >I'd be interested to have the source code for the translator. The most
> >recent version of H2O I can find is h2o-20020204.tar.gz, which I 
> >gather is
> >not the version used to generate these interfaces.
>
> The new version is a complete rewrite of the old tool. The C front end 
> is missing some features that are in version 1 (eg. support for calling 
> conventions, record alignment) but the overall structure is cleaner and 
> more flexible. For example, the processor can now split an API into 
> component modules, and there are user-definable rules for controlling 
> the mapping from C to Oberon-2 where the original definitions are 
> ambiguous (eg. for pointers in procedure parameter lists). Once all of 
> the core features are in (and properly documented) I plan to add 
> support for some C++ constructs such as references, classes, and 
> namespaces.

Kewl. At some point I'll build it and see how it copes with gl/glx.h.

> >Running bin/Test2 consumed 100% of CPU to rotate a simple wireframe 
> >object.
> >This was a bit surprising on an Athlon 1700+ but I gather this is a
> >"feature" of the freeglut implementation of libglut.
> 
> The test just uses a Glut.IdleFunc procedure to update the state and 
> refresh the display. There's no "throttling" in there, so it may well 
> do this depending on how GLUT is implemented. A better way to do it 
> would be to use a Glut timer to limit the frame rate.

I'm working my way through the 3rd edition of "OpenGL Superbible", porting
selected examples[1]. I can confirm that examples using GLUT timer functions
instead of the idle function don't have the same CPU impact.

One issue I've encountered is with the *ub variants of OpenGL functions,
specifically glColor3ub(). The parameters are of type Gl.ubyte which is
aliased to CHAR. This means that a call like:

  glColor3ub (255, 255, 0);

has to be converted to:

  Gl.Color3ub (CHR (255), CHR (255), CHR (0));

Unfortunately this sort of abuse of the Oberon type system is inevitable as
long as the Oberon languages fail to properly[2] support unsigned integer
types.

[1] I would put the ported examples on my web server, but they don't have a
licence that permits distribution of derived works. They don't appear to
have a licence at all so by default copyright law prevents distribution of
derived works. 10 years ago I wouldn't have bothered about it but
$cientology, RIAA and MPAA have between them made me far more cautious these
days.

[2] Pet Peeve.

Frank Copeland
-- 
Let's not complicate our relationship by trying to communicate with each other.

Re: [ooc-compiler] New OpenGL bindings available

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

Hi Frank,

>> Under OSX, you can just do:
>>   oo2c -r . --make Test2
>>   bin/Test2
>
> This worked under Debian GNU/Linux (testing), after...
>
>> in the extracted directory. For other operating systems, you will have
>> to adapt the LINK directives in the interface files.
>
> Gl.Mod: MODULE Gl [ INTERFACE "C"; LINK LIB "GL" END ];
> Glu.Mod: MODULE Glu [ INTERFACE "C"; LINK LIB "GLU" END ];
> Glut.Mod: MODULE Glut [ INTERFACE "C"; LINK LIB "glut" END ];

Thanks for confirming that. I think every platform (Linux, Mac, 
Windows) uses different names for these libraries.

>> Also there (under "misc"), is the original source used by the
>> translator to generate the output modules. Unfortunately there's no
>> documentation yet for this tool but if you're interested this will 
>> give
>> you an idea how it works.
>
> I'd be interested to have the source code for the translator. The most
> recent version of H2O I can find is h2o-20020204.tar.gz, which I 
> gather is
> not the version used to generate these interfaces.

The source code is in the ooc2 CVS repository (under src/H2O). Its not 
stable yet, so is not built as a standard tool. Once you've checked out 
and configured the compiler source, you should be able to build the 
translator by doing:
   oo2c --config oo2crc-install.xml -Mv TestH2O
Alternatively, you can do "make test" under tests/h2o.

The new version is a complete rewrite of the old tool. The C front end 
is missing some features that are in version 1 (eg. support for calling 
conventions, record alignment) but the overall structure is cleaner and 
more flexible. For example, the processor can now split an API into 
component modules, and there are user-definable rules for controlling 
the mapping from C to Oberon-2 where the original definitions are 
ambiguous (eg. for pointers in procedure parameter lists). Once all of 
the core features are in (and properly documented) I plan to add 
support for some C++ constructs such as references, classes, and 
namespaces.

>> Feedback is welcome, although I can't necessarily help with any
>> problems at the moment.
>
> Running bin/Test2 consumed 100% of CPU to rotate a simple wireframe 
> object.
> This was a bit surprising on an Athlon 1700+ but I gather this is a
> "feature" of the freeglut implementation of libglut.

The test just uses a Glut.IdleFunc procedure to update the state and 
refresh the display. There's no "throttling" in there, so it may well 
do this depending on how GLUT is implemented. A better way to do it 
would be to use a Glut timer to limit the frame rate.

Thanks for the feedback. Glad to hear it works for someone else too ;-)

Cheers,
   Stewart

Re: [ooc-compiler] New OpenGL bindings available

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

On Mon, Jan 24, 2005 at 12:10:13PM +0800, Stewart Greenhill wrote:

> Feedback is welcome, although I can't necessarily help with any 
> problems at the moment.

I have an NVidia 6600 GT 3D video card. The first working version of Test2
gave this warning:

  Xlib:  extension "XFree86-DRI" missing on display

This was due to having the Mesa (ie - software) versions of the OpenGL *-dev
packages installed instead of the NVidia versions. Installing the Debian
nvidia-glx-dev package and rebuilding solved this problem.

Frank Copeland
-- 
He is truly wise who gains wisdom from another's mishap.

Re: [ooc-compiler] New OpenGL bindings available

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

On Mon, Jan 24, 2005 at 12:10:13PM +0800, Stewart Greenhill wrote:

> Here are some new bindings for OpenGL.

[...]

> Under OSX, you can just do:
>   oo2c -r . --make Test2
>   bin/Test2

This worked under Debian GNU/Linux (testing), after...

> in the extracted directory. For other operating systems, you will have 
> to adapt the LINK directives in the interface files.

Gl.Mod: MODULE Gl [ INTERFACE "C"; LINK LIB "GL" END ];
Glu.Mod: MODULE Glu [ INTERFACE "C"; LINK LIB "GLU" END ];
Glut.Mod: MODULE Glut [ INTERFACE "C"; LINK LIB "glut" END ];

> Also there (under "misc"), is the original source used by the 
> translator to generate the output modules. Unfortunately there's no 
> documentation yet for this tool but if you're interested this will give 
> you an idea how it works.

I'd be interested to have the source code for the translator. The most
recent version of H2O I can find is h2o-20020204.tar.gz, which I gather is
not the version used to generate these interfaces.

> Feedback is welcome, although I can't necessarily help with any 
> problems at the moment.

Running bin/Test2 consumed 100% of CPU to rotate a simple wireframe object.
This was a bit surprising on an Athlon 1700+ but I gather this is a
"feature" of the freeglut implementation of libglut.

Frank Copeland
-- 
A man is not complete until he is married -- then he is finished.

Re: [ooc-compiler] Installation problems on Fedora Core 3

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

August <fus...@co...> writes:

> Hello all,
> 
> I have some trouble installing OOC 2.1.7 on Fedora Core 3 Linux. I have
> installed gc6.3 and it seems to work. Any clues?

This problem seems to be a duplicate of a report I got early
December.  Which means that I can duplicate my past answer as well :-)

| Subject: Re: Problems Installing on Fedora Core 3
| References: <110...@cp...>
| From: Michael van Acken <mv...@us...>
| Date: 03 Dec 2004 17:33:57 +0100
| 
| Gregory Gelfond <xx...@yy...> writes:
| 
| > Hello,
| > 
| > I am attempting to install the latest version of oo2c on Fedora Core 3.
| > I already have gc and glibtool installed, and I get an error message
| > when attempting to run the following command:
| > 
| > env "CFLAGS=-O2 -pipe" ./configure
| > 
| > Here are the messages I am getting from configure:
| > 
| > checking for gcc... gcc
| > [...]
| > checking for GC_malloc in -lgc... yes
| 
| It looks like this is a lie, because your config.log says
| 
| configure:4359: ./conftest
| ./conftest: error while loading shared libraries: libgc.so.1: cannot open shared object file: No such file or directory
| 
| You should take a look at the shared library files for gc and check if
| a required link is missing.  On my Debian setup, libgc looks like
| this:
| 
| ~$ ls -l /usr/lib/libgc.*
| -rw-r--r--  1 root root 164912 Mar 26  2002 /usr/lib/libgc.a
| lrwxrwxrwx  1 root root     12 Mar 13  2004 /usr/lib/libgc.so -> libgc.so.6.0
| lrwxrwxrwx  1 root root     12 Mar 13  2004 /usr/lib/libgc.so.6 -> libgc.so.6.0
| -rw-r--r--  1 root root 117540 Mar 26  2002 /usr/lib/libgc.so.6.0
| 
| If these files are fine: There are many ways in which a shared library
| installation may be broken: wrong or missing links, wrong or stale
| search paths, permissions, locations, etc.
| 
| Hope this helps.

In reply to this, I got the message that "Copying the gc library files
to /usr/lib rather than /usr/local/lib fixed the problem."

What the real reason for the link failure was I do not know.

-- mva

Re: [ooc-compiler] Installation problems on Fedora Core 3

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

In running a gc test application I get an error so something is
obviously wrong with gc. Maybe a question for the gc mailing list.

$ gcc test.c -o test -lgc
/usr/local/lib/libgc.so: undefined reference to `dlopen'
collect2: ld returned 1 exit status

No problems reported from gctest though.

$ ./gctest
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
Allocated 5716740 collectable objects
Allocated 306 uncollectable objects
Allocated 3750000 atomic objects
Allocated 34440 stubborn objects
Finalized 6612/6612 objects - finalization is probably ok
Total number of bytes allocated is 305241940
Final heap size is 12795904 bytes
Collector appears to work
Completed 539 collections


On m=C3=A5n, 2005-01-24 at 11:43 +0800, Stewart Greenhill wrote:
> Hi August,
>=20
> Does the C linker have the same problem? In other words, can you make a=
=20
> dummy "hello world" program and do:
>    gcc hello.c -o hello -lgc
>=20
> Does your C compiler look in "/usr/local/lib"? Is it in your=20
> LD_LIBRARY_PATH?
>=20
> Cheers,
>    Stewart
>=20
> On Monday, January 24, 2005, at 10:10  AM, August wrote:
>=20
> > Hello again,
> >
> > The libgc files are in /usr/local/lib and I have run ldconfig and (ju=
st
> > to be sure) reextracted oo2c_32-2.1.7.tar.bz2 and opened a new shell,
> > but I still get the same error message from configure. Hmm...
> >
> > On m=C3=A5n, 2005-01-24 at 09:19 +0800, Stewart Greenhill wrote:
> >> Hi August,
> >>
> >> The linker is not finding libgc. Check that you have installed the
> >> library in a place that the compiler knows about. You may also have =
to
> >> run "ldconfig" to update the linker. More details here:
> >>    http://sourceforge.net/mailarchive/message.php?msg_id=3D6525458
> >>
> >> Cheers,
> >>    Stewart
> >>
> >> On Monday, January 24, 2005, at 07:57  AM, August wrote:
> >>
> >>> Hello all,
> >>>
> >>> I have some trouble installing OOC 2.1.7 on Fedora Core 3 Linux. I=20
> >>> have
> >>> installed gc6.3 and it seems to work. Any clues?
> >>>
> >>> $ ./configure
> >>> checking for gcc... gcc
> >>> checking for C compiler default output file name... a.out
> >>> checking whether the C compiler works... yes
> >>> checking whether we are cross compiling... no
> >>> checking for suffix of executables...
> >>> checking for suffix of object files... o
> >>> checking whether we are using the GNU C compiler... yes
> >>> checking whether gcc accepts -g... yes
> >>> checking for gcc option to accept ANSI C... none needed
> >>> checking how to run the C preprocessor... gcc -E
> >>> checking for egrep... grep -E
> >>> checking for a BSD-compatible install... /usr/bin/install -c
> >>> checking for oo2c... bin/oo2c --config oo2crc-install.xml
> >>> checking for ooef... bin/ooef
> >>> checking for diff... /usr/bin/diff
> >>> checking for xsltproc... /usr/bin/xsltproc
> >>> checking for perl... /usr/bin/perl
> >>> checking for libtool... /usr/bin/libtool
> >>> checking for dlopen in -ldl... yes
> >>> checking for GC_malloc in -lgc... yes
> >>> checking for socket in -lxnet... no
> >>> checking for sem_init in -lrt... yes
> >>> checking for sem_init in -lposix4... no
> >>> checking for sin in -lm... yes
> >>> checking for ANSI C header files... no
> >>> checking for sys/types.h... yes
> >>> checking for sys/stat.h... yes
> >>> checking for stdlib.h... yes
> >>> checking for string.h... yes
> >>> checking for memory.h... yes
> >>> checking for strings.h... yes
> >>> checking for inttypes.h... yes
> >>> checking for stdint.h... yes
> >>> checking for unistd.h... yes
> >>> checking sys/time.h usability... yes
> >>> checking sys/time.h presence... yes
> >>> checking for sys/time.h... yes
> >>> checking for unistd.h... (cached) yes
> >>> checking io.h usability... no
> >>> checking io.h presence... no
> >>> checking for io.h... no
> >>> checking pwd.h usability... yes
> >>> checking pwd.h presence... yes
> >>> checking for pwd.h... yes
> >>> checking utime.h usability... yes
> >>> checking utime.h presence... yes
> >>> checking for utime.h... yes
> >>> checking for stdint.h... (cached) yes
> >>> checking for inttypes.h... (cached) yes
> >>> checking gc/gc.h usability... yes
> >>> checking gc/gc.h presence... yes
> >>> checking for gc/gc.h... yes
> >>> checking whether time.h and sys/time.h may both be included... yes
> >>> checking for long int... yes
> >>> checking size of long int... configure: error: cannot compute sizeo=
f
> >>> (long int), 77
> >>> See `config.log' for more details.
> >>>
> >>> --=20
> >>> August
> >>> <config.log>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive=20
> >> Reporting
> >> Tool for open source databases. Create drag-&-drop reports. Save tim=
e
> >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, et=
c.
> >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> >> _______________________________________________
> >> ooc-compiler mailing list
> >> ooc...@li...
> >> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
> > --=20
> > August
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporti=
ng
> > Tool for open source databases. Create drag-&-drop reports. Save time
> > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc=
.
> > Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> > _______________________________________________
> > ooc-compiler mailing list
> > ooc...@li...
> > https://lists.sourceforge.net/lists/listinfo/ooc-compiler
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
--=20
August

[ooc-compiler] New OpenGL bindings available

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

Hi Folks,

Still a work in progress...

Here are some new bindings for OpenGL.
   http://maple.murdoch.edu.au/~stewart/files/OpenGL-20050124.tar.gz
These are generated from the headers under Mac OSX (I think, version 
1.2.1 of OpenGL). Included are Gl.Mod, Glu.Mod, and Glut.Mod.
Also there are a couple of test programs adapted from the OpenGL "Red 
Book". "Test.Mod" draws a white square on a black background. 
"Test2.Mod" draws the "teapot" from the Glut library: click with the 
left mouse button to start rotation, right button to stop. Importantly, 
this shows that Oberon-2 procedures work fine as Glut callbacks.

Under OSX, you can just do:
   oo2c -r . --make Test2
   bin/Test2
in the extracted directory. For other operating systems, you will have 
to adapt the LINK directives in the interface files.
Also there (under "misc"), is the original source used by the 
translator to generate the output modules. Unfortunately there's no 
documentation yet for this tool but if you're interested this will give 
you an idea how it works.

Feedback is welcome, although I can't necessarily help with any 
problems at the moment.

Cheers,
   Stewart