ooc-compiler

Re: [ooc-compiler] Compiler error

[Riza D. <rd...@ya...>]

Hi Frank,

Sorry for the delay, but here is what I think...

/* The working version */
OOC_CHAR8 L__IsEmpty(struct L__Header *list, RT0__Struct list__tag) {
   register OOC_INT32 i0;

   i0 = (OOC_INT32)*(OOC_INT32*)(OOC_INT32)list;
   return (i0==0);
   ;
}

/* The not working version */
OOC_CHAR8 L__IsEmpty(const struct L__Header *list__ref) {
   register OOC_INT32 i0;
   OOC_ALLOCATE_VPAR(list,L__Header ,1)

   OOC_INITIALIZE_VPAR(list__ref,list,L__Header ,8)
   i0 = (OOC_INT32)*(OOC_INT32*)(OOC_INT32)list;
   return (i0==0);
   ;
}

The generated code for L__IsEmpty is almost identical. If you remove
the OOC_ALLOCATE_VPAR and OOC_INITIALIZE_VPAR and change the list
by casting it to a (struct L__Header*) it should work. I arrived at
this conclusion, because the list__tag in the working code is
not used at all.

So what we could do to pinpoint the problem (I think) is change in the
non working code the L__IsEmpty function as shown below and run the test
again. (I assume that the generated C code can be changed and compiled)
The C compiler might issue warnings, but should compile (If I made no
mistakes).

OOC_CHAR8 L__IsEmpty(const struct L__Header *list__ref) {
   register OOC_INT32 i0;
   /*OOC_ALLOCATE_VPAR(list,L__Header ,1)*/

   /*OOC_INITIALIZE_VPAR(list__ref,list,L__Header ,8)*/
	 struct L__Header *list = (struct L__Header *)list__ref;
   i0 = (OOC_INT32)*(OOC_INT32*)(OOC_INT32)list;
   return (i0==0);
   ;
}

What I suspect is that the initialization/copying done by the
OOC_INITIALIZE_VPAR, OOC_ALLOCATE_VPAR pair is not correct.
If the above code works, then the problem would be in those
OOC_* calls (they might be macros).

If you would not mind, could you please do this change and
test?

Kind Regards,
Riza



      

Re: [ooc-compiler] Strange Scan error

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

Hi Frank,

Try:
   r := sc.real;         (* REAL value scanned from input *)
instead of
   r := TextRider.real;  (* constant for REAL token type *)

Cheers,
   Stewart

Frank Hrebabetzky wrote:
> Another strange error. The program
> 
> ------------------------------------------------------------
> MODULE TestScan;
> 
> IMPORT Files, TextRider, Out;
> 
> VAR
>    file: Files.File;
>    res:  Files.Result;
>    sc:   TextRider.Scanner;
>    r:    LONGREAL;
> 
> PROCEDURE ScanReal (sc:TextRider.Scanner; VAR r:LONGREAL): BOOLEAN;
> BEGIN
>    sc.Scan;
>    IF sc.type=TextRider.real THEN
>      r:= TextRider.real;
>      RETURN TRUE
>    END;
>    RETURN FALSE
> END ScanReal;
> 
> BEGIN
>    file:= Files.Old ("par.txt", {Files.read}, res);
>    sc:= TextRider.ConnectScanner (file);
>    WHILE ScanReal (sc, r) DO Out.LongReal (r, 6, 3) END;
>    Out.Ln;
> END TestScan.
> -------------------------------------------------------------------
> 
> executed with the following par.txt content:
> 
> 10.0  11.0  12.0
> 
> prints out:
> 
>    3.00  3.00  3.00  3.00
> ##
> ## Runtime error in module TextRider at pos 31799
> ## Assertion failed, code 127
> 
> On order to see where these strange 3.00 come from I looked into the 
> generated TestScan.c and found the function:
> 
> ------------------------------------------------------------
> static OOC_CHAR8 TestScan__ScanReal(TextRider__Scanner sc, OOC_REAL64 *r) {
>    register OOC_INT32 i0;
> 
>    i0 = (OOC_INT32)sc;
>  
> OOC_TBCALL(((OOC_INT32)OOC_TBPROC_ADR(((OOC_INT32)OOC_TYPE_TAG((_check_pointer(i0, 
> 219)))), 
> TextRider__ScannerDesc_Scan)),TextRider__ScannerDesc_Scan)((TextRider__Scanner)i0);
>    i0 = *(OOC_INT16*)((_check_pointer(i0, 233))+16);
>    i0 = i0==3;
>    if (!i0) goto l3;
>    *r = 3.0000000000000000;
>    return 1u;
> l3:
>    return 0u;
>    ;
> }
> ------------------------------------------------------------
> 
> There is indeed a hard-coded (if this term can be used for a 
> computer-generated program, but anyway) 3.00... in it. Where does that 
> come from?
> 

[ooc-compiler] Strange Scan error

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

Another strange error. The program

------------------------------------------------------------
MODULE TestScan;

IMPORT Files, TextRider, Out;

VAR
   file: Files.File;
   res:  Files.Result;
   sc:   TextRider.Scanner;
   r:    LONGREAL;

PROCEDURE ScanReal (sc:TextRider.Scanner; VAR r:LONGREAL): BOOLEAN;
BEGIN
   sc.Scan;
   IF sc.type=TextRider.real THEN
     r:= TextRider.real;
     RETURN TRUE
   END;
   RETURN FALSE
END ScanReal;

BEGIN
   file:= Files.Old ("par.txt", {Files.read}, res);
   sc:= TextRider.ConnectScanner (file);
   WHILE ScanReal (sc, r) DO Out.LongReal (r, 6, 3) END;
   Out.Ln;
END TestScan.
-------------------------------------------------------------------

executed with the following par.txt content:

10.0  11.0  12.0

prints out:

   3.00  3.00  3.00  3.00
##
## Runtime error in module TextRider at pos 31799
## Assertion failed, code 127

On order to see where these strange 3.00 come from I looked into the 
generated TestScan.c and found the function:

------------------------------------------------------------
static OOC_CHAR8 TestScan__ScanReal(TextRider__Scanner sc, OOC_REAL64 *r) {
   register OOC_INT32 i0;

   i0 = (OOC_INT32)sc;
 
OOC_TBCALL(((OOC_INT32)OOC_TBPROC_ADR(((OOC_INT32)OOC_TYPE_TAG((_check_pointer(i0, 
219)))), 
TextRider__ScannerDesc_Scan)),TextRider__ScannerDesc_Scan)((TextRider__Scanner)i0);
   i0 = *(OOC_INT16*)((_check_pointer(i0, 233))+16);
   i0 = i0==3;
   if (!i0) goto l3;
   *r = 3.0000000000000000;
   return 1u;
l3:
   return 0u;
   ;
}
------------------------------------------------------------

There is indeed a hard-coded (if this term can be used for a 
computer-generated program, but anyway) 3.00... in it. Where does that 
come from?

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

Re: [ooc-compiler] Compiler error

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

On 07/30/2010 01:30 AM, Stewart Greenhill wrote:

>> oo2c --version
>> oo2c/gcc 2.1.11
>> gcc --version
>> gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

This remembers me that the MinGW folks recently had considerable 
difficulties with the update to a newer gcc version. I followed the 
discussion without understanding anything. Don't know whether this is 
relevant here.
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: [ooc-compiler] Compiler error

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

On 07/31/2010 03:39 AM, Riza Dindir wrote:
> Hey Frank,
>
> If it is not too much work, could you post the generated C code for the
> working program (after you changed the IsEmpty parameter to VAR).
>

Ok, Oberon with VAR (the one which works):
------------------------------------------------------
MODULE L;

IMPORT Out;

TYPE
   Item* =     POINTER TO ItemD;
   ItemD* =    RECORD
                 next-:      Item;
               END;

   Header* =   RECORD
                 first-, last-:      Item;
               END;

PROCEDURE IsEmpty* (VAR list:Header): BOOLEAN;
BEGIN RETURN list.first=NIL
END IsEmpty;

PROCEDURE Init* (VAR list:Header);
BEGIN
   list.first:= NIL;  list.last:= NIL;
   Out.String("List initialized");  Out.Ln;
END Init;

END L.

MODULE Test;

IMPORT L, Out;

TYPE
   Node  =     POINTER TO NodeD;
   NodeD  =    RECORD (L.ItemD)
                 sons-:  L.Header;
               END;

VAR n1: Node;


PROCEDURE (node:Node) Init;
BEGIN
   L.Init (node.sons);
   IF ~L.IsEmpty(node.sons) THEN
     Out.String("n1.sons not empty!"); Out.Ln;
   END
END Init;

BEGIN
   NEW (n1);
   n1.Init;
END Test.
--------------------------------------------------

Corresponding C code:

---------------------------------------------------

#include <L.d>
#include <__oo2c.h>
#include <setjmp.h>

OOC_CHAR8 L__IsEmpty(struct L__Header *list, RT0__Struct list__tag) {
   register OOC_INT32 i0;

   i0 = (OOC_INT32)*(OOC_INT32*)(OOC_INT32)list;
   return (i0==0);
   ;
}

void L__Init(struct L__Header *list, RT0__Struct list__tag) {

   *(OOC_INT32*)(OOC_INT32)list = 0;
   *(OOC_INT32*)((OOC_INT32)list+4) = 0;
   Out__String((OOC_CHAR8*)"List initialized", 17);
   Out__Ln();
   return;
   ;
}

void OOC_L_init(void) {

   return;
   ;
}

void OOC_L_destroy(void) {
}

/* --- */


#include <Test.d>
#include <__oo2c.h>
#include <setjmp.h>

void Test__NodeD_Init(Test__Node node) {
   register OOC_INT32 i0,i1,i2;

   i0 = (OOC_INT32)node;
   i1 = _check_pointer(i0, 216);
   i1 = (OOC_INT32)&_td_L__Header;
   L__Init((void*)((_check_pointer(i0, 216))+4), (RT0__Struct)i1);
   i2 = _check_pointer(i0, 244);
   i0 = L__IsEmpty((void*)((_check_pointer(i0, 244))+4), (RT0__Struct)i1);
   i0 = !i0;
   if (!i0) goto l4;
   Out__String((OOC_CHAR8*)"n1.sons not empty!", 19);
   Out__Ln();
l4:
   return;
   ;
}

void OOC_Test_init(void) {
   register OOC_INT32 i0;

   i0 = (OOC_INT32)RT0__NewObject(_td_Test__Node.baseTypes[0]);
   Test__n1 = (Test__Node)i0;
   Test__NodeD_Init((Test__Node)i0);
   return;
   ;
}

void OOC_Test_destroy(void) {
}

/* --- */
--------------------------------------------------------------

Changing one Oberon line to

	PROCEDURE IsEmpty* (list:Header): BOOLEAN;

(doesn't work) produces the C code

---------------------------------------------------------------
#include <L.d>
#include <__oo2c.h>
#include <setjmp.h>

OOC_CHAR8 L__IsEmpty(const struct L__Header *list__ref) {
   register OOC_INT32 i0;
   OOC_ALLOCATE_VPAR(list,L__Header ,1)

   OOC_INITIALIZE_VPAR(list__ref,list,L__Header ,8)
   i0 = (OOC_INT32)*(OOC_INT32*)(OOC_INT32)list;
   return (i0==0);
   ;
}

void L__Init(struct L__Header *list, RT0__Struct list__tag) {

   *(OOC_INT32*)(OOC_INT32)list = 0;
   *(OOC_INT32*)((OOC_INT32)list+4) = 0;
   Out__String((OOC_CHAR8*)"List initialized", 17);
   Out__Ln();
   return;
   ;
}

void OOC_L_init(void) {

   return;
   ;
}

void OOC_L_destroy(void) {
}

/* --- */

#include <Test.d>
#include <__oo2c.h>
#include <setjmp.h>

void Test__NodeD_Init(Test__Node node) {
   register OOC_INT32 i0,i1;

   i0 = (OOC_INT32)node;
   i1 = _check_pointer(i0, 216);
   L__Init((void*)((_check_pointer(i0, 216))+4), 
(RT0__Struct)((OOC_INT32)&_td_L__Header));
   i0 = L__IsEmpty((void*)((_check_pointer(i0, 244))+4));
   i0 = !i0;
   if (!i0) goto l4;
   Out__String((OOC_CHAR8*)"n1.sons not empty!", 19);
   Out__Ln();
l4:
   return;
   ;
}

void OOC_Test_init(void) {
   register OOC_INT32 i0;

   i0 = (OOC_INT32)RT0__NewObject(_td_Test__Node.baseTypes[0]);
   Test__n1 = (Test__Node)i0;
   Test__NodeD_Init((Test__Node)i0);
   return;
   ;
}

void OOC_Test_destroy(void) {
}

/* --- */

------------------------------------------------------------------

These are just the files obj/L.c and obj/Test.c.
If you need anything else, tell me.
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: [ooc-compiler] Compiler error

[Riza D. <rd...@ya...>]

Hey Frank,

If it is not too much work, could you post the generated C code for the
working program (after you changed the IsEmpty parameter to VAR).

Regards,
Riza Dindir

On Fri, 30 Jul 2010, Frank Hrebabetzky wrote
> It is 32-bit linux:
>     uname -m
>     i686
> With the changed L__Init I get the output
>     List initialized
>     Header size: 8
>     Pointer size: 4
>     n1.sons not empty!
> Changing the IsEmpty parameter to VAR settles the matter, output is now:
>     List initialized

> I didn't do that before because I prefer program clarity over 
> efficiency. But as a workaround it is acceptable of course.

> So: when do I need that? What is going on?



      

Re: [ooc-compiler] Compiler error

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

It is 32-bit linux:
	uname -m
	i686
With the changed L__Init I get the output
	List initialized
	Header size: 8
	Pointer size: 4
	n1.sons not empty!
Changing the IsEmpty parameter to VAR settles the matter, output is now:
	List initialized

I didn't do that before because I prefer program clarity over 
efficiency. But as a workaround it is acceptable of course.

So: when do I need that? What is going on?
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil


On 07/30/2010 01:30 AM, Stewart Greenhill wrote:
> Hmm... That code looks OK. At least, it matches my code which works
> fine. A few things to try:
>
> Is this possibly a 64-bit linux? Can you send me the output of:
> uname -m
>
> Try adding these lines before "return", in L__Init (obj/L.c).
> printf("Header size: %d\n", sizeof (struct L__Header));
> printf("Pointer size: %d\n", sizeof (struct L__Header *));
> Then do "oo2c -Mv Test". Rerun "Test" and it should output:
> Header size: 8
> Pointer size: 4
>
> If you add VAR to the declaration of IsEmpty does it make a difference?
> Like this:
> PROCEDURE IsEmpty* (VAR list:Header): BOOLEAN;
>
> Cheers,
> Stewart
>
> Frank Hrebabetzky wrote:
>> Hi Stewart,
>>
>> I deleted the bin, obj and sym directory and compiled with
>> oo2c --make Test
>> Same result as before. Then:
>> oo2c --version
>> oo2c/gcc 2.1.11
>> gcc --version
>> gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
>>
>> obj/Test.c:
>> ------------------------------------------------------------
>> #include <Test.d>
>> #include <__oo2c.h>
>> #include <setjmp.h>
>>
>> void Test__NodeD_Init(Test__Node node) {
>> register OOC_INT32 i0,i1;
>>
>> i0 = (OOC_INT32)node;
>> i1 = _check_pointer(i0, 216);
>> L__Init((void*)((_check_pointer(i0, 216))+4),
>> (RT0__Struct)((OOC_INT32)&_td_L__Header));
>> i0 = L__IsEmpty((void*)((_check_pointer(i0, 244))+4));
>> i0 = !i0;
>> if (!i0) goto l4;
>> Out__String((OOC_CHAR8*)"n1.sons not empty!", 19);
>> Out__Ln();
>> l4:
>> return;
>> ;
>> }
>>
>> void OOC_Test_init(void) {
>> register OOC_INT32 i0;
>>
>> i0 = (OOC_INT32)RT0__NewObject(_td_Test__Node.baseTypes[0]);
>> Test__n1 = (Test__Node)i0;
>> Test__NodeD_Init((Test__Node)i0);
>> return;
>> ;
>> }
>>
>> void OOC_Test_destroy(void) {
>> }
>>
>> /* --- */
>> ----------------------------------------------------------
>> obj/L.c:
>> ----------------------------------------------------------
>> #include <L.d>
>> #include <__oo2c.h>
>> #include <setjmp.h>
>>
>> OOC_CHAR8 L__IsEmpty(const struct L__Header *list__ref) {
>> register OOC_INT32 i0;
>> OOC_ALLOCATE_VPAR(list,L__Header ,1)
>>
>> OOC_INITIALIZE_VPAR(list__ref,list,L__Header ,8)
>> i0 = (OOC_INT32)*(OOC_INT32*)(OOC_INT32)list;
>> return (i0==0);
>> ;
>> }
>>
>> void L__Init(struct L__Header *list, RT0__Struct list__tag) {
>>
>> *(OOC_INT32*)(OOC_INT32)list = 0;
>> *(OOC_INT32*)((OOC_INT32)list+4) = 0;
>> Out__String((OOC_CHAR8*)"List initialized", 17);
>> Out__Ln();
>> return;
>> ;
>> }
>>
>> void OOC_L_init(void) {
>>
>> return;
>> ;
>> }
>>
>> void OOC_L_destroy(void) {
>> }
>>
>> /* --- */
>> --------------------------------------------------------
>>
>> I'm curious.
>
>
>

Re: [ooc-compiler] Dead or just comatose?

[Duke N. <duk...@ml...>]

On Fri, 30 Jul 2010, Frank Hrebabetzky wrote:

> On 07/30/2010 12:42 AM, Duke Normandin wrote:
> >
> > Which version of oberon.el are you using?
> >
>
> oberon2.el version 2.0

Is this the one written by Aaron Isotton, or Karl Landstrom?
-- 
Duke

Re: [ooc-compiler] Dead or just comatose?

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

On 07/30/2010 12:42 AM, Duke Normandin wrote:
>
> Which version of oberon.el are you using?
>

oberon2.el version 2.0

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

Re: [ooc-compiler] Dead or just comatose?

[Duke N. <duk...@ml...>]

On Thu, 29 Jul 2010, Frank Hrebabetzky wrote:

> Thanks a lot for all your responses, so the list is not _that_ dead
> after all. I think I will stick to OOC for my hobby programming, even
> without Michael aboard, as long as somebody (read: Stewart) answers my
> questions. What I like especially is that OOC
> - exists for Linux and Windows
> - facilitates calling C libraries.

I'm not sure if obc id capable of calling C libraries. I should look
into this as well.

> A really decent tool which I will continue to use is the oberon mode for
> emacs.

Which version of oberon.el are you using?

> So it seems that the other compilers which exist for Linux and
> Windows and which don't require russian language skills are
> 1. XDS
> 2. OBC (thanks for the hint, Duke)

No worries!
-- 
Duke

Re: [ooc-compiler] Compiler error

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

Hmm... That code looks OK. At least, it matches my code which works 
fine. A few things to try:

Is this possibly a 64-bit linux? Can you send me the output of:
   uname -m

Try adding these lines before "return", in L__Init (obj/L.c).
   printf("Header size: %d\n", sizeof (struct L__Header));
   printf("Pointer size: %d\n", sizeof (struct L__Header *));
Then do "oo2c -Mv Test". Rerun "Test" and it should output:
  Header size: 8
  Pointer size: 4

If you add VAR to the declaration of IsEmpty does it make a difference? 
Like this:
   PROCEDURE IsEmpty* (VAR list:Header): BOOLEAN;

Cheers,
   Stewart

Frank Hrebabetzky wrote:
> Hi Stewart,
> 
> I deleted the bin, obj and sym directory and compiled with
> 	oo2c  --make Test
> Same result as before. Then:
> 	oo2c --version
> 	oo2c/gcc 2.1.11
> 	gcc --version
> 	gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
> 
> obj/Test.c:
> ------------------------------------------------------------
> #include <Test.d>
> #include <__oo2c.h>
> #include <setjmp.h>
> 
> void Test__NodeD_Init(Test__Node node) {
>    register OOC_INT32 i0,i1;
> 
>    i0 = (OOC_INT32)node;
>    i1 = _check_pointer(i0, 216);
>    L__Init((void*)((_check_pointer(i0, 216))+4), 
> (RT0__Struct)((OOC_INT32)&_td_L__Header));
>    i0 = L__IsEmpty((void*)((_check_pointer(i0, 244))+4));
>    i0 = !i0;
>    if (!i0) goto l4;
>    Out__String((OOC_CHAR8*)"n1.sons not empty!", 19);
>    Out__Ln();
> l4:
>    return;
>    ;
> }
> 
> void OOC_Test_init(void) {
>    register OOC_INT32 i0;
> 
>    i0 = (OOC_INT32)RT0__NewObject(_td_Test__Node.baseTypes[0]);
>    Test__n1 = (Test__Node)i0;
>    Test__NodeD_Init((Test__Node)i0);
>    return;
>    ;
> }
> 
> void OOC_Test_destroy(void) {
> }
> 
> /* --- */
> ----------------------------------------------------------
> obj/L.c:
> ----------------------------------------------------------
> #include <L.d>
> #include <__oo2c.h>
> #include <setjmp.h>
> 
> OOC_CHAR8 L__IsEmpty(const struct L__Header *list__ref) {
>    register OOC_INT32 i0;
>    OOC_ALLOCATE_VPAR(list,L__Header ,1)
> 
>    OOC_INITIALIZE_VPAR(list__ref,list,L__Header ,8)
>    i0 = (OOC_INT32)*(OOC_INT32*)(OOC_INT32)list;
>    return (i0==0);
>    ;
> }
> 
> void L__Init(struct L__Header *list, RT0__Struct list__tag) {
> 
>    *(OOC_INT32*)(OOC_INT32)list = 0;
>    *(OOC_INT32*)((OOC_INT32)list+4) = 0;
>    Out__String((OOC_CHAR8*)"List initialized", 17);
>    Out__Ln();
>    return;
>    ;
> }
> 
> void OOC_L_init(void) {
> 
>    return;
>    ;
> }
> 
> void OOC_L_destroy(void) {
> }
> 
> /* --- */
> --------------------------------------------------------
> 
> I'm curious.

Re: [ooc-compiler] Dead or just comatose?

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

Thanks a lot for all your responses, so the list is not _that_ dead 
after all. I think I will stick to OOC for my hobby programming, even 
without Michael aboard, as long as somebody (read: Stewart) answers my 
questions. What I like especially is that OOC
- exists for Linux and Windows
- facilitates calling C libraries.
A really decent tool which I will continue to use is the oberon mode for 
emacs. So it seems that the other compilers which exist for Linux and 
Windows and which don't require russian language skills are
1. XDS
2. OBC (thanks for the hint, Duke)
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: [ooc-compiler] Compiler error

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

Hi Stewart,

I deleted the bin, obj and sym directory and compiled with
	oo2c  --make Test
Same result as before. Then:
	oo2c --version
	oo2c/gcc 2.1.11
	gcc --version
	gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

obj/Test.c:
------------------------------------------------------------
#include <Test.d>
#include <__oo2c.h>
#include <setjmp.h>

void Test__NodeD_Init(Test__Node node) {
   register OOC_INT32 i0,i1;

   i0 = (OOC_INT32)node;
   i1 = _check_pointer(i0, 216);
   L__Init((void*)((_check_pointer(i0, 216))+4), 
(RT0__Struct)((OOC_INT32)&_td_L__Header));
   i0 = L__IsEmpty((void*)((_check_pointer(i0, 244))+4));
   i0 = !i0;
   if (!i0) goto l4;
   Out__String((OOC_CHAR8*)"n1.sons not empty!", 19);
   Out__Ln();
l4:
   return;
   ;
}

void OOC_Test_init(void) {
   register OOC_INT32 i0;

   i0 = (OOC_INT32)RT0__NewObject(_td_Test__Node.baseTypes[0]);
   Test__n1 = (Test__Node)i0;
   Test__NodeD_Init((Test__Node)i0);
   return;
   ;
}

void OOC_Test_destroy(void) {
}

/* --- */
----------------------------------------------------------
obj/L.c:
----------------------------------------------------------
#include <L.d>
#include <__oo2c.h>
#include <setjmp.h>

OOC_CHAR8 L__IsEmpty(const struct L__Header *list__ref) {
   register OOC_INT32 i0;
   OOC_ALLOCATE_VPAR(list,L__Header ,1)

   OOC_INITIALIZE_VPAR(list__ref,list,L__Header ,8)
   i0 = (OOC_INT32)*(OOC_INT32*)(OOC_INT32)list;
   return (i0==0);
   ;
}

void L__Init(struct L__Header *list, RT0__Struct list__tag) {

   *(OOC_INT32*)(OOC_INT32)list = 0;
   *(OOC_INT32*)((OOC_INT32)list+4) = 0;
   Out__String((OOC_CHAR8*)"List initialized", 17);
   Out__Ln();
   return;
   ;
}

void OOC_L_init(void) {

   return;
   ;
}

void OOC_L_destroy(void) {
}

/* --- */
--------------------------------------------------------

I'm curious.
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil


On 07/28/2010 11:23 PM, Stewart Greenhill wrote:
> Hi Frank,
>
> Sorry for the delay. I just tested this code and it works fine for me.
>
> Which version of oo2c and gcc are you running?
>
> Can you post the output files obj/Test.c and obj/L.c? Do a clean build
> after first removing all of the files under the sym and obj directories.
>
> One slight inefficiency is that L.IsEmpty should be:
> PROCEDURE IsEmpty* (VAR list:Header): BOOLEAN;
> Otherwise it makes a copy of the record before testing the pointer.
>
> Cheers,
> Stewart
>
> Frank Hrebabetzky wrote:
>> Hi there,
>>
>> I guess I found a compiler error. I have a module L which implements a
>> rudimentary list and a module Test which imports L:
>>
>>
>> MODULE L;
>> IMPORT Out;
>>
>> TYPE
>> Item* = POINTER TO ItemD;
>> ItemD* = RECORD
>> next-: Item;
>> END;
>>
>> Header* = RECORD
>> first-, last-: Item;
>> END;
>>
>> PROCEDURE IsEmpty* (list:Header): BOOLEAN;
>> BEGIN RETURN list.first=NIL
>> END IsEmpty;
>>
>> PROCEDURE Init* (VAR list:Header);
>> BEGIN
>> list.first:= NIL; list.last:= NIL;
>> Out.String("List initialized"); Out.Ln;
>> END Init;
>>
>> END L.
>>
>>
>> MODULE Test;
>> IMPORT L, Out;
>>
>> TYPE
>> Node = POINTER TO NodeD;
>> NodeD = RECORD (L.ItemD)
>> sons-: L.Header;
>> END;
>> VAR n1: Node;
>>
>> PROCEDURE (node:Node) Init;
>> BEGIN
>> L.Init (node.sons);
>> IF ~L.IsEmpty(node.sons) THEN
>> Out.String("n1.sons not empty!"); Out.Ln;
>> END
>> END Init;
>>
>> BEGIN
>> NEW (n1);
>> n1.Init;
>> END Test.
>>
>>
>> Executing Test prints the following:
>>
>> List initialized
>> n1.sons not empty!
>>
>> which means that n1.Init didn't change n1. This is an error, isn't it?
>> If details matter I can tell them (platform, versions etc.).
>>
>

Re: [ooc-compiler] Dead or just comatose?

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

On 29 July 2010 04:58, Stewart Greenhill <sgr...@ii...> wrote:
> [...]
> It looks like there is quite a trend these days towards interpreted,
> dynamically typed code especially for things like web frameworks, which
> is where my interest in Python comes from. It looks like there is a
> great community and lots of libraries available. For some applications
> this can dramatically reduce development time which is a big point in
> its favour. However, I'm not a great fan of dynamic typing. It means
> that many bugs are not detected until run-time, and therefore requires a
> lot more testing to verify code. Also, the lack of defined return types
> makes APIs very hard to navigate. Compared with Javadocs (and OOC docs)
> Python docs are a nightmare. The other problem is performance, which is
> quite poor compared to compiled code. Of course, for some apps it
> doesn't matter (assuming you've got a fast enough machine).

Hi Stewart,

regarding the Python documentation: it took me years to get to a
decent hit rate when looking things up.  For some reason or other,
I was always looking at the wrong places first for a particular piece of
information.  The docs and my brain seem to be structured along
different lines ;-)

Just yesterday I read a nice article "Strong Typing vs. Strong
Testing" http://docs.google.com/View?id=dcsvntt2_25wpjvbbhk
With Python and Clojure I do not miss static type checks at all.
Both have their ways to make up for it.

> Scala is interesting because its functional but supports static typing
> (actually, type inference) and compiles to very fast code that runs on
> the JVM. I looked briefly at the Lift web framework which is implemented
> in Scala. Scala includes language-level XML support, and the basic APIs
> support actors, messaging, etc so its quite a good fit for a web
> environment. Unfortunately I don't have the brain-space at the moment to
> learn so many new things at the moment.
>
> What sort of things are you doing with Clojure?

I've done a lot of web application stuff, both at work and in private.
Libraries like compojure and hiccup make server side request parsing
and HTML generation trivial.  Also a big boon: for development one
can set up things so that functions can be replaced in the running
server, from within the editor.  With this, the turnaround time from
changing a function to running it for new HTML takes a fraction of a
second.  Btw, the package management done by leiningen or cljr is
great: a trivial interface towards the user but able to resolve all package
dependencies in the background.  With this I really appreciate the
wealth of Java libraries available.  For example, it took me three
minutes to get an OpenGL demo up and running on a laptop where
no Clojure was installed beforehand.

The other stuff I've done is database access (Oracle and CouchDB),
3D graphics (just a few days ago I implemented shadow mapping
for OpenGL using penumbra, something I wanted to do since I toyed
with OpenGL under Python), data analysis (unsurprisingly, Clojure
shines at list processing), and by now even general scripting
(although the JVM has a rather long startup time).

-- mva

Re: [ooc-compiler] Dead or just comatose?

[Peter F. <ph...@ac...>]

Hi all,

On Wed, Jul 28, 2010 at 10:58 PM, Stewart Greenhill
<sgr...@ii...> wrote:
> It looks like there is quite a trend these days towards interpreted,
> dynamically typed code especially for things like web frameworks, which
> is where my interest in Python comes from. It looks like there is a
> great community and lots of libraries available. For some applications
> this can dramatically reduce development time which is a big point in
> its favour. However, I'm not a great fan of dynamic typing. It means
> that many bugs are not detected until run-time, and therefore requires a
> lot more testing to verify code. Also, the lack of defined return types
> makes APIs very hard to navigate.

You may want to take a look at Google's Go language at golang.org
because it has some of the niceties of Python and friends combined
with solid Oberon (and even Lagoona :-D) roots, albeit hidden behind a
C-like syntax of dubious attractiveness. I've played with it a bit
last year and had a lot of fun. Still intend to do more with it later
this year. And oh, it's statically typed and compiled, they even
target embedded development to some extent.

Cheers,
Peter
-- 
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

Re: [ooc-compiler] Dead or just comatose?

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

Michael van Acken wrote:
> On 28 July 2010 17:29, Stewart Greenhill <sgr...@ii...> wrote:
>> [...]
>> These days I'm mostly using Java though I have recently been looking into
>> Python and Scala - don't have time to learn every new thing. I still have
>> some semi-active code using OOC. I occasionally use C for embedded
>> programming - still the most efficient for small machines.
> 
> Interesting that you mention Scala.  I was considering to take a look at
> this language as well.  But then I decided that one JVM based language
> like Clojure is more than enough for me.  So Odersky's 750+ pages Scala
> book never found its way onto my bookshelf.
> 
> Erlang is also tremendously interesting, but it's unlikely that I will
> encounter a problem in the near future where I can put its strengths to
> good use.  It sure does provide a very different view on programming, and
> especially on how one can do reliable and/or distributed systems.
> 
> When I started using Python years ago, I thought that it had a lot of appeal
> for an Oberon programmer like myself.  I like how it evolved over time, the
> Python guys are a bunch of very bright folks.

It looks like there is quite a trend these days towards interpreted, 
dynamically typed code especially for things like web frameworks, which 
is where my interest in Python comes from. It looks like there is a 
great community and lots of libraries available. For some applications 
this can dramatically reduce development time which is a big point in 
its favour. However, I'm not a great fan of dynamic typing. It means 
that many bugs are not detected until run-time, and therefore requires a 
lot more testing to verify code. Also, the lack of defined return types 
makes APIs very hard to navigate. Compared with Javadocs (and OOC docs) 
Python docs are a nightmare. The other problem is performance, which is 
quite poor compared to compiled code. Of course, for some apps it 
doesn't matter (assuming you've got a fast enough machine).

Scala is interesting because its functional but supports static typing 
(actually, type inference) and compiles to very fast code that runs on 
the JVM. I looked briefly at the Lift web framework which is implemented 
in Scala. Scala includes language-level XML support, and the basic APIs 
support actors, messaging, etc so its quite a good fit for a web 
environment. Unfortunately I don't have the brain-space at the moment to 
learn so many new things at the moment.

What sort of things are you doing with Clojure?

Cheers,
   Stewart

Re: [ooc-compiler] Compiler error

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

Hi Frank,

Sorry for the delay. I just tested this code and it works fine for me.

Which version of oo2c and gcc are you running?

Can you post the output files obj/Test.c and obj/L.c? Do a clean build 
after first removing all of the files under the sym and obj directories.

One slight inefficiency is that L.IsEmpty should be:
   PROCEDURE IsEmpty* (VAR list:Header): BOOLEAN;
Otherwise it makes a copy of the record before testing the pointer.

Cheers,
   Stewart

Frank Hrebabetzky wrote:
> Hi there,
> 
> I guess I found a compiler error. I have a module L which implements a 
> rudimentary list and a module Test which imports L:
> 
> 
> MODULE L;
> IMPORT Out;
> 
> TYPE
>    Item* =     POINTER TO ItemD;
>    ItemD* =    RECORD
>                  next-:      Item;
>                END;
> 
>    Header* =   RECORD
>                  first-, last-:      Item;
>                END;
> 
> PROCEDURE IsEmpty* (list:Header): BOOLEAN;
> BEGIN RETURN list.first=NIL
> END IsEmpty;
> 
> PROCEDURE Init* (VAR list:Header);
> BEGIN
>    list.first:= NIL;  list.last:= NIL;
>    Out.String("List initialized");  Out.Ln;
> END Init;
> 
> END L.
> 
> 
> MODULE Test;
> IMPORT L, Out;
> 
> TYPE
>    Node  =     POINTER TO NodeD;
>    NodeD  =    RECORD (L.ItemD)
>                  sons-:  L.Header;
>                END;
> VAR n1: Node;
> 
> PROCEDURE (node:Node) Init;
> BEGIN
>    L.Init (node.sons);
>    IF ~L.IsEmpty(node.sons) THEN
>      Out.String("n1.sons not empty!"); Out.Ln;
>    END
> END Init;
> 
> BEGIN
>    NEW (n1);
>    n1.Init;
> END Test.
> 
> 
> Executing Test prints the following:
> 
> List initialized
> n1.sons not empty!
> 
> which means that n1.Init didn't change n1. This is an error, isn't it?
> If details matter I can tell them (platform, versions etc.).
> 

[ooc-compiler] Here's someone that still loves oo2c

[Duke N. <duk...@ml...>]

Donald Daniel seems to be still strong on oo2c...

http://www.waltzballs.org/other/prog.html

HTH...
-- 
Duke

Re: [ooc-compiler] Dead or just comatose?

[Duke N. <duk...@ml...>]

On Wed, 28 Jul 2010, Michael van Acken wrote:

> On 28 July 2010 18:05, Duke Normandin <duk...@ml...> wrote:
> > [...]
> >> Actually no, I don't remember.  Nowadays I have fun with Clojure :-)
> >
> > That's a flavor of Lisp, is it not?
>
> Yes, it's a Lisp running on the JVM with an emphasis on pure
> functions and a distinct approach to handle mutable state.

I thought so! I'm dabbling with newLisp and CL/SLIME myself. I haven't
made up my mind yet whether or not "I just can't live without" Lisp - in
any flavor. The dabbling is interesting, though.
-- 
Duke

Re: [ooc-compiler] Dead or just comatose?

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

On 28 July 2010 18:05, Duke Normandin <duk...@ml...> wrote:
> [...]
>> Actually no, I don't remember.  Nowadays I have fun with Clojure :-)
>
> That's a flavor of Lisp, is it not?

Yes, it's a Lisp running on the JVM with an emphasis on pure
functions and a distinct approach to handle mutable state.

-- mva

Re: [ooc-compiler] Dead or just comatose?

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

On 28 July 2010 17:29, Stewart Greenhill <sgr...@ii...> wrote:
> [...]
> These days I'm mostly using Java though I have recently been looking into
> Python and Scala - don't have time to learn every new thing. I still have
> some semi-active code using OOC. I occasionally use C for embedded
> programming - still the most efficient for small machines.

Interesting that you mention Scala.  I was considering to take a look at
this language as well.  But then I decided that one JVM based language
like Clojure is more than enough for me.  So Odersky's 750+ pages Scala
book never found its way onto my bookshelf.

Erlang is also tremendously interesting, but it's unlikely that I will
encounter a problem in the near future where I can put its strengths to
good use.  It sure does provide a very different view on programming, and
especially on how one can do reliable and/or distributed systems.

When I started using Python years ago, I thought that it had a lot of appeal
for an Oberon programmer like myself.  I like how it evolved over time, the
Python guys are a bunch of very bright folks.

-- mva

Re: [ooc-compiler] Dead or just comatose?

[Duke N. <duk...@ml...>]

On Wed, 28 Jul 2010, Treutwein Bernhard wrote:

> Hi Duke, (Dukester?),

You bet! It's me.... ;)

> nice to meet you over here also ...

likewise...

> > Do you remember how mature ooc
> > was when you were last involved with it?
>
> hmm, I guess that Stewart Greenhill might be the one who is able to judge the
> maturity of OOC.
>
> OTOH, the last time I tried it, the bootstrapping process from nowhere to a
> running compiler, which was able to translate itself went smoothly ... which
> is in some sense a proof of maturity.

I agree! Stewart seems to be the default ooc guru and
flag-bearer. _long live Stewart Greenhill_ !! ;)

You might want to try the following compiler. It comes with a GUI
debugger as well. Works well on many platforms.

http://spivey.oriel.ox.ac.uk/corner/Software_%28Imperative_Programming%29

HTH
-- 
duke

Re: [ooc-compiler] Dead or just comatose?

[Duke N. <duk...@ml...>]

On Wed, 28 Jul 2010, Michael van Acken wrote:

> On 28 July 2010 16:05, Duke Normandin <duk...@ml...> wrote:
> > [...]
> >> for myself I can say that I stopped working with Oberon several
> >> years ago.  By now it's quite hard for me to even read and
> >> understand Oberon code.  Go figure...
> >
> > Well! You're no fun at all, are you! ;) Do you remember how mature ooc
> > was when you were last involved with it?
>
> Actually no, I don't remember.  Nowadays I have fun with Clojure :-)

That's a flavor of Lisp, is it not?
-- 
Duke

Re: [ooc-compiler] Dead or just comatose?

[Peter F. <ph...@ac...>]

Hi all,

On Wed, Jul 28, 2010 at 11:24 AM, Treutwein Bernhard
<Ber...@ve...> wrote:
> do I understand right: OOC is orphaned
>
> then the question is not:
>
> Dead or just comatose?
>
> but better
>
> How to reanimate it and who will lead the intensive care unit?

I always liked OOC although I had my troubles with it as well. :-D
Sadly I won't be leading the ICU for this, but the code is there and
if there are a few people with enough interest I am sure it'll be
picked up again. Maybe Michael can make this "orphanage" official by
putting something to the effect of "maintainer needed" on the sf.net
site or the ooc website (if there is still one?).

Cheers,
Peter
-- 
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

Re: [ooc-compiler] Dead or just comatose?

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

On 28/07/2010, at 10:26 PM, Michael van Acken <mic...@gm... 
 > wrote:

> On 28 July 2010 16:05, Duke Normandin <duk...@ml...> wrote:
>>
>> Well! You're no fun at all, are you! ;) Do you remember how mature  
>> ooc
>> was when you were last involved with it?
>
> Actually no, I don't remember.  Nowadays I have fun with Clojure :-)

These days I'm mostly using Java though I have recently been looking  
into Python and Scala - don't have time to learn every new thing. I  
still have some semi-active code using OOC. I occasionally use C for  
embedded programming - still the most efficient for small machines.

Cheers
Stewart