ooc-compiler

Re: [ooc-compiler] Deep-copying STRING

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

Hello!

> I need to do a deep copy of a variable of type STRING. What's the metho=
d?
> All I can find in the documentation is that STRING is a synonym for
> Object.String.
>=20
> Do I just do:
>=20
>   VAR newstring : STRING;
>=20
>   NEW (newstring);
>   newstring^ :=3D oldstring^;
>=20
> Frank Copeland

Instances of STRING or Object.String are inmutable, so normally there is =

no need to make a copy at all.

If you look at Object.Mod you'll see, that even String.ToString() will=20
return iteself for exactly that reason.

If you really need a copy it looks like you must use ToString16(), call=20
CharsUTF16() on the return value and use the result as parameter for=20
NewString16(). However possibly this does not work because of CharsUTF16 =

being read only, you have to try this.

One could add a Copy (and deep copy) method to Object (and implement=20
them for String). You have to ask Michael if this would be part of the=20
master plan. I fear that there might no simple generic way to implement=20
them (at least for deep copy), so most objects would not implement them. =

This might be OK, or might be not.

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

Re: [ooc-compiler] Deep-copying STRING

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

Frank Copeland <fj...@wo...> writes:

> I need to do a deep copy of a variable of type STRING. What's the method?
> All I can find in the documentation is that STRING is a synonym for
> Object.String.
> 
> Do I just do:
> 
>   VAR newstring : STRING;
> 
>   NEW (newstring);
>   newstring^ := oldstring^;

This is probably the best approach.  An alternative is
newstring := oldstring.Concat("")

-- mva

[ooc-compiler] Deep-copying STRING

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

I need to do a deep copy of a variable of type STRING. What's the method?
All I can find in the documentation is that STRING is a synonym for
Object.String.

Do I just do:

  VAR newstring : STRING;

  NEW (newstring);
  newstring^ := oldstring^;

Frank Copeland
-- 
A man always remembers his first love with special tenderness, but after
that begins to bunch them.
		-- Mencken

[ooc-compiler] Overloaded operators/Zonnon-style user-defined operators

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

Does anyone know how much effort it would be to added
overloaded operators and user-defined operators ala
Zonnon?

Michael G.

Re: [ooc-compiler] oo2c-2.1 released

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

Hi Marco,

This looks like a problem that was reported before:
   http://sourceforge.net/mailarchive/message.php?msg_id=6525458

Check that your GC shared library is in the search path for the dynamic 
loader. Check the above reply for more details.

Cheers,
   Stewart

On Monday, March 8, 2004, at 06:36 AM, Marco Oetken wrote:

> Hello!
>
> I have tried to install ooc on debian for my first time.
> gc 6.2 is installed but configure for oo2c fails:
>  CFLAGS=-O2 ./configure --prefix=/home/shadow/Oberon/OOC \
>     --enable-threads=pthreads
>
> stops at
> checking size of long int... configure: error: cannot compute sizeof 
> (long
> int), 77
>
> Does anyone know why configure fails and what to do?
>
> I have debian 3.0 with kernel 2.4 and gcc 2.95.4.
>
> Thanks in advance!
>
> Greetings
>   Marco
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] oo2c-2.1 released

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

Hello!

I have tried to install ooc on debian for my first time.
gc 6.2 is installed but configure for oo2c fails:
 CFLAGS=-O2 ./configure --prefix=/home/shadow/Oberon/OOC \
    --enable-threads=pthreads

stops at
checking size of long int... configure: error: cannot compute sizeof (long 
int), 77

Does anyone know why configure fails and what to do?

I have debian 3.0 with kernel 2.4 and gcc 2.95.4.

Thanks in advance!

Greetings
  Marco

[ooc-compiler] Embedded Oberon-2 Applications

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

Ok, I know you guys are using Oberon-2 for something. :-)
Why not give us all a brief insight into how you are using Oberon-2.
I'm particularly interested in embedded applications and internet
connectivity.  I'm writing several articles about Oberon-2 and would 
appreciate any pointers to web sites and any experiences with Oberon-2.
Note: I'm aware of ETH and all the standard Oberon-ring sites.

Thanks,
	Michael G.

[ooc-compiler] oo2c-2.1 released

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

This release incorporates some cleanup work that has been
pending for some time: a new environment variable to specify
repositories, support for shared library version numbers, and
other odds and ends.

With this the compiler is pretty much feature complete, so the
version number goes up to 2.1.


Changes:

(oo2c, oob, etc) The new environment variable OOC_REPS can be
used to pass a list of repository paths to the compiler and the
other tools.  OOC_REPS is a list of directories, separated by
colons `:'.  Empty paths are ignored.  This variable is an
alternative to using multiple `-r' command line options, or
editing the config file.

(oo2c) Pass library version from the pkginfo.xml file as option
`-version-info' to the libtool link command.

(oo2c) Fixed compiler crash with integer constants >=2^63.  (bug
#907308)

(oo2c) Avoid disproportionate translation time in the
instruction scheduler for large procedures.

(Object:Boxed) New functions BooleanToString(), IntToString(),
LongRealToString(), and SetToString().  Each takes a value of
the indicated type and returns a STRING.  The result is the same
as converting the value into its `Boxed' representation first,
and then calling ToString() on the object.


-- mva

Re: [ooc-compiler] Solved: Segmentation fault during installation

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

Hello!

> Thanks to the many suggestions in the list, I was able to solve the=20
> problem today, at least as far as the compiler is concerned (still=20
> struggling with VO, though). I'm still trying to figure out  what cause=
d=20
> the fault in the end, but what i did was

If you have problems with VO, tell them :-)

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

Re: [ooc-compiler] oo2c-2.0.18 allocator problem

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

On Wed, Feb 11, 2004 at 11:28:04AM +1100, fjc wrote:
> On Tue, Feb 10, 2004 at 08:06:46PM +0100, Tim Teulings wrote:
> 
> > This is already fixed in CVS and if I remember correctly occured with 
> > older version of oo2c, too.

Doh! Despite what I said it *does* happen in 2.0.17, I just screwed up the
test. That'll learn me to program after midnight, I'm too old for that stuff
anymore :-)

> > So it seems, like GC_MALLOC does not always clear memory?

It's not GC_MALLOC after all. I've just discovered that VisualPrefs sets
RT0.poisonHeap, so all allocated memory is filled with MAX(LONGINT). That
explains everything I experienced.

> The fact that a string doesn't get initialised isn't the issue, it's the
> possibility that objects can be created containing invalid pointers.

The bottom line appears to be that you simply cannot depend on pointers
being safe before they are explicitly initialised. You can't depend on
GC_MALLOC() clearing pointers in heap objects because it may not be linked
in and the system malloc() is used instead. On my system at least global
variables are cleared, but not procedure variables.

Knowing that I can proceed accordingly, but I think it puts an unwelcome
burden on programmers and makes programs less safe than they ought to be.

Frank Copeland
-- 
You can prove anything by mentioning another computer language.  :-)

             -- Larry Wall in <199...@wa...>

Re: [ooc-compiler] oo2c-2.0.18 allocator problem

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

On Tue, Feb 10, 2004 at 08:06:46PM +0100, Tim Teulings wrote:

> This is already fixed in CVS and if I remember correctly occured with 
> older version of oo2c, too. It seems like memory initialisation is 
> different among the installed systems. While in theory memory should not 
> be initialized at all (see manpage of malloc), it seems like it is on 
> most systems. This is bad, since the compiler does not warn you. The 
> questions is, who is responsible? libc? The gc? Is it realy always by 
> accidient that most of the time memory seems cleared?

The Oberon-2 language doesn't guarantee any variables are initialised, but
there's a strong implication that pointer and procedure variables are
guaranteed to be either NIL or point to a valid object. Otherwise pointers
are no safer than in C, which is supposed to be one of the strengths of the
language.

> So it seems, like GC_MALLOC does not always clear memory?

It says so explicitly in 'man GC_MALLOC', but not in gcinterface.html. In
both places it states that GC_MALLOC_ATOMIC does not clear memory. This is
Debian testing, libgc1 is version 6.2+6.3alpha2-1.

Looking at the changes to RT0_NewObject I can't see anything that would
cause it to use GC_MALLOC_ATOMIC by mistake, so I think you may be right.
The fact that a string doesn't get initialised isn't the issue, it's the
possibility that objects can be created containing invalid pointers.

Frank Copeland
-- 
This fortune would be seven words long if it were six words shorter.

Re: [ooc-compiler] Solved: Segmentation fault during installation

[Jan <juh...@mn...>]

Thanks to the many suggestions in the list, I was able to solve the 
problem today, at least as far as the compiler is concerned (still 
struggling with VO, though). I'm still trying to figure out  what caused 
the fault in the end, but what i did was

- use the most recent gc6.3alpha. I think that the other versions didn't 
install completely on my system, but this one did. Before that, I always 
had to install the includes by hand, dont ask me why.

- I adopted vedmeds suggestion for a script to run configure with all 
the environment vars defined properly. Since I didnt chose any exotic 
places for installation i didnt consider this important earlier, but the 
script did the trick for me.

I'm sorry that i'm not able to narrow things down more precisely, 
remember that i'm still quite new to Linux and oo2c.

Jan


vedmed wrote:
> Hello Jan,
> 
> Tuesday, February 10, 2004, 6:03:42 AM, you wrote:
> 
> J> At the moment, I think the problem must be be related to my distribution
> J> (SuSE 9.0 professional): I just finished trying installation on a 
> J> different machine at work that's running the same distribution (without 
> J> gc) with exactly the same results and behaviour that I get here at home.
> 
> J> Is there anyone using SuSE 9.0 who installed oo2c successfully? Are 
> J> there any libs or programs used during installation that might be 
> J> missing/corrupt/wrong version in SuSE 9.0?
> 
> I have successfully install gc6.3alpha4 and oo2c 2.0.18 on fresh
> installed SuSe 9.0
> At installation into home directory on SuSe to me it was necessary to
> specify a path to libraries at /etc/ld.conf and to execute ldconfig
> after installing gc.
> Other distribution (Fedora 1) did not demand these actions.
> For installation of packages instead of start configure the following
> bash script was used
> 
> #! /bin/sh
> PRF=$HOME/local
> export LDFLAGS=-L$PRF/lib
> export CFLAGS=-I$PRF/include
> export LD_LIBRARY_PATH=$PRF/lib
> export PKG_CONFIG_PATH=$PRF/lib/pkgconfig
> export CPP="gcc -E -I$PRF/include"
> ./configure --prefix=$PRF $*
> 
> on my computer ~/bin is a symlink to ~/local/bin
> 

Re: [ooc-compiler] oo2c-2.0.18 allocator problem

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

Hallo!

> The problem appears to be that the 'theme' element in the DisplayPrefsD=
esc
> object isn't being cleared when the object is allocated. Adding a state=
ment
> to VO:OS:X11:Display.Mod to explicitly assign an empty string to 'theme=
'
> cures the problem.

This has been fixe din CVS by defining a

   PROCEDURE (p : DisplayPrefs) Init*;

in VO:Base:Display, that does initialisation for all Drivers.

When removing this assignment I was able to reproduce it with current oo2=
c.

This is already fixed in CVS and if I remember correctly occured with=20
older version of oo2c, too. It seems like memory initialisation is=20
different among the installed systems. While in theory memory should not =

be initialized at all (see manpage of malloc), it seems like it is on=20
most systems. This is bad, since the compiler does not warn you. The=20
questions is, who is responsible? libc? The gc? Is it realy always by=20
accidient that most of the time memory seems cleared?

> 'man GC_malloc_atomic' says that GC_malloc_atomic doesn't clear the
> allocated memory, which is consistent with the observed behaviour. Howe=
ver,
> the DisplayPrefsDesc object does contain pointers, so GC_malloc_atomic
> shouldn't be getting called.

The gc documentation says that:

  void * GC_MALLOC(size_t nbytes)
     Allocates and clears nbytes of storage. Requires (amortized) time=20
proportional to nbytes. The resulting object will be automatically=20
deallocated when unreferenced. References from objects allocated with=20
the system malloc are usually not considered by the collector. (See=20
GC_MALLOC_UNCOLLECTABLE, however.) GC_MALLOC is a macro which invokes=20
GC_malloc by default or, if GC_DEBUG is defined before gc.h is included, =

a debugging version that checks occasionally for overwrite errors, and=20
the like.

An instance of DisplayPrefs is allocated at the end of VO:Prefs:Display. =

The code generated is like this:

   i0 =3D=20
(OOC_INT32)RT0__NewObject(_td_VO_Prefs_Display__DisplayItem.baseTypes[0])=
;

New object check for a special flag (RT0__flagAtomic) in the descriptor, =

which is: Since the second last entry is "0" (which should be the flags=20
attribute), it seems lie the flag is not set. So DisplayPrefs is not=20
marked as atomic.

RT0__StructDesc _td_VO_Base_Display__DisplayPrefs =3D {=20
(RT0__Struct[]){&_td_VO_Base_Display__DisplayPrefsDesc}, NULL, NULL,=20
&_mid, "DisplayPrefs", 4, -1, 0, RT0__strPointer };

So it seems, like GC_MALLOC does not always clear memory?

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

Re: [ooc-compiler] Segmentation fault during installation

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

Hallo!

> And I would like to know if anyone is running gcc 3.3.x under
> Linux/ix86?

Yes me, using Debian testing. Works. No problems. I havn't tested oo2c=20
2.0.18, but will do now. Perhaps that'll change everything ;-)

tim@edge:~$ gcc --version
gcc (GCC) 3.3.2 (Debian)
Copyright (C) 2003 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht f=FCr VERKAUFBARKEIT oder F=DCR SPEZIELLE=
=20
ZWECKE.

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

[ooc-compiler] oo2c-2.0.18 allocator problem

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

I'm building VO_031223 with oo2c_32-2.0.18 on a Debian testing box. With an empty
~/VisualOberon, VisualPrefs crashes with the following output:

## 
## Runtime error in module Object at pos 11466
## Array index out of range, 100 not in 0 <= x < 100
## 
0: /usr/local/lib/liboo2c.so.0 [0x4038302b]
1: /usr/local/lib/liboo2c.so.0(_runtime_error+0x4a) [0x403830da]
2: /usr/local/lib/liboo2c.so.0 [0x40383646]
3: /usr/local/lib/liboo2c.so.0(Object__NewLatin1+0x6a) [0x4038455a]
4: /usr/local/lib/liboo2c_vo.so.0(VO_OS_X11_Display__DisplayDesc_Open+0x1377) [0x400f3c47]
5: /usr/local/lib/liboo2c_vo.so.0(VO_OS_Probe__OpenDisplay+0x204) [0x400ff544]
6: VisualPrefs [0x804c0c2]
7: VisualPrefs [0x804c522]
8: /lib/libc.so.6(__libc_start_main+0xc6) [0x404d0dc6]
9: VisualPrefs [0x804bfb1]

The problem appears to be that the 'theme' element in the DisplayPrefsDesc
object isn't being cleared when the object is allocated. Adding a statement
to VO:OS:X11:Display.Mod to explicitly assign an empty string to 'theme'
cures the problem.

This problem does not occur when VisualPrefs is compiled with
oo2c_32-2.0.17, so suspicion immediately falls on the change to the
allocator in 2.0.18 to use GC_malloc_atomic in some cases. 

'man GC_malloc_atomic' says that GC_malloc_atomic doesn't clear the
allocated memory, which is consistent with the observed behaviour. However,
the DisplayPrefsDesc object does contain pointers, so GC_malloc_atomic
shouldn't be getting called.

Frank Copeland
-- 
All a man needs out of life is a place to sit 'n' spit in the fire.

Re: [ooc-compiler] Segmentation fault during installation

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

Jan <juh...@mn...> writes:
> [...]
> Hi Michael,
> I tried the solution you suggested. I renamed gc.h and libgc.*, so
> that configure wouldn't use them - the results are the same as
> described in my first post.
> 
> At the moment, I think the problem must be be related to my
> distribution (SuSE 9.0 professional): I just finished trying
> installation on a different machine at work that's running the same
> distribution (without gc) with exactly the same results and behaviour
> that I get here at home.

With gc out of the picture, the next likely candidate is gcc.  I never
had any problems with gcc under Linux/ix86, but I have to admit that I
am still running with sturdy old 2.95.4.  You don't happen to have
such an ancient compiler around?  In any case, twiddling with CFLAGS
is probably a good next step.  Please try

  make distclean
  CFLAGS="-O0 -g" ./configure ...

> Is there anyone using SuSE 9.0 who installed oo2c successfully? Are
> there any libs or programs used during installation that might be
> missing/corrupt/wrong version in SuSE 9.0?

And I would like to know if anyone is running gcc 3.3.x under
Linux/ix86?

-- mva

Re: [ooc-compiler] Segmentation fault during installation

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

Hallo!

Another suggestion. What threading library do you use. Suse 9.0 might be =

prepared for Kernel 2.6.x and thus might not have choosen the classic=20
pthreads package but the new three letter acronym version (LWT or=20
something like that). This may interfere witht he gc. You should be able =

to find that out by doing an ldd on the libgc.so.

You should also do an ldd on the oo2c binary that is used during the=20
build to find out if it is linked against the gc, but I think you=20
already have proven that.

Is the crash reproducable? Do you always get the same call stack when=20
you try to compile (using gdb) or is the call stack random. If it is=20
random, Michaels guess that this is a problem with the gc is more=20
likely, if is always stays the same, it is more likely that there is a=20
bug in the compiler (speaking of 60/40 or 70/30 and reverse). Ahhh,=20
Michael, did you use that special gc method to make the gc initialize=20
memory with a specific pattern to check for non-initialized variables?

How do you compile install the gc? Do you use one of the special=20
makefiles or the configure script? If you use the configure script=20
perhaps send the output (packed) to the mailinglist. Stewart, does it=20
generate a config.h, where we could detect strange configurations?

As Stewart hinter, try to explicitely compile the gc (and oo2c) single=20
threaeded, if multi-threaded is the default.


I do not have Suse 9.0 in reach. I have compiled the oo2c on Sun=20
Solaris, Windows, Mac OS X, and various Debian versions (woody and=20
testing) on x86 and ppc processors and never had a problem. Strange...

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

Re[2]: [ooc-compiler] Segmentation fault during installation

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

Hello Jan,

Tuesday, February 10, 2004, 6:03:42 AM, you wrote:

J> At the moment, I think the problem must be be related to my distribution
J> (SuSE 9.0 professional): I just finished trying installation on a 
J> different machine at work that's running the same distribution (without 
J> gc) with exactly the same results and behaviour that I get here at home.

J> Is there anyone using SuSE 9.0 who installed oo2c successfully? Are 
J> there any libs or programs used during installation that might be 
J> missing/corrupt/wrong version in SuSE 9.0?

I have successfully install gc6.3alpha4 and oo2c 2.0.18 on fresh
installed SuSe 9.0
At installation into home directory on SuSe to me it was necessary to
specify a path to libraries at /etc/ld.conf and to execute ldconfig
after installing gc.
Other distribution (Fedora 1) did not demand these actions.
For installation of packages instead of start configure the following
bash script was used

#! /bin/sh
PRF=$HOME/local
export LDFLAGS=-L$PRF/lib
export CFLAGS=-I$PRF/include
export LD_LIBRARY_PATH=$PRF/lib
export PKG_CONFIG_PATH=$PRF/lib/pkgconfig
export CPP="gcc -E -I$PRF/include"
./configure --prefix=$PRF $*

on my computer ~/bin is a symlink to ~/local/bin

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

Re: [ooc-compiler] Segmentation fault during installation

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

Hi Jan,

Two suggestions:

1) Try running the executable that fails under gdb. That should 
indicate the context in which the problem occurs.

2) Recent versions of the GC seem to default to building threaded 
collectors. On some platforms it is necessary to specify particular 
flags when compiling the _client_ code. If you have a threaded GC, you 
will probably have to specify "-DGC_LINUX_THREADS" in CPPFLAGS, or 
something like that. I don't know about Linux, but this is certainly 
necessary under Windows and Mac OS X (see README.{MACOS,WIN32} for 
discussion). Omitting the client flags can cause things to go horribly 
wrong.

Cheers,
   Stewart

On Tuesday, February 10, 2004, at 09:03 AM, Jan wrote:

> Michael van Acken wrote:
>> For some reasons I currently do not get any mails from ooc-compiler,
>> but Tim kindly forwarded this to me:
>>> [...]
>>> gc6.1 seems to have installed smoothly (including make check). My 
>>> only
>>> modification was that since including gc.h didn't work the way
>>> described in INSTALL (using CPPFLAGS), I copied the contents of
>>> gc/include to /usr/local/include/gc instead.
>> Segfaults like this are usually caused by bad interaction with the
>> gc.  I would suggest to try to build first without gc (it should be
>> sufficient to move the gc headers out of the may, then "make
>> distclean", then "configure").  The build may run out of memory, but
>> repeated "make" should do the trick.
>> If this works out, a more recent gc may get you further.
>
> Hi Michael,
> I tried the solution you suggested. I renamed gc.h and libgc.*, so 
> that configure wouldn't use them - the results are the same as 
> described in my first post.
>
> At the moment, I think the problem must be be related to my 
> distribution (SuSE 9.0 professional): I just finished trying 
> installation on a different machine at work that's running the same 
> distribution (without gc) with exactly the same results and behaviour 
> that I get here at home.
>
> Is there anyone using SuSE 9.0 who installed oo2c successfully? Are 
> there any libs or programs used during installation that might be 
> missing/corrupt/wrong version in SuSE 9.0?
>
> Jan
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] Segmentation fault during installation

[Jan <juh...@mn...>]

Michael van Acken wrote:
> For some reasons I currently do not get any mails from ooc-compiler,
> but Tim kindly forwarded this to me:
> 
>>[...]
>>gc6.1 seems to have installed smoothly (including make check). My only
>>modification was that since including gc.h didn't work the way
>>described in INSTALL (using CPPFLAGS), I copied the contents of
>>gc/include to /usr/local/include/gc instead.
> 
> 
> Segfaults like this are usually caused by bad interaction with the
> gc.  I would suggest to try to build first without gc (it should be
> sufficient to move the gc headers out of the may, then "make
> distclean", then "configure").  The build may run out of memory, but
> repeated "make" should do the trick.
> 
> If this works out, a more recent gc may get you further.

Hi Michael,
I tried the solution you suggested. I renamed gc.h and libgc.*, so that 
configure wouldn't use them - the results are the same as described in 
my first post.

At the moment, I think the problem must be be related to my distribution 
(SuSE 9.0 professional): I just finished trying installation on a 
different machine at work that's running the same distribution (without 
gc) with exactly the same results and behaviour that I get here at home.

Is there anyone using SuSE 9.0 who installed oo2c successfully? Are 
there any libs or programs used during installation that might be 
missing/corrupt/wrong version in SuSE 9.0?

Jan

Re: [ooc-compiler] Segmentation fault during installation

[Jan <juh...@mn...>]

Hi Tim,
thanks a lot for your quick response!

Tim Teulings wrote:

 >> Which Linux distribution and version do you use? Which gcc version do
 >> you use (gcc --version)?


gcc (GCC) 3.3.1 (SuSE Linux)
SuSE 9.0 professional.


 >> Are you sure, that libgc is used? What does the configure script output
 >> tell regarding libgc?


Well, that's funny, libgc is not mentioned in conigure output at all. It
only checks for gc.h:

==
juh@linux:~/Daten/Download/tmp/oo2c_32-2.0.18> ./configure >log.txt
juh@linux:~/Daten/Download/tmp/oo2c_32-2.0.18> grep <log.txt libgc
juh@linux:~/Daten/Download/tmp/oo2c_32-2.0.18> grep <log.txt gc
checking for gcc... gcc
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for GC_malloc in -lgc... yes
checking gc/gc.h usability... yes
checking gc/gc.h presence... yes
checking for gc/gc.h... yes
==

But if I'm not wrong, "GC_malloc in -lgc... yes" is showing that libgc
is used, right?


 >> Are you sure, you are not running out of memory
 >> (that would likely happen, if you oo2c doe snot use libgc)? For some


I don't think so, at least when looking at my system monitor (is there
another way to check this?).


 >> distribution there should be a package for libgc. Make sure, that you
 >> either use that or a manual installation (and not both).


As far as I can tell (by using "pin libgc") there is no rpm in SuSU 9.0.
     I'm not 100% sure if I completely removed the remains of different
gc versions that I tried. I assumed that successful installation of
gc6.1. should replace any remains, though I'm not 100% sure on this.


 >> Can you start the last command that crahsed manually from gdb (gdb 
<oo2c
 >> command and parameter>), start it (run) and if it crashes send the
 >> resulting stack trace to the list (bt)?


Okay, here it comes:

==
juh@linux:~/Daten/Download/tmp/oo2c_32-2.0.18> gdb ./stage0/oo2c
GNU gdb 5.3.92
[...]
This GDB was configured as "i586-suse-linux"...
(gdb) run --config oo2crc-install.xml -r lib -r .  --build-package liboo2c
Starting program:
/home/juh/Daten/Download/tmp/oo2c_32-2.0.18/stage0/oo2c --config
oo2crc-install.xml -r lib -r .  --build-package liboo2c
[New Thread 16384 (LWP 28279)]
- /home/juh/Daten/Download/tmp/oo2c_32-2.0.18/lib/pkginfo.xml
- /home/juh/Daten/Download/tmp/oo2c_32-2.0.18/pkginfo.xml
- /home/juh/Daten/Download/tmp/oo2c_32-2.0.18/lib/pkginfo.xml
- /home/juh/Daten/Download/tmp/oo2c_32-2.0.18/pkginfo.xml
- lib/src/liboo2c.Mod

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 28279)]
0x081038d5 in OOC_Scanner_Pragma__ParsePragma_GetBool.18 () at
obj/OOC/Scanner/Pragma.c:283
283           i1 =
OOC_TYPE_TEST(((OOC_INT32)OOC_TYPE_TAG((_check_pointer(i0, 7881)))),
&_td_Config__BooleanVarDesc);
(gdb) bt
#0  0x081038d5 in OOC_Scanner_Pragma__ParsePragma_GetBool.18 () at
obj/OOC/Scanner/Pragma.c:283
#1  0x08104662 in OOC_Scanner_Pragma__ParsePragma_BoolExpression.26 ()
at obj/OOC/Scanner/Pragma.c:797
#2  0x08104e24 in OOC_Scanner_Pragma__ParsePragma (state=0xbfffee40,
state__tag=0x8187a00) at obj/OOC/Scanner/Pragma.c:1202
#3  0x08105710 in OOC_Scanner_Pragma__AddSymbol (state=0xbfffee40,
state__tag=0x8187a00, inputMode=0xbfffee32 "\001K\032", id=75 'K',
      cstart=1806, cend=1808, line=73, column=26) at
obj/OOC/Scanner/Pragma.c:1410
#4  0x081013d3 in OOC_Scanner__ScanInput (builder=0x81e0788,
defaultPragmas=0x81df5c0, scanOptions=63) at obj/OOC/Scanner.c:1531
#5  0x08074bfb in OOC_Auxiliary_ParseModule__ParseModule (m=0x82004b8,
checkModuleName=0 '\0', createNamespace=0 '\0',
      writeSymbolFile=0 '\0', abortAfterImport=1 '\001',
libraryName=0x820fa08, uses=0x81e05a8, ast=0xbfffef38, symTab=0xbfffef3c,
      pragmaHistory=0xbfffef40, errList=0x81e0788) at
obj/OOC/Auxiliary/ParseModule.c:35
#6  0x080baa30 in OOC_Make__RulesDesc_GetImports (r=0x81dc0e8,
module=0x82004b8) at obj/OOC/Make.c:538
#7  0x080bafbf in OOC_Make__RulesDesc_UpdateSymbolFile (r=0x81dc0e8,
module=0x82004b8) at obj/OOC/Make.c:815
#8  0x080bd272 in OOC_Make__RulesDesc_Update (r=0x81dc0e8,
module=0x82004b8, fileId=1 '\001') at obj/OOC/Make.c:2062
#9  0x080bccfe in OOC_Make__RulesDesc_UpdateLibrary (r=0x81dc0e8,
module=0x82004b8) at obj/OOC/Make.c:1895
#10 0x080bd0af in OOC_Make__RulesDesc_Update (r=0x81dc0e8,
module=0x82004b8, fileId=19 '\023') at obj/OOC/Make.c:2006
#11 0x0815b467 in oo2c__BuildPackage (pkg=0x81f8a80, rep=0x8215410,
install=0 '\0') at obj/oo2c.c:441
#12 0x0815cce6 in OOC_oo2c_init () at obj/oo2c.c:1183
#13 0x0815d59a in main (argc=2, argv=0x2) at obj/oo2c_.c:345
(gdb)
==

I hope that helps to clarify the problem.

Thanks again,
Jan

Re: [ooc-compiler] Segmentation fault during installation

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

Hallo!

> When trying to install any of the recent oo2c releases, I get a=20
> segmentation fault during "make", on the first invocation of=20
> stage0/oo2c. Having switched over to Linux only recently, I still=20
> consider myself a newbie. So any help getting this running is very much=
=20
> appreciated!

Which Linux distribution and version do you use? Which gcc version do=20
you use (gcc --version)?

> gc6.1 seems to have installed smoothly (including make check). My only =

> modification was that since including gc.h didn't work the way describe=
d=20
> in INSTALL (using CPPFLAGS), I copied the contents of gc/include to=20
> /usr/local/include/gc instead.

Are you sure, that libgc is used? What does the configure script output=20
tell regarding libgc? Are you sure, you are not running out of memory=20
(that would likely happen, if you oo2c doe snot use libgc)? For some=20
distribution there should be a package for libgc. Make sure, that you=20
either use that or a manual installation (and not both).

Can you start the last command that crahsed manually from gdb (gdb <oo2c =

command and parameter>), start it (run) and if it crashes send the=20
resulting stack trace to the list (bt)?

> I tried oo2c 2.0.16 and 2.0.17 and different versions of gc with exactl=
y=20
> the same error.

All proven to work on my system.

> I *did* manage to compile the pre 2.0 versions of oo2c earlier, though.=
=20
> But I'd love to use VisualOberon and I'd love to use a decent=20
> programming language again.

Nice to hear :-)

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

[ooc-compiler] Segmentation fault during installation

[Jan <juh...@mn...>]

Hello!
When trying to install any of the recent oo2c releases, I get a 
segmentation fault during "make", on the first invocation of 
stage0/oo2c. Having switched over to Linux only recently, I still 
consider myself a newbie. So any help getting this running is very much 
appreciated!

make stops with:

==
stage0/oo2c --config oo2crc-install.xml -r lib -r .  --build-package liboo2c
- /home/juh/Daten/Download/tmp/oo2c_32-2.0.18/lib/pkginfo.xml
- /home/juh/Daten/Download/tmp/oo2c_32-2.0.18/pkginfo.xml
- /home/juh/Daten/Download/tmp/oo2c_32-2.0.18/lib/pkginfo.xml
- /home/juh/Daten/Download/tmp/oo2c_32-2.0.18/pkginfo.xml
- lib/src/liboo2c.Mod
make: *** [lib/obj/liboo2c.la] Speicherzugriffsfehler
==

When running this last command with strace the last lines of 
strace-output are:

==
stat64("/home/juh/Daten/Download/tmp/oo2c_32-2.0.18/lib/src/liboo2c.Mod", 
{st_mode=S_IFREG|0640, st_size=2127, ...}) = 0
stat64("/home/juh/Daten/Download/tmp/oo2c_32-2.0.18/lib/sym/liboo2c.Sym", 
0xbfffed90) = -1 ENOENT (No such file or directory)
open("lib/src/liboo2c.Mod", O_RDONLY)   = 8
write(1, "- lib/src/liboo2c.Mod\n", 22) = 22
read(8, "MODULE liboo2c;\n<* Warnings := F"..., 12288) = 2127
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigaction(SIGSEGV, {SIG_DFL}, {0x401e98f0, [SEGV], 
SA_RESTORER|SA_RESTART, 0x400d3aa8}, 8) = 0
kill(19110, SIGSEGV)                    = 0
sigreturn()                             = ? (mask now [RTMIN])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
==

gc6.1 seems to have installed smoothly (including make check). My only 
modification was that since including gc.h didn't work the way described 
in INSTALL (using CPPFLAGS), I copied the contents of gc/include to 
/usr/local/include/gc instead.

I tried oo2c 2.0.16 and 2.0.17 and different versions of gc with exactly 
the same error.

I *did* manage to compile the pre 2.0 versions of oo2c earlier, though. 
But I'd love to use VisualOberon and I'd love to use a decent 
programming language again.

Thanks,
Jan

[ooc-compiler] oo2c-2.0.18 released

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

Almost all changes from 2.0.17 to .18 deal with the interaction
between the oo2c run-time system and the gc: atomic objects,
finalization, and weak references.  All of this was contributed by
Stewart Greenhill.


Changelog:

Heap objects of which the compiler knows that they do not contain any
pointers (or which are marked as NO_TRACED_POINTERS) are allocated
using GC_malloc_atomic().  Depending on the heap usage of a program,
this may reduce the chance that the GC classifies objects as live
because it considers non-pointer data as pointers, and may reduce the
cost of tracing live objects.

A finalization method can be specified for classes derived from
Object.Object (or RT0.Object), simply by redefining the Finalize()
method.  It is called by the run-time system before the object is
collected by the gc.

A new library module `WeakRef' implements weak pointers to objects;
that is, pointers that do not keep the referenced object live as far
as the gc is concerned.  If a WeakRef pointer refers to an object that
is reclaimed, then this pointer is automatically set to NIL.

Bug fixes for some scenarios involving parametric types (in
particular, parameter passing to procedure arguments of parametric
array types) are included as well.

-- mva

[ooc-compiler] New UnixCalc 2.0 Release

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

UnixCalc is an Oberon-2 based command line calculator with the
ability to evaluate equations and represent extended precision
numbers with up to 500 digits.  The complete source code can be
obtained from: 

    www.comp-inspirations.com/code/unixcalc-2.0.tar.bz2

At least V2.0.16 or higher of the OO2C compiler will be required 
to build the executable.

More detailed information is available at:

   www.comp-inspirations.com/code/unixcalc-2.0.txt

Have fun!  Please let me know about any bugs.

Michael Griebling
Computer Inspirations