From dragisha at m3w.org  Thu May  1 19:49:28 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 1 May 2014 19:49:28 +0200
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <535FA2B2.70108@gmail.com>
References: <535FA2B2.70108@gmail.com>
Message-ID: <A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>

It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.
--
Dragi?a Duri?
dragisha at m3w.org



On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:

> I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty? When I try to install it with Ubuntu Software Centre I get told the following:
> 
> Lintian check results for /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:
> Can't use an undefined value as an ARRAY reference at /usr/share/perl5/
> Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.
> 
> Is this a Perl issue or an installer issue?
> 
> -- Bruce
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140501/835298de/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140501/835298de/attachment.sig>

From rcolebur at SCIRES.COM  Sat May 24 06:57:36 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 24 May 2014 04:57:36 +0000
Subject: [M3devel] compilation problems with assertions in RTCollector.m3
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF9269F8F6@ATLEX04-SRV.SCIRES.LOCAL>

I updated my sandbox to be current with the HEAD branch via CVS, then tried to rebuild everything.

I first built a minimal distribution on Windows XP.  Everything seemed to work fine.

Now, using my newly rebuilt cm3.exe, I decided to rebuild everything.  Unfortunately, now I'm running into problems even in the first stage.

Here are some examples of the errors I am getting.  These runtime errors happen compiling various packages.  (I've tried rebuilding several times.)

I show 3 separate incidents below and the last one has a partial stack trace.  In each case, there is an assertion failure in the RTCollector while running the compiler:

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 699
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x12f374   0x6ca19e  CleanBetween + 0x22 in ..\src\runtime\common\RTCollector.m3
0x12f3ac   0x6ca031  CopySome + 0xeb in ..\src\runtime\common\RTCollector.m3
0x12f3b8   0x6c9b02  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3
0x12f3c8   0x6c94d6  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3
0x12f40c   0x6c916a  CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3
0x12f44c   0x6dc586  AllocTraced + 0xd3 in ..\src\runtime\common\RTAllocator.m3
0x12f480   0x6dbbd8  GetTracedObj + 0x86 in ..\src\runtime\common\RTAllocator.m3
0x12f49c   0x6db70c  AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3
0x12f4d0   0x529913  Init_chars + 0x20b in ..\src\misc\CG.m3
0x12f4f8   0x4f948b  Init_chars + 0xb9 in ..\src\misc\M3String.m3
.........  .........  ... more frames ...

WARNING:  Encountered an error when processing package "m3-sys\m3front" for "-build".

Any help in solving this problem would be appreciated.

Thanks,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140524/2b9cb0f6/attachment.html>

From wagner at elegosoft.com  Sun May 25 18:36:16 2014
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 25 May 2014 18:36:16 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
Message-ID: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>

On Sun, 25 May 2014 22:35:09 +0800
Bruce Axtens <bruce.axtens at gmail.com> wrote:

> Dear Sir
> 
> Should I assume that CM3 is alive, in palliative care or dead? The trac
> system is full of spam and the roadmap hasn't moved for 3 years.
> 
> I had a long and fruitful relationship with Modula-2 years ago and thought
> that perhaps I could restart things with CM3.

There is certainly some activity in M3 development recently, though
the community is rather small.
The trac system has never been much used by the community members;
and the WWW presentation and regression testing system has lacked
my support, as I couldn't spent any time on these topics for
almost 3 years.

You should check the m3devel mailing list for news though:
https://mail.elegosoft.com/pipermail/m3devel

There has been a lot of activity at the beginning of this year;
it has ceased again during recent weeks.

All CVS commits can be found here:
https://mail.elegosoft.com/pipermail/m3commit

A new release is long overdue; I'm afraid I cannot do the release
engineering this time.

There has been some effort on moving the CVS repositories to git;
I'm not sure what the status is there, too.

Any help wrt. documentation, presentation or software is greatly
appreciated ;-)

Regards,

Olaf Wagner
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


From mika at async.caltech.edu  Mon May 26 21:22:46 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 12:22:46 -0700
Subject: [M3devel] problems on FreeBSD 10.0-RELEASE
Message-ID: <20140526192247.0A2D71A209C@async.async.caltech.edu>

Hi m3devel,

The usual story.. new computer, new OS, trying to set up CM3.

I installed the binary snapshot 

cm3-bin-core-AMD64_FREEBSD-d5.9.0-x86_64-unknown-freebsd8.3-2013-10-15-17-59-51.tgz

cvs synced against current as of today

ran ./upgrade.sh and got various errors.  (See below.)  Versions...

root at pluto:/home/mika/cm3/cm3/scripts # uname -a
FreeBSD pluto 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

root at pluto:/home/mika/cm3/cm3/scripts # gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd10.0/4.7.3/lto-wrapper
Target: x86_64-portbld-freebsd10.0
Configured with: ./../gcc-4.7.3/configure --disable-bootstrap --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc47 --libexecdir=/usr/local/libexec/gcc47 --program-suffix=47 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc47/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc47 --build=x86_64-portbld-freebsd10.0
Thread model: posix
gcc version 4.7.3 (FreeBSD Ports Collection) 
root at pluto:/home/mika/cm3/cm3/scripts # 

Any ideas?  It looks like gcc is having trouble compiling gcc?

     Mika


build/gcov-iov '4.7.1' '' \
    > tmp-gcov-iov.h
/bin/sh ../../gcc-4.7/gcc/../move-if-change tmp-gcov-iov.h gcov-iov.h
echo timestamp > s-iov
gcc -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7/gcc -I../../gcc-4.7/gcc/. -I../../gcc-4.7/gcc/../include -I../../gcc-4.7/gcc/../libcpp/include -I/usr/local/include ../../gcc-4.7/gcc/attribs.c -o attribs.o
gcc -c   -g -O2 -DIN_GCC  -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7/gcc -I../../gcc-4.7/gcc/. -I../../gcc-4.7/gcc/../include -I../../gcc-4.7/gcc/../libcpp/include -I/usr/local/include ../../gcc-4.7/gcc/main.c -o main.o
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:46:
In file included from ../../gcc-4.7/gcc/tree.h:30:
../../gcc-4.7/gcc/statistics.h:48:46: error: reference to 'function' is ambiguous
extern void statistics_counter_event (struct function *, const char *, int);
                                             ^
../../gcc-4.7/gcc/statistics.h:41:8: note: candidate found by name lookup is 'function'
struct function;
       ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:46:
In file included from ../../gcc-4.7/gcc/tree.h:30:
../../gcc-4.7/gcc/statistics.h:49:48: error: reference to 'function' is ambiguous
extern void statistics_histogram_event (struct function *, const char *, int);
                                               ^
../../gcc-4.7/gcc/statistics.h:41:8: note: candidate found by name lookup is 'function'
struct function;
       ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
gcc -c   -g -O2 -DIN_GCC  -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7/gcc -I../../gcc-4.7/gcc/. -I../../gcc-4.7/gcc/../include -I../../gcc-4.7/gcc/../libcpp/include -I/usr/local/include ../../gcc-4.7/gcc/tree-browser.c -o tree-browser.o
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:46:
../../gcc-4.7/gcc/tree.h:3547:10: error: reference to 'function' is ambiguous
  struct function *f;
         ^
../../gcc-4.7/gcc/tree.h:2653:8: note: candidate found by name lookup is 'function'
struct function;
       ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:643:24: error: reference to 'function' is ambiguous
add_local_decl (struct function *fun, tree d)
                       ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:657:23: error: reference to 'function' is ambiguous
extern GTY(()) struct function *cfun;
                      ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:693:30: error: reference to 'function' is ambiguous
extern void set_cfun (struct function *new_cfun);
                             ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:694:31: error: reference to 'function' is ambiguous
extern void push_cfun (struct function *new_cfun);
                              ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:732:40: error: reference to 'function' is ambiguous
extern void free_after_parsing (struct function *);
                                       ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:733:44: error: reference to 'function' is ambiguous
extern void free_after_compilation (struct function *);
                                           ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:764:50: error: reference to 'function' is ambiguous
extern bool optimize_function_for_size_p (struct function *);
                                                 ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:765:51: error: reference to 'function' is ambiguous
extern bool optimize_function_for_speed_p (struct function *);
                                                  ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
../../gcc-4.7/gcc/basic-block.h:779:31: error: reference to 'function' is ambiguous
extern void init_flow (struct function *);
                              ^../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:59:
../../gcc-4.7/gcc/output.h:137:6: warning: 'format' attribute argument not supported: __asm_fprintf__ [-Wignored-attributes]
     ATTRIBUTE_ASM_FPRINTF(2, 3);
     ^
../../gcc-4.7/gcc/output.h:123:53: note: expanded from macro 'ATTRIBUTE_ASM_FPRINTF'
#define ATTRIBUTE_ASM_FPRINTF(m, n) __attribute__ ((__format__ (__asm_fprintf__, m, n))) ATTRIBUTE_NONNULL(m)
                                                    ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:63:
../../gcc-4.7/gcc/langhooks-def.h:40:38: error: reference to 'function' is ambiguous
extern void lhd_do_nothing_f (struct function *);
                                     ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:69:
In file included from ../../gcc-4.7/gcc/expr.h:28:
In file included from ../../gcc-4.7/gcc/rtl.h:2244:
./genrtl.h:385:3: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
  XWINT (rt, 1) = arg1;
  ^          ~
../../gcc-4.7/gcc/rtl.h:633:29: note: expanded from macro 'XWINT'
#define XWINT(RTX, N)               ((RTX)->u.hwint[N])
                                     ^
../../gcc-4.7/gcc/rtl.h:344:5: note: array 'hwint' declared here
    HOST_WIDE_INT hwint[1];
    ^
../../gcc-4.7/gcc/hwint.h:64:26: note: expanded from macro 'HOST_WIDE_INT'
#   define HOST_WIDE_INT long
                         ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:69:
In file included from ../../gcc-4.7/gcc/expr.h:28:
In file included from ../../gcc-4.7/gcc/rtl.h:2244:
./genrtl.h:386:3: warning: array index 2 is past the end of the array (which contains 1 element) [-Warray-bounds]
  XWINT (rt, 2) = arg2;
  ^          ~
../../gcc-4.7/gcc/rtl.h:633:29: note: expanded from macro 'XWINT'
#define XWINT(RTX, N)               ((RTX)->u.hwint[N])
                                     ^
../../gcc-4.7/gcc/rtl.h:344:5: note: array 'hwint' declared here
    HOST_WIDE_INT hwint[1];
    ^../../gcc-4.7/gcc/hwint.h:64:26: note: expanded from macro 'HOST_WIDE_INT'
#   define HOST_WIDE_INT long
                         ^
3 warnings and 13 errors generated.
gmake: *** [m3cg/parse.o] Error 1
gmake: *** Waiting for unfinished jobs....
/bin/sh ../../gcc-4.7/gcc/../move-if-change tmp-attrtab.c insn-attrtab.c
echo timestamp > s-attrtab
/bin/sh ../../gcc-4.7/gcc/../move-if-change tmp-automata.c insn-automata.c
echo timestamp > s-automata
"/usr/home/mika/cm3/cm3/m3-sys/m3cc/src/m3makefile", line 327: quake runtime error: exit 2: cd ../AMD64_FREEBSD && cd gcc && gmake  MAKE="gmake -j4  "  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: -j4  s-modes insn-config.h m3cg

--procedure--  -line-  -file---
exec               --  <builtin>
m3cc_Run          327  /usr/home/mika/cm3/cm3/m3-sys/m3cc/src/m3makefile
include_dir       577  /usr/home/mika/cm3/cm3/m3-sys/m3cc/src/m3makefile
                    6  /usr/home/mika/cm3/cm3/m3-sys/m3cc/AMD64_FREEBSD/m3make.args

Fatal Error: package build failed
 ==> /home/mika/cm3/cm3/m3-sys/m3cc done

Critical Mass Modula-3 version d5.9.0
  last updated: 2010-07-21
  compiled: 2014-05-26 19:11:28
  configuration: /usr/local/cm3/bin/cm3.cfg
  host: AMD64_FREEBSD
quake runtime error: "/usr/local/cm3/bin/cm3.cfg", line 2: quake runtime error: undefined variable: SL

--procedure--  -line-  -file---
                    2  /usr/local/cm3/bin/cm3.cfg
  target: 

./upgrade.sh: /home/mika/cm3/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg: not found
root at pluto:/home/mika/cm3/cm3/scripts # 



From adacore at marino.st  Mon May 26 21:37:55 2014
From: adacore at marino.st (John Marino)
Date: Mon, 26 May 2014 21:37:55 +0200
Subject: [M3devel] problems on FreeBSD 10.0-RELEASE
In-Reply-To: <20140526192247.0A2D71A209C@async.async.caltech.edu>
References: <20140526192247.0A2D71A209C@async.async.caltech.edu>
Message-ID: <53839813.3020406@marino.st>

On 5/26/2014 21:22, mika at async.caltech.edu wrote:
> Hi m3devel,
> 
> The usual story.. new computer, new OS, trying to set up CM3.
> 
> I installed the binary snapshot 
> 
> cm3-bin-core-AMD64_FREEBSD-d5.9.0-x86_64-unknown-freebsd8.3-2013-10-15-17-59-51.tgz
> 
> cvs synced against current as of today
> 

Did you know that modula3 is can be built from ports or installed as a
prebuilt binary on FreeBSD?

http://www.freshports.org/lang/modula3


If you don't need the binary snapshot specifically, maybe the ports M3
is good enough.

John


From mika at async.caltech.edu  Tue May 27 00:22:27 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 15:22:27 -0700
Subject: [M3devel] freebsd 10
Message-ID: <20140526222227.A66181A209C@async.async.caltech.edu>


Thanks so much for the reminder that Modula-3 is in FreeBSD ports.
That's great!  I've used it on FreeBSD since 1999 (was that FreeBSD
2?) and this is definitely the easiest install ever.

But the default configuration uses pthreads.  Pthreads support in Modula-3
is broken.

root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # AMD64_FREEBSD/threadtest 
Writing file...done
Creating read threads...done
Creating fork threads...done
Creating alloc threads...done
Creating lock threads...done
running...printing oldest/median age/newest
.

***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
***

Abort (core dumped)
root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # 

I wonder what the best way of reconfiguring this installation to use
user threads (which always work right, in my experience) is...

    Mika


From adacore at marino.st  Tue May 27 00:35:46 2014
From: adacore at marino.st (John Marino)
Date: Tue, 27 May 2014 00:35:46 +0200
Subject: [M3devel] freebsd 10
In-Reply-To: <20140526222227.A66181A209C@async.async.caltech.edu>
References: <20140526222227.A66181A209C@async.async.caltech.edu>
Message-ID: <5383C1C2.9040002@marino.st>

On 5/27/2014 00:22, mika at async.caltech.edu wrote:
> Thanks so much for the reminder that Modula-3 is in FreeBSD ports.
> That's great!  I've used it on FreeBSD since 1999 (was that FreeBSD
> 2?) and this is definitely the easiest install ever.

Actually it was gone for many years, it only came back a few months ago
after a long hiatus.


> But the default configuration uses pthreads.  Pthreads support in Modula-3
> is broken.

Really?  I didn't know that.  That's not good.

> 
> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # AMD64_FREEBSD/threadtest 
> Writing file...done
> Creating read threads...done
> Creating fork threads...done
> Creating alloc threads...done
> Creating lock threads...done
> running...printing oldest/median age/newest
> .
> 
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
> ***
> 
> Abort (core dumped)
> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # 
> 
> I wonder what the best way of reconfiguring this installation to use
> user threads (which always work right, in my experience) is...
> 

Probably adding something to the build environment but I don't know
what.  How does one normally build "user threads" over posix threads?


John




From mika at async.caltech.edu  Tue May 27 01:40:21 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 16:40:21 -0700
Subject: [M3devel] freebsd 10
In-Reply-To: <5383C1C2.9040002@marino.st>
References: <20140526222227.A66181A209C@async.async.caltech.edu>
	<5383C1C2.9040002@marino.st>
Message-ID: <20140526234021.98E721A209C@async.async.caltech.edu>

John Marino writes:
>On 5/27/2014 00:22, mika at async.caltech.edu wrote:
>> Thanks so much for the reminder that Modula-3 is in FreeBSD ports.
>> That's great!  I've used it on FreeBSD since 1999 (was that FreeBSD
>> 2?) and this is definitely the easiest install ever.
>
>Actually it was gone for many years, it only came back a few months ago
>after a long hiatus.

You mean from FreeBSD ports, specifically, right?  I've always been able
to run up-to-date Modula-3 on FreeBSD but it's been a bit of a hassle
installing things (from DECSRC, Polytechnique de Montreal, or elego).
Having it in ports definitely makes things much much easier.

>
>
>> But the default configuration uses pthreads.  Pthreads support in Modula-3
>> is broken.
>
>Really?  I didn't know that.  That's not good.
>
>> 
>> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # AMD64_FREEBSD/threadtest 
>> Writing file...done
>> Creating read threads...done
>> Creating fork threads...done
>> Creating alloc threads...done
>> Creating lock threads...done
>> running...printing oldest/median age/newest
>> .
>> 
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>> ***
>> 
>> Abort (core dumped)
>> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # 
>> 
>> I wonder what the best way of reconfiguring this installation to use
>> user threads (which always work right, in my experience) is...
>> 
>
>Probably adding something to the build environment but I don't know
>what.  How does one normally build "user threads" over posix threads?

Peter's following email suggests we "just" need an upgrade.

Otherwise the procedure is, if I remember right, to change a flag in
m3core/threads, rebuild m3core, then rebuild the compiler, then rebuild
everything else.

    Mika

>
>
>John
>


From mika at async.caltech.edu  Tue May 27 01:49:16 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 16:49:16 -0700
Subject: [M3devel] freebsd 10
In-Reply-To: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
References: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
Message-ID: <20140526234916.864741A209C@async.async.caltech.edu>


Peter, have you/someone run the thread tester exhaustively?

I did this:

#!/bin/csh

while ( 1 ) 
        limit cputime 5
        rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
end

With what's in FreeBSD's ports I get a variety of failures:


1.
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
***

2.
running...printing oldest/median age/newest
.Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.

3. (most common)
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
***

4.
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
***

5. (letting it run a bit longer)
!!! lock Thread 23 appears starved or deadlocked !!!

This is all running in a single-cpu instance (M3.medium) of EC2...  usually things get worse with more processors.

FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
    root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
XEN: Hypervisor version 4.2 detected.
CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e  Stepping = 4
  Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  Standard Extended Features=0x200<ENHMOVSB>
real memory  = 4026531840 (3840 MB)
avail memory = 3872776192 (3693 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <Xen HVM>




>>>>>

Hi

I think tony put a fix into the collector that fixes that problem. The scheduler with pthreads is more agressive and under high load the mutator could have a newly allocated page collected before the object was initalised. would be good if you check it . There was a report of an assert failure a few days ago in the region of code affected, if we could find out which assert failed I could take a look. 
The only other problem is the odd failure in forking. Seems to occur in the child process in initstackbase which initiates a collection which then finds a weak ref to a mutex which is in a thread that does not exist in the child. Not sure what to do about that.
The pthreads seems pretty stable at least on linux. 

Peter 



From dragisha at m3w.org  Tue May 27 17:34:15 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 27 May 2014 17:34:15 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
Message-ID: <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>

You can count on me for release engineering, Git migration? Maybe CI, if I have resources. Problem is - feedback is poor from core developers wrt Git migration. I am ready for long time now.

On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:

> On Sun, 25 May 2014 22:35:09 +0800
> Bruce Axtens <bruce.axtens at gmail.com> wrote:
> 
>> Dear Sir
>> 
>> Should I assume that CM3 is alive, in palliative care or dead? The trac
>> system is full of spam and the roadmap hasn't moved for 3 years.
>> 
>> I had a long and fruitful relationship with Modula-2 years ago and thought
>> that perhaps I could restart things with CM3.
> 
> There is certainly some activity in M3 development recently, though
> the community is rather small.
> The trac system has never been much used by the community members;
> and the WWW presentation and regression testing system has lacked
> my support, as I couldn't spent any time on these topics for
> almost 3 years.
> 
> You should check the m3devel mailing list for news though:
> https://mail.elegosoft.com/pipermail/m3devel
> 
> There has been a lot of activity at the beginning of this year;
> it has ceased again during recent weeks.
> 
> All CVS commits can be found here:
> https://mail.elegosoft.com/pipermail/m3commit
> 
> A new release is long overdue; I'm afraid I cannot do the release
> engineering this time.
> 
> There has been some effort on moving the CVS repositories to git;
> I'm not sure what the status is there, too.
> 
> Any help wrt. documentation, presentation or software is greatly
> appreciated ;-)
> 
> Regards,
> 
> Olaf Wagner
> -- 
> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140527/6354fe6f/attachment.sig>

From adacore at marino.st  Tue May 27 17:40:57 2014
From: adacore at marino.st (John Marino)
Date: Tue, 27 May 2014 17:40:57 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
Message-ID: <5384B209.3080504@marino.st>

On 5/27/2014 17:34, Dragi?a Duri? wrote:
> You can count on me for release engineering, Git migration? Maybe CI,
> if I have resources. Problem is - feedback is poor from core
> developers wrt Git migration. I am ready for long time now.


This might be a good time to remind that I've been waiting for a release
that feature C-backend support for both FreeBSD and DragonFly (new).
The version in FreeBSD ports is 4 years old, but there's not been a
release since then.  The last time I was active on the list we discussed
the needs of FreeBSD and for porting M3 to DragonFly and something was
supposed to happen code-wise (and then release-wise) but I don't think
anything did in the end.

I was extremely busy with other projects but was planning on pinging on
this topic soon anyway.

John


> 
> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
> 
>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
>> <bruce.axtens at gmail.com> wrote:
>> 
>>> Dear Sir
>>> 
>>> Should I assume that CM3 is alive, in palliative care or dead?
>>> The trac system is full of spam and the roadmap hasn't moved for
>>> 3 years.
>>> 
>>> I had a long and fruitful relationship with Modula-2 years ago
>>> and thought that perhaps I could restart things with CM3.
>> 
>> There is certainly some activity in M3 development recently,
>> though the community is rather small. The trac system has never
>> been much used by the community members; and the WWW presentation
>> and regression testing system has lacked my support, as I couldn't
>> spent any time on these topics for almost 3 years.
>> 
>> You should check the m3devel mailing list for news though: 
>> https://mail.elegosoft.com/pipermail/m3devel
>> 
>> There has been a lot of activity at the beginning of this year; it
>> has ceased again during recent weeks.
>> 
>> All CVS commits can be found here: 
>> https://mail.elegosoft.com/pipermail/m3commit
>> 
>> A new release is long overdue; I'm afraid I cannot do the release 
>> engineering this time.
>> 
>> There has been some effort on moving the CVS repositories to git; 
>> I'm not sure what the status is there, too.
>> 
>> Any help wrt. documentation, presentation or software is greatly 
>> appreciated ;-)
>> 
>> Regards,
>> 
>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
>> | USt-IdNr: DE163214194
> 


From hosking at cs.purdue.edu  Tue May 27 17:56:49 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2014 11:56:49 -0400
Subject: [M3devel] compilation problems with assertions in RTCollector.m3
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF9269F8F6@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF9269F8F6@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <B36B7B19-18BA-4B8A-9BA2-245188D6CDF8@cs.purdue.edu>

Just committed a (hopeful) fix.  Please give it a try.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





On May 24, 2014, at 12:57 AM, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:

> I updated my sandbox to be current with the HEAD branch via CVS, then tried to rebuild everything.
>  
> I first built a minimal distribution on Windows XP.  Everything seemed to work fine.
>  
> Now, using my newly rebuilt cm3.exe, I decided to rebuild everything.  Unfortunately, now I?m running into problems even in the first stage.
>  
> Here are some examples of the errors I am getting.  These runtime errors happen compiling various packages.  (I?ve tried rebuilding several times.)
>  
> I show 3 separate incidents below and the last one has a partial stack trace.  In each case, there is an assertion failure in the RTCollector while running the compiler:
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\runtime\common\RTCollector.m3", line 1092
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\runtime\common\RTCollector.m3", line 699
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\runtime\common\RTCollector.m3", line 1092
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x12f374   0x6ca19e  CleanBetween + 0x22 in ..\src\runtime\common\RTCollector.m3
> 0x12f3ac   0x6ca031  CopySome + 0xeb in ..\src\runtime\common\RTCollector.m3
> 0x12f3b8   0x6c9b02  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3
> 0x12f3c8   0x6c94d6  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3
> 0x12f40c   0x6c916a  CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3
> 0x12f44c   0x6dc586  AllocTraced + 0xd3 in ..\src\runtime\common\RTAllocator.m3
> 0x12f480   0x6dbbd8  GetTracedObj + 0x86 in ..\src\runtime\common\RTAllocator.m3
> 0x12f49c   0x6db70c  AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3
> 0x12f4d0   0x529913  Init_chars + 0x20b in ..\src\misc\CG.m3
> 0x12f4f8   0x4f948b  Init_chars + 0xb9 in ..\src\misc\M3String.m3
> .........  .........  ... more frames ...
>  
> WARNING:  Encountered an error when processing package "m3-sys\m3front" for "-build".
>  
> Any help in solving this problem would be appreciated.
>  
> Thanks,
> Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140527/8b621349/attachment.html>

From mika at async.caltech.edu  Tue May 27 18:07:23 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Tue, 27 May 2014 09:07:23 -0700
Subject: [M3devel] freebsd 10
In-Reply-To: <CAEy6uxpCcLmoMf-C6caZUFNDmGWdqyyL6xMNchhnWkYeRnDGCA@mail.gmail.com>
References: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
	<20140526234916.864741A209C@async.async.caltech.edu>
	<CAEy6uxpCcLmoMf-C6caZUFNDmGWdqyyL6xMNchhnWkYeRnDGCA@mail.gmail.com>
Message-ID: <20140527160723.1296A1A2096@async.async.caltech.edu>


Peter, there's nothing here that constitutes a bug in the thread tester
itself, right?  These are all errors in the runtime (garbage collector,
threading system, Rd/Wr possibly)?

    Mika

Peter McKinna writes:
>--089e0122f628a8285004fa56cf42
>Content-Type: text/plain; charset=UTF-8
>
>Yeah I did a fair bit of testing that program it was annoying me. If you
>run it as threadtest -n 6 -tests alloc  you are just testing allocations
>and it should not crash . However if you put a diagnostic check of the
>retuned array in that test every now and again every element will be non
>zero and the same number corresponding to gray flag of the object header in
>the collector. ( this is from memory havent looked atvthe code for a while
>)  if you have -tests read, alloc  then it will probably crash since the
>read test allocates obects which are dereferenced either in FileRd or in
>the collector in move. If you examine the obect in gdb after the crash all
>fields of the object have the same value as in the alloc test I think its
>2^22 . Your crashes 1 and 4 are the same . Your 2nd example only occurs if
>you have the fork test in the set of tests. It actually crashes the child
>process via an abort after printing that message although that is not
>apparent . You might argue that the error can be ignored since the child
>usually does an exec straight after fork.
>
>Peter
>On 27/05/2014 9:49 AM, <mika at async.caltech.edu> wrote:
>
>>
>> Peter, have you/someone run the thread tester exhaustively?
>>
>> I did this:
>>
>> #!/bin/csh
>>
>> while ( 1 )
>>         limit cputime 5
>>         rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
>> end
>>
>> With what's in FreeBSD's ports I get a variety of failures:
>>
>>
>> 1.
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>> ***
>>
>> 2.
>> running...printing oldest/median age/newest
>> .Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete,
>> file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>>
>> 3. (most common)
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>> ***
>>
>> 4.
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>> ***
>>
>> 5. (letting it run a bit longer)
>> !!! lock Thread 23 appears starved or deadlocked !!!
>>
>> This is all running in a single-cpu instance (M3.medium) of EC2...
>>  usually things get worse with more processors.
>>
>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>>     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>> XEN: Hypervisor version 4.2 detected.
>> CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
>>   Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e
>>  Stepping = 4
>>
>> Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>>
>> Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,H
>V>
>>   AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
>>   AMD Features2=0x1<LAHF>
>>   Standard Extended Features=0x200<ENHMOVSB>
>> real memory  = 4026531840 (3840 MB)
>> avail memory = 3872776192 (3693 MB)
>> Event timer "LAPIC" quality 400
>> ACPI APIC Table: <Xen HVM>
>>
>>
>>
>>
>> >>>>>
>>
>> Hi
>>
>> I think tony put a fix into the collector that fixes that problem. The
>> scheduler with pthreads is more agressive and under high load the mutator
>> could have a newly allocated page collected before the object was
>> initalised. would be good if you check it . There was a report of an assert
>> failure a few days ago in the region of code affected, if we could find out
>> which assert failed I could take a look.
>> The only other problem is the odd failure in forking. Seems to occur in
>> the child process in initstackbase which initiates a collection which then
>> finds a weak ref to a mutex which is in a thread that does not exist in the
>> child. Not sure what to do about that.
>> The pthreads seems pretty stable at least on linux.
>>
>> Peter
>>
>>
>
>--089e0122f628a8285004fa56cf42
>Content-Type: text/html; charset=UTF-8
>Content-Transfer-Encoding: quoted-printable
>
><p dir=3D"ltr">Yeah I did a fair bit of testing that program it was annoyin=
>g me. If you run it as threadtest -n 6 -tests alloc=C2=A0 you are just test=
>ing allocations and it should not crash . However if you put a diagnostic c=
>heck of the retuned array in that test every now and again every element wi=
>ll be non zero and the same number corresponding to gray flag of the object=
> header in the collector. ( this is from memory havent looked atvthe code f=
>or a while )=C2=A0 if you have -tests read, alloc=C2=A0 then it will probab=
>ly crash since the read test allocates obects which are dereferenced either=
> in FileRd or in the collector in move. If you examine the obect in gdb aft=
>er the crash all fields of the object have the same value as in the alloc t=
>est I think its 2^22 . Your crashes 1 and 4 are the same . Your 2nd example=
> only occurs if you have the fork test in the set of tests. It actually cra=
>shes the child process via an abort after printing that message although th=
>at is not apparent . You might argue that the error can be ignored since th=
>e child usually does an exec straight after fork.</p>
>
><p dir=3D"ltr">Peter</p>
><div class=3D"gmail_quote">On 27/05/2014 9:49 AM,  &lt;<a href=3D"mailto:mi=
>ka at async.caltech.edu">mika at async.caltech.edu</a>&gt; wrote:<br type=3D"attr=
>ibution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
>r-left:1px #ccc solid;padding-left:1ex">
><br>
>Peter, have you/someone run the thread tester exhaustively?<br>
><br>
>I did this:<br>
><br>
>#!/bin/csh<br>
><br>
>while ( 1 )<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr=
>eadtest<br>
>end<br>
><br>
>With what&#39;s in FreeBSD&#39;s ports I get a variety of failures:<br>
><br>
><br>
>1.<br>
>***<br>
>*** runtime error:<br>
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>IL<br>
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>***<br>
><br>
>2.<br>
>running...printing oldest/median age/newest<br>
>.Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele=
>te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.<br>
><br>
>3. (most common)<br>
>***<br>
>*** runtime error:<br>
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>IL<br>
>*** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R=
>TCollector.m3<br>
>***<br>
><br>
>4.<br>
>***<br>
>*** runtime error:<br>
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>IL<br>
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>***<br>
><br>
>5. (letting it run a bit longer)<br>
>!!! lock Thread 23 appears starved or deadlocked !!!<br>
><br>
>This is all running in a single-cpu instance (M3.medium) of EC2... =C2=A0us=
>ually things get worse with more processors.<br>
><br>
>FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014<br>
>=C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER=
>IC amd64<br>
>FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610<br>
>XEN: Hypervisor version 4.2 detected.<br>
>CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)<b=
>r>
>=C2=A0 Origin =3D &quot;GenuineIntel&quot; =C2=A0Id =3D 0x306e4 =C2=A0Famil=
>y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4<br>
>=C2=A0 Features=3D0x1783fbff&lt;FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP=
>,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT&gt;<br>
>=C2=A0 Features2=3D0xffba2203&lt;SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4=
>.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV&gt;<br>
>=C2=A0 AMD Features=3D0x28100800&lt;SYSCALL,NX,RDTSCP,LM&gt;<br>
>=C2=A0 AMD Features2=3D0x1&lt;LAHF&gt;<br>
>=C2=A0 Standard Extended Features=3D0x200&lt;ENHMOVSB&gt;<br>
>real memory =C2=A0=3D 4026531840 (3840 MB)<br>
>avail memory =3D 3872776192 (3693 MB)<br>
>Event timer &quot;LAPIC&quot; quality 400<br>
>ACPI APIC Table: &lt;Xen HVM&gt;<br>
><br>
><br>
><br>
><br>
>&gt;&gt;&gt;&gt;&gt;<br>
><br>
>Hi<br>
><br>
>I think tony put a fix into the collector that fixes that problem. The sche=
>duler with pthreads is more agressive and under high load the mutator could=
> have a newly allocated page collected before the object was initalised. wo=
>uld be good if you check it . There was a report of an assert failure a few=
> days ago in the region of code affected, if we could find out which assert=
> failed I could take a look.<br>
>
>The only other problem is the odd failure in forking. Seems to occur in the=
> child process in initstackbase which initiates a collection which then fin=
>ds a weak ref to a mutex which is in a thread that does not exist in the ch=
>ild. Not sure what to do about that.<br>
>
>The pthreads seems pretty stable at least on linux.<br>
><br>
>Peter<br>
><br>
></blockquote></div>
>
>--089e0122f628a8285004fa56cf42--


From hosking at cs.purdue.edu  Tue May 27 18:24:50 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2014 12:24:50 -0400
Subject: [M3devel] freebsd 10
In-Reply-To: <20140527160723.1296A1A2096@async.async.caltech.edu>
References: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
	<20140526234916.864741A209C@async.async.caltech.edu>
	<CAEy6uxpCcLmoMf-C6caZUFNDmGWdqyyL6xMNchhnWkYeRnDGCA@mail.gmail.com>
	<20140527160723.1296A1A2096@async.async.caltech.edu>
Message-ID: <81669A74-4D31-442A-A8AE-7B14BF8E1AC2@cs.purdue.edu>

I would love to get a read on whether Peter?s suggested fix (which I put in a few weeks ago and just revised slightly) has narrowed the set of problems the thread test program illuminates.  Re fork, I?d like to understand that problem a little better to see if we can find a fix.

On May 27, 2014, at 12:07 PM, mika at async.caltech.edu wrote:

> 
> Peter, there's nothing here that constitutes a bug in the thread tester
> itself, right?  These are all errors in the runtime (garbage collector,
> threading system, Rd/Wr possibly)?
> 
>    Mika
> 
> Peter McKinna writes:
>> --089e0122f628a8285004fa56cf42
>> Content-Type: text/plain; charset=UTF-8
>> 
>> Yeah I did a fair bit of testing that program it was annoying me. If you
>> run it as threadtest -n 6 -tests alloc  you are just testing allocations
>> and it should not crash . However if you put a diagnostic check of the
>> retuned array in that test every now and again every element will be non
>> zero and the same number corresponding to gray flag of the object header in
>> the collector. ( this is from memory havent looked atvthe code for a while
>> )  if you have -tests read, alloc  then it will probably crash since the
>> read test allocates obects which are dereferenced either in FileRd or in
>> the collector in move. If you examine the obect in gdb after the crash all
>> fields of the object have the same value as in the alloc test I think its
>> 2^22 . Your crashes 1 and 4 are the same . Your 2nd example only occurs if
>> you have the fork test in the set of tests. It actually crashes the child
>> process via an abort after printing that message although that is not
>> apparent . You might argue that the error can be ignored since the child
>> usually does an exec straight after fork.
>> 
>> Peter
>> On 27/05/2014 9:49 AM, <mika at async.caltech.edu> wrote:
>> 
>>> 
>>> Peter, have you/someone run the thread tester exhaustively?
>>> 
>>> I did this:
>>> 
>>> #!/bin/csh
>>> 
>>> while ( 1 )
>>>        limit cputime 5
>>>        rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
>>> end
>>> 
>>> With what's in FreeBSD's ports I get a variety of failures:
>>> 
>>> 
>>> 1.
>>> ***
>>> *** runtime error:
>>> ***    Segmentation violation - possible attempt to dereference NIL
>>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>>> ***
>>> 
>>> 2.
>>> running...printing oldest/median age/newest
>>> .Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete,
>>> file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>>> 
>>> 3. (most common)
>>> ***
>>> *** runtime error:
>>> ***    Segmentation violation - possible attempt to dereference NIL
>>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>>> ***
>>> 
>>> 4.
>>> ***
>>> *** runtime error:
>>> ***    Segmentation violation - possible attempt to dereference NIL
>>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>>> ***
>>> 
>>> 5. (letting it run a bit longer)
>>> !!! lock Thread 23 appears starved or deadlocked !!!
>>> 
>>> This is all running in a single-cpu instance (M3.medium) of EC2...
>>> usually things get worse with more processors.
>>> 
>>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>>>    root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>>> XEN: Hypervisor version 4.2 detected.
>>> CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
>>>  Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e
>>> Stepping = 4
>>> 
>>> Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>>> 
>>> Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,H
>> V>
>>>  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
>>>  AMD Features2=0x1<LAHF>
>>>  Standard Extended Features=0x200<ENHMOVSB>
>>> real memory  = 4026531840 (3840 MB)
>>> avail memory = 3872776192 (3693 MB)
>>> Event timer "LAPIC" quality 400
>>> ACPI APIC Table: <Xen HVM>
>>> 
>>> 
>>> 
>>> 
>>>>>>>> 
>>> 
>>> Hi
>>> 
>>> I think tony put a fix into the collector that fixes that problem. The
>>> scheduler with pthreads is more agressive and under high load the mutator
>>> could have a newly allocated page collected before the object was
>>> initalised. would be good if you check it . There was a report of an assert
>>> failure a few days ago in the region of code affected, if we could find out
>>> which assert failed I could take a look.
>>> The only other problem is the odd failure in forking. Seems to occur in
>>> the child process in initstackbase which initiates a collection which then
>>> finds a weak ref to a mutex which is in a thread that does not exist in the
>>> child. Not sure what to do about that.
>>> The pthreads seems pretty stable at least on linux.
>>> 
>>> Peter
>>> 
>>> 
>> 
>> --089e0122f628a8285004fa56cf42
>> Content-Type: text/html; charset=UTF-8
>> Content-Transfer-Encoding: quoted-printable
>> 
>> <p dir=3D"ltr">Yeah I did a fair bit of testing that program it was annoyin=
>> g me. If you run it as threadtest -n 6 -tests alloc=C2=A0 you are just test=
>> ing allocations and it should not crash . However if you put a diagnostic c=
>> heck of the retuned array in that test every now and again every element wi=
>> ll be non zero and the same number corresponding to gray flag of the object=
>> header in the collector. ( this is from memory havent looked atvthe code f=
>> or a while )=C2=A0 if you have -tests read, alloc=C2=A0 then it will probab=
>> ly crash since the read test allocates obects which are dereferenced either=
>> in FileRd or in the collector in move. If you examine the obect in gdb aft=
>> er the crash all fields of the object have the same value as in the alloc t=
>> est I think its 2^22 . Your crashes 1 and 4 are the same . Your 2nd example=
>> only occurs if you have the fork test in the set of tests. It actually cra=
>> shes the child process via an abort after printing that message although th=
>> at is not apparent . You might argue that the error can be ignored since th=
>> e child usually does an exec straight after fork.</p>
>> 
>> <p dir=3D"ltr">Peter</p>
>> <div class=3D"gmail_quote">On 27/05/2014 9:49 AM,  &lt;<a href=3D"mailto:mi=
>> ka at async.caltech.edu">mika at async.caltech.edu</a>&gt; wrote:<br type=3D"attr=
>> ibution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
>> r-left:1px #ccc solid;padding-left:1ex">
>> <br>
>> Peter, have you/someone run the thread tester exhaustively?<br>
>> <br>
>> I did this:<br>
>> <br>
>> #!/bin/csh<br>
>> <br>
>> while ( 1 )<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr=
>> eadtest<br>
>> end<br>
>> <br>
>> With what&#39;s in FreeBSD&#39;s ports I get a variety of failures:<br>
>> <br>
>> <br>
>> 1.<br>
>> ***<br>
>> *** runtime error:<br>
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>> IL<br>
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>> ***<br>
>> <br>
>> 2.<br>
>> running...printing oldest/median age/newest<br>
>> .Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele=
>> te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.<br>
>> <br>
>> 3. (most common)<br>
>> ***<br>
>> *** runtime error:<br>
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>> IL<br>
>> *** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R=
>> TCollector.m3<br>
>> ***<br>
>> <br>
>> 4.<br>
>> ***<br>
>> *** runtime error:<br>
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>> IL<br>
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>> ***<br>
>> <br>
>> 5. (letting it run a bit longer)<br>
>> !!! lock Thread 23 appears starved or deadlocked !!!<br>
>> <br>
>> This is all running in a single-cpu instance (M3.medium) of EC2... =C2=A0us=
>> ually things get worse with more processors.<br>
>> <br>
>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014<br>
>> =C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER=
>> IC amd64<br>
>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610<br>
>> XEN: Hypervisor version 4.2 detected.<br>
>> CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)<b=
>> r>
>> =C2=A0 Origin =3D &quot;GenuineIntel&quot; =C2=A0Id =3D 0x306e4 =C2=A0Famil=
>> y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4<br>
>> =C2=A0 Features=3D0x1783fbff&lt;FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP=
>> ,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT&gt;<br>
>> =C2=A0 Features2=3D0xffba2203&lt;SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4=
>> .2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV&gt;<br>
>> =C2=A0 AMD Features=3D0x28100800&lt;SYSCALL,NX,RDTSCP,LM&gt;<br>
>> =C2=A0 AMD Features2=3D0x1&lt;LAHF&gt;<br>
>> =C2=A0 Standard Extended Features=3D0x200&lt;ENHMOVSB&gt;<br>
>> real memory =C2=A0=3D 4026531840 (3840 MB)<br>
>> avail memory =3D 3872776192 (3693 MB)<br>
>> Event timer &quot;LAPIC&quot; quality 400<br>
>> ACPI APIC Table: &lt;Xen HVM&gt;<br>
>> <br>
>> <br>
>> <br>
>> <br>
>> &gt;&gt;&gt;&gt;&gt;<br>
>> <br>
>> Hi<br>
>> <br>
>> I think tony put a fix into the collector that fixes that problem. The sche=
>> duler with pthreads is more agressive and under high load the mutator could=
>> have a newly allocated page collected before the object was initalised. wo=
>> uld be good if you check it . There was a report of an assert failure a few=
>> days ago in the region of code affected, if we could find out which assert=
>> failed I could take a look.<br>
>> 
>> The only other problem is the odd failure in forking. Seems to occur in the=
>> child process in initstackbase which initiates a collection which then fin=
>> ds a weak ref to a mutex which is in a thread that does not exist in the ch=
>> ild. Not sure what to do about that.<br>
>> 
>> The pthreads seems pretty stable at least on linux.<br>
>> <br>
>> Peter<br>
>> <br>
>> </blockquote></div>
>> 
>> --089e0122f628a8285004fa56cf42--



Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484







From hosking at cs.purdue.edu  Tue May 27 18:49:12 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2014 12:49:12 -0400
Subject: [M3devel] Status of CM3
In-Reply-To: <5384B209.3080504@marino.st>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
	<5384B209.3080504@marino.st>
Message-ID: <A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>

Jay might comment on C backend status for those platforms.

On May 27, 2014, at 11:40 AM, John Marino <adacore at marino.st> wrote:

> On 5/27/2014 17:34, Dragi?a Duri? wrote:
>> You can count on me for release engineering, Git migration? Maybe CI,
>> if I have resources. Problem is - feedback is poor from core
>> developers wrt Git migration. I am ready for long time now.
> 
> 
> This might be a good time to remind that I've been waiting for a release
> that feature C-backend support for both FreeBSD and DragonFly (new).
> The version in FreeBSD ports is 4 years old, but there's not been a
> release since then.  The last time I was active on the list we discussed
> the needs of FreeBSD and for porting M3 to DragonFly and something was
> supposed to happen code-wise (and then release-wise) but I don't think
> anything did in the end.
> 
> I was extremely busy with other projects but was planning on pinging on
> this topic soon anyway.
> 
> John
> 
> 
>> 
>> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
>> 
>>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
>>> <bruce.axtens at gmail.com> wrote:
>>> 
>>>> Dear Sir
>>>> 
>>>> Should I assume that CM3 is alive, in palliative care or dead?
>>>> The trac system is full of spam and the roadmap hasn't moved for
>>>> 3 years.
>>>> 
>>>> I had a long and fruitful relationship with Modula-2 years ago
>>>> and thought that perhaps I could restart things with CM3.
>>> 
>>> There is certainly some activity in M3 development recently,
>>> though the community is rather small. The trac system has never
>>> been much used by the community members; and the WWW presentation
>>> and regression testing system has lacked my support, as I couldn't
>>> spent any time on these topics for almost 3 years.
>>> 
>>> You should check the m3devel mailing list for news though: 
>>> https://mail.elegosoft.com/pipermail/m3devel
>>> 
>>> There has been a lot of activity at the beginning of this year; it
>>> has ceased again during recent weeks.
>>> 
>>> All CVS commits can be found here: 
>>> https://mail.elegosoft.com/pipermail/m3commit
>>> 
>>> A new release is long overdue; I'm afraid I cannot do the release 
>>> engineering this time.
>>> 
>>> There has been some effort on moving the CVS repositories to git; 
>>> I'm not sure what the status is there, too.
>>> 
>>> Any help wrt. documentation, presentation or software is greatly 
>>> appreciated ;-)
>>> 
>>> Regards,
>>> 
>>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
>>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
>>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
>>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
>>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
>>> | USt-IdNr: DE163214194
>> 



Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484







From jay.krell at cornell.edu  Wed May 28 08:20:10 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 06:20:10 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
Message-ID: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>

 Sorry, my life has really changed and I have hardly any time now..
 I still hope to come back. 



The C backend works quite well.
I was able to cross-to and self-world-build many platforms.
Including bring up new platform: AMD64_NT.
There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.
jmpbuf remains a platform-specificity in the frontend.


 I believe we had mostly good experience with Linux/arm and maybe Dragonfly? 
 Not sure.


 Going through C source and C compiler is noticable slower. 


The "levelness" of the output is near what I was aiming for, for the first go.
 - records all have fields; you can view them in standard debuggers -- good! 
    This took me a while but I got there. 
 - but globals are not viewable -- all offsets into particular records 
 - all locals/parameters get numbers on the end to disambiguate
    from "nearby" name clashes, though usually it isn't needed;
    this is near the top of the things to fix


The "levelness" is still low in that the word size and posix vs. NT is baked in.
If you want "one source release", you really need to make about 6 currently:
  posix 32bit little endian (many systems)  
  posix 32bit big endian (rare: sparc32_solaris, ppc_darwin) 
  posix 64bit little endian (many systems)  
  posix 64bit big endian (rare: sparc64_solaris, ppc64_darwin)  
  nt 32bit little endian 
  nt 64bit little endian 


 There is one recent outstanding bug report where the generated C is invalid. 


 Besides jmpbuf, I'd like to see endianness factored out.
 There is approx one instance of endian specificity in the frontend
 I'd like to see removed. And then htos/htol/stoh/ltoh moved to C.


I'd also like to see exception handling optionally implemented on top of C++ exception
handling or NT C exception handling (also maybe VMS/Tru64/Ultrix C exception handling...).


For a release though, most of this isn't needed.
Mainly: fix the one bug, decide if performance and debugability is adequate.


 - Jay



> From: hosking at cs.purdue.edu
> Date: Tue, 27 May 2014 12:49:12 -0400
> To: adacore at marino.st; jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
> Subject: Re: [M3devel] Status of CM3
> 
> Jay might comment on C backend status for those platforms.
> 
> On May 27, 2014, at 11:40 AM, John Marino <adacore at marino.st> wrote:
> 
> > On 5/27/2014 17:34, Dragi?a Duri? wrote:
> >> You can count on me for release engineering, Git migration. Maybe CI,
> >> if I have resources. Problem is - feedback is poor from core
> >> developers wrt Git migration. I am ready for long time now.
> > 
> > 
> > This might be a good time to remind that I've been waiting for a release
> > that feature C-backend support for both FreeBSD and DragonFly (new).
> > The version in FreeBSD ports is 4 years old, but there's not been a
> > release since then.  The last time I was active on the list we discussed
> > the needs of FreeBSD and for porting M3 to DragonFly and something was
> > supposed to happen code-wise (and then release-wise) but I don't think
> > anything did in the end.
> > 
> > I was extremely busy with other projects but was planning on pinging on
> > this topic soon anyway.
> > 
> > John
> > 
> > 
> >> 
> >> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
> >> 
> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
> >>> <bruce.axtens at gmail.com> wrote:
> >>> 
> >>>> Dear Sir
> >>>> 
> >>>> Should I assume that CM3 is alive, in palliative care or dead?
> >>>> The trac system is full of spam and the roadmap hasn't moved for
> >>>> 3 years.
> >>>> 
> >>>> I had a long and fruitful relationship with Modula-2 years ago
> >>>> and thought that perhaps I could restart things with CM3.
> >>> 
> >>> There is certainly some activity in M3 development recently,
> >>> though the community is rather small. The trac system has never
> >>> been much used by the community members; and the WWW presentation
> >>> and regression testing system has lacked my support, as I couldn't
> >>> spent any time on these topics for almost 3 years.
> >>> 
> >>> You should check the m3devel mailing list for news though: 
> >>> https://mail.elegosoft.com/pipermail/m3devel
> >>> 
> >>> There has been a lot of activity at the beginning of this year; it
> >>> has ceased again during recent weeks.
> >>> 
> >>> All CVS commits can be found here: 
> >>> https://mail.elegosoft.com/pipermail/m3commit
> >>> 
> >>> A new release is long overdue; I'm afraid I cannot do the release 
> >>> engineering this time.
> >>> 
> >>> There has been some effort on moving the CVS repositories to git; 
> >>> I'm not sure what the status is there, too.
> >>> 
> >>> Any help wrt. documentation, presentation or software is greatly 
> >>> appreciated ;-)
> >>> 
> >>> Regards,
> >>> 
> >>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
> >>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> >>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
> >>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
> >>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
> >>> | USt-IdNr: DE163214194
> >> 
> 
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +1 765 427 5484
> 
> 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/f5d9fc88/attachment.html>

From jay.krell at cornell.edu  Wed May 28 08:33:14 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 06:33:14 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>,
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, ,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, ,
	<5384B209.3080504@marino.st>, ,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>,
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
Message-ID: <COL130-W2013AC1C6E95C966ADE57BE6250@phx.gbl>

sorry, a correction: because of the jmpbuf matter, there is far more "variety" in the output C than the six I listed.
It isn't quite that every platform is unique, but close enough.

Anyway, the C backend is in very good shape relative to its goals.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; adacore at marino.st
Date: Wed, 28 May 2014 06:20:10 +0000
CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
Subject: Re: [M3devel] Status of CM3




 Sorry, my life has really changed and I have hardly any time now..
 I still hope to come back. 



The C backend works quite well.
I was able to cross-to and self-world-build many platforms.
Including bring up new platform: AMD64_NT.
There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.
jmpbuf remains a platform-specificity in the frontend.


 I believe we had mostly good experience with Linux/arm and maybe Dragonfly? 
 Not sure.


 Going through C source and C compiler is noticable slower. 


The "levelness" of the output is near what I was aiming for, for the first go.
 - records all have fields; you can view them in standard debuggers -- good! 
    This took me a while but I got there. 
 - but globals are not viewable -- all offsets into particular records 
 - all locals/parameters get numbers on the end to disambiguate
    from "nearby" name clashes, though usually it isn't needed;
    this is near the top of the things to fix


The "levelness" is still low in that the word size and posix vs. NT is baked in.
If you want "one source release", you really need to make about 6 currently:
  posix 32bit little endian (many systems)  
  posix 32bit big endian (rare: sparc32_solaris, ppc_darwin) 
  posix 64bit little endian (many systems)  
  posix 64bit big endian (rare: sparc64_solaris, ppc64_darwin)  
  nt 32bit little endian 
  nt 64bit little endian 


 There is one recent outstanding bug report where the generated C is invalid. 


 Besides jmpbuf, I'd like to see endianness factored out.
 There is approx one instance of endian specificity in the frontend
 I'd like to see removed. And then htos/htol/stoh/ltoh moved to C.


I'd also like to see exception handling optionally implemented on top of C++ exception
handling or NT C exception handling (also maybe VMS/Tru64/Ultrix C exception handling...).


For a release though, most of this isn't needed.
Mainly: fix the one bug, decide if performance and debugability is adequate.


 - Jay



> From: hosking at cs.purdue.edu
> Date: Tue, 27 May 2014 12:49:12 -0400
> To: adacore at marino.st; jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
> Subject: Re: [M3devel] Status of CM3
> 
> Jay might comment on C backend status for those platforms.
> 
> On May 27, 2014, at 11:40 AM, John Marino <adacore at marino.st> wrote:
> 
> > On 5/27/2014 17:34, Dragi?a Duri? wrote:
> >> You can count on me for release engineering, Git migration. Maybe CI,
> >> if I have resources. Problem is - feedback is poor from core
> >> developers wrt Git migration. I am ready for long time now.
> > 
> > 
> > This might be a good time to remind that I've been waiting for a release
> > that feature C-backend support for both FreeBSD and DragonFly (new).
> > The version in FreeBSD ports is 4 years old, but there's not been a
> > release since then.  The last time I was active on the list we discussed
> > the needs of FreeBSD and for porting M3 to DragonFly and something was
> > supposed to happen code-wise (and then release-wise) but I don't think
> > anything did in the end.
> > 
> > I was extremely busy with other projects but was planning on pinging on
> > this topic soon anyway.
> > 
> > John
> > 
> > 
> >> 
> >> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
> >> 
> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
> >>> <bruce.axtens at gmail.com> wrote:
> >>> 
> >>>> Dear Sir
> >>>> 
> >>>> Should I assume that CM3 is alive, in palliative care or dead?
> >>>> The trac system is full of spam and the roadmap hasn't moved for
> >>>> 3 years.
> >>>> 
> >>>> I had a long and fruitful relationship with Modula-2 years ago
> >>>> and thought that perhaps I could restart things with CM3.
> >>> 
> >>> There is certainly some activity in M3 development recently,
> >>> though the community is rather small. The trac system has never
> >>> been much used by the community members; and the WWW presentation
> >>> and regression testing system has lacked my support, as I couldn't
> >>> spent any time on these topics for almost 3 years.
> >>> 
> >>> You should check the m3devel mailing list for news though: 
> >>> https://mail.elegosoft.com/pipermail/m3devel
> >>> 
> >>> There has been a lot of activity at the beginning of this year; it
> >>> has ceased again during recent weeks.
> >>> 
> >>> All CVS commits can be found here: 
> >>> https://mail.elegosoft.com/pipermail/m3commit
> >>> 
> >>> A new release is long overdue; I'm afraid I cannot do the release 
> >>> engineering this time.
> >>> 
> >>> There has been some effort on moving the CVS repositories to git; 
> >>> I'm not sure what the status is there, too.
> >>> 
> >>> Any help wrt. documentation, presentation or software is greatly 
> >>> appreciated ;-)
> >>> 
> >>> Regards,
> >>> 
> >>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
> >>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> >>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
> >>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
> >>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
> >>> | USt-IdNr: DE163214194
> >> 
> 
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +1 765 427 5484
> 
> 
> 
> 
> 
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/aff2833b/attachment.html>

From jay.krell at cornell.edu  Wed May 28 08:42:33 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 06:42:33 +0000
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>
References: <535FA2B2.70108@gmail.com>,
	<A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>
Message-ID: <COL130-W1019248A16E06F580E4D88E6250@phx.gbl>

.deb is just a .tar.gz or .tar.bz2 or .tar.xz with a little bit more around it.
They can be fancy but ours is not, it is just a compressed .tar.
Can you just crack it open and install the underlying parts?
It is likely "position independent" and you can extract it anywhere in your file system -- /usr/local/cm3, $HOME/cm3, etc.

I build them pretty "manually" see here:
https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/pylib.py  
the function MakeDebianPackage
Ok, it is an actually an "ar" file, and inside the main thing is data.tar with some compression like .gz or .xz.

 - Jay

From: dragisha at m3w.org
Date: Thu, 1 May 2014 19:49:28 +0200
To: bruceax at gmail.com
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr

It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.

--Dragi?a Duri?dragisha at m3w.org



On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:
  

    
  
  
    I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty?
    When I try to install it with Ubuntu Software Centre I get told the
    following:

    

    Lintian check results for
      /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:

      Can't use an undefined value as an ARRAY reference at
      /usr/share/perl5/

      Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.

    
    

    Is this a Perl issue or an installer issue?

    

    -- Bruce

    

  


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/3b4c0333/attachment.html>

From estellnb at elstel.org  Wed May 28 10:03:21 2014
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Wed, 28 May 2014 10:03:21 +0200
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <COL130-W1019248A16E06F580E4D88E6250@phx.gbl>
References: <535FA2B2.70108@gmail.com>,
	<A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>
	<COL130-W1019248A16E06F580E4D88E6250@phx.gbl>
Message-ID: <8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org>

If it is a true .deb you need to apply 
> ar x xy.deb
and then
> tar -xvJ <~/aux/data.tar.xz

(A real  .deb will also contain a control .tar.gz with control, shlibs, md5sums, postinst, etc.)

It should be built with
> pushd BUILD
> dpkg-buildpackage -sa -kmy at email.org
> popd
and checked with
> lintian -EvIL +pedantic my.dsc


Am 28.05.2014 um 08:42 schrieb Jay K:

> .deb is just a .tar.gz or .tar.bz2 or .tar.xz with a little bit more around it.
> They can be fancy but ours is not, it is just a compressed .tar.
> Can you just crack it open and install the underlying parts?
> It is likely "position independent" and you can extract it anywhere in your file system -- /usr/local/cm3, $HOME/cm3, etc.
> 
> I build them pretty "manually" see here:
> https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/pylib.py  
> the function MakeDebianPackage
> Ok, it is an actually an "ar" file, and inside the main thing is data.tar with some compression like .gz or .xz.
> 
>  - Jay
> 
> From: dragisha at m3w.org
> Date: Thu, 1 May 2014 19:49:28 +0200
> To: bruceax at gmail.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr
> 
> It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.
> --
> Dragi?a Duri?
> dragisha at m3w.org
> 
> 
> 
> On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:
> 
> I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty? When I try to install it with Ubuntu Software Centre I get told the following:
> 
> Lintian check results for /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:
> Can't use an undefined value as an ARRAY reference at /usr/share/perl5/
> Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.
> 
> Is this a Perl issue or an installer issue?
> 
> -- Bruce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/d6e4ec51/attachment.html>

From estellnb at elstel.org  Wed May 28 10:40:34 2014
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Wed, 28 May 2014 10:40:34 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
Message-ID: <8400B243-1D27-4651-84AB-071E26329507@elstel.org>

A new release would be great!
I have been waiting to get all the qt and gtk libraries packed with a new release.
If I wanna do some end user application development like the CoAN simulator in Modula-3 it will actually need to work with a release because I can not demand the users of my applications to compile the compiler first (That would harshly drop the usage rates).

Concerning a contribution from my side for a new CM3 release I could perhaps manage to get everything packed into .deb and .rpm package in summer as I do already have some experience in this field.

Regards,
Elmar
 

Am 25.05.2014 um 18:36 schrieb Olaf Wagner:

> On Sun, 25 May 2014 22:35:09 +0800
> Bruce Axtens <bruce.axtens at gmail.com> wrote:
> 
>> Dear Sir
>> 
>> Should I assume that CM3 is alive, in palliative care or dead? The trac
>> system is full of spam and the roadmap hasn't moved for 3 years.
>> 
>> I had a long and fruitful relationship with Modula-2 years ago and thought
>> that perhaps I could restart things with CM3.
> 
> There is certainly some activity in M3 development recently, though
> the community is rather small.
> The trac system has never been much used by the community members;
> and the WWW presentation and regression testing system has lacked
> my support, as I couldn't spent any time on these topics for
> almost 3 years.
> 
> You should check the m3devel mailing list for news though:
> https://mail.elegosoft.com/pipermail/m3devel
> 
> There has been a lot of activity at the beginning of this year;
> it has ceased again during recent weeks.
> 
> All CVS commits can be found here:
> https://mail.elegosoft.com/pipermail/m3commit
> 
> A new release is long overdue; I'm afraid I cannot do the release
> engineering this time.
> 
> There has been some effort on moving the CVS repositories to git;
> I'm not sure what the status is there, too.
> 
> Any help wrt. documentation, presentation or software is greatly
> appreciated ;-)
> 
> Regards,
> 
> Olaf Wagner
> -- 
> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From adacore at marino.st  Wed May 28 10:41:06 2014
From: adacore at marino.st (John Marino)
Date: Wed, 28 May 2014 10:41:06 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
Message-ID: <5385A122.4020205@marino.st>

On 5/28/2014 08:20, Jay K wrote:
>  Sorry, my life has really changed and I have hardly any time now..
>  I still hope to come back.
> 
> 
> 
> The C backend works quite well.
> I was able to cross-to and self-world-build many platforms.
> Including bring up new platform: AMD64_NT.
> There is a jmpbuf alignment problem on AMD64_NT worked around by using
> libcmt.lib instead of msvcrt.dll.
> jmpbuf remains a platform-specificity in the frontend.
> 
> 
>  I believe we had mostly good experience with Linux/arm and maybe
> Dragonfly?
>  Not sure.


Hi Jay,
The assumptions I was working on was this:
A) There has been no release
B) We want to convert FreeBSD to c-backend
C) There is no support for DragonFly, we want to add that
D) We want to do B+C before the next release

So I thought there was some build-framework stuff that needed to happen
for FreeBSD and DragonFly prior to the release, otherwise we'd just have
to patch it all up and we were trying to avoid needing those patches.

I am not even at the point of evaluating the C-Backend.
Maybe if there was a release candidate then I could figure out what's
missing a provide patches.

At the very, very least we could have CM3 on github and build from a
specific tag.  I am not wild about that, but it's better than what's
available now.  (FreeBSD ports can build straight from github although
it's not really encouraged)

So if for no other reason, I'd like to see CM3 migrate to github ASAP.

Regards,
John


From jay.krell at cornell.edu  Wed May 28 19:08:31 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 17:08:31 +0000
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org>
References: <535FA2B2.70108@gmail.com>, ,
	<A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>,
	<COL130-W1019248A16E06F580E4D88E6250@phx.gbl>,
	<8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org>
Message-ID: <COL130-W8356F05B7DCCB173BE7B78E6250@phx.gbl>

The .debs do have other files, at least one. See the code I pointed at.
I don't make them with the usual tools,
for an eaiser potential cross build story -- fewer dependencies.
It worked at the time.
 
 
# Debian architecture strings:
# see http://www.debian.org/doc/debian-policy/footnotes.html#f73

DebianArchitecture = {
  "LINUXLIBC6" : "i386",
  "FreeBSD4" : "i386",
  "NT386" : "i386",
  "I386" : "i386",
  "IA64" : "ia64",
  "ALPHA" : "alpha",
  "AMD64" : "amd64",
  "HPPA" : "hppa",
  "PA32" : "hppa",
  "PA64" : "hppa",
  "MIPS" : "mips",
  "MIPS32" : "mips",
  "MIPS64" : "mips",
  "PPC" : "powerpc",
  "PPC32" : "powerpc",
  "PPC64" : "ppc",
  "SOLsun" : "sparc",
  "SOLgnu" : "sparc",
  "SPARC" : "sparc",
  "SPARC32" : "sparc",
  "SPARC64" : "sparc",
  }

def MakeDebianPackage(input, prefix):
#
# .deb file format:
# an ar archive containing (I think the order matters):
#   debian-binary:
#     text file that just says "2.0\n"
#   control.tar.gz:
#     metadata, minimum is control file
#   data.tar.gz or .bz2 or .lzma
#     payload
# User has no choice where the install goes.
#
    if SearchPath("lzma"):
        compresser = "lzma"
        compressed_extension = "lzma"
    elif isfile("/home/jkrell/bin/lzma"):
        compresser = "/home/jkrell/bin/lzma"
        compressed_extension = "lzma"
    else:
        compresser = "gzip"
        compressed_extension = "gz"
    # while testing, gzip is much faster
    # compresser = "gzip"
    # compressed_extension = "gz"
    print("cd " + input)
    os.chdir(input)
    CreateDirectory("./debian")
    MoveSkel(prefix)
    newline = "\012" # take no chances
    open("./debian-binary", "w").write("2.0" + newline)
    os.chdir("./debian")
    architecture = DebianArchitecture.get(Target) or DebianArchitecture.get(Target[:Target.index("_")])
    control = (
      "Package: cm3-" + Target + "-" + CM3VERSION + newline
    + "Version: 1.0" + newline
    + "Maintainer: somebody at somewhere.com" + newline
    + "Architecture: " + architecture + newline
    + "Description: good stuff" + newline)
    print("control:" + control)
    open("./control", "w").write(control)

    command = "tar cf ../control.tar ."
    print(command)
    os.system(command)

    command = "gzip ../control.tar"
    print(command)
    os.system(command)

    os.chdir(input)
    command = "tar cf data.tar ." + prefix
    if isfile("data.tar." + compressed_extension) or isfile("data.tar"):
        print("skipping " + command)
    else:
        print(command)
        os.system(command)
    command = compresser + " data.tar"
    if isfile("data.tar." + compressed_extension):
        print("skipping " + command)
    else:
        print(command)
        os.system(command)

    command = "ar cr " + input + ".deb debian-binary control.tar.gz data.tar." + compressed_extension
    print(command)
    os.system(command)
    RestoreSkel(prefix)

 
 - Jay


 
From: estellnb at elstel.org
Date: Wed, 28 May 2014 10:03:21 +0200
To: jay.krell at cornell.edu; dragisha at m3w.org; bruceax at gmail.com
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr

If it is a true .deb you need to apply > ar x xy.deband then> tar -xvJ <~/aux/data.tar.xz
(A real  .deb will also contain a control .tar.gz with control, shlibs, md5sums, postinst, etc.)
It should be built with> pushd BUILD> dpkg-buildpackage -sa -kmy at email.org> popdand checked with> lintian -EvIL +pedantic my.dsc

Am 28.05.2014 um 08:42 schrieb Jay K:.deb is just a .tar.gz or .tar.bz2 or .tar.xz with a little bit more around it.
They can be fancy but ours is not, it is just a compressed .tar.
Can you just crack it open and install the underlying parts?
It is likely "position independent" and you can extract it anywhere in your file system -- /usr/local/cm3, $HOME/cm3, etc.

I build them pretty "manually" see here:
https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/pylib.py  
the function MakeDebianPackage
Ok, it is an actually an "ar" file, and inside the main thing is data.tar with some compression like .gz or .xz.

 - Jay

From: dragisha at m3w.org
Date: Thu, 1 May 2014 19:49:28 +0200
To: bruceax at gmail.com
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr

It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.
--Dragi?a Duri?dragisha at m3w.org

On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty? When I try to install it with Ubuntu Software Centre I get told the following:

Lintian check results for /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:
Can't use an undefined value as an ARRAY reference at /usr/share/perl5/
Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.

Is this a Perl issue or an installer issue?

-- Bruce
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/cca064e6/attachment.html>

From jay.krell at cornell.edu  Wed May 28 19:31:43 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 17:31:43 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <5385A122.4020205@marino.st>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
Message-ID: <COL130-W77F293FE76307E7C81612DE6250@phx.gbl>

 > A) There has been no release

 
There has been no release.
 
 
> B) We want to convert FreeBSD to c-backend


I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
 
 
Specifically, I no longer have shelves full of a myriad of computers, but I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux, OpenBSD, FreeBSD, NetBSD), I have the Solaris opencsw sparc32/sparc64/x86/amd64 machines, I have the Mac, I have Windows, I have the Elego Debian/amd64 maybe Debian/x86 machine and I tested many/all of these successfully. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't offer the thread/suspend/getcontext stuff -- something cooperative suspend will fix eventually.
 
 
Adding new platforms is fairly straightforward. Far more than it used to be.
You just make few scattered easy edits.
My pseudo goal is to drive that down to be easier and easier.
Several platforms have been relatively recently brought back or brought up or at least shown to work completely or almost to me.
 
What remains unclear to me is the consensus decision on exactly what the switch looks like.
  1) unconditionally switch all targets  
  2) leave it as some sort of user option  
  3) have new targets only supported using the C backend 
 
 
There are downsides to the C backend. Specifically:
  1) On systems that support m3gdb, debugging is not as good as with m3gdb 
   m3gdb is an old fork of gdb, doesn't work on all platforms (e.g. Darwin, HP-UX, NT), but does work on many. 
  2) Compilation is noticeably slower. 
  3) The output is not necessarily ABI compatible with the non-C backend. 
 
 
My inclination is unconditional switch to C backend for all targets that use m3cc, leave m3cc to bit-rot.
Think more about the integrated backend. In reality, given more time, I'd like to extend the integrated backend to support more targets. But that so far seems beyond most of our scopes.
 
The safe thing is user-option. But it is also confusing.
Given the ABI variation, do we double all the platforms?
I386_LINUX and I386_LINUX_C?
 
 
 And then later POSIX_32BIT_LITTLEENDIAN_C? 
 And then later GENERIC_C? 
 
Do we switch the existing ones, and introduce I386_LINUX_M3CC?
 
 
 > C) There is no support for DragonFly, we want to add that
 
This is easy.

> D) We want to do B+C before the next release
 
C is easy. B requires a decision/consensus.
 
Thanks,
 - Jay


 
> Date: Wed, 28 May 2014 10:41:06 +0200
> From: adacore at marino.st
> To: jay.krell at cornell.edu; hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
> Subject: Re: [M3devel] Status of CM3
> 
> On 5/28/2014 08:20, Jay K wrote:
> >  Sorry, my life has really changed and I have hardly any time now..
> >  I still hope to come back.
> > 
> > 
> > 
> > The C backend works quite well.
> > I was able to cross-to and self-world-build many platforms.
> > Including bring up new platform: AMD64_NT.
> > There is a jmpbuf alignment problem on AMD64_NT worked around by using
> > libcmt.lib instead of msvcrt.dll.
> > jmpbuf remains a platform-specificity in the frontend.
> > 
> > 
> >  I believe we had mostly good experience with Linux/arm and maybe
> > Dragonfly?
> >  Not sure.
> 
> 
> Hi Jay,
> The assumptions I was working on was this:
> A) There has been no release
> B) We want to convert FreeBSD to c-backend
> C) There is no support for DragonFly, we want to add that
> D) We want to do B+C before the next release
> 
> So I thought there was some build-framework stuff that needed to happen
> for FreeBSD and DragonFly prior to the release, otherwise we'd just have
> to patch it all up and we were trying to avoid needing those patches.
> 
> I am not even at the point of evaluating the C-Backend.
> Maybe if there was a release candidate then I could figure out what's
> missing a provide patches.
> 
> At the very, very least we could have CM3 on github and build from a
> specific tag.  I am not wild about that, but it's better than what's
> available now.  (FreeBSD ports can build straight from github although
> it's not really encouraged)
> 
> So if for no other reason, I'd like to see CM3 migrate to github ASAP.
> 
> Regards,
> John
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/21fbcbf9/attachment.html>

From mika at async.caltech.edu  Wed May 28 20:04:38 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Wed, 28 May 2014 11:04:38 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
Message-ID: <20140528180438.09C0F1A2097@async.async.caltech.edu>


Yes it worked pretty well as far as I remember.  There was still some
issue with a segfault we never debugged, but that was compiling all the
CM3 stuff plus my own big repository.  You were able to help me bootstrap
the regular compiler on ARM so that is what the regular ARM_LINUX is now
(for Raspberry Pi).

     Mika

---

Jay wrote:
The C backend works quite well.
I was able to cross-to and self-world-build many platforms.
Including bring up new platform: AMD64_NT.
There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.
jmpbuf remains a platform-specificity in the frontend.


 I believe we had mostly good experience with Linux/arm and maybe Dragonfly? 
 Not sure.


 Going through C source and C compiler is noticable slower. 




From adacore at marino.st  Wed May 28 20:24:06 2014
From: adacore at marino.st (John Marino)
Date: Wed, 28 May 2014 20:24:06 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
Message-ID: <538629C6.9070200@marino.st>

On 5/28/2014 19:31, Jay K wrote:
>> B) We want to convert FreeBSD to c-backend
> 
> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>  
>  > C) There is no support for DragonFly, we want to add that
>  
> This is easy.
> 
>> D) We want to do B+C before the next release
>  
> C is easy. B requires a decision/consensus.
>  

Hi Jay,
B requires a decision if it replaces m3cc on FreeBSD.
However if FreeBSD can keep m3cc but also be configured to build with
C-backend, then it shouldn't need a consensus as everyone wins.

I realize that that the real question is not about FreeBSD, but rather a
project-wide decision, however.

John


From mika at async.caltech.edu  Wed May 28 20:25:03 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Wed, 28 May 2014 11:25:03 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
Message-ID: <20140528182503.087801A2095@async.async.caltech.edu>

Jay K writes:
>--_af0f88f0-4e39-4643-873b-5267a8c2a602_
...
>> B) We want to convert FreeBSD to c-backend
>
>
>I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>=20
>=20
>Specifically=2C I no longer have shelves full of a myriad of computers=2C b=
>ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux=2C Open=
>BSD=2C FreeBSD=2C NetBSD)=2C I have the Solaris opencsw sparc32/sparc64/x86=
>/amd64 machines=2C I have the Mac=2C I have Windows=2C I have the Elego Deb=
>ian/amd64 maybe Debian/x86 machine and I tested many/all of these successfu=
>lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't of=
>fer the thread/suspend/getcontext stuff -- something cooperative suspend wi=
>ll fix eventually.
...

I don't think the C backend is perfect.  If you want to switch
unconditionally, I'll have to make time to help debug it.  My fuzzy 
memory, as I mentioned, is that there's some unexplained segfault.
Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
Something like that?  Ring a bell for anyone?

I quite like the native backends.  The code is more compact than
the C backend's.  I haven't done a performance comparison... I know
performance of Modula-3 code has in general been sliding backwards
through the versions.  Things just get slower and slower and slower
with time.  I think it's a shame because Modula-3's niche (well the one
I am interested in) is to be "almost the performance and simplicity of
C with the safety of Java (and some cool software engineering stuff)".
CM3 definitely compromised this, and while they added some cool new
features, most of them (e.g., dynamic relinking of running programs) as
far as I know are not being used.  The work on cleaning up TEXTs has 
gone a ways to remedying the situation but I think there's much else.
Ok now I'm off on a tangent...

    Mika


From hosking at cs.purdue.edu  Wed May 28 21:32:40 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 28 May 2014 15:32:40 -0400
Subject: [M3devel] Status of CM3
In-Reply-To: <20140528182503.087801A2095@async.async.caltech.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<20140528182503.087801A2095@async.async.caltech.edu>
Message-ID: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>

What is really needed is some time and attention put in to bring the CM3 runtime up to date with respect to advances in the field of runtime systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" locking), cooperative GC safepoints, integration with a modern code generator (LLVM!), on-the-fly GC (avoiding the need for stopping the world).

It would be wonderful to attack these, but they are also somewhat interrelated (on-the-fly depends on per-thread safepoint handshakes, biased locking requires compiler work, etc.).  So they cannot be simply carved off independently.

On May 28, 2014, at 2:25 PM, mika at async.caltech.edu wrote:

> Jay K writes:
>> --_af0f88f0-4e39-4643-873b-5267a8c2a602_
> ...
>>> B) We want to convert FreeBSD to c-backend
>> 
>> 
>> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>> =20
>> =20
>> Specifically=2C I no longer have shelves full of a myriad of computers=2C b=
>> ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux=2C Open=
>> BSD=2C FreeBSD=2C NetBSD)=2C I have the Solaris opencsw sparc32/sparc64/x86=
>> /amd64 machines=2C I have the Mac=2C I have Windows=2C I have the Elego Deb=
>> ian/amd64 maybe Debian/x86 machine and I tested many/all of these successfu=
>> lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't of=
>> fer the thread/suspend/getcontext stuff -- something cooperative suspend wi=
>> ll fix eventually.
> ...
> 
> I don't think the C backend is perfect.  If you want to switch
> unconditionally, I'll have to make time to help debug it.  My fuzzy 
> memory, as I mentioned, is that there's some unexplained segfault.
> Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
> Something like that?  Ring a bell for anyone?
> 
> I quite like the native backends.  The code is more compact than
> the C backend's.  I haven't done a performance comparison... I know
> performance of Modula-3 code has in general been sliding backwards
> through the versions.  Things just get slower and slower and slower
> with time.  I think it's a shame because Modula-3's niche (well the one
> I am interested in) is to be "almost the performance and simplicity of
> C with the safety of Java (and some cool software engineering stuff)".
> CM3 definitely compromised this, and while they added some cool new
> features, most of them (e.g., dynamic relinking of running programs) as
> far as I know are not being used.  The work on cleaning up TEXTs has 
> gone a ways to remedying the situation but I think there's much else.
> Ok now I'm off on a tangent...
> 
>   Mika

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/2368d3c9/attachment.html>

From jay.krell at cornell.edu  Wed May 28 22:13:56 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 20:13:56 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>,
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, ,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, ,
	<5384B209.3080504@marino.st>, ,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>,
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>, ,
	<5385A122.4020205@marino.st>,
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>,
	<20140528182503.087801A2095@async.async.caltech.edu>,
	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
Message-ID: <COL130-W29A4F6A942B48899A58222E6250@phx.gbl>

I'd be happy with:
  - cooperative GC, for portability, it'd remove a lot of our #ifdefs, fix PPC_DARWIN under Rosetta, and address a nagging concern I have for even NT/x86 on AMD64 wrt SuspendThread near-in-time to syscalls.
  - no-stop-the-world, for scaling 
 
Aren't they fairly standalone?
I could do without LLVM at this point. C/C++ backend is more portable.
I'd like to hope/depend that underlying pthreads/win32 does a good job with locking.
 
 - Jay

 
From: hosking at cs.purdue.edu
Date: Wed, 28 May 2014 15:32:40 -0400
To: mika at async.caltech.edu
CC: m3devel at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] Status of CM3

What is really needed is some time and attention put in to bring the CM3 runtime up to date with respect to advances in the field of runtime systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" locking), cooperative GC safepoints, integration with a modern code generator (LLVM!), on-the-fly GC (avoiding the need for stopping the world).

It would be wonderful to attack these, but they are also somewhat interrelated (on-the-fly depends on per-thread safepoint handshakes, biased locking requires compiler work, etc.).  So they cannot be simply carved off independently.

On May 28, 2014, at 2:25 PM, mika at async.caltech.edu wrote:

Jay K writes:
--_af0f88f0-4e39-4643-873b-5267a8c2a602_
...
B) We want to convert FreeBSD to c-backend


I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
=20
=20
Specifically=2C I no longer have shelves full of a myriad of computers=2C b=
ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux=2C Open=
BSD=2C FreeBSD=2C NetBSD)=2C I have the Solaris opencsw sparc32/sparc64/x86=
/amd64 machines=2C I have the Mac=2C I have Windows=2C I have the Elego Deb=
ian/amd64 maybe Debian/x86 machine and I tested many/all of these successfu=
lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't of=
fer the thread/suspend/getcontext stuff -- something cooperative suspend wi=
ll fix eventually.
...

I don't think the C backend is perfect.  If you want to switch
unconditionally, I'll have to make time to help debug it.  My fuzzy 
memory, as I mentioned, is that there's some unexplained segfault.
Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
Something like that?  Ring a bell for anyone?

I quite like the native backends.  The code is more compact than
the C backend's.  I haven't done a performance comparison... I know
performance of Modula-3 code has in general been sliding backwards
through the versions.  Things just get slower and slower and slower
with time.  I think it's a shame because Modula-3's niche (well the one
I am interested in) is to be "almost the performance and simplicity of
C with the safety of Java (and some cool software engineering stuff)".
CM3 definitely compromised this, and while they added some cool new
features, most of them (e.g., dynamic relinking of running programs) as
far as I know are not being used.  The work on cleaning up TEXTs has 
gone a ways to remedying the situation but I think there's much else.
Ok now I'm off on a tangent...

   Mika


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/c8543840/attachment.html>

From mika at async.caltech.edu  Wed May 28 22:32:18 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Wed, 28 May 2014 13:32:18 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<20140528182503.087801A2095@async.async.caltech.edu>
	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
Message-ID: <20140528203218.658CC1A2096@async.async.caltech.edu>


All that stuff is important but sometimes you just want a fast
single-threaded parser (or whatever)...

I *think* that if I write a program using ARRAY OF CHAR and hand-code everything 
not to allocate memory, etc., I get about as good performance in native CM3 as
I used to see in PM3.  It shouldn't be any slower than C, whether that is true
or not I don't know.

It is easier to write such (old-fashioned) programs in Modula-3 than in C, which
is one of the reasons I really like this programming language...

It would be nice if the performance loss in going to TEXT (for example) were not
that great.  Partly that has to do with some of the issues you talk about (GC/locking),
of course.

Tony Hosking writes:
>
>--Apple-Mail=_0963FC1A-17A1-4B57-93C6-C196F4ECCDC1
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=us-ascii
>
>What is really needed is some time and attention put in to bring the CM3 =
>runtime up to date with respect to advances in the field of runtime =
>systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" =
>locking), cooperative GC safepoints, integration with a modern code =
>generator (LLVM!), on-the-fly GC (avoiding the need for stopping the =
>world).
>
>It would be wonderful to attack these, but they are also somewhat =
>interrelated (on-the-fly depends on per-thread safepoint handshakes, =
>biased locking requires compiler work, etc.).  So they cannot be simply =
>carved off independently.
>
>On May 28, 2014, at 2:25 PM, mika at async.caltech.edu wrote:
>
>> Jay K writes:
>>> --_af0f88f0-4e39-4643-873b-5267a8c2a602_
>> ...
>>>> B) We want to convert FreeBSD to c-backend
>>>=20
>>>=20
>>> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C =
>backend.
>>> =3D20
>>> =3D20
>>> Specifically=3D2C I no longer have shelves full of a myriad of =
>computers=3D2C b=3D
>>> ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. =
>Linux=3D2C Open=3D
>>> BSD=3D2C FreeBSD=3D2C NetBSD)=3D2C I have the Solaris opencsw =
>sparc32/sparc64/x86=3D
>>> /amd64 machines=3D2C I have the Mac=3D2C I have Windows=3D2C I have =
>the Elego Deb=3D
>>> ian/amd64 maybe Debian/x86 machine and I tested many/all of these =
>successfu=3D
>>> lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta =
>doesn't of=3D
>>> fer the thread/suspend/getcontext stuff -- something cooperative =
>suspend wi=3D
>>> ll fix eventually.
>> ...
>>=20
>> I don't think the C backend is perfect.  If you want to switch
>> unconditionally, I'll have to make time to help debug it.  My fuzzy=20
>> memory, as I mentioned, is that there's some unexplained segfault.
>> Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
>> Something like that?  Ring a bell for anyone?
>>=20
>> I quite like the native backends.  The code is more compact than
>> the C backend's.  I haven't done a performance comparison... I know
>> performance of Modula-3 code has in general been sliding backwards
>> through the versions.  Things just get slower and slower and slower
>> with time.  I think it's a shame because Modula-3's niche (well the =
>one
>> I am interested in) is to be "almost the performance and simplicity of
>> C with the safety of Java (and some cool software engineering stuff)".
>> CM3 definitely compromised this, and while they added some cool new
>> features, most of them (e.g., dynamic relinking of running programs) =
>as
>> far as I know are not being used.  The work on cleaning up TEXTs has=20=
>
>> gone a ways to remedying the situation but I think there's much else.
>> Ok now I'm off on a tangent...
>>=20
>>   Mika
>
>Antony Hosking | Associate Professor | Computer Science | Purdue =
>University
>305 N. University Street | West Lafayette | IN 47907 | USA
>Mobile +1 765 427 5484
>
>
>
>
>
>
>--Apple-Mail=_0963FC1A-17A1-4B57-93C6-C196F4ECCDC1
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/html;
>	charset=us-ascii
>
><html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
>charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">What =
>is really needed is some time and attention put in to bring the CM3 =
>runtime up to date with respect to advances in the field of runtime =
>systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" =
>locking), cooperative GC safepoints, integration with a modern code =
>generator (LLVM!), on-the-fly GC (avoiding the need for stopping the =
>world).<br><br>It would be wonderful to attack these, but they are also =
>somewhat interrelated (on-the-fly depends on per-thread safepoint =
>handshakes, biased locking requires compiler work, etc.). &nbsp;So they =
>cannot be simply carved off independently.<br><br>On May 28, 2014, at =
>2:25 PM, <a =
>href=3D"mailto:mika at async.caltech.edu">mika at async.caltech.edu</a> =
>wrote:<br><br><blockquote type=3D"cite">Jay K writes:<br><blockquote =
>type=3D"cite">--_af0f88f0-4e39-4643-873b-5267a8c2a602_<br></blockquote>...=
><br><blockquote type=3D"cite"><blockquote type=3D"cite">B) We want to =
>convert FreeBSD to c-backend<br></blockquote><br><br>I believe I tested =
>FreeBSD/x86 and/or FreeBSD/amd64 with the C =
>backend.<br>=3D20<br>=3D20<br>Specifically=3D2C I no longer have shelves =
>full of a myriad of computers=3D2C b=3D<br>ut I have x86 and AMD64 VMs =
>on a Mac readily accessible (i.e. Linux=3D2C Open=3D<br>BSD=3D2C =
>FreeBSD=3D2C NetBSD)=3D2C I have the Solaris opencsw =
>sparc32/sparc64/x86=3D<br>/amd64 machines=3D2C I have the Mac=3D2C I =
>have Windows=3D2C I have the Elego Deb=3D<br>ian/amd64 maybe Debian/x86 =
>machine and I tested many/all of these successfu=3D<br>lly. PPC/Mac =
>can't entirely be tested on x86/Mac because Rosetta doesn't of=3D<br>fer =
>the thread/suspend/getcontext stuff -- something cooperative suspend =
>wi=3D<br>ll fix eventually.<br></blockquote>...<br><br>I don't think the =
>C backend is perfect. &nbsp;If you want to switch<br>unconditionally, =
>I'll have to make time to help debug it. &nbsp;My fuzzy <br>memory, as I =
>mentioned, is that there's some unexplained segfault.<br>Ah it was with =
>Juno, I think. &nbsp;Trestle? &nbsp;Overflow in window =
>resizing?<br>Something like that? &nbsp;Ring a bell for anyone?<br><br>I =
>quite like the native backends. &nbsp;The code is more compact =
>than<br>the C backend's. &nbsp;I haven't done a performance =
>comparison... I know<br>performance of Modula-3 code has in general been =
>sliding backwards<br>through the versions. &nbsp;Things just get slower =
>and slower and slower<br>with time. &nbsp;I think it's a shame because =
>Modula-3's niche (well the one<br>I am interested in) is to be "almost =
>the performance and simplicity of<br>C with the safety of Java (and some =
>cool software engineering stuff)".<br>CM3 definitely compromised this, =
>and while they added some cool new<br>features, most of them (e.g., =
>dynamic relinking of running programs) as<br>far as I know are not being =
>used. &nbsp;The work on cleaning up TEXTs has <br>gone a ways to =
>remedying the situation but I think there's much else.<br>Ok now I'm off =
>on a tangent...<br><br> &nbsp;&nbsp;Mika<br></blockquote><br><div>
><span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
>0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
>0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0px;  "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
>Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
>font-weight: normal; letter-spacing: normal; line-height: normal; =
>orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
>break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
>after-white-space; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF"><font =
>class=3D"Apple-style-span" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Antony =
>Hosking</span></span></font></font><font class=3D"Apple-style-span" =
>face=3D"Gill Sans"><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-converted-space">&nbsp;</span>|<span =
>class=3D"Apple-converted-space">&nbsp;</span></span></span><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; "><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; =
>">Associate Professor</span></span><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; "><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; ">&nbsp;| Computer Science | Purdue =
>University</span></span></font></div><div><font class=3D"Apple-style-span"=
> face=3D"GillSans-Light"><span class=3D"Apple-style-span" =
>style=3D"font-family: GillSans-Light; ">305 N. University Street | West =
>Lafayette | IN 47907 | USA</span></font></div><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Mobile</span></span></font><font =
>class=3D"Apple-style-span" face=3D"GillSans-Light"><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-converted-space">&nbsp;</span>+1 765 427 =
>5484</span></span></font></div><div><font class=3D"Apple-style-span" =
>face=3D"GillSans-Light"><br =
>class=3D"khtml-block-placeholder"></font></div></span></span></span></span=
>></span></span></span><br =
>class=3D"Apple-interchange-newline"></span></div></span></div></span><br =
>class=3D"Apple-interchange-newline"></span><br =
>class=3D"Apple-interchange-newline">
></div>
><br></body></html>=
>
>--Apple-Mail=_0963FC1A-17A1-4B57-93C6-C196F4ECCDC1--


From rcolebur at SCIRES.COM  Thu May 29 05:12:25 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 03:12:25 +0000
Subject: [M3devel] compilation problems with assertions in RTCollector.m3
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6C9B@ATLEX04-SRV.SCIRES.LOCAL>

Tony:

There is an error in "cm3\m3-libs\m3core\src\runtime\common\RTCollector.m3" at line 593.
"hdr" is not defined.
>From context, I'm not sure if it should be "h" or "he", but I've taken a guess on my local copy and changed it to "h".
I'm now running into additional problems.

So, I'll let you make the appropriate fix in the repository.

new source -> compiling RTCollector.m3
"..\src\runtime\common\RTCollector.m3", line 593: undefined (hdr)

Thanks,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Tuesday, May 27, 2014 11:57 AM
To: Coleburn, Randy
Cc: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] compilation problems with assertions in RTCollector.m3

Just committed a (hopeful) fix.  Please give it a try.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484






On May 24, 2014, at 12:57 AM, Coleburn, Randy <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> wrote:


I updated my sandbox to be current with the HEAD branch via CVS, then tried to rebuild everything.

I first built a minimal distribution on Windows XP.  Everything seemed to work fine.

Now, using my newly rebuilt cm3.exe, I decided to rebuild everything.  Unfortunately, now I'm running into problems even in the first stage.

Here are some examples of the errors I am getting.  These runtime errors happen compiling various packages.  (I've tried rebuilding several times.)

I show 3 separate incidents below and the last one has a partial stack trace.  In each case, there is an assertion failure in the RTCollector while running the compiler:

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 699
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x12f374   0x6ca19e  CleanBetween + 0x22 in ..\src\runtime\common\RTCollector.m3
0x12f3ac   0x6ca031  CopySome + 0xeb in ..\src\runtime\common\RTCollector.m3
0x12f3b8   0x6c9b02  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3
0x12f3c8   0x6c94d6  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3
0x12f40c   0x6c916a  CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3
0x12f44c   0x6dc586  AllocTraced + 0xd3 in ..\src\runtime\common\RTAllocator.m3
0x12f480   0x6dbbd8  GetTracedObj + 0x86 in ..\src\runtime\common\RTAllocator.m3
0x12f49c   0x6db70c  AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3
0x12f4d0   0x529913  Init_chars + 0x20b in ..\src\misc\CG.m3
0x12f4f8   0x4f948b  Init_chars + 0xb9 in ..\src\misc\M3String.m3
.........  .........  ... more frames ...

WARNING:  Encountered an error when processing package "m3-sys\m3front" for "-build".

Any help in solving this problem would be appreciated.

Thanks,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/abd55109/attachment.html>

From rcolebur at SCIRES.COM  Thu May 29 07:35:13 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 05:35:13 +0000
Subject: [M3devel] good news on Thread Tester program
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EA8@ATLEX04-SRV.SCIRES.LOCAL>

Tony & Mika:

I have good news to report about the Thread Tester program on Windows XP.

After making the change to RTCollector.m3" at line 593 from "hdr" to "h" and rebuilding everything again, I am now able FOR THE FIRST TIME EVER to get the Thread Tester program to run to completion!

See output below, including verbose mode.  I've also run with "-tests ALL" and it still runs to completion.

So, I think Tony's last round of changes may have been instrumental in fixing a problem with the collector, or either my edit did something weird in which case this may give Tony another clue to the puzzle.

--Randy Coleburn

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread>NT386\threadtest.exe
Writing file...done
Creating read threads...done
Creating fork threads...done
Creating alloc threads...done
Creating lock threads...done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread>NT386\threadtest.exe -verbose
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating fork threads...
   fork=9
   fork=10
   fork=11
done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 54 loops.
   read Thread 1 completed 59 loops.
   read Thread 2 completed 74 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   alloc Thread 15 completed 4713 loops.
   alloc Thread 16 completed 2190 loops.
   alloc Thread 17 completed 2292 loops.
   lock Thread 21 completed 1684145 loops.
   lock Thread 22 completed 3063707 loops.
   lock Thread 23 completed 3541711 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 60 loops.
   read Thread 1 completed 111 loops.
   read Thread 2 completed 64 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 6 loops.
   alloc Thread 15 completed 3280 loops.
   alloc Thread 16 completed 2470 loops.
   alloc Thread 17 completed 1307 loops.
   lock Thread 21 completed 2317559 loops.
   lock Thread 22 completed 3341857 loops.
   lock Thread 23 completed 3498231 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 19 loops.
   read Thread 1 completed 40 loops.
   read Thread 2 completed 56 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 2100 loops.
   alloc Thread 16 completed 1227 loops.
   alloc Thread 17 completed 1612 loops.
   lock Thread 21 completed 2281438 loops.
   lock Thread 22 completed 3874612 loops.
   lock Thread 23 completed 3777331 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 65 loops.
   read Thread 1 completed 67 loops.
   read Thread 2 completed 58 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 3860 loops.
   alloc Thread 16 completed 1897 loops.
   alloc Thread 17 completed 1261 loops.
   lock Thread 21 completed 2422432 loops.
   lock Thread 22 completed 3524236 loops.
   lock Thread 23 completed 3381697 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 62 loops.
   read Thread 1 completed 78 loops.
   read Thread 2 completed 105 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 8 loops.
   alloc Thread 15 completed 3659 loops.
   alloc Thread 16 completed 2552 loops.
   alloc Thread 17 completed 1838 loops.
   lock Thread 21 completed 1202534 loops.
   lock Thread 22 completed 2055904 loops.
   lock Thread 23 completed 2086094 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 57 loops.
   read Thread 1 completed 77 loops.
   read Thread 2 completed 64 loops.
   fork Thread 9 completed 8 loops.
   fork Thread 10 completed 9 loops.
   fork Thread 11 completed 8 loops.
   alloc Thread 15 completed 4430 loops.
   alloc Thread 16 completed 3199 loops.
   alloc Thread 17 completed 4229 loops.
   lock Thread 21 completed 1143292 loops.
   lock Thread 22 completed 1630285 loops.
   lock Thread 23 completed 2056873 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 36 loops.
   read Thread 1 completed 32 loops.
   read Thread 2 completed 61 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 2025 loops.
   alloc Thread 16 completed 669 loops.
   alloc Thread 17 completed 1874 loops.
   lock Thread 21 completed 2457649 loops.
   lock Thread 22 completed 4119545 loops.
   lock Thread 23 completed 3744966 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 19 loops.
   read Thread 1 completed 22 loops.
   read Thread 2 completed 23 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   alloc Thread 15 completed 2785 loops.
   alloc Thread 16 completed 1408 loops.
   alloc Thread 17 completed 1687 loops.
   lock Thread 21 completed 2406833 loops.
   lock Thread 22 completed 4204846 loops.
   lock Thread 23 completed 4080463 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 34 loops.
   read Thread 1 completed 66 loops.
   read Thread 2 completed 70 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 6 loops.
   alloc Thread 15 completed 2967 loops.
   alloc Thread 16 completed 1514 loops.
   alloc Thread 17 completed 1045 loops.
   lock Thread 21 completed 2094655 loops.
   lock Thread 22 completed 3280113 loops.
   lock Thread 23 completed 3632821 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 61 loops.
   read Thread 1 completed 14 loops.
   read Thread 2 completed 26 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 3055 loops.
   alloc Thread 16 completed 1943 loops.
   alloc Thread 17 completed 915 loops.
   lock Thread 21 completed 2255832 loops.
   lock Thread 22 completed 3704985 loops.
   lock Thread 23 completed 3691192 loops.
All tests complete.  Congratulations.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/439c02ae/attachment.html>

From rcolebur at SCIRES.COM  Thu May 29 07:40:15 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 05:40:15 +0000
Subject: [M3devel] build problems with libunicode
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>

I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).

The m3-libs\libunicode package fails to build (see errors below).

I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.

The problem module is: UnsafeUniCodec.m3

Thanks,
Randy Coleburn

C:\cm3\Sandbox\cm3\m3-libs\libunicode>cm3
--- building in NT386 ---

new source -> compiling UnsafeUniCodec.m3
"..\src\UnsafeUniCodec.m3", line 81: warning: not used (Sink)
"..\src\UnsafeUniCodec.m3", line 81: warning: not used (Wch)
"..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: UniCodec.Range
"..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Wr.Failure
"..\src\UnsafeUniCodec.m3", line 88: warning: not used (Source)
"..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.EndOfFile
"..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.Failure
"..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 96: warning: not used (Sink)
"..\src\UnsafeUniCodec.m3", line 96: warning: not used (Wch)
"..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: UniCodec.Range
"..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Wr.Failure
"..\src\UnsafeUniCodec.m3", line 105: warning: not used (Source)
"..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.EndOfFile
"..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.Failure
"..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 126: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 154: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 155: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 195: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 196: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 237: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 238: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 280: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 679: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 680: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 681: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 682: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 736: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 737: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 738: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 739: LOOPHOLE: expression's size differs from type's
16 errors and 18 warnings encountered
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/3c462f6e/attachment.html>

From rcolebur at SCIRES.COM  Thu May 29 07:44:29 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 05:44:29 +0000
Subject: [M3devel] build problems with "elego\prjm"
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6F20@ATLEX04-SRV.SCIRES.LOCAL>

I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).

The "elego\prjm" package fails to build (see errors below).

I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone wants to work on a solution.

Thanks,
Randy Coleburn

--- processing package "elego\prjm" ---
--- purging derived files from NT386 ---

--- cleaning NT386 ---

ignoring ..\src\m3overrides

--- building in NT386 ---

ignoring ..\src\m3overrides

C:\cm3\bin\m3bundle -name ProjectManagerBundle -element UsageHelp ..\src\UsageHelp -element compactrc ..\src\compactrc -element ShortUsageHelp ..\src\ShortUsageHelp
new source -> compiling ProjectManagerBundle.i3
new source -> compiling ProjectManagerBundle.m3
new source -> compiling Creation.i3
new source -> compiling Creation.m3

Fatal Error: bad version stamps: TimePrjDescTbl.i3

missing export: LongrealType.T imported by TimePrjDescTbl.i3
missing export: LongrealType.Brand imported by TimePrjDescTbl.i3

WARNING:  Encountered an error when processing package "elego\prjm" for "-build".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/b2ebf95c/attachment.html>

From jay.krell at cornell.edu  Thu May 29 09:26:07 2014
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 29 May 2014 07:26:07 +0000
Subject: [M3devel] build problems with "elego\prjm"
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6F20@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6F20@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL130-W811DED36FA9471989BC550E6240@phx.gbl>

This might be a "builder" incrementality problem,
related to that this module was moved from libm3
to m3core, a while ago.

I don't think we cope with such movement correctly.
 
Can you be sure to clean rebuild m3core, libm3,
and prjm, and maybe everything else?

Given the unicode problem, maybe not.
 
Thanks,
 - Jay



 
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Thu, 29 May 2014 05:44:29 +0000
Subject: [M3devel] build problems with "elego\prjm"









I?ve been rebuilding everything from the HEAD branch on Windows XP (32-bit).
 
The ?elego\prjm? package fails to build (see errors below).
 
I haven?t taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone wants to work on a solution.
 
Thanks,
Randy Coleburn
 
--- processing package "elego\prjm" ---
--- purging derived files from NT386 ---
 
--- cleaning NT386 ---
 
ignoring ..\src\m3overrides
 
--- building in NT386 ---
 
ignoring ..\src\m3overrides
 
C:\cm3\bin\m3bundle -name ProjectManagerBundle -element UsageHelp ..\src\UsageHelp -element compactrc ..\src\compactrc -element ShortUsageHelp ..\src\ShortUsageHelp
new source -> compiling ProjectManagerBundle.i3
new source -> compiling ProjectManagerBundle.m3
new source -> compiling Creation.i3
new source -> compiling Creation.m3
 
Fatal Error: bad version stamps: TimePrjDescTbl.i3
 
missing export: LongrealType.T imported by TimePrjDescTbl.i3
missing export: LongrealType.Brand imported by TimePrjDescTbl.i3
 
WARNING:  Encountered an error when processing package "elego\prjm" for "-build".
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/281f1505/attachment.html>

From jay.krell at cornell.edu  Thu May 29 02:26:24 2014
From: jay.krell at cornell.edu (Jay)
Date: Wed, 28 May 2014 17:26:24 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <538629C6.9070200@marino.st>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
	<5384B209.3080504@marino.st>
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<538629C6.9070200@marino.st>
Message-ID: <310E0B12-3444-4235-9157-A677C642F5F8@gmail.com>

I'm afraid offering both will lead to disuse of one and/or double test matrix.

Btw though FreeBSD and Dragonfly -- no relationship from our point of view. 

The C backend runs on any host & whether or not it is used can be a per target decision.

 - Jay

On May 28, 2014, at 11:24 AM, John Marino <adacore at marino.st> wrote:

> On 5/28/2014 19:31, Jay K wrote:
>>> B) We want to convert FreeBSD to c-backend
>> 
>> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>> 
>>> C) There is no support for DragonFly, we want to add that
>> 
>> This is easy.
>> 
>>> D) We want to do B+C before the next release
>> 
>> C is easy. B requires a decision/consensus.
> 
> Hi Jay,
> B requires a decision if it replaces m3cc on FreeBSD.
> However if FreeBSD can keep m3cc but also be configured to build with
> C-backend, then it shouldn't need a consensus as everyone wins.
> 
> I realize that that the real question is not about FreeBSD, but rather a
> project-wide decision, however.
> 
> John


From hosking at cs.purdue.edu  Thu May 29 15:40:54 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 29 May 2014 09:40:54 -0400
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <9C6CB9C2-D5D1-4D1B-8A5F-8DCCA3F3E0FE@cs.purdue.edu>

Jay?

On May 29, 2014, at 1:40 AM, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:

> I?ve been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>  
> The m3-libs\libunicode package fails to build (see errors below).
>  
> I haven?t taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>  
> The problem module is: UnsafeUniCodec.m3
>  
> Thanks,
> Randy Coleburn
>  
> C:\cm3\Sandbox\cm3\m3-libs\libunicode>cm3
> --- building in NT386 ---
>  
> new source -> compiling UnsafeUniCodec.m3
> "..\src\UnsafeUniCodec.m3", line 81: warning: not used (Sink)
> "..\src\UnsafeUniCodec.m3", line 81: warning: not used (Wch)
> "..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: UniCodec.Range
> "..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Wr.Failure
> "..\src\UnsafeUniCodec.m3", line 88: warning: not used (Source)
> "..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.EndOfFile
> "..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.Failure
> "..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 96: warning: not used (Sink)
> "..\src\UnsafeUniCodec.m3", line 96: warning: not used (Wch)
> "..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: UniCodec.Range
> "..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Wr.Failure
> "..\src\UnsafeUniCodec.m3", line 105: warning: not used (Source)
> "..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.EndOfFile
> "..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.Failure
> "..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 126: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 154: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 155: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 195: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 196: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 237: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 238: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 280: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 679: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 680: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 681: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 682: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 736: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 737: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 738: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 739: LOOPHOLE: expression's size differs from type's
> 16 errors and 18 warnings encountered

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/df0eb5a2/attachment.html>

From rodney_bates at lcwb.coop  Thu May 29 17:26:37 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 29 May 2014 10:26:37 -0500
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <538751AD.8080206@lcwb.coop>



On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> I?ve been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>
> The m3-libs\libunicode package fails to build (see errors below).
>
> I haven?t taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>
> The problem module is: UnsafeUniCodec.m3
>
> Thanks,
>
> Randy Coleburn
>

I am responsible for libunicode.

1. libunicode won't and is not designed to build unless the compiler is
    configured to make WIDECHAR have full unicode range, which, by default,
    it is not.

2. The simplest way to thus configure the compiler is to add the line
    Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
    everything, starting with m3core.

You can bootstrap all of this using the release compiler, see
cm3/scripts/README-build-unicode

I put libunicode in a separate package for that reason, and left the compiler
configured by default for the existing 16-bit range of WIDECHAR, so there
would be no perturbation to anybody's code unless you take some action.

We can change the default if there is consensus to do so.  Most code should
not be affected, but some lower-level things will be.  There is lots of info
on this subject, including what you get from it and what kinds of code might
be affected in:

cm3/README-unicode-summary
cm3/README-unicode
cm3/scripts/README-build-unicode

Rodney Bates
rodney.m.bates at acm.org


From rcolebur at SCIRES.COM  Thu May 29 22:54:55 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 20:54:55 +0000
Subject: [M3devel] build problems with libunicode
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>

Rodney:

Thanks very much for your response.

As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.

I'll take a look at your release notes.

Thanks,
Randy Coleburn

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Thursday, May 29, 2014 11:27 AM
To: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] build problems with libunicode



On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>
> The m3-libs\libunicode package fails to build (see errors below).
>
> I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>
> The problem module is: UnsafeUniCodec.m3
>
> Thanks,
>
> Randy Coleburn
>

I am responsible for libunicode.

1. libunicode won't and is not designed to build unless the compiler is
    configured to make WIDECHAR have full unicode range, which, by default,
    it is not.

2. The simplest way to thus configure the compiler is to add the line
    Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
    everything, starting with m3core.

You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode

I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.

We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:

cm3/README-unicode-summary
cm3/README-unicode
cm3/scripts/README-build-unicode

Rodney Bates
rodney.m.bates at acm.org


From rcolebur at SCIRES.COM  Thu May 29 23:37:59 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 21:37:59 +0000
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>

Rodney:

I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.

So, not sure why libunicode is trying to build on Windows (NT386).

--Randy Coleburn

-----Original Message-----
From: Coleburn, Randy 
Sent: Thursday, May 29, 2014 4:55 PM
To: m3devel at elegosoft.com
Subject: Re: [M3devel] build problems with libunicode

Rodney:

Thanks very much for your response.

As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.

I'll take a look at your release notes.

Thanks,
Randy Coleburn

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Thursday, May 29, 2014 11:27 AM
To: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] build problems with libunicode



On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>
> The m3-libs\libunicode package fails to build (see errors below).
>
> I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>
> The problem module is: UnsafeUniCodec.m3
>
> Thanks,
>
> Randy Coleburn
>

I am responsible for libunicode.

1. libunicode won't and is not designed to build unless the compiler is
    configured to make WIDECHAR have full unicode range, which, by default,
    it is not.

2. The simplest way to thus configure the compiler is to add the line
    Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
    everything, starting with m3core.

You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode

I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.

We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:

cm3/README-unicode-summary
cm3/README-unicode
cm3/scripts/README-build-unicode

Rodney Bates
rodney.m.bates at acm.org


From rcolebur at SCIRES.COM  Thu May 29 23:42:09 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 21:42:09 +0000
Subject: [M3devel] build problems with "elego\prjm"
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8AB1@ATLEX04-SRV.SCIRES.LOCAL>

Jay:

I've performed a clean rebuild of everything, but I still get the same error with "elego\prjm".
I'm also finding that "libunicode" is trying to build, yet there is no "Unicode_WIDECHAR" definition in the cm3.cfg files.
BTW, my target is NT386.

--Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, May 29, 2014 3:26 AM
To: Coleburn, Randy; m3devel
Subject: EXT:RE: [M3devel] build problems with "elego\prjm"

This might be a "builder" incrementality problem,
related to that this module was moved from libm3
to m3core, a while ago.

I don't think we cope with such movement correctly.

Can you be sure to clean rebuild m3core, libm3,
and prjm, and maybe everything else?

Given the unicode problem, maybe not.

Thanks,
 - Jay




________________________________
From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Date: Thu, 29 May 2014 05:44:29 +0000
Subject: [M3devel] build problems with "elego\prjm"
I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).

The "elego\prjm" package fails to build (see errors below).

I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone wants to work on a solution.

Thanks,
Randy Coleburn

--- processing package "elego\prjm" ---
--- purging derived files from NT386 ---

--- cleaning NT386 ---

ignoring ..\src\m3overrides

--- building in NT386 ---

ignoring ..\src\m3overrides

C:\cm3\bin\m3bundle -name ProjectManagerBundle -element UsageHelp ..\src\UsageHelp -element compactrc ..\src\compactrc -element ShortUsageHelp ..\src\ShortUsageHelp
new source -> compiling ProjectManagerBundle.i3
new source -> compiling ProjectManagerBundle.m3
new source -> compiling Creation.i3
new source -> compiling Creation.m3

Fatal Error: bad version stamps: TimePrjDescTbl.i3

missing export: LongrealType.T imported by TimePrjDescTbl.i3
missing export: LongrealType.Brand imported by TimePrjDescTbl.i3

WARNING:  Encountered an error when processing package "elego\prjm" for "-build".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/749b6377/attachment.html>

From jay.krell at cornell.edu  Fri May 30 02:07:11 2014
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 30 May 2014 00:07:11 +0000
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>

Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile
 
 
do something to filter itself out from building with a compiler that won't work?
 
Can you add a builtin quake function
WideCharByteSize() or some other name
 
that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?
 
 
 
 - Jay


> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Thu, 29 May 2014 21:37:59 +0000
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.
> 
> So, not sure why libunicode is trying to build on Windows (NT386).
> 
> --Randy Coleburn
> 
> -----Original Message-----
> From: Coleburn, Randy 
> Sent: Thursday, May 29, 2014 4:55 PM
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> Thanks very much for your response.
> 
> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.
> 
> I'll take a look at your release notes.
> 
> Thanks,
> Randy Coleburn
> 
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
> Sent: Thursday, May 29, 2014 11:27 AM
> To: m3devel at elegosoft.com
> Subject: EXT:Re: [M3devel] build problems with libunicode
> 
> 
> 
> On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
> >
> > The m3-libs\libunicode package fails to build (see errors below).
> >
> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
> >
> > The problem module is: UnsafeUniCodec.m3
> >
> > Thanks,
> >
> > Randy Coleburn
> >
> 
> I am responsible for libunicode.
> 
> 1. libunicode won't and is not designed to build unless the compiler is
>     configured to make WIDECHAR have full unicode range, which, by default,
>     it is not.
> 
> 2. The simplest way to thus configure the compiler is to add the line
>     Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
>     everything, starting with m3core.
> 
> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode
> 
> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.
> 
> We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:
> 
> cm3/README-unicode-summary
> cm3/README-unicode
> cm3/scripts/README-build-unicode
> 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/d4f41ef9/attachment.html>

From jay.krell at cornell.edu  Fri May 30 03:12:12 2014
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 30 May 2014 01:12:12 +0000
Subject: [M3devel] build problems with libunicode
In-Reply-To: <COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>
Message-ID: <COL130-W839E8D0F54961D3CD30386E6270@phx.gbl>

I guess Unicode_WIDECHAR = TRUE is what you picked, so:
 
if not defined("Unicode_WIDECHAR")
 Unicode_WIDECHAR = FALSE
end
in cm3cfg.common and libunicode/src/m3makefile
 
and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile?
 
 
I would have likely used a function returning byte size.
 
 
 
 - Jay

 
From: jay.krell at cornell.edu
To: rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] build problems with libunicode
Date: Fri, 30 May 2014 00:07:11 +0000




Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile
 
 
do something to filter itself out from building with a compiler that won't work?
 
Can you add a builtin quake function
WideCharByteSize() or some other name
 
that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?
 
 
 
 - Jay


> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Thu, 29 May 2014 21:37:59 +0000
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.
> 
> So, not sure why libunicode is trying to build on Windows (NT386).
> 
> --Randy Coleburn
> 
> -----Original Message-----
> From: Coleburn, Randy 
> Sent: Thursday, May 29, 2014 4:55 PM
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> Thanks very much for your response.
> 
> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.
> 
> I'll take a look at your release notes.
> 
> Thanks,
> Randy Coleburn
> 
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
> Sent: Thursday, May 29, 2014 11:27 AM
> To: m3devel at elegosoft.com
> Subject: EXT:Re: [M3devel] build problems with libunicode
> 
> 
> 
> On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
> >
> > The m3-libs\libunicode package fails to build (see errors below).
> >
> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
> >
> > The problem module is: UnsafeUniCodec.m3
> >
> > Thanks,
> >
> > Randy Coleburn
> >
> 
> I am responsible for libunicode.
> 
> 1. libunicode won't and is not designed to build unless the compiler is
>     configured to make WIDECHAR have full unicode range, which, by default,
>     it is not.
> 
> 2. The simplest way to thus configure the compiler is to add the line
>     Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
>     everything, starting with m3core.
> 
> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode
> 
> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.
> 
> We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:
> 
> cm3/README-unicode-summary
> cm3/README-unicode
> cm3/scripts/README-build-unicode
> 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/1fdba61b/attachment.html>

From rcolebur at SCIRES.COM  Fri May 30 03:38:01 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 30 May 2014 01:38:01 +0000
Subject: [M3devel] build problems with libunicode
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL>

Jay / Rodney:

Well I didn't "pick" anything, but it appears that since I chose to rebuild everything based on pkginfo.txt that is why libunicode is now trying to build on my Windows box.

I have several options:

1.      Using my build scripts, I could choose to exclude libunicode (I have an option for that).

2.      We could modify the cm3.cfg and m3makefile as Jay suggests to prevent libunicode from trying to build unless Unicode_WIDECHAR is defined and TRUE.

3.      Etc.

For the short term, I think I'll try #1.
Then, I'll think about some mods for #2 and commit them if they test out.  That way, the Unicode_WIDECHAR could be used to turn this feature on and off as Rodney suggested.

For the elego\prjm package, I'm not sure whether it is supposed to be buildable on Windows.  If not, I can just exclude it, or we can modify the m3makefile to prevent it from building on Windows.  Obviously, I never used this package before.

Thanks for your help!

Thanks,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, May 29, 2014 9:12 PM
To: Coleburn, Randy; m3devel
Subject: EXT:RE: [M3devel] build problems with libunicode

I guess Unicode_WIDECHAR = TRUE is what you picked, so:

if not defined("Unicode_WIDECHAR")
 Unicode_WIDECHAR = FALSE
end
in cm3cfg.common and libunicode/src/m3makefile

and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile?


I would have likely used a function returning byte size.



 - Jay


________________________________
From: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Subject: RE: [M3devel] build problems with libunicode
Date: Fri, 30 May 2014 00:07:11 +0000
Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile


do something to filter itself out from building with a compiler that won't work?

Can you add a builtin quake function
WideCharByteSize() or some other name

that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?



 - Jay

> From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
> To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Date: Thu, 29 May 2014 21:37:59 +0000
> Subject: Re: [M3devel] build problems with libunicode
>
> Rodney:
>
> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.
>
> So, not sure why libunicode is trying to build on Windows (NT386).
>
> --Randy Coleburn
>
> -----Original Message-----
> From: Coleburn, Randy
> Sent: Thursday, May 29, 2014 4:55 PM
> To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: Re: [M3devel] build problems with libunicode
>
> Rodney:
>
> Thanks very much for your response.
>
> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.
>
> I'll take a look at your release notes.
>
> Thanks,
> Randy Coleburn
>
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop]
> Sent: Thursday, May 29, 2014 11:27 AM
> To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: EXT:Re: [M3devel] build problems with libunicode
>
>
>
> On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
> >
> > The m3-libs\libunicode package fails to build (see errors below).
> >
> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
> >
> > The problem module is: UnsafeUniCodec.m3
> >
> > Thanks,
> >
> > Randy Coleburn
> >
>
> I am responsible for libunicode.
>
> 1. libunicode won't and is not designed to build unless the compiler is
> configured to make WIDECHAR have full unicode range, which, by default,
> it is not.
>
> 2. The simplest way to thus configure the compiler is to add the line
> Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
> everything, starting with m3core.
>
> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode
>
> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.
>
> We can change the default if there is consensus to do so. Most code should not be affected, but some lower-level things will be. There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:
>
> cm3/README-unicode-summary
> cm3/README-unicode
> cm3/scripts/README-build-unicode
>
> Rodney Bates
> rodney.m.bates at acm.org<mailto:rodney.m.bates at acm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/59bbf6ba/attachment.html>

From estellnb at elstel.org  Fri May 30 10:00:00 2014
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Fri, 30 May 2014 10:00:00 +0200
Subject: [M3devel] build problems with libunicode
In-Reply-To: <538751AD.8080206@lcwb.coop>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
	<538751AD.8080206@lcwb.coop>
Message-ID: <D3148A49-F24C-4F8C-ADA8-B6449DA9868D@elstel.org>


Am 29.05.2014 um 17:26 schrieb Rodney M. Bates:

> 
> I am responsible for libunicode.
> 
> 1. libunicode won't and is not designed to build unless the compiler is
>   configured to make WIDECHAR have full unicode range, which, by default,
>   it is not.
> 
> I put libunicode in a separate package for that reason, and left the compiler
> configured by default for the existing 16-bit range of WIDECHAR, so there
> would be no perturbation to anybody's code unless you take some action.
> 
> We can change the default if there is consensus to do so.  Most code should
> not be affected, but some lower-level things will be.  

Well, the program I wanna port would actually profit from both types:
* a 16-bit unicode type for interfacing with gtk & qt
* a 32-bit unicode type for the program level user input function yielding math & greek letters

Will it be possible to simply declare BITS 16 FOR WIDECHAR when unicode support is enabled?
What complications to the Text library will that cause if we have a 16-bit and a 32-bit character 
type at the same time?
What would you think about leaving WIDECHAR as 16-bit and rather introducing UCHAR as 
32-bit character type? I believe this would be the best solution as it does not break any existing
code.

Best Regards,
Elmar Stellnberger

> 
> Rodney Bates
> rodney.m.bates at acm.org
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/59d2aacc/attachment.html>

From dragisha at m3w.org  Fri May 30 13:50:17 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 30 May 2014 13:50:17 +0200
Subject: [M3devel] Git, a call for participation - AGAIN
In-Reply-To: <688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF925D0BFD@ATLEX04-SRV.SCIRES.LOCAL>,
	<A297D619-A23C-4583-82DD-FED9716EC843@m3w.org>
	<C7E469CD-A4A1-4CAD-BF27-AEC6E7EE22CF@SCIRES.COM>
	<688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
Message-ID: <BBA0A7FF-4D15-47CC-A9A3-F2A34962D623@m3w.org>

I am making latest CVS repo conversion. Please send your github usernames to me.

dd

On 19 Feb 2014, at 23:34, Dragi?a Duri? <dragisha at m3w.org> wrote:

> You will need separate working directory. With git, you will have whole cm3 repository cloned in toplevel .git folder. With svn you have .svn folders around, and CVS folders with cvs.
> 
> On 19 Feb 2014, at 18:05, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
> 
>> Sorry, I should rephrase the question:  Do I need to create a separate folder tree for my local copy of the cm3 source code tree for use with Git, or can I reuse the existing folder tree that I use with CVS?
>> 
>> --Randy Coleburn
>> 
>> On Feb 19, 2014, at 2:10 AM, "Dragi?a Duri?" <dragisha at m3w.org> wrote:
>> 
>>> Email was for conversion process and it is all set-up.
>>> 
>>> Github account, and request to me (dragisha) on github for cm3 repository is separate step.
>>> 
>>> You don?t really need TortoiseGit. Github has it?s GUI shell, but everything is doable just well with Git Bash console. I will share my Git on Windows experience as we progress with migration. 
>>> 
>>> Sandbox? Meaning virtual machine or?
>>> 
>>> dd
>>> 
>>> On 18 Feb 2014, at 01:30, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>> 
>>>> I have ssh set up with existing repository.  Do I need a different ssh for the Git, or will we use the existing one?
>>>> I seem to recall providing you with my email earlier for the authors file.
>>>> I can install TortoiseGit at some point and run a test when you are ready.
>>>> BTW, do I need to create a separate sandbox for Git, or can I just reuse existing CVS sandbox?
>>>> --Randy
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 6:05 PM
>>>> To: Coleburn, Randy
>>>> Cc: m3devel
>>>> Subject: EXT:Re: [M3devel] Git, a call for participation
>>>>  
>>>> Randy,
>>>>  
>>>> You don?t need to install anything on your computer to participate in Github project. If you have ssh enabled, you are ready to go. If not, then problem can be with corporate proxies running NTLM authentication. My company enabled github and bitbucket access without NTLM so I don?t have experience solving it, but I know it is possible.
>>>>  
>>>> dd
>>>> 
>>>> On 17 Feb 2014, at 16:24, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>>> 
>>>> 
>>>> Dragi?a:
>>>>  
>>>> I am not currently a member of GitHub.  From what I understand, this site provides some social networking functionality and requires that software supporting this functionality be installed on your computer.
>>>>  
>>>> 1.      Is it possible to take advantage of Git for source code checkin/checkout WITHOUT also becoming a member of GitHub?  
>>>> If so, what, if any, are the limitations of not being a member wrt the future of the CM3 repository?
>>>> 
>>>> 
>>>> 2.      What are the security concerns with installing the GitHub software?
>>>>  
>>>> My company severely restricts use of social media (it is blocked via the various firewalls), so that may make use of GitHub more difficult in my situation.
>>>>  
>>>> I think I should be able to use TortoiseGit for source code checkin/out, since I currently use TortoiseCVS; however, I have not used TortoiseGit before, so there will be a slight learning curve for me I?m sure.
>>>>  
>>>> Thanks,
>>>> Randy Coleburn
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 2:52 AM
>>>> To: m3devel
>>>> Subject: EXT:[M3devel] Git, a call for participation
>>>>  
>>>> Hi,
>>>>  
>>>> To proceed with planned conversion, I need developers to join github and connect me there (dragisha @ github). Once we have developers connected there, we can proceed and switch.
>>>>  
>>>> TIA, 
>>>> --
>>>> Dragi?a Duri?
>>>> dragisha at m3w.org
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/a6409f28/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/a6409f28/attachment.sig>

From rodney_bates at lcwb.coop  Fri May 30 19:08:26 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 30 May 2014 12:08:26 -0500
Subject: [M3devel] build problems with libunicode
In-Reply-To: <COL130-W839E8D0F54961D3CD30386E6270@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>
	<COL130-W839E8D0F54961D3CD30386E6270@phx.gbl>
Message-ID: <5388BB0A.6040603@lcwb.coop>

Hmm, fix it in the m3makefile and just not mess with the do-cm3-*.sh scripts at all.
That shouldn't be too hard.  The m3makfile could emit a loud warning that UniCodec
was not a working version.

Or maybe not build even UniCodec's interface, which would no doubt entail not building
anything in the library at all.  None of it will be of much use without full Unicode
WIDECHAR.

On 05/29/2014 08:12 PM, Jay K wrote:
> I guess Unicode_WIDECHAR = TRUE is what you picked, so:
>
> if not defined("Unicode_WIDECHAR")
>   Unicode_WIDECHAR = FALSE
> end
> in cm3cfg.common and libunicode/src/m3makefile
>
> and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile?
>
>
> I would have likely used a function returning byte size.
>
>
>
>   - Jay
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 --
> From: jay.krell at cornell.edu
> To: rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] build problems with libunicode
> Date: Fri, 30 May 2014 00:07:11 +0000
>
> Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile
>
>
> do something to filter itself out from building with a compiler that won't work?
>
> Can you add a builtin quake function
> WideCharByteSize() or some other name
>
> that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
> and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?
>
>
>
>   - Jay
>
>
-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Fri May 30 21:49:29 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 30 May 2014 14:49:29 -0500
Subject: [M3devel] No short-circuit "or" and "and" in Quake
Message-ID: <5388E0C9.1030500@lcwb.coop>

I just discovered by accident, an undocumented peculiarity in Quake.
The "or" boolean operator (and, presumably "and" too) do not have the
usual short-circuit property.  So, for example, you can't write:

if not defined("Unicode_WIDECHAR")
    or empty (Unicode_WIDECHAR)

If it's undefined, Quake will still evaluate and crash on the second
condition.


-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Fri May 30 18:39:39 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 30 May 2014 11:39:39 -0500
Subject: [M3devel] build problems with libunicode
In-Reply-To: <D3148A49-F24C-4F8C-ADA8-B6449DA9868D@elstel.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
	<538751AD.8080206@lcwb.coop>
	<D3148A49-F24C-4F8C-ADA8-B6449DA9868D@elstel.org>
Message-ID: <5388B44B.2000602@lcwb.coop>



On 05/30/2014 03:00 AM, Elmar Stellnberger wrote:
>
> Am 29.05.2014 um 17:26 schrieb Rodney M. Bates:
>
>>
>> I am responsible for libunicode.
>>
>> 1. libunicode won't and is not designed to build unless the compiler is
>>   configured to make WIDECHAR have full unicode range, which, by default,
>>   it is not.
>>
>> I put libunicode in a separate package for that reason, and left the compiler
>> configured by default for the existing 16-bit range of WIDECHAR, so there
>> would be no perturbation to anybody's code unless you take some action.
>>
>> We can change the default if there is consensus to do so.  Most code should
>> not be affected, but some lower-level things will be.
>
> Well, the program I wanna port would actually profit from both types:
> * a 16-bit unicode type for interfacing with gtk & qt
> * a 32-bit unicode type for the program level user input function yielding math & greek letters
>
> Will it be possible to simply declare BITS 16 FOR WIDECHAR when unicode support is enabled?

This would not compile, as BITS FOR must be enough bits to hold the value set of the type.
But BITS 16 FOR [FIRST(WIDECHAR)..VAL(16_FFFF),WIDECHAR] would give you what you need to
pass in and out of a library that uses a 16-bit character.  You could either keep your
characters in this type or assign back and forth between this and WIDECHAR, which would
do runtime value checks where necessary.

But do gtk and qt actually treat all characters as 16-bit fixed-size code points, or do they
actually use UTF16, with the 16-bit value being a code unit, not a code point?  In the
latter case, using UniWr and UniRd to do the encoding/decoding would be a much cleaner
option.

> What complications to the Text library will that cause if we have a 16-bit and a 32-bit character
> type at the same time?

The Text library already has two sizes: CHAR (8) and WIDECHAR (either 16 or 32).  A third would require more
code.  Pickles and network objects would need quite a bit of additional code, and they are quite
a bit more complicated than Text, because they have to handle values written by different compilers.

> What would you think about leaving WIDECHAR as 16-bit and rather introducing UCHAR as
> 32-bit character type? I believe this would be the best solution as it does not break any existing
> code.
>
> Best Regards,
> Elmar Stellnberger
>
>>
>> Rodney Bates
>> rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>
>>
>

-- 
Rodney Bates
rodney.m.bates at acm.org


From dragisha at m3w.org  Fri May 30 22:48:31 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 30 May 2014 22:48:31 +0200
Subject: [M3devel] Git, a call for participation
In-Reply-To: <688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF925D0BFD@ATLEX04-SRV.SCIRES.LOCAL>,
	<A297D619-A23C-4583-82DD-FED9716EC843@m3w.org>
	<C7E469CD-A4A1-4CAD-BF27-AEC6E7EE22CF@SCIRES.COM>
	<688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
Message-ID: <610A2ACE-7BE8-4546-98AB-7690D7CC010B@m3w.org>

My plan:

* Do a conversion to Git, place it on github.
* As m3devel people identify/communicate with me on github, access rights will be granted one by one.
* Alternatively we can use pull-request mechanism. We can also extend jenkins to do non-canonical builds/testing. Canonical being a master branch of repo from first item.
* Install Jenkins on my server box, connect to donated slave instances, do builds, distribute results over some (yet undefined) public server. I don?t have bandwidth for big file distribution.
* Move pieces to better locations, as they become available.

Any suggestions?

On 19 Feb 2014, at 23:34, Dragi?a Duri? <dragisha at m3w.org> wrote:

> You will need separate working directory. With git, you will have whole cm3 repository cloned in toplevel .git folder. With svn you have .svn folders around, and CVS folders with cvs.
> 
> On 19 Feb 2014, at 18:05, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
> 
>> Sorry, I should rephrase the question:  Do I need to create a separate folder tree for my local copy of the cm3 source code tree for use with Git, or can I reuse the existing folder tree that I use with CVS?
>> 
>> --Randy Coleburn
>> 
>> On Feb 19, 2014, at 2:10 AM, "Dragi?a Duri?" <dragisha at m3w.org> wrote:
>> 
>>> Email was for conversion process and it is all set-up.
>>> 
>>> Github account, and request to me (dragisha) on github for cm3 repository is separate step.
>>> 
>>> You don?t really need TortoiseGit. Github has it?s GUI shell, but everything is doable just well with Git Bash console. I will share my Git on Windows experience as we progress with migration. 
>>> 
>>> Sandbox? Meaning virtual machine or?
>>> 
>>> dd
>>> 
>>> On 18 Feb 2014, at 01:30, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>> 
>>>> I have ssh set up with existing repository.  Do I need a different ssh for the Git, or will we use the existing one?
>>>> I seem to recall providing you with my email earlier for the authors file.
>>>> I can install TortoiseGit at some point and run a test when you are ready.
>>>> BTW, do I need to create a separate sandbox for Git, or can I just reuse existing CVS sandbox?
>>>> --Randy
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 6:05 PM
>>>> To: Coleburn, Randy
>>>> Cc: m3devel
>>>> Subject: EXT:Re: [M3devel] Git, a call for participation
>>>>  
>>>> Randy,
>>>>  
>>>> You don?t need to install anything on your computer to participate in Github project. If you have ssh enabled, you are ready to go. If not, then problem can be with corporate proxies running NTLM authentication. My company enabled github and bitbucket access without NTLM so I don?t have experience solving it, but I know it is possible.
>>>>  
>>>> dd
>>>> 
>>>> On 17 Feb 2014, at 16:24, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>>> 
>>>> 
>>>> Dragi?a:
>>>>  
>>>> I am not currently a member of GitHub.  From what I understand, this site provides some social networking functionality and requires that software supporting this functionality be installed on your computer.
>>>>  
>>>> 1.      Is it possible to take advantage of Git for source code checkin/checkout WITHOUT also becoming a member of GitHub?  
>>>> If so, what, if any, are the limitations of not being a member wrt the future of the CM3 repository?
>>>> 
>>>> 
>>>> 2.      What are the security concerns with installing the GitHub software?
>>>>  
>>>> My company severely restricts use of social media (it is blocked via the various firewalls), so that may make use of GitHub more difficult in my situation.
>>>>  
>>>> I think I should be able to use TortoiseGit for source code checkin/out, since I currently use TortoiseCVS; however, I have not used TortoiseGit before, so there will be a slight learning curve for me I?m sure.
>>>>  
>>>> Thanks,
>>>> Randy Coleburn
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 2:52 AM
>>>> To: m3devel
>>>> Subject: EXT:[M3devel] Git, a call for participation
>>>>  
>>>> Hi,
>>>>  
>>>> To proceed with planned conversion, I need developers to join github and connect me there (dragisha @ github). Once we have developers connected there, we can proceed and switch.
>>>>  
>>>> TIA, 
>>>> --
>>>> Dragi?a Duri?
>>>> dragisha at m3w.org
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/3f720996/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/3f720996/attachment.sig>

From jay.krell at cornell.edu  Sat May 31 01:13:48 2014
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 30 May 2014 23:13:48 +0000
Subject: [M3devel] No short-circuit "or" and "and" in Quake
In-Reply-To: <5388E0C9.1030500@lcwb.coop>
References: <5388E0C9.1030500@lcwb.coop>
Message-ID: <COL130-W31F76F5445BA76A31EA982E6270@phx.gbl>

Yes, I know, it is unfortunate and counterintuitive. I workaround it all the time.
 
 - Jay

 
> Date: Fri, 30 May 2014 14:49:29 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: [M3devel] No short-circuit "or" and "and" in Quake
> 
> I just discovered by accident, an undocumented peculiarity in Quake.
> The "or" boolean operator (and, presumably "and" too) do not have the
> usual short-circuit property.  So, for example, you can't write:
> 
> if not defined("Unicode_WIDECHAR")
>     or empty (Unicode_WIDECHAR)
> 
> If it's undefined, Quake will still evaluate and crash on the second
> condition.
> 
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/907ee3a4/attachment.html>

From wagner at elegosoft.com  Sat May 31 10:50:03 2014
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 31 May 2014 10:50:03 +0200
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <20140531105003.c365f974ec13b9f47b5fda34@elegosoft.com>

On Fri, 30 May 2014 01:38:01 +0000
"Coleburn, Randy" <rcolebur at SCIRES.COM> wrote:

> Jay / Rodney:
> 
> For the elego\prjm package, I'm not sure whether it is supposed to be buildable on Windows.  If not, I can just exclude it, or we can modify the m3makefile to prevent it from building on Windows.  Obviously, I never used this package before.

All the packages from Elego used to build on Windows, Linux, BSD
and Solaris platforms. However, I don't think anything depends
on this that you will need so you should be safe to exclude
all the stuff in the elego directory.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


From wagner at elegosoft.com  Sat May 31 11:38:52 2014
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 31 May 2014 11:38:52 +0200
Subject: [M3devel] CVS to GIT migration -- shutdown of elego's CVS services
	for M3
Message-ID: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com>

Hello all,

with the possibility of the CM3 project being hosted on Github,
where it can be continued safely and with much more and better
hardware resources than elego could ever provide, elego will
stop providing the legacy CVS service for the source code as
soon as possible. This does not mean that we will stop all of
our support, and we certainly won't remove access to the sources
before easy access to them at another provider is established.
But we would like to urge all the developers to help with the
migration and ensure that the use and development of Modula-3
will continue as seamlessly as possible.

The WWW service can stay online some time longer, though
I think all the stuff available there should be reviewed
and moved to a Wiki with easy access for all the developers.

13 months ago I set up this Wiki page at the M3 Trac
instance to allocate all the things that I thought should
be done and considered, but nobody else has contributed
to that, so that has probably not been the right approach: 

https://cm3-bugs.elegosoft.com/cm3/wiki/CvsToGitMigration

However, I think a clean migration to git should be no
big problem, and it should also improve the visibility
and ease of use of the assets, so it will be all for the
best of the project.

Some personal notes:

After the huge amount of time I spent in preparing, testing
and bundling the last release of CM3 several years ago,
I was not able to sustain any noticable contribution to
the M3 development. Both private and business matters
claimed so much attention that I was not able to provide
the necessary time to even keep all the infrastructure
-- WWW, scripts, CI etc. -- in proper and usable shape.
And I'm afraid that this won't change soon, so there is
no hope for much contribution from my side for the
foreseeable future. 

I would dearly like to see the use of Modula-3 spread and
the project prosper and thrive and I'll try to support
this as much as I can. Embarrassing desasters like
heartbleed could easily have been prevented by the use
of Modula-3 or the application of the sound principles
and techniques that are its base. I still believe that
using a safe language for large projects should be a
inevitable decision from an engineering point of view,
but keeping the users and developers of M3 in a kind of
enclave won't help in the large run.

So please see my decision to discontinue the repository
support as a friendly push to start moving in the right
direction.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


From schlepptop at henning-thielemann.de  Sat May 31 11:53:19 2014
From: schlepptop at henning-thielemann.de (Henning Thielemann)
Date: Sat, 31 May 2014 11:53:19 +0200
Subject: [M3devel] CVS to GIT migration -- shutdown of elego's CVS
 services for M3
In-Reply-To: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com>
References: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com>
Message-ID: <5389A68F.1070003@henning-thielemann.de>

Am 31.05.2014 11:38, schrieb Olaf Wagner:

> The WWW service can stay online some time longer, though
> I think all the stuff available there should be reviewed
> and moved to a Wiki with easy access for all the developers.

Btw. I like Wikis that you can edit offline, like gitit.



From bruce.axtens at gmail.com  Sat May 31 16:05:49 2014
From: bruce.axtens at gmail.com (Bruce M. Axtens)
Date: Sat, 31 May 2014 22:05:49 +0800
Subject: [M3devel] Problem building on Win7
In-Reply-To: <53898228.9010807@elego.de>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>	<5384B209.3080504@marino.st>	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>	<5385A122.4020205@marino.st>	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>	<20140528182503.087801A2095@async.async.caltech.edu>	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>	<20140528203218.658CC1A2096@async.async.caltech.edu>	<5386B98C.7040904@gmail.com>
	<CAA4N+4aiaLGcbJ3GwhyAtbkOWELHQ=fvR4xMSFOMe2RD9y7foA@mail.gmail.com>
	<53898228.9010807@elego.de>
Message-ID: <5389E1BD.4030603@gmail.com>

G'day everyone

I downloaded cm3-bin-core-NT386-5.8.6-REL.tgz and ran cminstall.exe. I 
then changed directory to c:\cm3\examples\hello\src and tried to build 
the example, viz

    C:\cm3\examples\hello\src>cm3
    --- building in ..\NT386 ---

    new source -> compiling Hello.m3
      -> linking hello.exe
    "C:\cm3\bin/config\NT386.common", line 969: quake runtime error:
    link failed, see C:\cm3\examples\hello\NT386\hello.lst for more
    information


    --procedure--  -line-  -file---
    error              --  <builtin>
    m3_link           969  C:\cm3\bin/config\NT386.common
    program            --  <builtin>
    include_dir        27 C:\cm3\examples\hello\src\m3makefile
                         4 C:\cm3\examples\hello\NT386\m3make.args


    Fatal Error: procedure "m3_link" defined in "C:\cm3\bin\cm3.cfg" failed.


    C:\cm3\examples\hello\src>type ..\NT386\hello.lst
    Microsoft (R) Incremental Linker Version 10.00.40219.01
    Copyright (C) Microsoft Corporation.  All rights reserved.

    -out:hello.exe
    -subsystem:console
    -entry:mainCRTStartup
    -nodefaultlib
    -debug
    -incremental:no
    -opt:ref
    -delayload:wsock32.dll
    -delayload:advapi32.dll
    -delayload:gdi32.dll
    -delayload:netapi32.dll
    -delayload:user32.dll
    -delayload:comctl32.dll
    delayimp.lib
    _m3main.obj
    Hello.mo
    C:\cm3\pkg\libm3\NT386\m3.lib
    C:\cm3\pkg\m3core\NT386\m3core.lib
    winspool.lib
    comctl32.lib
    wsock32.lib
    comdlg32.lib
    netapi32.lib
    gdi32.lib
    user32.lib
    advapi32.lib
    kernel32.lib
    msvcrt.lib
    C:\cm3\bin\..\lib\hand.obj
    LINK : fatal error LNK1181: cannot open input file 'delayimp.lib'

delayimp.lib is nowhere to be found in the c:\cm3 tree. So I downloaded 
the CVS tree in the expectation that I'd find it in there, but It's NOT 
there.

Where do I go from here?

Kind regards,
Bruce M. Axtens


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/2039f6b6/attachment.html>

From bruce.axtens at gmail.com  Sat May 31 16:33:50 2014
From: bruce.axtens at gmail.com (Bruce M. Axtens)
Date: Sat, 31 May 2014 22:33:50 +0800
Subject: [M3devel] Starting out with CM3
In-Reply-To: <53893F74.1040608@gmail.com>
References: <53893F74.1040608@gmail.com>
Message-ID: <5389E84E.10407@gmail.com>

G'day everyone

I've slurped down the full CVS tree. How do I build for Windows 7 ... 
from scratch? Is there a readme/faq for this somewhere?

Kind regards,
Bruce.





From bruce.axtens at gmail.com  Sat May 31 16:34:47 2014
From: bruce.axtens at gmail.com (Bruce M. Axtens)
Date: Sat, 31 May 2014 22:34:47 +0800
Subject: [M3devel] Starting out with CM3
In-Reply-To: <53893F74.1040608@gmail.com>
References: <53893F74.1040608@gmail.com>
Message-ID: <5389E887.5050405@gmail.com>

Oh and while I'm at it, seeing as I have a recent MinGW here, how do I 
build for MinGW?

Bruce.



From jay.krell at cornell.edu  Sat May 31 18:47:34 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:47:34 +0000
Subject: [M3devel] Problem building on Win7
In-Reply-To: <5389E1BD.4030603@gmail.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>	<5384B209.3080504@marino.st>
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<20140528182503.087801A2095@async.async.caltech.edu>
	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
	<20140528203218.658CC1A2096@async.async.caltech.edu>
	<5386B98C.7040904@gmail.com>,
	<CAA4N+4aiaLGcbJ3GwhyAtbkOWELHQ=fvR4xMSFOMe2RD9y7foA@mail.gmail.com>,
	<53898228.9010807@elego.de>, <5389E1BD.4030603@gmail.com>
Message-ID: <COL130-W931C4DEDBF0FDA3E034326E6260@phx.gbl>

delayimp.lib comes with Visual C++. We could without it though.
i.e. remove it and all the:
-delayload:wsock32.dll
-delayload:advapi32.dll
-delayload:gdi32.dll
-delayload:netapi32.dll
-delayload:user32.dll
-delayload:comctl32.dll
 
will work, albeit with extra .dll loads.

- Jay
 
Date: Sat, 31 May 2014 22:05:49 +0800
From: bruce.axtens at gmail.com
To: m3devel at elegosoft.com
Subject: [M3devel] Problem building on Win7


  
    
  
  
    G'day everyone

    
      
         

          I downloaded cm3-bin-core-NT386-5.8.6-REL.tgz and ran
          cminstall.exe. I then changed directory to
          c:\cm3\examples\hello\src and tried to build the example, viz

          C:\cm3\examples\hello\src>cm3

                --- building in ..\NT386 ---

                

                new source -> compiling Hello.m3

                 -> linking hello.exe

                "C:\cm3\bin/config\NT386.common", line 969: quake
                runtime error: link failed, see
                C:\cm3\examples\hello\NT386\hello.lst for more
                information

                

                

                --procedure--  -line-  -file---

                error              --  <builtin>

                m3_link           969  C:\cm3\bin/config\NT386.common

                program            --  <builtin>

                include_dir        27 
                C:\cm3\examples\hello\src\m3makefile

                                    4 
                C:\cm3\examples\hello\NT386\m3make.args

                

                

                Fatal Error: procedure "m3_link" defined in
                "C:\cm3\bin\cm3.cfg" failed.

                

                

                C:\cm3\examples\hello\src>type ..\NT386\hello.lst

                Microsoft (R) Incremental Linker Version 10.00.40219.01

                Copyright (C) Microsoft Corporation.  All rights
                reserved.

                

                -out:hello.exe

                -subsystem:console

                -entry:mainCRTStartup

                -nodefaultlib

                -debug

                -incremental:no

                -opt:ref

                -delayload:wsock32.dll

                -delayload:advapi32.dll

                -delayload:gdi32.dll

                -delayload:netapi32.dll

                -delayload:user32.dll

                -delayload:comctl32.dll

                delayimp.lib

                _m3main.obj

                Hello.mo

                C:\cm3\pkg\libm3\NT386\m3.lib

                C:\cm3\pkg\m3core\NT386\m3core.lib

                winspool.lib

                comctl32.lib

                wsock32.lib

                comdlg32.lib

                netapi32.lib

                gdi32.lib

                user32.lib

                advapi32.lib

                kernel32.lib

                msvcrt.lib

                C:\cm3\bin\..\lib\hand.obj

                LINK : fatal error LNK1181: cannot open input file
                'delayimp.lib'

            

          
          delayimp.lib is nowhere to be found in the c:\cm3 tree. So I
          downloaded the CVS tree in the expectation that I'd find it in
          there, but It's NOT there. 

          

          Where do I go from here?

          

          Kind regards,

          Bruce M. Axtens

          

        
      
      

     		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/d8852449/attachment.html>

From jay.krell at cornell.edu  Sat May 31 18:53:14 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:53:14 +0000
Subject: [M3devel] Starting out with CM3
In-Reply-To: <5389E84E.10407@gmail.com>
References: <53893F74.1040608@gmail.com>,<5389E84E.10407@gmail.com>
Message-ID: <COL130-W2D53D27D3ED6A677231B9E6260@phx.gbl>

You have to start with a minimal working toolset: cm3, m3core, libm3, C compiler/linker.
And then scripts/python/upgrade.py && scripts/python/do-cm3-all.py.
Optionally you can cross-build to start -- but still need working cm3 on host, and C compiler/linker, preferably on target.
 
 - Jay

 
> Date: Sat, 31 May 2014 22:33:50 +0800
> From: bruce.axtens at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Starting out with CM3
> 
> G'day everyone
> 
> I've slurped down the full CVS tree. How do I build for Windows 7 ... 
> from scratch? Is there a readme/faq for this somewhere?
> 
> Kind regards,
> Bruce.
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/abc9934d/attachment.html>

From jay.krell at cornell.edu  Sat May 31 18:53:23 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:53:23 +0000
Subject: [M3devel] Starting out with CM3
In-Reply-To: <5389E84E.10407@gmail.com>
References: <53893F74.1040608@gmail.com>,<5389E84E.10407@gmail.com>
Message-ID: <COL130-W2E7FA119353D9CCFA0AD4E6260@phx.gbl>

You have to start with a minimal working toolset: cm3, m3core, libm3, C compiler/linker.
And then scripts/python/upgrade.py && scripts/python/do-cm3-all.py.
Optionally you can cross-build to start -- but still need working cm3 on host, and C compiler/linker, preferably on target.
 
 - Jay

 
> Date: Sat, 31 May 2014 22:33:50 +0800
> From: bruce.axtens at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Starting out with CM3
> 
> G'day everyone
> 
> I've slurped down the full CVS tree. How do I build for Windows 7 ... 
> from scratch? Is there a readme/faq for this somewhere?
> 
> Kind regards,
> Bruce.
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/b81e477c/attachment.html>

From jay.krell at cornell.edu  Sat May 31 18:53:25 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:53:25 +0000
Subject: [M3devel] Starting out with CM3
In-Reply-To: <5389E84E.10407@gmail.com>
References: <53893F74.1040608@gmail.com>,<5389E84E.10407@gmail.com>
Message-ID: <COL130-W2AEDFC48A2FB8E4FD5367E6260@phx.gbl>

You have to start with a minimal working toolset: cm3, m3core, libm3, C compiler/linker.
And then scripts/python/upgrade.py && scripts/python/do-cm3-all.py.
Optionally you can cross-build to start -- but still need working cm3 on host, and C compiler/linker, preferably on target.
 
 - Jay

 
> Date: Sat, 31 May 2014 22:33:50 +0800
> From: bruce.axtens at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Starting out with CM3
> 
> G'day everyone
> 
> I've slurped down the full CVS tree. How do I build for Windows 7 ... 
> from scratch? Is there a readme/faq for this somewhere?
> 
> Kind regards,
> Bruce.
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/a8619162/attachment.html>

From dragisha at m3w.org  Sat May 31 21:56:13 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 31 May 2014 21:56:13 +0200
Subject: [M3devel] Git synchronized to CVS@May30
Message-ID: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>

https://github.com/dragisha/cm3

Please let me have your usernames on github.

I am continuing now through Jenkins setup. I hope to have few platforms happily building from tomorrow on.

dd



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/781db7e3/attachment.sig>

From dragisha at m3w.org  Sat May 31 23:01:17 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 31 May 2014 23:01:17 +0200
Subject: [M3devel] Git synchronized to CVS@May30
In-Reply-To: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>
References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>
Message-ID: <F952131C-30FB-47CA-BEC4-9888B76E7ABA@m3w.org>

I have added Rodney and Anthony for now. And I am waiting for few other people to give me exact data. And everybody else to give me any data :)

What I need is short form show on github, to be sure it is you I am adding. Thanks in advance!

dd

On 31 May 2014, at 21:56, Dragi?a Duri? <dragisha at m3w.org> wrote:

> https://github.com/dragisha/cm3
> 
> Please let me have your usernames on github.
> 
> I am continuing now through Jenkins setup. I hope to have few platforms happily building from tomorrow on.
> 
> dd
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/90ad439d/attachment.sig>

From dragisha at m3w.org  Thu May  1 19:49:28 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 1 May 2014 19:49:28 +0200
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <535FA2B2.70108@gmail.com>
References: <535FA2B2.70108@gmail.com>
Message-ID: <A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>

It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.
--
Dragi?a Duri?
dragisha at m3w.org



On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:

> I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty? When I try to install it with Ubuntu Software Centre I get told the following:
> 
> Lintian check results for /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:
> Can't use an undefined value as an ARRAY reference at /usr/share/perl5/
> Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.
> 
> Is this a Perl issue or an installer issue?
> 
> -- Bruce
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140501/835298de/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140501/835298de/attachment-0001.sig>

From rcolebur at SCIRES.COM  Sat May 24 06:57:36 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 24 May 2014 04:57:36 +0000
Subject: [M3devel] compilation problems with assertions in RTCollector.m3
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF9269F8F6@ATLEX04-SRV.SCIRES.LOCAL>

I updated my sandbox to be current with the HEAD branch via CVS, then tried to rebuild everything.

I first built a minimal distribution on Windows XP.  Everything seemed to work fine.

Now, using my newly rebuilt cm3.exe, I decided to rebuild everything.  Unfortunately, now I'm running into problems even in the first stage.

Here are some examples of the errors I am getting.  These runtime errors happen compiling various packages.  (I've tried rebuilding several times.)

I show 3 separate incidents below and the last one has a partial stack trace.  In each case, there is an assertion failure in the RTCollector while running the compiler:

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 699
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x12f374   0x6ca19e  CleanBetween + 0x22 in ..\src\runtime\common\RTCollector.m3
0x12f3ac   0x6ca031  CopySome + 0xeb in ..\src\runtime\common\RTCollector.m3
0x12f3b8   0x6c9b02  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3
0x12f3c8   0x6c94d6  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3
0x12f40c   0x6c916a  CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3
0x12f44c   0x6dc586  AllocTraced + 0xd3 in ..\src\runtime\common\RTAllocator.m3
0x12f480   0x6dbbd8  GetTracedObj + 0x86 in ..\src\runtime\common\RTAllocator.m3
0x12f49c   0x6db70c  AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3
0x12f4d0   0x529913  Init_chars + 0x20b in ..\src\misc\CG.m3
0x12f4f8   0x4f948b  Init_chars + 0xb9 in ..\src\misc\M3String.m3
.........  .........  ... more frames ...

WARNING:  Encountered an error when processing package "m3-sys\m3front" for "-build".

Any help in solving this problem would be appreciated.

Thanks,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140524/2b9cb0f6/attachment-0001.html>

From wagner at elegosoft.com  Sun May 25 18:36:16 2014
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 25 May 2014 18:36:16 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
Message-ID: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>

On Sun, 25 May 2014 22:35:09 +0800
Bruce Axtens <bruce.axtens at gmail.com> wrote:

> Dear Sir
> 
> Should I assume that CM3 is alive, in palliative care or dead? The trac
> system is full of spam and the roadmap hasn't moved for 3 years.
> 
> I had a long and fruitful relationship with Modula-2 years ago and thought
> that perhaps I could restart things with CM3.

There is certainly some activity in M3 development recently, though
the community is rather small.
The trac system has never been much used by the community members;
and the WWW presentation and regression testing system has lacked
my support, as I couldn't spent any time on these topics for
almost 3 years.

You should check the m3devel mailing list for news though:
https://mail.elegosoft.com/pipermail/m3devel

There has been a lot of activity at the beginning of this year;
it has ceased again during recent weeks.

All CVS commits can be found here:
https://mail.elegosoft.com/pipermail/m3commit

A new release is long overdue; I'm afraid I cannot do the release
engineering this time.

There has been some effort on moving the CVS repositories to git;
I'm not sure what the status is there, too.

Any help wrt. documentation, presentation or software is greatly
appreciated ;-)

Regards,

Olaf Wagner
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


From mika at async.caltech.edu  Mon May 26 21:22:46 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 12:22:46 -0700
Subject: [M3devel] problems on FreeBSD 10.0-RELEASE
Message-ID: <20140526192247.0A2D71A209C@async.async.caltech.edu>

Hi m3devel,

The usual story.. new computer, new OS, trying to set up CM3.

I installed the binary snapshot 

cm3-bin-core-AMD64_FREEBSD-d5.9.0-x86_64-unknown-freebsd8.3-2013-10-15-17-59-51.tgz

cvs synced against current as of today

ran ./upgrade.sh and got various errors.  (See below.)  Versions...

root at pluto:/home/mika/cm3/cm3/scripts # uname -a
FreeBSD pluto 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

root at pluto:/home/mika/cm3/cm3/scripts # gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd10.0/4.7.3/lto-wrapper
Target: x86_64-portbld-freebsd10.0
Configured with: ./../gcc-4.7.3/configure --disable-bootstrap --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc47 --libexecdir=/usr/local/libexec/gcc47 --program-suffix=47 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc47/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc47 --build=x86_64-portbld-freebsd10.0
Thread model: posix
gcc version 4.7.3 (FreeBSD Ports Collection) 
root at pluto:/home/mika/cm3/cm3/scripts # 

Any ideas?  It looks like gcc is having trouble compiling gcc?

     Mika


build/gcov-iov '4.7.1' '' \
    > tmp-gcov-iov.h
/bin/sh ../../gcc-4.7/gcc/../move-if-change tmp-gcov-iov.h gcov-iov.h
echo timestamp > s-iov
gcc -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7/gcc -I../../gcc-4.7/gcc/. -I../../gcc-4.7/gcc/../include -I../../gcc-4.7/gcc/../libcpp/include -I/usr/local/include ../../gcc-4.7/gcc/attribs.c -o attribs.o
gcc -c   -g -O2 -DIN_GCC  -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7/gcc -I../../gcc-4.7/gcc/. -I../../gcc-4.7/gcc/../include -I../../gcc-4.7/gcc/../libcpp/include -I/usr/local/include ../../gcc-4.7/gcc/main.c -o main.o
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:46:
In file included from ../../gcc-4.7/gcc/tree.h:30:
../../gcc-4.7/gcc/statistics.h:48:46: error: reference to 'function' is ambiguous
extern void statistics_counter_event (struct function *, const char *, int);
                                             ^
../../gcc-4.7/gcc/statistics.h:41:8: note: candidate found by name lookup is 'function'
struct function;
       ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:46:
In file included from ../../gcc-4.7/gcc/tree.h:30:
../../gcc-4.7/gcc/statistics.h:49:48: error: reference to 'function' is ambiguous
extern void statistics_histogram_event (struct function *, const char *, int);
                                               ^
../../gcc-4.7/gcc/statistics.h:41:8: note: candidate found by name lookup is 'function'
struct function;
       ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
gcc -c   -g -O2 -DIN_GCC  -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7/gcc -I../../gcc-4.7/gcc/. -I../../gcc-4.7/gcc/../include -I../../gcc-4.7/gcc/../libcpp/include -I/usr/local/include ../../gcc-4.7/gcc/tree-browser.c -o tree-browser.o
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:46:
../../gcc-4.7/gcc/tree.h:3547:10: error: reference to 'function' is ambiguous
  struct function *f;
         ^
../../gcc-4.7/gcc/tree.h:2653:8: note: candidate found by name lookup is 'function'
struct function;
       ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:643:24: error: reference to 'function' is ambiguous
add_local_decl (struct function *fun, tree d)
                       ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:657:23: error: reference to 'function' is ambiguous
extern GTY(()) struct function *cfun;
                      ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:693:30: error: reference to 'function' is ambiguous
extern void set_cfun (struct function *new_cfun);
                             ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:694:31: error: reference to 'function' is ambiguous
extern void push_cfun (struct function *new_cfun);
                              ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:732:40: error: reference to 'function' is ambiguous
extern void free_after_parsing (struct function *);
                                       ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:733:44: error: reference to 'function' is ambiguous
extern void free_after_compilation (struct function *);
                                           ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:764:50: error: reference to 'function' is ambiguous
extern bool optimize_function_for_size_p (struct function *);
                                                 ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:765:51: error: reference to 'function' is ambiguous
extern bool optimize_function_for_speed_p (struct function *);
                                                  ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
../../gcc-4.7/gcc/basic-block.h:779:31: error: reference to 'function' is ambiguous
extern void init_flow (struct function *);
                              ^../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:59:
../../gcc-4.7/gcc/output.h:137:6: warning: 'format' attribute argument not supported: __asm_fprintf__ [-Wignored-attributes]
     ATTRIBUTE_ASM_FPRINTF(2, 3);
     ^
../../gcc-4.7/gcc/output.h:123:53: note: expanded from macro 'ATTRIBUTE_ASM_FPRINTF'
#define ATTRIBUTE_ASM_FPRINTF(m, n) __attribute__ ((__format__ (__asm_fprintf__, m, n))) ATTRIBUTE_NONNULL(m)
                                                    ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:63:
../../gcc-4.7/gcc/langhooks-def.h:40:38: error: reference to 'function' is ambiguous
extern void lhd_do_nothing_f (struct function *);
                                     ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:69:
In file included from ../../gcc-4.7/gcc/expr.h:28:
In file included from ../../gcc-4.7/gcc/rtl.h:2244:
./genrtl.h:385:3: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
  XWINT (rt, 1) = arg1;
  ^          ~
../../gcc-4.7/gcc/rtl.h:633:29: note: expanded from macro 'XWINT'
#define XWINT(RTX, N)               ((RTX)->u.hwint[N])
                                     ^
../../gcc-4.7/gcc/rtl.h:344:5: note: array 'hwint' declared here
    HOST_WIDE_INT hwint[1];
    ^
../../gcc-4.7/gcc/hwint.h:64:26: note: expanded from macro 'HOST_WIDE_INT'
#   define HOST_WIDE_INT long
                         ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:69:
In file included from ../../gcc-4.7/gcc/expr.h:28:
In file included from ../../gcc-4.7/gcc/rtl.h:2244:
./genrtl.h:386:3: warning: array index 2 is past the end of the array (which contains 1 element) [-Warray-bounds]
  XWINT (rt, 2) = arg2;
  ^          ~
../../gcc-4.7/gcc/rtl.h:633:29: note: expanded from macro 'XWINT'
#define XWINT(RTX, N)               ((RTX)->u.hwint[N])
                                     ^
../../gcc-4.7/gcc/rtl.h:344:5: note: array 'hwint' declared here
    HOST_WIDE_INT hwint[1];
    ^../../gcc-4.7/gcc/hwint.h:64:26: note: expanded from macro 'HOST_WIDE_INT'
#   define HOST_WIDE_INT long
                         ^
3 warnings and 13 errors generated.
gmake: *** [m3cg/parse.o] Error 1
gmake: *** Waiting for unfinished jobs....
/bin/sh ../../gcc-4.7/gcc/../move-if-change tmp-attrtab.c insn-attrtab.c
echo timestamp > s-attrtab
/bin/sh ../../gcc-4.7/gcc/../move-if-change tmp-automata.c insn-automata.c
echo timestamp > s-automata
"/usr/home/mika/cm3/cm3/m3-sys/m3cc/src/m3makefile", line 327: quake runtime error: exit 2: cd ../AMD64_FREEBSD && cd gcc && gmake  MAKE="gmake -j4  "  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: -j4  s-modes insn-config.h m3cg

--procedure--  -line-  -file---
exec               --  <builtin>
m3cc_Run          327  /usr/home/mika/cm3/cm3/m3-sys/m3cc/src/m3makefile
include_dir       577  /usr/home/mika/cm3/cm3/m3-sys/m3cc/src/m3makefile
                    6  /usr/home/mika/cm3/cm3/m3-sys/m3cc/AMD64_FREEBSD/m3make.args

Fatal Error: package build failed
 ==> /home/mika/cm3/cm3/m3-sys/m3cc done

Critical Mass Modula-3 version d5.9.0
  last updated: 2010-07-21
  compiled: 2014-05-26 19:11:28
  configuration: /usr/local/cm3/bin/cm3.cfg
  host: AMD64_FREEBSD
quake runtime error: "/usr/local/cm3/bin/cm3.cfg", line 2: quake runtime error: undefined variable: SL

--procedure--  -line-  -file---
                    2  /usr/local/cm3/bin/cm3.cfg
  target: 

./upgrade.sh: /home/mika/cm3/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg: not found
root at pluto:/home/mika/cm3/cm3/scripts # 



From adacore at marino.st  Mon May 26 21:37:55 2014
From: adacore at marino.st (John Marino)
Date: Mon, 26 May 2014 21:37:55 +0200
Subject: [M3devel] problems on FreeBSD 10.0-RELEASE
In-Reply-To: <20140526192247.0A2D71A209C@async.async.caltech.edu>
References: <20140526192247.0A2D71A209C@async.async.caltech.edu>
Message-ID: <53839813.3020406@marino.st>

On 5/26/2014 21:22, mika at async.caltech.edu wrote:
> Hi m3devel,
> 
> The usual story.. new computer, new OS, trying to set up CM3.
> 
> I installed the binary snapshot 
> 
> cm3-bin-core-AMD64_FREEBSD-d5.9.0-x86_64-unknown-freebsd8.3-2013-10-15-17-59-51.tgz
> 
> cvs synced against current as of today
> 

Did you know that modula3 is can be built from ports or installed as a
prebuilt binary on FreeBSD?

http://www.freshports.org/lang/modula3


If you don't need the binary snapshot specifically, maybe the ports M3
is good enough.

John


From mika at async.caltech.edu  Tue May 27 00:22:27 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 15:22:27 -0700
Subject: [M3devel] freebsd 10
Message-ID: <20140526222227.A66181A209C@async.async.caltech.edu>


Thanks so much for the reminder that Modula-3 is in FreeBSD ports.
That's great!  I've used it on FreeBSD since 1999 (was that FreeBSD
2?) and this is definitely the easiest install ever.

But the default configuration uses pthreads.  Pthreads support in Modula-3
is broken.

root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # AMD64_FREEBSD/threadtest 
Writing file...done
Creating read threads...done
Creating fork threads...done
Creating alloc threads...done
Creating lock threads...done
running...printing oldest/median age/newest
.

***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
***

Abort (core dumped)
root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # 

I wonder what the best way of reconfiguring this installation to use
user threads (which always work right, in my experience) is...

    Mika


From adacore at marino.st  Tue May 27 00:35:46 2014
From: adacore at marino.st (John Marino)
Date: Tue, 27 May 2014 00:35:46 +0200
Subject: [M3devel] freebsd 10
In-Reply-To: <20140526222227.A66181A209C@async.async.caltech.edu>
References: <20140526222227.A66181A209C@async.async.caltech.edu>
Message-ID: <5383C1C2.9040002@marino.st>

On 5/27/2014 00:22, mika at async.caltech.edu wrote:
> Thanks so much for the reminder that Modula-3 is in FreeBSD ports.
> That's great!  I've used it on FreeBSD since 1999 (was that FreeBSD
> 2?) and this is definitely the easiest install ever.

Actually it was gone for many years, it only came back a few months ago
after a long hiatus.


> But the default configuration uses pthreads.  Pthreads support in Modula-3
> is broken.

Really?  I didn't know that.  That's not good.

> 
> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # AMD64_FREEBSD/threadtest 
> Writing file...done
> Creating read threads...done
> Creating fork threads...done
> Creating alloc threads...done
> Creating lock threads...done
> running...printing oldest/median age/newest
> .
> 
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
> ***
> 
> Abort (core dumped)
> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # 
> 
> I wonder what the best way of reconfiguring this installation to use
> user threads (which always work right, in my experience) is...
> 

Probably adding something to the build environment but I don't know
what.  How does one normally build "user threads" over posix threads?


John




From mika at async.caltech.edu  Tue May 27 01:40:21 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 16:40:21 -0700
Subject: [M3devel] freebsd 10
In-Reply-To: <5383C1C2.9040002@marino.st>
References: <20140526222227.A66181A209C@async.async.caltech.edu>
	<5383C1C2.9040002@marino.st>
Message-ID: <20140526234021.98E721A209C@async.async.caltech.edu>

John Marino writes:
>On 5/27/2014 00:22, mika at async.caltech.edu wrote:
>> Thanks so much for the reminder that Modula-3 is in FreeBSD ports.
>> That's great!  I've used it on FreeBSD since 1999 (was that FreeBSD
>> 2?) and this is definitely the easiest install ever.
>
>Actually it was gone for many years, it only came back a few months ago
>after a long hiatus.

You mean from FreeBSD ports, specifically, right?  I've always been able
to run up-to-date Modula-3 on FreeBSD but it's been a bit of a hassle
installing things (from DECSRC, Polytechnique de Montreal, or elego).
Having it in ports definitely makes things much much easier.

>
>
>> But the default configuration uses pthreads.  Pthreads support in Modula-3
>> is broken.
>
>Really?  I didn't know that.  That's not good.
>
>> 
>> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # AMD64_FREEBSD/threadtest 
>> Writing file...done
>> Creating read threads...done
>> Creating fork threads...done
>> Creating alloc threads...done
>> Creating lock threads...done
>> running...printing oldest/median age/newest
>> .
>> 
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>> ***
>> 
>> Abort (core dumped)
>> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # 
>> 
>> I wonder what the best way of reconfiguring this installation to use
>> user threads (which always work right, in my experience) is...
>> 
>
>Probably adding something to the build environment but I don't know
>what.  How does one normally build "user threads" over posix threads?

Peter's following email suggests we "just" need an upgrade.

Otherwise the procedure is, if I remember right, to change a flag in
m3core/threads, rebuild m3core, then rebuild the compiler, then rebuild
everything else.

    Mika

>
>
>John
>


From mika at async.caltech.edu  Tue May 27 01:49:16 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 16:49:16 -0700
Subject: [M3devel] freebsd 10
In-Reply-To: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
References: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
Message-ID: <20140526234916.864741A209C@async.async.caltech.edu>


Peter, have you/someone run the thread tester exhaustively?

I did this:

#!/bin/csh

while ( 1 ) 
        limit cputime 5
        rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
end

With what's in FreeBSD's ports I get a variety of failures:


1.
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
***

2.
running...printing oldest/median age/newest
.Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.

3. (most common)
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
***

4.
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
***

5. (letting it run a bit longer)
!!! lock Thread 23 appears starved or deadlocked !!!

This is all running in a single-cpu instance (M3.medium) of EC2...  usually things get worse with more processors.

FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
    root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
XEN: Hypervisor version 4.2 detected.
CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e  Stepping = 4
  Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  Standard Extended Features=0x200<ENHMOVSB>
real memory  = 4026531840 (3840 MB)
avail memory = 3872776192 (3693 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <Xen HVM>




>>>>>

Hi

I think tony put a fix into the collector that fixes that problem. The scheduler with pthreads is more agressive and under high load the mutator could have a newly allocated page collected before the object was initalised. would be good if you check it . There was a report of an assert failure a few days ago in the region of code affected, if we could find out which assert failed I could take a look. 
The only other problem is the odd failure in forking. Seems to occur in the child process in initstackbase which initiates a collection which then finds a weak ref to a mutex which is in a thread that does not exist in the child. Not sure what to do about that.
The pthreads seems pretty stable at least on linux. 

Peter 



From dragisha at m3w.org  Tue May 27 17:34:15 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 27 May 2014 17:34:15 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
Message-ID: <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>

You can count on me for release engineering, Git migration? Maybe CI, if I have resources. Problem is - feedback is poor from core developers wrt Git migration. I am ready for long time now.

On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:

> On Sun, 25 May 2014 22:35:09 +0800
> Bruce Axtens <bruce.axtens at gmail.com> wrote:
> 
>> Dear Sir
>> 
>> Should I assume that CM3 is alive, in palliative care or dead? The trac
>> system is full of spam and the roadmap hasn't moved for 3 years.
>> 
>> I had a long and fruitful relationship with Modula-2 years ago and thought
>> that perhaps I could restart things with CM3.
> 
> There is certainly some activity in M3 development recently, though
> the community is rather small.
> The trac system has never been much used by the community members;
> and the WWW presentation and regression testing system has lacked
> my support, as I couldn't spent any time on these topics for
> almost 3 years.
> 
> You should check the m3devel mailing list for news though:
> https://mail.elegosoft.com/pipermail/m3devel
> 
> There has been a lot of activity at the beginning of this year;
> it has ceased again during recent weeks.
> 
> All CVS commits can be found here:
> https://mail.elegosoft.com/pipermail/m3commit
> 
> A new release is long overdue; I'm afraid I cannot do the release
> engineering this time.
> 
> There has been some effort on moving the CVS repositories to git;
> I'm not sure what the status is there, too.
> 
> Any help wrt. documentation, presentation or software is greatly
> appreciated ;-)
> 
> Regards,
> 
> Olaf Wagner
> -- 
> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140527/6354fe6f/attachment-0001.sig>

From adacore at marino.st  Tue May 27 17:40:57 2014
From: adacore at marino.st (John Marino)
Date: Tue, 27 May 2014 17:40:57 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
Message-ID: <5384B209.3080504@marino.st>

On 5/27/2014 17:34, Dragi?a Duri? wrote:
> You can count on me for release engineering, Git migration? Maybe CI,
> if I have resources. Problem is - feedback is poor from core
> developers wrt Git migration. I am ready for long time now.


This might be a good time to remind that I've been waiting for a release
that feature C-backend support for both FreeBSD and DragonFly (new).
The version in FreeBSD ports is 4 years old, but there's not been a
release since then.  The last time I was active on the list we discussed
the needs of FreeBSD and for porting M3 to DragonFly and something was
supposed to happen code-wise (and then release-wise) but I don't think
anything did in the end.

I was extremely busy with other projects but was planning on pinging on
this topic soon anyway.

John


> 
> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
> 
>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
>> <bruce.axtens at gmail.com> wrote:
>> 
>>> Dear Sir
>>> 
>>> Should I assume that CM3 is alive, in palliative care or dead?
>>> The trac system is full of spam and the roadmap hasn't moved for
>>> 3 years.
>>> 
>>> I had a long and fruitful relationship with Modula-2 years ago
>>> and thought that perhaps I could restart things with CM3.
>> 
>> There is certainly some activity in M3 development recently,
>> though the community is rather small. The trac system has never
>> been much used by the community members; and the WWW presentation
>> and regression testing system has lacked my support, as I couldn't
>> spent any time on these topics for almost 3 years.
>> 
>> You should check the m3devel mailing list for news though: 
>> https://mail.elegosoft.com/pipermail/m3devel
>> 
>> There has been a lot of activity at the beginning of this year; it
>> has ceased again during recent weeks.
>> 
>> All CVS commits can be found here: 
>> https://mail.elegosoft.com/pipermail/m3commit
>> 
>> A new release is long overdue; I'm afraid I cannot do the release 
>> engineering this time.
>> 
>> There has been some effort on moving the CVS repositories to git; 
>> I'm not sure what the status is there, too.
>> 
>> Any help wrt. documentation, presentation or software is greatly 
>> appreciated ;-)
>> 
>> Regards,
>> 
>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
>> | USt-IdNr: DE163214194
> 


From hosking at cs.purdue.edu  Tue May 27 17:56:49 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2014 11:56:49 -0400
Subject: [M3devel] compilation problems with assertions in RTCollector.m3
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF9269F8F6@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF9269F8F6@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <B36B7B19-18BA-4B8A-9BA2-245188D6CDF8@cs.purdue.edu>

Just committed a (hopeful) fix.  Please give it a try.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





On May 24, 2014, at 12:57 AM, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:

> I updated my sandbox to be current with the HEAD branch via CVS, then tried to rebuild everything.
>  
> I first built a minimal distribution on Windows XP.  Everything seemed to work fine.
>  
> Now, using my newly rebuilt cm3.exe, I decided to rebuild everything.  Unfortunately, now I?m running into problems even in the first stage.
>  
> Here are some examples of the errors I am getting.  These runtime errors happen compiling various packages.  (I?ve tried rebuilding several times.)
>  
> I show 3 separate incidents below and the last one has a partial stack trace.  In each case, there is an assertion failure in the RTCollector while running the compiler:
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\runtime\common\RTCollector.m3", line 1092
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\runtime\common\RTCollector.m3", line 699
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\runtime\common\RTCollector.m3", line 1092
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x12f374   0x6ca19e  CleanBetween + 0x22 in ..\src\runtime\common\RTCollector.m3
> 0x12f3ac   0x6ca031  CopySome + 0xeb in ..\src\runtime\common\RTCollector.m3
> 0x12f3b8   0x6c9b02  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3
> 0x12f3c8   0x6c94d6  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3
> 0x12f40c   0x6c916a  CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3
> 0x12f44c   0x6dc586  AllocTraced + 0xd3 in ..\src\runtime\common\RTAllocator.m3
> 0x12f480   0x6dbbd8  GetTracedObj + 0x86 in ..\src\runtime\common\RTAllocator.m3
> 0x12f49c   0x6db70c  AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3
> 0x12f4d0   0x529913  Init_chars + 0x20b in ..\src\misc\CG.m3
> 0x12f4f8   0x4f948b  Init_chars + 0xb9 in ..\src\misc\M3String.m3
> .........  .........  ... more frames ...
>  
> WARNING:  Encountered an error when processing package "m3-sys\m3front" for "-build".
>  
> Any help in solving this problem would be appreciated.
>  
> Thanks,
> Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140527/8b621349/attachment-0001.html>

From mika at async.caltech.edu  Tue May 27 18:07:23 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Tue, 27 May 2014 09:07:23 -0700
Subject: [M3devel] freebsd 10
In-Reply-To: <CAEy6uxpCcLmoMf-C6caZUFNDmGWdqyyL6xMNchhnWkYeRnDGCA@mail.gmail.com>
References: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
	<20140526234916.864741A209C@async.async.caltech.edu>
	<CAEy6uxpCcLmoMf-C6caZUFNDmGWdqyyL6xMNchhnWkYeRnDGCA@mail.gmail.com>
Message-ID: <20140527160723.1296A1A2096@async.async.caltech.edu>


Peter, there's nothing here that constitutes a bug in the thread tester
itself, right?  These are all errors in the runtime (garbage collector,
threading system, Rd/Wr possibly)?

    Mika

Peter McKinna writes:
>--089e0122f628a8285004fa56cf42
>Content-Type: text/plain; charset=UTF-8
>
>Yeah I did a fair bit of testing that program it was annoying me. If you
>run it as threadtest -n 6 -tests alloc  you are just testing allocations
>and it should not crash . However if you put a diagnostic check of the
>retuned array in that test every now and again every element will be non
>zero and the same number corresponding to gray flag of the object header in
>the collector. ( this is from memory havent looked atvthe code for a while
>)  if you have -tests read, alloc  then it will probably crash since the
>read test allocates obects which are dereferenced either in FileRd or in
>the collector in move. If you examine the obect in gdb after the crash all
>fields of the object have the same value as in the alloc test I think its
>2^22 . Your crashes 1 and 4 are the same . Your 2nd example only occurs if
>you have the fork test in the set of tests. It actually crashes the child
>process via an abort after printing that message although that is not
>apparent . You might argue that the error can be ignored since the child
>usually does an exec straight after fork.
>
>Peter
>On 27/05/2014 9:49 AM, <mika at async.caltech.edu> wrote:
>
>>
>> Peter, have you/someone run the thread tester exhaustively?
>>
>> I did this:
>>
>> #!/bin/csh
>>
>> while ( 1 )
>>         limit cputime 5
>>         rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
>> end
>>
>> With what's in FreeBSD's ports I get a variety of failures:
>>
>>
>> 1.
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>> ***
>>
>> 2.
>> running...printing oldest/median age/newest
>> .Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete,
>> file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>>
>> 3. (most common)
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>> ***
>>
>> 4.
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>> ***
>>
>> 5. (letting it run a bit longer)
>> !!! lock Thread 23 appears starved or deadlocked !!!
>>
>> This is all running in a single-cpu instance (M3.medium) of EC2...
>>  usually things get worse with more processors.
>>
>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>>     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>> XEN: Hypervisor version 4.2 detected.
>> CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
>>   Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e
>>  Stepping = 4
>>
>> Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>>
>> Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,H
>V>
>>   AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
>>   AMD Features2=0x1<LAHF>
>>   Standard Extended Features=0x200<ENHMOVSB>
>> real memory  = 4026531840 (3840 MB)
>> avail memory = 3872776192 (3693 MB)
>> Event timer "LAPIC" quality 400
>> ACPI APIC Table: <Xen HVM>
>>
>>
>>
>>
>> >>>>>
>>
>> Hi
>>
>> I think tony put a fix into the collector that fixes that problem. The
>> scheduler with pthreads is more agressive and under high load the mutator
>> could have a newly allocated page collected before the object was
>> initalised. would be good if you check it . There was a report of an assert
>> failure a few days ago in the region of code affected, if we could find out
>> which assert failed I could take a look.
>> The only other problem is the odd failure in forking. Seems to occur in
>> the child process in initstackbase which initiates a collection which then
>> finds a weak ref to a mutex which is in a thread that does not exist in the
>> child. Not sure what to do about that.
>> The pthreads seems pretty stable at least on linux.
>>
>> Peter
>>
>>
>
>--089e0122f628a8285004fa56cf42
>Content-Type: text/html; charset=UTF-8
>Content-Transfer-Encoding: quoted-printable
>
><p dir=3D"ltr">Yeah I did a fair bit of testing that program it was annoyin=
>g me. If you run it as threadtest -n 6 -tests alloc=C2=A0 you are just test=
>ing allocations and it should not crash . However if you put a diagnostic c=
>heck of the retuned array in that test every now and again every element wi=
>ll be non zero and the same number corresponding to gray flag of the object=
> header in the collector. ( this is from memory havent looked atvthe code f=
>or a while )=C2=A0 if you have -tests read, alloc=C2=A0 then it will probab=
>ly crash since the read test allocates obects which are dereferenced either=
> in FileRd or in the collector in move. If you examine the obect in gdb aft=
>er the crash all fields of the object have the same value as in the alloc t=
>est I think its 2^22 . Your crashes 1 and 4 are the same . Your 2nd example=
> only occurs if you have the fork test in the set of tests. It actually cra=
>shes the child process via an abort after printing that message although th=
>at is not apparent . You might argue that the error can be ignored since th=
>e child usually does an exec straight after fork.</p>
>
><p dir=3D"ltr">Peter</p>
><div class=3D"gmail_quote">On 27/05/2014 9:49 AM,  &lt;<a href=3D"mailto:mi=
>ka at async.caltech.edu">mika at async.caltech.edu</a>&gt; wrote:<br type=3D"attr=
>ibution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
>r-left:1px #ccc solid;padding-left:1ex">
><br>
>Peter, have you/someone run the thread tester exhaustively?<br>
><br>
>I did this:<br>
><br>
>#!/bin/csh<br>
><br>
>while ( 1 )<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr=
>eadtest<br>
>end<br>
><br>
>With what&#39;s in FreeBSD&#39;s ports I get a variety of failures:<br>
><br>
><br>
>1.<br>
>***<br>
>*** runtime error:<br>
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>IL<br>
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>***<br>
><br>
>2.<br>
>running...printing oldest/median age/newest<br>
>.Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele=
>te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.<br>
><br>
>3. (most common)<br>
>***<br>
>*** runtime error:<br>
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>IL<br>
>*** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R=
>TCollector.m3<br>
>***<br>
><br>
>4.<br>
>***<br>
>*** runtime error:<br>
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>IL<br>
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>***<br>
><br>
>5. (letting it run a bit longer)<br>
>!!! lock Thread 23 appears starved or deadlocked !!!<br>
><br>
>This is all running in a single-cpu instance (M3.medium) of EC2... =C2=A0us=
>ually things get worse with more processors.<br>
><br>
>FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014<br>
>=C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER=
>IC amd64<br>
>FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610<br>
>XEN: Hypervisor version 4.2 detected.<br>
>CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)<b=
>r>
>=C2=A0 Origin =3D &quot;GenuineIntel&quot; =C2=A0Id =3D 0x306e4 =C2=A0Famil=
>y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4<br>
>=C2=A0 Features=3D0x1783fbff&lt;FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP=
>,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT&gt;<br>
>=C2=A0 Features2=3D0xffba2203&lt;SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4=
>.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV&gt;<br>
>=C2=A0 AMD Features=3D0x28100800&lt;SYSCALL,NX,RDTSCP,LM&gt;<br>
>=C2=A0 AMD Features2=3D0x1&lt;LAHF&gt;<br>
>=C2=A0 Standard Extended Features=3D0x200&lt;ENHMOVSB&gt;<br>
>real memory =C2=A0=3D 4026531840 (3840 MB)<br>
>avail memory =3D 3872776192 (3693 MB)<br>
>Event timer &quot;LAPIC&quot; quality 400<br>
>ACPI APIC Table: &lt;Xen HVM&gt;<br>
><br>
><br>
><br>
><br>
>&gt;&gt;&gt;&gt;&gt;<br>
><br>
>Hi<br>
><br>
>I think tony put a fix into the collector that fixes that problem. The sche=
>duler with pthreads is more agressive and under high load the mutator could=
> have a newly allocated page collected before the object was initalised. wo=
>uld be good if you check it . There was a report of an assert failure a few=
> days ago in the region of code affected, if we could find out which assert=
> failed I could take a look.<br>
>
>The only other problem is the odd failure in forking. Seems to occur in the=
> child process in initstackbase which initiates a collection which then fin=
>ds a weak ref to a mutex which is in a thread that does not exist in the ch=
>ild. Not sure what to do about that.<br>
>
>The pthreads seems pretty stable at least on linux.<br>
><br>
>Peter<br>
><br>
></blockquote></div>
>
>--089e0122f628a8285004fa56cf42--


From hosking at cs.purdue.edu  Tue May 27 18:24:50 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2014 12:24:50 -0400
Subject: [M3devel] freebsd 10
In-Reply-To: <20140527160723.1296A1A2096@async.async.caltech.edu>
References: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
	<20140526234916.864741A209C@async.async.caltech.edu>
	<CAEy6uxpCcLmoMf-C6caZUFNDmGWdqyyL6xMNchhnWkYeRnDGCA@mail.gmail.com>
	<20140527160723.1296A1A2096@async.async.caltech.edu>
Message-ID: <81669A74-4D31-442A-A8AE-7B14BF8E1AC2@cs.purdue.edu>

I would love to get a read on whether Peter?s suggested fix (which I put in a few weeks ago and just revised slightly) has narrowed the set of problems the thread test program illuminates.  Re fork, I?d like to understand that problem a little better to see if we can find a fix.

On May 27, 2014, at 12:07 PM, mika at async.caltech.edu wrote:

> 
> Peter, there's nothing here that constitutes a bug in the thread tester
> itself, right?  These are all errors in the runtime (garbage collector,
> threading system, Rd/Wr possibly)?
> 
>    Mika
> 
> Peter McKinna writes:
>> --089e0122f628a8285004fa56cf42
>> Content-Type: text/plain; charset=UTF-8
>> 
>> Yeah I did a fair bit of testing that program it was annoying me. If you
>> run it as threadtest -n 6 -tests alloc  you are just testing allocations
>> and it should not crash . However if you put a diagnostic check of the
>> retuned array in that test every now and again every element will be non
>> zero and the same number corresponding to gray flag of the object header in
>> the collector. ( this is from memory havent looked atvthe code for a while
>> )  if you have -tests read, alloc  then it will probably crash since the
>> read test allocates obects which are dereferenced either in FileRd or in
>> the collector in move. If you examine the obect in gdb after the crash all
>> fields of the object have the same value as in the alloc test I think its
>> 2^22 . Your crashes 1 and 4 are the same . Your 2nd example only occurs if
>> you have the fork test in the set of tests. It actually crashes the child
>> process via an abort after printing that message although that is not
>> apparent . You might argue that the error can be ignored since the child
>> usually does an exec straight after fork.
>> 
>> Peter
>> On 27/05/2014 9:49 AM, <mika at async.caltech.edu> wrote:
>> 
>>> 
>>> Peter, have you/someone run the thread tester exhaustively?
>>> 
>>> I did this:
>>> 
>>> #!/bin/csh
>>> 
>>> while ( 1 )
>>>        limit cputime 5
>>>        rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
>>> end
>>> 
>>> With what's in FreeBSD's ports I get a variety of failures:
>>> 
>>> 
>>> 1.
>>> ***
>>> *** runtime error:
>>> ***    Segmentation violation - possible attempt to dereference NIL
>>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>>> ***
>>> 
>>> 2.
>>> running...printing oldest/median age/newest
>>> .Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete,
>>> file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>>> 
>>> 3. (most common)
>>> ***
>>> *** runtime error:
>>> ***    Segmentation violation - possible attempt to dereference NIL
>>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>>> ***
>>> 
>>> 4.
>>> ***
>>> *** runtime error:
>>> ***    Segmentation violation - possible attempt to dereference NIL
>>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>>> ***
>>> 
>>> 5. (letting it run a bit longer)
>>> !!! lock Thread 23 appears starved or deadlocked !!!
>>> 
>>> This is all running in a single-cpu instance (M3.medium) of EC2...
>>> usually things get worse with more processors.
>>> 
>>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>>>    root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>>> XEN: Hypervisor version 4.2 detected.
>>> CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
>>>  Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e
>>> Stepping = 4
>>> 
>>> Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>>> 
>>> Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,H
>> V>
>>>  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
>>>  AMD Features2=0x1<LAHF>
>>>  Standard Extended Features=0x200<ENHMOVSB>
>>> real memory  = 4026531840 (3840 MB)
>>> avail memory = 3872776192 (3693 MB)
>>> Event timer "LAPIC" quality 400
>>> ACPI APIC Table: <Xen HVM>
>>> 
>>> 
>>> 
>>> 
>>>>>>>> 
>>> 
>>> Hi
>>> 
>>> I think tony put a fix into the collector that fixes that problem. The
>>> scheduler with pthreads is more agressive and under high load the mutator
>>> could have a newly allocated page collected before the object was
>>> initalised. would be good if you check it . There was a report of an assert
>>> failure a few days ago in the region of code affected, if we could find out
>>> which assert failed I could take a look.
>>> The only other problem is the odd failure in forking. Seems to occur in
>>> the child process in initstackbase which initiates a collection which then
>>> finds a weak ref to a mutex which is in a thread that does not exist in the
>>> child. Not sure what to do about that.
>>> The pthreads seems pretty stable at least on linux.
>>> 
>>> Peter
>>> 
>>> 
>> 
>> --089e0122f628a8285004fa56cf42
>> Content-Type: text/html; charset=UTF-8
>> Content-Transfer-Encoding: quoted-printable
>> 
>> <p dir=3D"ltr">Yeah I did a fair bit of testing that program it was annoyin=
>> g me. If you run it as threadtest -n 6 -tests alloc=C2=A0 you are just test=
>> ing allocations and it should not crash . However if you put a diagnostic c=
>> heck of the retuned array in that test every now and again every element wi=
>> ll be non zero and the same number corresponding to gray flag of the object=
>> header in the collector. ( this is from memory havent looked atvthe code f=
>> or a while )=C2=A0 if you have -tests read, alloc=C2=A0 then it will probab=
>> ly crash since the read test allocates obects which are dereferenced either=
>> in FileRd or in the collector in move. If you examine the obect in gdb aft=
>> er the crash all fields of the object have the same value as in the alloc t=
>> est I think its 2^22 . Your crashes 1 and 4 are the same . Your 2nd example=
>> only occurs if you have the fork test in the set of tests. It actually cra=
>> shes the child process via an abort after printing that message although th=
>> at is not apparent . You might argue that the error can be ignored since th=
>> e child usually does an exec straight after fork.</p>
>> 
>> <p dir=3D"ltr">Peter</p>
>> <div class=3D"gmail_quote">On 27/05/2014 9:49 AM,  &lt;<a href=3D"mailto:mi=
>> ka at async.caltech.edu">mika at async.caltech.edu</a>&gt; wrote:<br type=3D"attr=
>> ibution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
>> r-left:1px #ccc solid;padding-left:1ex">
>> <br>
>> Peter, have you/someone run the thread tester exhaustively?<br>
>> <br>
>> I did this:<br>
>> <br>
>> #!/bin/csh<br>
>> <br>
>> while ( 1 )<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr=
>> eadtest<br>
>> end<br>
>> <br>
>> With what&#39;s in FreeBSD&#39;s ports I get a variety of failures:<br>
>> <br>
>> <br>
>> 1.<br>
>> ***<br>
>> *** runtime error:<br>
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>> IL<br>
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>> ***<br>
>> <br>
>> 2.<br>
>> running...printing oldest/median age/newest<br>
>> .Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele=
>> te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.<br>
>> <br>
>> 3. (most common)<br>
>> ***<br>
>> *** runtime error:<br>
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>> IL<br>
>> *** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R=
>> TCollector.m3<br>
>> ***<br>
>> <br>
>> 4.<br>
>> ***<br>
>> *** runtime error:<br>
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>> IL<br>
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>> ***<br>
>> <br>
>> 5. (letting it run a bit longer)<br>
>> !!! lock Thread 23 appears starved or deadlocked !!!<br>
>> <br>
>> This is all running in a single-cpu instance (M3.medium) of EC2... =C2=A0us=
>> ually things get worse with more processors.<br>
>> <br>
>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014<br>
>> =C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER=
>> IC amd64<br>
>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610<br>
>> XEN: Hypervisor version 4.2 detected.<br>
>> CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)<b=
>> r>
>> =C2=A0 Origin =3D &quot;GenuineIntel&quot; =C2=A0Id =3D 0x306e4 =C2=A0Famil=
>> y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4<br>
>> =C2=A0 Features=3D0x1783fbff&lt;FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP=
>> ,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT&gt;<br>
>> =C2=A0 Features2=3D0xffba2203&lt;SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4=
>> .2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV&gt;<br>
>> =C2=A0 AMD Features=3D0x28100800&lt;SYSCALL,NX,RDTSCP,LM&gt;<br>
>> =C2=A0 AMD Features2=3D0x1&lt;LAHF&gt;<br>
>> =C2=A0 Standard Extended Features=3D0x200&lt;ENHMOVSB&gt;<br>
>> real memory =C2=A0=3D 4026531840 (3840 MB)<br>
>> avail memory =3D 3872776192 (3693 MB)<br>
>> Event timer &quot;LAPIC&quot; quality 400<br>
>> ACPI APIC Table: &lt;Xen HVM&gt;<br>
>> <br>
>> <br>
>> <br>
>> <br>
>> &gt;&gt;&gt;&gt;&gt;<br>
>> <br>
>> Hi<br>
>> <br>
>> I think tony put a fix into the collector that fixes that problem. The sche=
>> duler with pthreads is more agressive and under high load the mutator could=
>> have a newly allocated page collected before the object was initalised. wo=
>> uld be good if you check it . There was a report of an assert failure a few=
>> days ago in the region of code affected, if we could find out which assert=
>> failed I could take a look.<br>
>> 
>> The only other problem is the odd failure in forking. Seems to occur in the=
>> child process in initstackbase which initiates a collection which then fin=
>> ds a weak ref to a mutex which is in a thread that does not exist in the ch=
>> ild. Not sure what to do about that.<br>
>> 
>> The pthreads seems pretty stable at least on linux.<br>
>> <br>
>> Peter<br>
>> <br>
>> </blockquote></div>
>> 
>> --089e0122f628a8285004fa56cf42--



Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484







From hosking at cs.purdue.edu  Tue May 27 18:49:12 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2014 12:49:12 -0400
Subject: [M3devel] Status of CM3
In-Reply-To: <5384B209.3080504@marino.st>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
	<5384B209.3080504@marino.st>
Message-ID: <A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>

Jay might comment on C backend status for those platforms.

On May 27, 2014, at 11:40 AM, John Marino <adacore at marino.st> wrote:

> On 5/27/2014 17:34, Dragi?a Duri? wrote:
>> You can count on me for release engineering, Git migration? Maybe CI,
>> if I have resources. Problem is - feedback is poor from core
>> developers wrt Git migration. I am ready for long time now.
> 
> 
> This might be a good time to remind that I've been waiting for a release
> that feature C-backend support for both FreeBSD and DragonFly (new).
> The version in FreeBSD ports is 4 years old, but there's not been a
> release since then.  The last time I was active on the list we discussed
> the needs of FreeBSD and for porting M3 to DragonFly and something was
> supposed to happen code-wise (and then release-wise) but I don't think
> anything did in the end.
> 
> I was extremely busy with other projects but was planning on pinging on
> this topic soon anyway.
> 
> John
> 
> 
>> 
>> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
>> 
>>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
>>> <bruce.axtens at gmail.com> wrote:
>>> 
>>>> Dear Sir
>>>> 
>>>> Should I assume that CM3 is alive, in palliative care or dead?
>>>> The trac system is full of spam and the roadmap hasn't moved for
>>>> 3 years.
>>>> 
>>>> I had a long and fruitful relationship with Modula-2 years ago
>>>> and thought that perhaps I could restart things with CM3.
>>> 
>>> There is certainly some activity in M3 development recently,
>>> though the community is rather small. The trac system has never
>>> been much used by the community members; and the WWW presentation
>>> and regression testing system has lacked my support, as I couldn't
>>> spent any time on these topics for almost 3 years.
>>> 
>>> You should check the m3devel mailing list for news though: 
>>> https://mail.elegosoft.com/pipermail/m3devel
>>> 
>>> There has been a lot of activity at the beginning of this year; it
>>> has ceased again during recent weeks.
>>> 
>>> All CVS commits can be found here: 
>>> https://mail.elegosoft.com/pipermail/m3commit
>>> 
>>> A new release is long overdue; I'm afraid I cannot do the release 
>>> engineering this time.
>>> 
>>> There has been some effort on moving the CVS repositories to git; 
>>> I'm not sure what the status is there, too.
>>> 
>>> Any help wrt. documentation, presentation or software is greatly 
>>> appreciated ;-)
>>> 
>>> Regards,
>>> 
>>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
>>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
>>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
>>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
>>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
>>> | USt-IdNr: DE163214194
>> 



Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484







From jay.krell at cornell.edu  Wed May 28 08:20:10 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 06:20:10 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
Message-ID: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>

 Sorry, my life has really changed and I have hardly any time now..
 I still hope to come back. 



The C backend works quite well.
I was able to cross-to and self-world-build many platforms.
Including bring up new platform: AMD64_NT.
There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.
jmpbuf remains a platform-specificity in the frontend.


 I believe we had mostly good experience with Linux/arm and maybe Dragonfly? 
 Not sure.


 Going through C source and C compiler is noticable slower. 


The "levelness" of the output is near what I was aiming for, for the first go.
 - records all have fields; you can view them in standard debuggers -- good! 
    This took me a while but I got there. 
 - but globals are not viewable -- all offsets into particular records 
 - all locals/parameters get numbers on the end to disambiguate
    from "nearby" name clashes, though usually it isn't needed;
    this is near the top of the things to fix


The "levelness" is still low in that the word size and posix vs. NT is baked in.
If you want "one source release", you really need to make about 6 currently:
  posix 32bit little endian (many systems)  
  posix 32bit big endian (rare: sparc32_solaris, ppc_darwin) 
  posix 64bit little endian (many systems)  
  posix 64bit big endian (rare: sparc64_solaris, ppc64_darwin)  
  nt 32bit little endian 
  nt 64bit little endian 


 There is one recent outstanding bug report where the generated C is invalid. 


 Besides jmpbuf, I'd like to see endianness factored out.
 There is approx one instance of endian specificity in the frontend
 I'd like to see removed. And then htos/htol/stoh/ltoh moved to C.


I'd also like to see exception handling optionally implemented on top of C++ exception
handling or NT C exception handling (also maybe VMS/Tru64/Ultrix C exception handling...).


For a release though, most of this isn't needed.
Mainly: fix the one bug, decide if performance and debugability is adequate.


 - Jay



> From: hosking at cs.purdue.edu
> Date: Tue, 27 May 2014 12:49:12 -0400
> To: adacore at marino.st; jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
> Subject: Re: [M3devel] Status of CM3
> 
> Jay might comment on C backend status for those platforms.
> 
> On May 27, 2014, at 11:40 AM, John Marino <adacore at marino.st> wrote:
> 
> > On 5/27/2014 17:34, Dragi?a Duri? wrote:
> >> You can count on me for release engineering, Git migration. Maybe CI,
> >> if I have resources. Problem is - feedback is poor from core
> >> developers wrt Git migration. I am ready for long time now.
> > 
> > 
> > This might be a good time to remind that I've been waiting for a release
> > that feature C-backend support for both FreeBSD and DragonFly (new).
> > The version in FreeBSD ports is 4 years old, but there's not been a
> > release since then.  The last time I was active on the list we discussed
> > the needs of FreeBSD and for porting M3 to DragonFly and something was
> > supposed to happen code-wise (and then release-wise) but I don't think
> > anything did in the end.
> > 
> > I was extremely busy with other projects but was planning on pinging on
> > this topic soon anyway.
> > 
> > John
> > 
> > 
> >> 
> >> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
> >> 
> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
> >>> <bruce.axtens at gmail.com> wrote:
> >>> 
> >>>> Dear Sir
> >>>> 
> >>>> Should I assume that CM3 is alive, in palliative care or dead?
> >>>> The trac system is full of spam and the roadmap hasn't moved for
> >>>> 3 years.
> >>>> 
> >>>> I had a long and fruitful relationship with Modula-2 years ago
> >>>> and thought that perhaps I could restart things with CM3.
> >>> 
> >>> There is certainly some activity in M3 development recently,
> >>> though the community is rather small. The trac system has never
> >>> been much used by the community members; and the WWW presentation
> >>> and regression testing system has lacked my support, as I couldn't
> >>> spent any time on these topics for almost 3 years.
> >>> 
> >>> You should check the m3devel mailing list for news though: 
> >>> https://mail.elegosoft.com/pipermail/m3devel
> >>> 
> >>> There has been a lot of activity at the beginning of this year; it
> >>> has ceased again during recent weeks.
> >>> 
> >>> All CVS commits can be found here: 
> >>> https://mail.elegosoft.com/pipermail/m3commit
> >>> 
> >>> A new release is long overdue; I'm afraid I cannot do the release 
> >>> engineering this time.
> >>> 
> >>> There has been some effort on moving the CVS repositories to git; 
> >>> I'm not sure what the status is there, too.
> >>> 
> >>> Any help wrt. documentation, presentation or software is greatly 
> >>> appreciated ;-)
> >>> 
> >>> Regards,
> >>> 
> >>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
> >>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> >>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
> >>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
> >>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
> >>> | USt-IdNr: DE163214194
> >> 
> 
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +1 765 427 5484
> 
> 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/f5d9fc88/attachment-0001.html>

From jay.krell at cornell.edu  Wed May 28 08:33:14 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 06:33:14 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>,
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, ,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, ,
	<5384B209.3080504@marino.st>, ,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>,
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
Message-ID: <COL130-W2013AC1C6E95C966ADE57BE6250@phx.gbl>

sorry, a correction: because of the jmpbuf matter, there is far more "variety" in the output C than the six I listed.
It isn't quite that every platform is unique, but close enough.

Anyway, the C backend is in very good shape relative to its goals.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; adacore at marino.st
Date: Wed, 28 May 2014 06:20:10 +0000
CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
Subject: Re: [M3devel] Status of CM3




 Sorry, my life has really changed and I have hardly any time now..
 I still hope to come back. 



The C backend works quite well.
I was able to cross-to and self-world-build many platforms.
Including bring up new platform: AMD64_NT.
There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.
jmpbuf remains a platform-specificity in the frontend.


 I believe we had mostly good experience with Linux/arm and maybe Dragonfly? 
 Not sure.


 Going through C source and C compiler is noticable slower. 


The "levelness" of the output is near what I was aiming for, for the first go.
 - records all have fields; you can view them in standard debuggers -- good! 
    This took me a while but I got there. 
 - but globals are not viewable -- all offsets into particular records 
 - all locals/parameters get numbers on the end to disambiguate
    from "nearby" name clashes, though usually it isn't needed;
    this is near the top of the things to fix


The "levelness" is still low in that the word size and posix vs. NT is baked in.
If you want "one source release", you really need to make about 6 currently:
  posix 32bit little endian (many systems)  
  posix 32bit big endian (rare: sparc32_solaris, ppc_darwin) 
  posix 64bit little endian (many systems)  
  posix 64bit big endian (rare: sparc64_solaris, ppc64_darwin)  
  nt 32bit little endian 
  nt 64bit little endian 


 There is one recent outstanding bug report where the generated C is invalid. 


 Besides jmpbuf, I'd like to see endianness factored out.
 There is approx one instance of endian specificity in the frontend
 I'd like to see removed. And then htos/htol/stoh/ltoh moved to C.


I'd also like to see exception handling optionally implemented on top of C++ exception
handling or NT C exception handling (also maybe VMS/Tru64/Ultrix C exception handling...).


For a release though, most of this isn't needed.
Mainly: fix the one bug, decide if performance and debugability is adequate.


 - Jay



> From: hosking at cs.purdue.edu
> Date: Tue, 27 May 2014 12:49:12 -0400
> To: adacore at marino.st; jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
> Subject: Re: [M3devel] Status of CM3
> 
> Jay might comment on C backend status for those platforms.
> 
> On May 27, 2014, at 11:40 AM, John Marino <adacore at marino.st> wrote:
> 
> > On 5/27/2014 17:34, Dragi?a Duri? wrote:
> >> You can count on me for release engineering, Git migration. Maybe CI,
> >> if I have resources. Problem is - feedback is poor from core
> >> developers wrt Git migration. I am ready for long time now.
> > 
> > 
> > This might be a good time to remind that I've been waiting for a release
> > that feature C-backend support for both FreeBSD and DragonFly (new).
> > The version in FreeBSD ports is 4 years old, but there's not been a
> > release since then.  The last time I was active on the list we discussed
> > the needs of FreeBSD and for porting M3 to DragonFly and something was
> > supposed to happen code-wise (and then release-wise) but I don't think
> > anything did in the end.
> > 
> > I was extremely busy with other projects but was planning on pinging on
> > this topic soon anyway.
> > 
> > John
> > 
> > 
> >> 
> >> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
> >> 
> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
> >>> <bruce.axtens at gmail.com> wrote:
> >>> 
> >>>> Dear Sir
> >>>> 
> >>>> Should I assume that CM3 is alive, in palliative care or dead?
> >>>> The trac system is full of spam and the roadmap hasn't moved for
> >>>> 3 years.
> >>>> 
> >>>> I had a long and fruitful relationship with Modula-2 years ago
> >>>> and thought that perhaps I could restart things with CM3.
> >>> 
> >>> There is certainly some activity in M3 development recently,
> >>> though the community is rather small. The trac system has never
> >>> been much used by the community members; and the WWW presentation
> >>> and regression testing system has lacked my support, as I couldn't
> >>> spent any time on these topics for almost 3 years.
> >>> 
> >>> You should check the m3devel mailing list for news though: 
> >>> https://mail.elegosoft.com/pipermail/m3devel
> >>> 
> >>> There has been a lot of activity at the beginning of this year; it
> >>> has ceased again during recent weeks.
> >>> 
> >>> All CVS commits can be found here: 
> >>> https://mail.elegosoft.com/pipermail/m3commit
> >>> 
> >>> A new release is long overdue; I'm afraid I cannot do the release 
> >>> engineering this time.
> >>> 
> >>> There has been some effort on moving the CVS repositories to git; 
> >>> I'm not sure what the status is there, too.
> >>> 
> >>> Any help wrt. documentation, presentation or software is greatly 
> >>> appreciated ;-)
> >>> 
> >>> Regards,
> >>> 
> >>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
> >>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> >>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
> >>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
> >>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
> >>> | USt-IdNr: DE163214194
> >> 
> 
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +1 765 427 5484
> 
> 
> 
> 
> 
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/aff2833b/attachment-0001.html>

From jay.krell at cornell.edu  Wed May 28 08:42:33 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 06:42:33 +0000
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>
References: <535FA2B2.70108@gmail.com>,
	<A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>
Message-ID: <COL130-W1019248A16E06F580E4D88E6250@phx.gbl>

.deb is just a .tar.gz or .tar.bz2 or .tar.xz with a little bit more around it.
They can be fancy but ours is not, it is just a compressed .tar.
Can you just crack it open and install the underlying parts?
It is likely "position independent" and you can extract it anywhere in your file system -- /usr/local/cm3, $HOME/cm3, etc.

I build them pretty "manually" see here:
https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/pylib.py  
the function MakeDebianPackage
Ok, it is an actually an "ar" file, and inside the main thing is data.tar with some compression like .gz or .xz.

 - Jay

From: dragisha at m3w.org
Date: Thu, 1 May 2014 19:49:28 +0200
To: bruceax at gmail.com
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr

It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.

--Dragi?a Duri?dragisha at m3w.org



On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:
  

    
  
  
    I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty?
    When I try to install it with Ubuntu Software Centre I get told the
    following:

    

    Lintian check results for
      /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:

      Can't use an undefined value as an ARRAY reference at
      /usr/share/perl5/

      Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.

    
    

    Is this a Perl issue or an installer issue?

    

    -- Bruce

    

  


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/3b4c0333/attachment-0001.html>

From estellnb at elstel.org  Wed May 28 10:03:21 2014
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Wed, 28 May 2014 10:03:21 +0200
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <COL130-W1019248A16E06F580E4D88E6250@phx.gbl>
References: <535FA2B2.70108@gmail.com>,
	<A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>
	<COL130-W1019248A16E06F580E4D88E6250@phx.gbl>
Message-ID: <8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org>

If it is a true .deb you need to apply 
> ar x xy.deb
and then
> tar -xvJ <~/aux/data.tar.xz

(A real  .deb will also contain a control .tar.gz with control, shlibs, md5sums, postinst, etc.)

It should be built with
> pushd BUILD
> dpkg-buildpackage -sa -kmy at email.org
> popd
and checked with
> lintian -EvIL +pedantic my.dsc


Am 28.05.2014 um 08:42 schrieb Jay K:

> .deb is just a .tar.gz or .tar.bz2 or .tar.xz with a little bit more around it.
> They can be fancy but ours is not, it is just a compressed .tar.
> Can you just crack it open and install the underlying parts?
> It is likely "position independent" and you can extract it anywhere in your file system -- /usr/local/cm3, $HOME/cm3, etc.
> 
> I build them pretty "manually" see here:
> https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/pylib.py  
> the function MakeDebianPackage
> Ok, it is an actually an "ar" file, and inside the main thing is data.tar with some compression like .gz or .xz.
> 
>  - Jay
> 
> From: dragisha at m3w.org
> Date: Thu, 1 May 2014 19:49:28 +0200
> To: bruceax at gmail.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr
> 
> It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.
> --
> Dragi?a Duri?
> dragisha at m3w.org
> 
> 
> 
> On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:
> 
> I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty? When I try to install it with Ubuntu Software Centre I get told the following:
> 
> Lintian check results for /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:
> Can't use an undefined value as an ARRAY reference at /usr/share/perl5/
> Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.
> 
> Is this a Perl issue or an installer issue?
> 
> -- Bruce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/d6e4ec51/attachment-0001.html>

From estellnb at elstel.org  Wed May 28 10:40:34 2014
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Wed, 28 May 2014 10:40:34 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
Message-ID: <8400B243-1D27-4651-84AB-071E26329507@elstel.org>

A new release would be great!
I have been waiting to get all the qt and gtk libraries packed with a new release.
If I wanna do some end user application development like the CoAN simulator in Modula-3 it will actually need to work with a release because I can not demand the users of my applications to compile the compiler first (That would harshly drop the usage rates).

Concerning a contribution from my side for a new CM3 release I could perhaps manage to get everything packed into .deb and .rpm package in summer as I do already have some experience in this field.

Regards,
Elmar
 

Am 25.05.2014 um 18:36 schrieb Olaf Wagner:

> On Sun, 25 May 2014 22:35:09 +0800
> Bruce Axtens <bruce.axtens at gmail.com> wrote:
> 
>> Dear Sir
>> 
>> Should I assume that CM3 is alive, in palliative care or dead? The trac
>> system is full of spam and the roadmap hasn't moved for 3 years.
>> 
>> I had a long and fruitful relationship with Modula-2 years ago and thought
>> that perhaps I could restart things with CM3.
> 
> There is certainly some activity in M3 development recently, though
> the community is rather small.
> The trac system has never been much used by the community members;
> and the WWW presentation and regression testing system has lacked
> my support, as I couldn't spent any time on these topics for
> almost 3 years.
> 
> You should check the m3devel mailing list for news though:
> https://mail.elegosoft.com/pipermail/m3devel
> 
> There has been a lot of activity at the beginning of this year;
> it has ceased again during recent weeks.
> 
> All CVS commits can be found here:
> https://mail.elegosoft.com/pipermail/m3commit
> 
> A new release is long overdue; I'm afraid I cannot do the release
> engineering this time.
> 
> There has been some effort on moving the CVS repositories to git;
> I'm not sure what the status is there, too.
> 
> Any help wrt. documentation, presentation or software is greatly
> appreciated ;-)
> 
> Regards,
> 
> Olaf Wagner
> -- 
> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From adacore at marino.st  Wed May 28 10:41:06 2014
From: adacore at marino.st (John Marino)
Date: Wed, 28 May 2014 10:41:06 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
Message-ID: <5385A122.4020205@marino.st>

On 5/28/2014 08:20, Jay K wrote:
>  Sorry, my life has really changed and I have hardly any time now..
>  I still hope to come back.
> 
> 
> 
> The C backend works quite well.
> I was able to cross-to and self-world-build many platforms.
> Including bring up new platform: AMD64_NT.
> There is a jmpbuf alignment problem on AMD64_NT worked around by using
> libcmt.lib instead of msvcrt.dll.
> jmpbuf remains a platform-specificity in the frontend.
> 
> 
>  I believe we had mostly good experience with Linux/arm and maybe
> Dragonfly?
>  Not sure.


Hi Jay,
The assumptions I was working on was this:
A) There has been no release
B) We want to convert FreeBSD to c-backend
C) There is no support for DragonFly, we want to add that
D) We want to do B+C before the next release

So I thought there was some build-framework stuff that needed to happen
for FreeBSD and DragonFly prior to the release, otherwise we'd just have
to patch it all up and we were trying to avoid needing those patches.

I am not even at the point of evaluating the C-Backend.
Maybe if there was a release candidate then I could figure out what's
missing a provide patches.

At the very, very least we could have CM3 on github and build from a
specific tag.  I am not wild about that, but it's better than what's
available now.  (FreeBSD ports can build straight from github although
it's not really encouraged)

So if for no other reason, I'd like to see CM3 migrate to github ASAP.

Regards,
John


From jay.krell at cornell.edu  Wed May 28 19:08:31 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 17:08:31 +0000
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org>
References: <535FA2B2.70108@gmail.com>, ,
	<A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>,
	<COL130-W1019248A16E06F580E4D88E6250@phx.gbl>,
	<8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org>
Message-ID: <COL130-W8356F05B7DCCB173BE7B78E6250@phx.gbl>

The .debs do have other files, at least one. See the code I pointed at.
I don't make them with the usual tools,
for an eaiser potential cross build story -- fewer dependencies.
It worked at the time.
 
 
# Debian architecture strings:
# see http://www.debian.org/doc/debian-policy/footnotes.html#f73

DebianArchitecture = {
  "LINUXLIBC6" : "i386",
  "FreeBSD4" : "i386",
  "NT386" : "i386",
  "I386" : "i386",
  "IA64" : "ia64",
  "ALPHA" : "alpha",
  "AMD64" : "amd64",
  "HPPA" : "hppa",
  "PA32" : "hppa",
  "PA64" : "hppa",
  "MIPS" : "mips",
  "MIPS32" : "mips",
  "MIPS64" : "mips",
  "PPC" : "powerpc",
  "PPC32" : "powerpc",
  "PPC64" : "ppc",
  "SOLsun" : "sparc",
  "SOLgnu" : "sparc",
  "SPARC" : "sparc",
  "SPARC32" : "sparc",
  "SPARC64" : "sparc",
  }

def MakeDebianPackage(input, prefix):
#
# .deb file format:
# an ar archive containing (I think the order matters):
#   debian-binary:
#     text file that just says "2.0\n"
#   control.tar.gz:
#     metadata, minimum is control file
#   data.tar.gz or .bz2 or .lzma
#     payload
# User has no choice where the install goes.
#
    if SearchPath("lzma"):
        compresser = "lzma"
        compressed_extension = "lzma"
    elif isfile("/home/jkrell/bin/lzma"):
        compresser = "/home/jkrell/bin/lzma"
        compressed_extension = "lzma"
    else:
        compresser = "gzip"
        compressed_extension = "gz"
    # while testing, gzip is much faster
    # compresser = "gzip"
    # compressed_extension = "gz"
    print("cd " + input)
    os.chdir(input)
    CreateDirectory("./debian")
    MoveSkel(prefix)
    newline = "\012" # take no chances
    open("./debian-binary", "w").write("2.0" + newline)
    os.chdir("./debian")
    architecture = DebianArchitecture.get(Target) or DebianArchitecture.get(Target[:Target.index("_")])
    control = (
      "Package: cm3-" + Target + "-" + CM3VERSION + newline
    + "Version: 1.0" + newline
    + "Maintainer: somebody at somewhere.com" + newline
    + "Architecture: " + architecture + newline
    + "Description: good stuff" + newline)
    print("control:" + control)
    open("./control", "w").write(control)

    command = "tar cf ../control.tar ."
    print(command)
    os.system(command)

    command = "gzip ../control.tar"
    print(command)
    os.system(command)

    os.chdir(input)
    command = "tar cf data.tar ." + prefix
    if isfile("data.tar." + compressed_extension) or isfile("data.tar"):
        print("skipping " + command)
    else:
        print(command)
        os.system(command)
    command = compresser + " data.tar"
    if isfile("data.tar." + compressed_extension):
        print("skipping " + command)
    else:
        print(command)
        os.system(command)

    command = "ar cr " + input + ".deb debian-binary control.tar.gz data.tar." + compressed_extension
    print(command)
    os.system(command)
    RestoreSkel(prefix)

 
 - Jay


 
From: estellnb at elstel.org
Date: Wed, 28 May 2014 10:03:21 +0200
To: jay.krell at cornell.edu; dragisha at m3w.org; bruceax at gmail.com
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr

If it is a true .deb you need to apply > ar x xy.deband then> tar -xvJ <~/aux/data.tar.xz
(A real  .deb will also contain a control .tar.gz with control, shlibs, md5sums, postinst, etc.)
It should be built with> pushd BUILD> dpkg-buildpackage -sa -kmy at email.org> popdand checked with> lintian -EvIL +pedantic my.dsc

Am 28.05.2014 um 08:42 schrieb Jay K:.deb is just a .tar.gz or .tar.bz2 or .tar.xz with a little bit more around it.
They can be fancy but ours is not, it is just a compressed .tar.
Can you just crack it open and install the underlying parts?
It is likely "position independent" and you can extract it anywhere in your file system -- /usr/local/cm3, $HOME/cm3, etc.

I build them pretty "manually" see here:
https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/pylib.py  
the function MakeDebianPackage
Ok, it is an actually an "ar" file, and inside the main thing is data.tar with some compression like .gz or .xz.

 - Jay

From: dragisha at m3w.org
Date: Thu, 1 May 2014 19:49:28 +0200
To: bruceax at gmail.com
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr

It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.
--Dragi?a Duri?dragisha at m3w.org

On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty? When I try to install it with Ubuntu Software Centre I get told the following:

Lintian check results for /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:
Can't use an undefined value as an ARRAY reference at /usr/share/perl5/
Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.

Is this a Perl issue or an installer issue?

-- Bruce
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/cca064e6/attachment-0001.html>

From jay.krell at cornell.edu  Wed May 28 19:31:43 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 17:31:43 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <5385A122.4020205@marino.st>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
Message-ID: <COL130-W77F293FE76307E7C81612DE6250@phx.gbl>

 > A) There has been no release

 
There has been no release.
 
 
> B) We want to convert FreeBSD to c-backend


I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
 
 
Specifically, I no longer have shelves full of a myriad of computers, but I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux, OpenBSD, FreeBSD, NetBSD), I have the Solaris opencsw sparc32/sparc64/x86/amd64 machines, I have the Mac, I have Windows, I have the Elego Debian/amd64 maybe Debian/x86 machine and I tested many/all of these successfully. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't offer the thread/suspend/getcontext stuff -- something cooperative suspend will fix eventually.
 
 
Adding new platforms is fairly straightforward. Far more than it used to be.
You just make few scattered easy edits.
My pseudo goal is to drive that down to be easier and easier.
Several platforms have been relatively recently brought back or brought up or at least shown to work completely or almost to me.
 
What remains unclear to me is the consensus decision on exactly what the switch looks like.
  1) unconditionally switch all targets  
  2) leave it as some sort of user option  
  3) have new targets only supported using the C backend 
 
 
There are downsides to the C backend. Specifically:
  1) On systems that support m3gdb, debugging is not as good as with m3gdb 
   m3gdb is an old fork of gdb, doesn't work on all platforms (e.g. Darwin, HP-UX, NT), but does work on many. 
  2) Compilation is noticeably slower. 
  3) The output is not necessarily ABI compatible with the non-C backend. 
 
 
My inclination is unconditional switch to C backend for all targets that use m3cc, leave m3cc to bit-rot.
Think more about the integrated backend. In reality, given more time, I'd like to extend the integrated backend to support more targets. But that so far seems beyond most of our scopes.
 
The safe thing is user-option. But it is also confusing.
Given the ABI variation, do we double all the platforms?
I386_LINUX and I386_LINUX_C?
 
 
 And then later POSIX_32BIT_LITTLEENDIAN_C? 
 And then later GENERIC_C? 
 
Do we switch the existing ones, and introduce I386_LINUX_M3CC?
 
 
 > C) There is no support for DragonFly, we want to add that
 
This is easy.

> D) We want to do B+C before the next release
 
C is easy. B requires a decision/consensus.
 
Thanks,
 - Jay


 
> Date: Wed, 28 May 2014 10:41:06 +0200
> From: adacore at marino.st
> To: jay.krell at cornell.edu; hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
> Subject: Re: [M3devel] Status of CM3
> 
> On 5/28/2014 08:20, Jay K wrote:
> >  Sorry, my life has really changed and I have hardly any time now..
> >  I still hope to come back.
> > 
> > 
> > 
> > The C backend works quite well.
> > I was able to cross-to and self-world-build many platforms.
> > Including bring up new platform: AMD64_NT.
> > There is a jmpbuf alignment problem on AMD64_NT worked around by using
> > libcmt.lib instead of msvcrt.dll.
> > jmpbuf remains a platform-specificity in the frontend.
> > 
> > 
> >  I believe we had mostly good experience with Linux/arm and maybe
> > Dragonfly?
> >  Not sure.
> 
> 
> Hi Jay,
> The assumptions I was working on was this:
> A) There has been no release
> B) We want to convert FreeBSD to c-backend
> C) There is no support for DragonFly, we want to add that
> D) We want to do B+C before the next release
> 
> So I thought there was some build-framework stuff that needed to happen
> for FreeBSD and DragonFly prior to the release, otherwise we'd just have
> to patch it all up and we were trying to avoid needing those patches.
> 
> I am not even at the point of evaluating the C-Backend.
> Maybe if there was a release candidate then I could figure out what's
> missing a provide patches.
> 
> At the very, very least we could have CM3 on github and build from a
> specific tag.  I am not wild about that, but it's better than what's
> available now.  (FreeBSD ports can build straight from github although
> it's not really encouraged)
> 
> So if for no other reason, I'd like to see CM3 migrate to github ASAP.
> 
> Regards,
> John
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/21fbcbf9/attachment-0001.html>

From mika at async.caltech.edu  Wed May 28 20:04:38 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Wed, 28 May 2014 11:04:38 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
Message-ID: <20140528180438.09C0F1A2097@async.async.caltech.edu>


Yes it worked pretty well as far as I remember.  There was still some
issue with a segfault we never debugged, but that was compiling all the
CM3 stuff plus my own big repository.  You were able to help me bootstrap
the regular compiler on ARM so that is what the regular ARM_LINUX is now
(for Raspberry Pi).

     Mika

---

Jay wrote:
The C backend works quite well.
I was able to cross-to and self-world-build many platforms.
Including bring up new platform: AMD64_NT.
There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.
jmpbuf remains a platform-specificity in the frontend.


 I believe we had mostly good experience with Linux/arm and maybe Dragonfly? 
 Not sure.


 Going through C source and C compiler is noticable slower. 




From adacore at marino.st  Wed May 28 20:24:06 2014
From: adacore at marino.st (John Marino)
Date: Wed, 28 May 2014 20:24:06 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
Message-ID: <538629C6.9070200@marino.st>

On 5/28/2014 19:31, Jay K wrote:
>> B) We want to convert FreeBSD to c-backend
> 
> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>  
>  > C) There is no support for DragonFly, we want to add that
>  
> This is easy.
> 
>> D) We want to do B+C before the next release
>  
> C is easy. B requires a decision/consensus.
>  

Hi Jay,
B requires a decision if it replaces m3cc on FreeBSD.
However if FreeBSD can keep m3cc but also be configured to build with
C-backend, then it shouldn't need a consensus as everyone wins.

I realize that that the real question is not about FreeBSD, but rather a
project-wide decision, however.

John


From mika at async.caltech.edu  Wed May 28 20:25:03 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Wed, 28 May 2014 11:25:03 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
Message-ID: <20140528182503.087801A2095@async.async.caltech.edu>

Jay K writes:
>--_af0f88f0-4e39-4643-873b-5267a8c2a602_
...
>> B) We want to convert FreeBSD to c-backend
>
>
>I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>=20
>=20
>Specifically=2C I no longer have shelves full of a myriad of computers=2C b=
>ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux=2C Open=
>BSD=2C FreeBSD=2C NetBSD)=2C I have the Solaris opencsw sparc32/sparc64/x86=
>/amd64 machines=2C I have the Mac=2C I have Windows=2C I have the Elego Deb=
>ian/amd64 maybe Debian/x86 machine and I tested many/all of these successfu=
>lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't of=
>fer the thread/suspend/getcontext stuff -- something cooperative suspend wi=
>ll fix eventually.
...

I don't think the C backend is perfect.  If you want to switch
unconditionally, I'll have to make time to help debug it.  My fuzzy 
memory, as I mentioned, is that there's some unexplained segfault.
Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
Something like that?  Ring a bell for anyone?

I quite like the native backends.  The code is more compact than
the C backend's.  I haven't done a performance comparison... I know
performance of Modula-3 code has in general been sliding backwards
through the versions.  Things just get slower and slower and slower
with time.  I think it's a shame because Modula-3's niche (well the one
I am interested in) is to be "almost the performance and simplicity of
C with the safety of Java (and some cool software engineering stuff)".
CM3 definitely compromised this, and while they added some cool new
features, most of them (e.g., dynamic relinking of running programs) as
far as I know are not being used.  The work on cleaning up TEXTs has 
gone a ways to remedying the situation but I think there's much else.
Ok now I'm off on a tangent...

    Mika


From hosking at cs.purdue.edu  Wed May 28 21:32:40 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 28 May 2014 15:32:40 -0400
Subject: [M3devel] Status of CM3
In-Reply-To: <20140528182503.087801A2095@async.async.caltech.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<20140528182503.087801A2095@async.async.caltech.edu>
Message-ID: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>

What is really needed is some time and attention put in to bring the CM3 runtime up to date with respect to advances in the field of runtime systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" locking), cooperative GC safepoints, integration with a modern code generator (LLVM!), on-the-fly GC (avoiding the need for stopping the world).

It would be wonderful to attack these, but they are also somewhat interrelated (on-the-fly depends on per-thread safepoint handshakes, biased locking requires compiler work, etc.).  So they cannot be simply carved off independently.

On May 28, 2014, at 2:25 PM, mika at async.caltech.edu wrote:

> Jay K writes:
>> --_af0f88f0-4e39-4643-873b-5267a8c2a602_
> ...
>>> B) We want to convert FreeBSD to c-backend
>> 
>> 
>> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>> =20
>> =20
>> Specifically=2C I no longer have shelves full of a myriad of computers=2C b=
>> ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux=2C Open=
>> BSD=2C FreeBSD=2C NetBSD)=2C I have the Solaris opencsw sparc32/sparc64/x86=
>> /amd64 machines=2C I have the Mac=2C I have Windows=2C I have the Elego Deb=
>> ian/amd64 maybe Debian/x86 machine and I tested many/all of these successfu=
>> lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't of=
>> fer the thread/suspend/getcontext stuff -- something cooperative suspend wi=
>> ll fix eventually.
> ...
> 
> I don't think the C backend is perfect.  If you want to switch
> unconditionally, I'll have to make time to help debug it.  My fuzzy 
> memory, as I mentioned, is that there's some unexplained segfault.
> Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
> Something like that?  Ring a bell for anyone?
> 
> I quite like the native backends.  The code is more compact than
> the C backend's.  I haven't done a performance comparison... I know
> performance of Modula-3 code has in general been sliding backwards
> through the versions.  Things just get slower and slower and slower
> with time.  I think it's a shame because Modula-3's niche (well the one
> I am interested in) is to be "almost the performance and simplicity of
> C with the safety of Java (and some cool software engineering stuff)".
> CM3 definitely compromised this, and while they added some cool new
> features, most of them (e.g., dynamic relinking of running programs) as
> far as I know are not being used.  The work on cleaning up TEXTs has 
> gone a ways to remedying the situation but I think there's much else.
> Ok now I'm off on a tangent...
> 
>   Mika

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/2368d3c9/attachment-0001.html>

From jay.krell at cornell.edu  Wed May 28 22:13:56 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 20:13:56 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>,
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, ,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, ,
	<5384B209.3080504@marino.st>, ,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>,
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>, ,
	<5385A122.4020205@marino.st>,
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>,
	<20140528182503.087801A2095@async.async.caltech.edu>,
	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
Message-ID: <COL130-W29A4F6A942B48899A58222E6250@phx.gbl>

I'd be happy with:
  - cooperative GC, for portability, it'd remove a lot of our #ifdefs, fix PPC_DARWIN under Rosetta, and address a nagging concern I have for even NT/x86 on AMD64 wrt SuspendThread near-in-time to syscalls.
  - no-stop-the-world, for scaling 
 
Aren't they fairly standalone?
I could do without LLVM at this point. C/C++ backend is more portable.
I'd like to hope/depend that underlying pthreads/win32 does a good job with locking.
 
 - Jay

 
From: hosking at cs.purdue.edu
Date: Wed, 28 May 2014 15:32:40 -0400
To: mika at async.caltech.edu
CC: m3devel at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] Status of CM3

What is really needed is some time and attention put in to bring the CM3 runtime up to date with respect to advances in the field of runtime systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" locking), cooperative GC safepoints, integration with a modern code generator (LLVM!), on-the-fly GC (avoiding the need for stopping the world).

It would be wonderful to attack these, but they are also somewhat interrelated (on-the-fly depends on per-thread safepoint handshakes, biased locking requires compiler work, etc.).  So they cannot be simply carved off independently.

On May 28, 2014, at 2:25 PM, mika at async.caltech.edu wrote:

Jay K writes:
--_af0f88f0-4e39-4643-873b-5267a8c2a602_
...
B) We want to convert FreeBSD to c-backend


I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
=20
=20
Specifically=2C I no longer have shelves full of a myriad of computers=2C b=
ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux=2C Open=
BSD=2C FreeBSD=2C NetBSD)=2C I have the Solaris opencsw sparc32/sparc64/x86=
/amd64 machines=2C I have the Mac=2C I have Windows=2C I have the Elego Deb=
ian/amd64 maybe Debian/x86 machine and I tested many/all of these successfu=
lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't of=
fer the thread/suspend/getcontext stuff -- something cooperative suspend wi=
ll fix eventually.
...

I don't think the C backend is perfect.  If you want to switch
unconditionally, I'll have to make time to help debug it.  My fuzzy 
memory, as I mentioned, is that there's some unexplained segfault.
Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
Something like that?  Ring a bell for anyone?

I quite like the native backends.  The code is more compact than
the C backend's.  I haven't done a performance comparison... I know
performance of Modula-3 code has in general been sliding backwards
through the versions.  Things just get slower and slower and slower
with time.  I think it's a shame because Modula-3's niche (well the one
I am interested in) is to be "almost the performance and simplicity of
C with the safety of Java (and some cool software engineering stuff)".
CM3 definitely compromised this, and while they added some cool new
features, most of them (e.g., dynamic relinking of running programs) as
far as I know are not being used.  The work on cleaning up TEXTs has 
gone a ways to remedying the situation but I think there's much else.
Ok now I'm off on a tangent...

   Mika


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/c8543840/attachment-0001.html>

From mika at async.caltech.edu  Wed May 28 22:32:18 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Wed, 28 May 2014 13:32:18 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<20140528182503.087801A2095@async.async.caltech.edu>
	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
Message-ID: <20140528203218.658CC1A2096@async.async.caltech.edu>


All that stuff is important but sometimes you just want a fast
single-threaded parser (or whatever)...

I *think* that if I write a program using ARRAY OF CHAR and hand-code everything 
not to allocate memory, etc., I get about as good performance in native CM3 as
I used to see in PM3.  It shouldn't be any slower than C, whether that is true
or not I don't know.

It is easier to write such (old-fashioned) programs in Modula-3 than in C, which
is one of the reasons I really like this programming language...

It would be nice if the performance loss in going to TEXT (for example) were not
that great.  Partly that has to do with some of the issues you talk about (GC/locking),
of course.

Tony Hosking writes:
>
>--Apple-Mail=_0963FC1A-17A1-4B57-93C6-C196F4ECCDC1
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=us-ascii
>
>What is really needed is some time and attention put in to bring the CM3 =
>runtime up to date with respect to advances in the field of runtime =
>systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" =
>locking), cooperative GC safepoints, integration with a modern code =
>generator (LLVM!), on-the-fly GC (avoiding the need for stopping the =
>world).
>
>It would be wonderful to attack these, but they are also somewhat =
>interrelated (on-the-fly depends on per-thread safepoint handshakes, =
>biased locking requires compiler work, etc.).  So they cannot be simply =
>carved off independently.
>
>On May 28, 2014, at 2:25 PM, mika at async.caltech.edu wrote:
>
>> Jay K writes:
>>> --_af0f88f0-4e39-4643-873b-5267a8c2a602_
>> ...
>>>> B) We want to convert FreeBSD to c-backend
>>>=20
>>>=20
>>> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C =
>backend.
>>> =3D20
>>> =3D20
>>> Specifically=3D2C I no longer have shelves full of a myriad of =
>computers=3D2C b=3D
>>> ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. =
>Linux=3D2C Open=3D
>>> BSD=3D2C FreeBSD=3D2C NetBSD)=3D2C I have the Solaris opencsw =
>sparc32/sparc64/x86=3D
>>> /amd64 machines=3D2C I have the Mac=3D2C I have Windows=3D2C I have =
>the Elego Deb=3D
>>> ian/amd64 maybe Debian/x86 machine and I tested many/all of these =
>successfu=3D
>>> lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta =
>doesn't of=3D
>>> fer the thread/suspend/getcontext stuff -- something cooperative =
>suspend wi=3D
>>> ll fix eventually.
>> ...
>>=20
>> I don't think the C backend is perfect.  If you want to switch
>> unconditionally, I'll have to make time to help debug it.  My fuzzy=20
>> memory, as I mentioned, is that there's some unexplained segfault.
>> Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
>> Something like that?  Ring a bell for anyone?
>>=20
>> I quite like the native backends.  The code is more compact than
>> the C backend's.  I haven't done a performance comparison... I know
>> performance of Modula-3 code has in general been sliding backwards
>> through the versions.  Things just get slower and slower and slower
>> with time.  I think it's a shame because Modula-3's niche (well the =
>one
>> I am interested in) is to be "almost the performance and simplicity of
>> C with the safety of Java (and some cool software engineering stuff)".
>> CM3 definitely compromised this, and while they added some cool new
>> features, most of them (e.g., dynamic relinking of running programs) =
>as
>> far as I know are not being used.  The work on cleaning up TEXTs has=20=
>
>> gone a ways to remedying the situation but I think there's much else.
>> Ok now I'm off on a tangent...
>>=20
>>   Mika
>
>Antony Hosking | Associate Professor | Computer Science | Purdue =
>University
>305 N. University Street | West Lafayette | IN 47907 | USA
>Mobile +1 765 427 5484
>
>
>
>
>
>
>--Apple-Mail=_0963FC1A-17A1-4B57-93C6-C196F4ECCDC1
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/html;
>	charset=us-ascii
>
><html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
>charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">What =
>is really needed is some time and attention put in to bring the CM3 =
>runtime up to date with respect to advances in the field of runtime =
>systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" =
>locking), cooperative GC safepoints, integration with a modern code =
>generator (LLVM!), on-the-fly GC (avoiding the need for stopping the =
>world).<br><br>It would be wonderful to attack these, but they are also =
>somewhat interrelated (on-the-fly depends on per-thread safepoint =
>handshakes, biased locking requires compiler work, etc.). &nbsp;So they =
>cannot be simply carved off independently.<br><br>On May 28, 2014, at =
>2:25 PM, <a =
>href=3D"mailto:mika at async.caltech.edu">mika at async.caltech.edu</a> =
>wrote:<br><br><blockquote type=3D"cite">Jay K writes:<br><blockquote =
>type=3D"cite">--_af0f88f0-4e39-4643-873b-5267a8c2a602_<br></blockquote>...=
><br><blockquote type=3D"cite"><blockquote type=3D"cite">B) We want to =
>convert FreeBSD to c-backend<br></blockquote><br><br>I believe I tested =
>FreeBSD/x86 and/or FreeBSD/amd64 with the C =
>backend.<br>=3D20<br>=3D20<br>Specifically=3D2C I no longer have shelves =
>full of a myriad of computers=3D2C b=3D<br>ut I have x86 and AMD64 VMs =
>on a Mac readily accessible (i.e. Linux=3D2C Open=3D<br>BSD=3D2C =
>FreeBSD=3D2C NetBSD)=3D2C I have the Solaris opencsw =
>sparc32/sparc64/x86=3D<br>/amd64 machines=3D2C I have the Mac=3D2C I =
>have Windows=3D2C I have the Elego Deb=3D<br>ian/amd64 maybe Debian/x86 =
>machine and I tested many/all of these successfu=3D<br>lly. PPC/Mac =
>can't entirely be tested on x86/Mac because Rosetta doesn't of=3D<br>fer =
>the thread/suspend/getcontext stuff -- something cooperative suspend =
>wi=3D<br>ll fix eventually.<br></blockquote>...<br><br>I don't think the =
>C backend is perfect. &nbsp;If you want to switch<br>unconditionally, =
>I'll have to make time to help debug it. &nbsp;My fuzzy <br>memory, as I =
>mentioned, is that there's some unexplained segfault.<br>Ah it was with =
>Juno, I think. &nbsp;Trestle? &nbsp;Overflow in window =
>resizing?<br>Something like that? &nbsp;Ring a bell for anyone?<br><br>I =
>quite like the native backends. &nbsp;The code is more compact =
>than<br>the C backend's. &nbsp;I haven't done a performance =
>comparison... I know<br>performance of Modula-3 code has in general been =
>sliding backwards<br>through the versions. &nbsp;Things just get slower =
>and slower and slower<br>with time. &nbsp;I think it's a shame because =
>Modula-3's niche (well the one<br>I am interested in) is to be "almost =
>the performance and simplicity of<br>C with the safety of Java (and some =
>cool software engineering stuff)".<br>CM3 definitely compromised this, =
>and while they added some cool new<br>features, most of them (e.g., =
>dynamic relinking of running programs) as<br>far as I know are not being =
>used. &nbsp;The work on cleaning up TEXTs has <br>gone a ways to =
>remedying the situation but I think there's much else.<br>Ok now I'm off =
>on a tangent...<br><br> &nbsp;&nbsp;Mika<br></blockquote><br><div>
><span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
>0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
>0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0px;  "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
>Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
>font-weight: normal; letter-spacing: normal; line-height: normal; =
>orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
>break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
>after-white-space; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF"><font =
>class=3D"Apple-style-span" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Antony =
>Hosking</span></span></font></font><font class=3D"Apple-style-span" =
>face=3D"Gill Sans"><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-converted-space">&nbsp;</span>|<span =
>class=3D"Apple-converted-space">&nbsp;</span></span></span><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; "><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; =
>">Associate Professor</span></span><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; "><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; ">&nbsp;| Computer Science | Purdue =
>University</span></span></font></div><div><font class=3D"Apple-style-span"=
> face=3D"GillSans-Light"><span class=3D"Apple-style-span" =
>style=3D"font-family: GillSans-Light; ">305 N. University Street | West =
>Lafayette | IN 47907 | USA</span></font></div><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Mobile</span></span></font><font =
>class=3D"Apple-style-span" face=3D"GillSans-Light"><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-converted-space">&nbsp;</span>+1 765 427 =
>5484</span></span></font></div><div><font class=3D"Apple-style-span" =
>face=3D"GillSans-Light"><br =
>class=3D"khtml-block-placeholder"></font></div></span></span></span></span=
>></span></span></span><br =
>class=3D"Apple-interchange-newline"></span></div></span></div></span><br =
>class=3D"Apple-interchange-newline"></span><br =
>class=3D"Apple-interchange-newline">
></div>
><br></body></html>=
>
>--Apple-Mail=_0963FC1A-17A1-4B57-93C6-C196F4ECCDC1--


From rcolebur at SCIRES.COM  Thu May 29 05:12:25 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 03:12:25 +0000
Subject: [M3devel] compilation problems with assertions in RTCollector.m3
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6C9B@ATLEX04-SRV.SCIRES.LOCAL>

Tony:

There is an error in "cm3\m3-libs\m3core\src\runtime\common\RTCollector.m3" at line 593.
"hdr" is not defined.
>From context, I'm not sure if it should be "h" or "he", but I've taken a guess on my local copy and changed it to "h".
I'm now running into additional problems.

So, I'll let you make the appropriate fix in the repository.

new source -> compiling RTCollector.m3
"..\src\runtime\common\RTCollector.m3", line 593: undefined (hdr)

Thanks,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Tuesday, May 27, 2014 11:57 AM
To: Coleburn, Randy
Cc: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] compilation problems with assertions in RTCollector.m3

Just committed a (hopeful) fix.  Please give it a try.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484






On May 24, 2014, at 12:57 AM, Coleburn, Randy <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> wrote:


I updated my sandbox to be current with the HEAD branch via CVS, then tried to rebuild everything.

I first built a minimal distribution on Windows XP.  Everything seemed to work fine.

Now, using my newly rebuilt cm3.exe, I decided to rebuild everything.  Unfortunately, now I'm running into problems even in the first stage.

Here are some examples of the errors I am getting.  These runtime errors happen compiling various packages.  (I've tried rebuilding several times.)

I show 3 separate incidents below and the last one has a partial stack trace.  In each case, there is an assertion failure in the RTCollector while running the compiler:

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 699
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x12f374   0x6ca19e  CleanBetween + 0x22 in ..\src\runtime\common\RTCollector.m3
0x12f3ac   0x6ca031  CopySome + 0xeb in ..\src\runtime\common\RTCollector.m3
0x12f3b8   0x6c9b02  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3
0x12f3c8   0x6c94d6  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3
0x12f40c   0x6c916a  CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3
0x12f44c   0x6dc586  AllocTraced + 0xd3 in ..\src\runtime\common\RTAllocator.m3
0x12f480   0x6dbbd8  GetTracedObj + 0x86 in ..\src\runtime\common\RTAllocator.m3
0x12f49c   0x6db70c  AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3
0x12f4d0   0x529913  Init_chars + 0x20b in ..\src\misc\CG.m3
0x12f4f8   0x4f948b  Init_chars + 0xb9 in ..\src\misc\M3String.m3
.........  .........  ... more frames ...

WARNING:  Encountered an error when processing package "m3-sys\m3front" for "-build".

Any help in solving this problem would be appreciated.

Thanks,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/abd55109/attachment-0001.html>

From rcolebur at SCIRES.COM  Thu May 29 07:35:13 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 05:35:13 +0000
Subject: [M3devel] good news on Thread Tester program
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EA8@ATLEX04-SRV.SCIRES.LOCAL>

Tony & Mika:

I have good news to report about the Thread Tester program on Windows XP.

After making the change to RTCollector.m3" at line 593 from "hdr" to "h" and rebuilding everything again, I am now able FOR THE FIRST TIME EVER to get the Thread Tester program to run to completion!

See output below, including verbose mode.  I've also run with "-tests ALL" and it still runs to completion.

So, I think Tony's last round of changes may have been instrumental in fixing a problem with the collector, or either my edit did something weird in which case this may give Tony another clue to the puzzle.

--Randy Coleburn

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread>NT386\threadtest.exe
Writing file...done
Creating read threads...done
Creating fork threads...done
Creating alloc threads...done
Creating lock threads...done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread>NT386\threadtest.exe -verbose
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating fork threads...
   fork=9
   fork=10
   fork=11
done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 54 loops.
   read Thread 1 completed 59 loops.
   read Thread 2 completed 74 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   alloc Thread 15 completed 4713 loops.
   alloc Thread 16 completed 2190 loops.
   alloc Thread 17 completed 2292 loops.
   lock Thread 21 completed 1684145 loops.
   lock Thread 22 completed 3063707 loops.
   lock Thread 23 completed 3541711 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 60 loops.
   read Thread 1 completed 111 loops.
   read Thread 2 completed 64 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 6 loops.
   alloc Thread 15 completed 3280 loops.
   alloc Thread 16 completed 2470 loops.
   alloc Thread 17 completed 1307 loops.
   lock Thread 21 completed 2317559 loops.
   lock Thread 22 completed 3341857 loops.
   lock Thread 23 completed 3498231 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 19 loops.
   read Thread 1 completed 40 loops.
   read Thread 2 completed 56 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 2100 loops.
   alloc Thread 16 completed 1227 loops.
   alloc Thread 17 completed 1612 loops.
   lock Thread 21 completed 2281438 loops.
   lock Thread 22 completed 3874612 loops.
   lock Thread 23 completed 3777331 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 65 loops.
   read Thread 1 completed 67 loops.
   read Thread 2 completed 58 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 3860 loops.
   alloc Thread 16 completed 1897 loops.
   alloc Thread 17 completed 1261 loops.
   lock Thread 21 completed 2422432 loops.
   lock Thread 22 completed 3524236 loops.
   lock Thread 23 completed 3381697 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 62 loops.
   read Thread 1 completed 78 loops.
   read Thread 2 completed 105 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 8 loops.
   alloc Thread 15 completed 3659 loops.
   alloc Thread 16 completed 2552 loops.
   alloc Thread 17 completed 1838 loops.
   lock Thread 21 completed 1202534 loops.
   lock Thread 22 completed 2055904 loops.
   lock Thread 23 completed 2086094 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 57 loops.
   read Thread 1 completed 77 loops.
   read Thread 2 completed 64 loops.
   fork Thread 9 completed 8 loops.
   fork Thread 10 completed 9 loops.
   fork Thread 11 completed 8 loops.
   alloc Thread 15 completed 4430 loops.
   alloc Thread 16 completed 3199 loops.
   alloc Thread 17 completed 4229 loops.
   lock Thread 21 completed 1143292 loops.
   lock Thread 22 completed 1630285 loops.
   lock Thread 23 completed 2056873 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 36 loops.
   read Thread 1 completed 32 loops.
   read Thread 2 completed 61 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 2025 loops.
   alloc Thread 16 completed 669 loops.
   alloc Thread 17 completed 1874 loops.
   lock Thread 21 completed 2457649 loops.
   lock Thread 22 completed 4119545 loops.
   lock Thread 23 completed 3744966 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 19 loops.
   read Thread 1 completed 22 loops.
   read Thread 2 completed 23 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   alloc Thread 15 completed 2785 loops.
   alloc Thread 16 completed 1408 loops.
   alloc Thread 17 completed 1687 loops.
   lock Thread 21 completed 2406833 loops.
   lock Thread 22 completed 4204846 loops.
   lock Thread 23 completed 4080463 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 34 loops.
   read Thread 1 completed 66 loops.
   read Thread 2 completed 70 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 6 loops.
   alloc Thread 15 completed 2967 loops.
   alloc Thread 16 completed 1514 loops.
   alloc Thread 17 completed 1045 loops.
   lock Thread 21 completed 2094655 loops.
   lock Thread 22 completed 3280113 loops.
   lock Thread 23 completed 3632821 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 61 loops.
   read Thread 1 completed 14 loops.
   read Thread 2 completed 26 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 3055 loops.
   alloc Thread 16 completed 1943 loops.
   alloc Thread 17 completed 915 loops.
   lock Thread 21 completed 2255832 loops.
   lock Thread 22 completed 3704985 loops.
   lock Thread 23 completed 3691192 loops.
All tests complete.  Congratulations.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/439c02ae/attachment-0001.html>

From rcolebur at SCIRES.COM  Thu May 29 07:40:15 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 05:40:15 +0000
Subject: [M3devel] build problems with libunicode
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>

I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).

The m3-libs\libunicode package fails to build (see errors below).

I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.

The problem module is: UnsafeUniCodec.m3

Thanks,
Randy Coleburn

C:\cm3\Sandbox\cm3\m3-libs\libunicode>cm3
--- building in NT386 ---

new source -> compiling UnsafeUniCodec.m3
"..\src\UnsafeUniCodec.m3", line 81: warning: not used (Sink)
"..\src\UnsafeUniCodec.m3", line 81: warning: not used (Wch)
"..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: UniCodec.Range
"..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Wr.Failure
"..\src\UnsafeUniCodec.m3", line 88: warning: not used (Source)
"..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.EndOfFile
"..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.Failure
"..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 96: warning: not used (Sink)
"..\src\UnsafeUniCodec.m3", line 96: warning: not used (Wch)
"..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: UniCodec.Range
"..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Wr.Failure
"..\src\UnsafeUniCodec.m3", line 105: warning: not used (Source)
"..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.EndOfFile
"..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.Failure
"..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 126: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 154: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 155: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 195: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 196: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 237: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 238: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 280: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 679: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 680: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 681: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 682: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 736: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 737: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 738: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 739: LOOPHOLE: expression's size differs from type's
16 errors and 18 warnings encountered
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/3c462f6e/attachment-0001.html>

From rcolebur at SCIRES.COM  Thu May 29 07:44:29 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 05:44:29 +0000
Subject: [M3devel] build problems with "elego\prjm"
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6F20@ATLEX04-SRV.SCIRES.LOCAL>

I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).

The "elego\prjm" package fails to build (see errors below).

I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone wants to work on a solution.

Thanks,
Randy Coleburn

--- processing package "elego\prjm" ---
--- purging derived files from NT386 ---

--- cleaning NT386 ---

ignoring ..\src\m3overrides

--- building in NT386 ---

ignoring ..\src\m3overrides

C:\cm3\bin\m3bundle -name ProjectManagerBundle -element UsageHelp ..\src\UsageHelp -element compactrc ..\src\compactrc -element ShortUsageHelp ..\src\ShortUsageHelp
new source -> compiling ProjectManagerBundle.i3
new source -> compiling ProjectManagerBundle.m3
new source -> compiling Creation.i3
new source -> compiling Creation.m3

Fatal Error: bad version stamps: TimePrjDescTbl.i3

missing export: LongrealType.T imported by TimePrjDescTbl.i3
missing export: LongrealType.Brand imported by TimePrjDescTbl.i3

WARNING:  Encountered an error when processing package "elego\prjm" for "-build".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/b2ebf95c/attachment-0001.html>

From jay.krell at cornell.edu  Thu May 29 09:26:07 2014
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 29 May 2014 07:26:07 +0000
Subject: [M3devel] build problems with "elego\prjm"
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6F20@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6F20@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL130-W811DED36FA9471989BC550E6240@phx.gbl>

This might be a "builder" incrementality problem,
related to that this module was moved from libm3
to m3core, a while ago.

I don't think we cope with such movement correctly.
 
Can you be sure to clean rebuild m3core, libm3,
and prjm, and maybe everything else?

Given the unicode problem, maybe not.
 
Thanks,
 - Jay



 
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Thu, 29 May 2014 05:44:29 +0000
Subject: [M3devel] build problems with "elego\prjm"









I?ve been rebuilding everything from the HEAD branch on Windows XP (32-bit).
 
The ?elego\prjm? package fails to build (see errors below).
 
I haven?t taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone wants to work on a solution.
 
Thanks,
Randy Coleburn
 
--- processing package "elego\prjm" ---
--- purging derived files from NT386 ---
 
--- cleaning NT386 ---
 
ignoring ..\src\m3overrides
 
--- building in NT386 ---
 
ignoring ..\src\m3overrides
 
C:\cm3\bin\m3bundle -name ProjectManagerBundle -element UsageHelp ..\src\UsageHelp -element compactrc ..\src\compactrc -element ShortUsageHelp ..\src\ShortUsageHelp
new source -> compiling ProjectManagerBundle.i3
new source -> compiling ProjectManagerBundle.m3
new source -> compiling Creation.i3
new source -> compiling Creation.m3
 
Fatal Error: bad version stamps: TimePrjDescTbl.i3
 
missing export: LongrealType.T imported by TimePrjDescTbl.i3
missing export: LongrealType.Brand imported by TimePrjDescTbl.i3
 
WARNING:  Encountered an error when processing package "elego\prjm" for "-build".
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/281f1505/attachment-0001.html>

From jay.krell at cornell.edu  Thu May 29 02:26:24 2014
From: jay.krell at cornell.edu (Jay)
Date: Wed, 28 May 2014 17:26:24 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <538629C6.9070200@marino.st>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
	<5384B209.3080504@marino.st>
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<538629C6.9070200@marino.st>
Message-ID: <310E0B12-3444-4235-9157-A677C642F5F8@gmail.com>

I'm afraid offering both will lead to disuse of one and/or double test matrix.

Btw though FreeBSD and Dragonfly -- no relationship from our point of view. 

The C backend runs on any host & whether or not it is used can be a per target decision.

 - Jay

On May 28, 2014, at 11:24 AM, John Marino <adacore at marino.st> wrote:

> On 5/28/2014 19:31, Jay K wrote:
>>> B) We want to convert FreeBSD to c-backend
>> 
>> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>> 
>>> C) There is no support for DragonFly, we want to add that
>> 
>> This is easy.
>> 
>>> D) We want to do B+C before the next release
>> 
>> C is easy. B requires a decision/consensus.
> 
> Hi Jay,
> B requires a decision if it replaces m3cc on FreeBSD.
> However if FreeBSD can keep m3cc but also be configured to build with
> C-backend, then it shouldn't need a consensus as everyone wins.
> 
> I realize that that the real question is not about FreeBSD, but rather a
> project-wide decision, however.
> 
> John


From hosking at cs.purdue.edu  Thu May 29 15:40:54 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 29 May 2014 09:40:54 -0400
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <9C6CB9C2-D5D1-4D1B-8A5F-8DCCA3F3E0FE@cs.purdue.edu>

Jay?

On May 29, 2014, at 1:40 AM, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:

> I?ve been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>  
> The m3-libs\libunicode package fails to build (see errors below).
>  
> I haven?t taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>  
> The problem module is: UnsafeUniCodec.m3
>  
> Thanks,
> Randy Coleburn
>  
> C:\cm3\Sandbox\cm3\m3-libs\libunicode>cm3
> --- building in NT386 ---
>  
> new source -> compiling UnsafeUniCodec.m3
> "..\src\UnsafeUniCodec.m3", line 81: warning: not used (Sink)
> "..\src\UnsafeUniCodec.m3", line 81: warning: not used (Wch)
> "..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: UniCodec.Range
> "..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Wr.Failure
> "..\src\UnsafeUniCodec.m3", line 88: warning: not used (Source)
> "..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.EndOfFile
> "..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.Failure
> "..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 96: warning: not used (Sink)
> "..\src\UnsafeUniCodec.m3", line 96: warning: not used (Wch)
> "..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: UniCodec.Range
> "..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Wr.Failure
> "..\src\UnsafeUniCodec.m3", line 105: warning: not used (Source)
> "..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.EndOfFile
> "..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.Failure
> "..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 126: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 154: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 155: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 195: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 196: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 237: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 238: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 280: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 679: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 680: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 681: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 682: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 736: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 737: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 738: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 739: LOOPHOLE: expression's size differs from type's
> 16 errors and 18 warnings encountered

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/df0eb5a2/attachment-0001.html>

From rodney_bates at lcwb.coop  Thu May 29 17:26:37 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 29 May 2014 10:26:37 -0500
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <538751AD.8080206@lcwb.coop>



On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> I?ve been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>
> The m3-libs\libunicode package fails to build (see errors below).
>
> I haven?t taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>
> The problem module is: UnsafeUniCodec.m3
>
> Thanks,
>
> Randy Coleburn
>

I am responsible for libunicode.

1. libunicode won't and is not designed to build unless the compiler is
    configured to make WIDECHAR have full unicode range, which, by default,
    it is not.

2. The simplest way to thus configure the compiler is to add the line
    Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
    everything, starting with m3core.

You can bootstrap all of this using the release compiler, see
cm3/scripts/README-build-unicode

I put libunicode in a separate package for that reason, and left the compiler
configured by default for the existing 16-bit range of WIDECHAR, so there
would be no perturbation to anybody's code unless you take some action.

We can change the default if there is consensus to do so.  Most code should
not be affected, but some lower-level things will be.  There is lots of info
on this subject, including what you get from it and what kinds of code might
be affected in:

cm3/README-unicode-summary
cm3/README-unicode
cm3/scripts/README-build-unicode

Rodney Bates
rodney.m.bates at acm.org


From rcolebur at SCIRES.COM  Thu May 29 22:54:55 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 20:54:55 +0000
Subject: [M3devel] build problems with libunicode
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>

Rodney:

Thanks very much for your response.

As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.

I'll take a look at your release notes.

Thanks,
Randy Coleburn

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Thursday, May 29, 2014 11:27 AM
To: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] build problems with libunicode



On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>
> The m3-libs\libunicode package fails to build (see errors below).
>
> I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>
> The problem module is: UnsafeUniCodec.m3
>
> Thanks,
>
> Randy Coleburn
>

I am responsible for libunicode.

1. libunicode won't and is not designed to build unless the compiler is
    configured to make WIDECHAR have full unicode range, which, by default,
    it is not.

2. The simplest way to thus configure the compiler is to add the line
    Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
    everything, starting with m3core.

You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode

I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.

We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:

cm3/README-unicode-summary
cm3/README-unicode
cm3/scripts/README-build-unicode

Rodney Bates
rodney.m.bates at acm.org


From rcolebur at SCIRES.COM  Thu May 29 23:37:59 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 21:37:59 +0000
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>

Rodney:

I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.

So, not sure why libunicode is trying to build on Windows (NT386).

--Randy Coleburn

-----Original Message-----
From: Coleburn, Randy 
Sent: Thursday, May 29, 2014 4:55 PM
To: m3devel at elegosoft.com
Subject: Re: [M3devel] build problems with libunicode

Rodney:

Thanks very much for your response.

As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.

I'll take a look at your release notes.

Thanks,
Randy Coleburn

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Thursday, May 29, 2014 11:27 AM
To: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] build problems with libunicode



On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>
> The m3-libs\libunicode package fails to build (see errors below).
>
> I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>
> The problem module is: UnsafeUniCodec.m3
>
> Thanks,
>
> Randy Coleburn
>

I am responsible for libunicode.

1. libunicode won't and is not designed to build unless the compiler is
    configured to make WIDECHAR have full unicode range, which, by default,
    it is not.

2. The simplest way to thus configure the compiler is to add the line
    Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
    everything, starting with m3core.

You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode

I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.

We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:

cm3/README-unicode-summary
cm3/README-unicode
cm3/scripts/README-build-unicode

Rodney Bates
rodney.m.bates at acm.org


From rcolebur at SCIRES.COM  Thu May 29 23:42:09 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 21:42:09 +0000
Subject: [M3devel] build problems with "elego\prjm"
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8AB1@ATLEX04-SRV.SCIRES.LOCAL>

Jay:

I've performed a clean rebuild of everything, but I still get the same error with "elego\prjm".
I'm also finding that "libunicode" is trying to build, yet there is no "Unicode_WIDECHAR" definition in the cm3.cfg files.
BTW, my target is NT386.

--Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, May 29, 2014 3:26 AM
To: Coleburn, Randy; m3devel
Subject: EXT:RE: [M3devel] build problems with "elego\prjm"

This might be a "builder" incrementality problem,
related to that this module was moved from libm3
to m3core, a while ago.

I don't think we cope with such movement correctly.

Can you be sure to clean rebuild m3core, libm3,
and prjm, and maybe everything else?

Given the unicode problem, maybe not.

Thanks,
 - Jay




________________________________
From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Date: Thu, 29 May 2014 05:44:29 +0000
Subject: [M3devel] build problems with "elego\prjm"
I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).

The "elego\prjm" package fails to build (see errors below).

I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone wants to work on a solution.

Thanks,
Randy Coleburn

--- processing package "elego\prjm" ---
--- purging derived files from NT386 ---

--- cleaning NT386 ---

ignoring ..\src\m3overrides

--- building in NT386 ---

ignoring ..\src\m3overrides

C:\cm3\bin\m3bundle -name ProjectManagerBundle -element UsageHelp ..\src\UsageHelp -element compactrc ..\src\compactrc -element ShortUsageHelp ..\src\ShortUsageHelp
new source -> compiling ProjectManagerBundle.i3
new source -> compiling ProjectManagerBundle.m3
new source -> compiling Creation.i3
new source -> compiling Creation.m3

Fatal Error: bad version stamps: TimePrjDescTbl.i3

missing export: LongrealType.T imported by TimePrjDescTbl.i3
missing export: LongrealType.Brand imported by TimePrjDescTbl.i3

WARNING:  Encountered an error when processing package "elego\prjm" for "-build".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/749b6377/attachment-0001.html>

From jay.krell at cornell.edu  Fri May 30 02:07:11 2014
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 30 May 2014 00:07:11 +0000
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>

Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile
 
 
do something to filter itself out from building with a compiler that won't work?
 
Can you add a builtin quake function
WideCharByteSize() or some other name
 
that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?
 
 
 
 - Jay


> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Thu, 29 May 2014 21:37:59 +0000
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.
> 
> So, not sure why libunicode is trying to build on Windows (NT386).
> 
> --Randy Coleburn
> 
> -----Original Message-----
> From: Coleburn, Randy 
> Sent: Thursday, May 29, 2014 4:55 PM
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> Thanks very much for your response.
> 
> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.
> 
> I'll take a look at your release notes.
> 
> Thanks,
> Randy Coleburn
> 
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
> Sent: Thursday, May 29, 2014 11:27 AM
> To: m3devel at elegosoft.com
> Subject: EXT:Re: [M3devel] build problems with libunicode
> 
> 
> 
> On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
> >
> > The m3-libs\libunicode package fails to build (see errors below).
> >
> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
> >
> > The problem module is: UnsafeUniCodec.m3
> >
> > Thanks,
> >
> > Randy Coleburn
> >
> 
> I am responsible for libunicode.
> 
> 1. libunicode won't and is not designed to build unless the compiler is
>     configured to make WIDECHAR have full unicode range, which, by default,
>     it is not.
> 
> 2. The simplest way to thus configure the compiler is to add the line
>     Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
>     everything, starting with m3core.
> 
> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode
> 
> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.
> 
> We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:
> 
> cm3/README-unicode-summary
> cm3/README-unicode
> cm3/scripts/README-build-unicode
> 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/d4f41ef9/attachment-0001.html>

From jay.krell at cornell.edu  Fri May 30 03:12:12 2014
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 30 May 2014 01:12:12 +0000
Subject: [M3devel] build problems with libunicode
In-Reply-To: <COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>
Message-ID: <COL130-W839E8D0F54961D3CD30386E6270@phx.gbl>

I guess Unicode_WIDECHAR = TRUE is what you picked, so:
 
if not defined("Unicode_WIDECHAR")
 Unicode_WIDECHAR = FALSE
end
in cm3cfg.common and libunicode/src/m3makefile
 
and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile?
 
 
I would have likely used a function returning byte size.
 
 
 
 - Jay

 
From: jay.krell at cornell.edu
To: rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] build problems with libunicode
Date: Fri, 30 May 2014 00:07:11 +0000




Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile
 
 
do something to filter itself out from building with a compiler that won't work?
 
Can you add a builtin quake function
WideCharByteSize() or some other name
 
that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?
 
 
 
 - Jay


> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Thu, 29 May 2014 21:37:59 +0000
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.
> 
> So, not sure why libunicode is trying to build on Windows (NT386).
> 
> --Randy Coleburn
> 
> -----Original Message-----
> From: Coleburn, Randy 
> Sent: Thursday, May 29, 2014 4:55 PM
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> Thanks very much for your response.
> 
> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.
> 
> I'll take a look at your release notes.
> 
> Thanks,
> Randy Coleburn
> 
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
> Sent: Thursday, May 29, 2014 11:27 AM
> To: m3devel at elegosoft.com
> Subject: EXT:Re: [M3devel] build problems with libunicode
> 
> 
> 
> On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
> >
> > The m3-libs\libunicode package fails to build (see errors below).
> >
> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
> >
> > The problem module is: UnsafeUniCodec.m3
> >
> > Thanks,
> >
> > Randy Coleburn
> >
> 
> I am responsible for libunicode.
> 
> 1. libunicode won't and is not designed to build unless the compiler is
>     configured to make WIDECHAR have full unicode range, which, by default,
>     it is not.
> 
> 2. The simplest way to thus configure the compiler is to add the line
>     Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
>     everything, starting with m3core.
> 
> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode
> 
> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.
> 
> We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:
> 
> cm3/README-unicode-summary
> cm3/README-unicode
> cm3/scripts/README-build-unicode
> 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/1fdba61b/attachment-0001.html>

From rcolebur at SCIRES.COM  Fri May 30 03:38:01 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 30 May 2014 01:38:01 +0000
Subject: [M3devel] build problems with libunicode
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL>

Jay / Rodney:

Well I didn't "pick" anything, but it appears that since I chose to rebuild everything based on pkginfo.txt that is why libunicode is now trying to build on my Windows box.

I have several options:

1.      Using my build scripts, I could choose to exclude libunicode (I have an option for that).

2.      We could modify the cm3.cfg and m3makefile as Jay suggests to prevent libunicode from trying to build unless Unicode_WIDECHAR is defined and TRUE.

3.      Etc.

For the short term, I think I'll try #1.
Then, I'll think about some mods for #2 and commit them if they test out.  That way, the Unicode_WIDECHAR could be used to turn this feature on and off as Rodney suggested.

For the elego\prjm package, I'm not sure whether it is supposed to be buildable on Windows.  If not, I can just exclude it, or we can modify the m3makefile to prevent it from building on Windows.  Obviously, I never used this package before.

Thanks for your help!

Thanks,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, May 29, 2014 9:12 PM
To: Coleburn, Randy; m3devel
Subject: EXT:RE: [M3devel] build problems with libunicode

I guess Unicode_WIDECHAR = TRUE is what you picked, so:

if not defined("Unicode_WIDECHAR")
 Unicode_WIDECHAR = FALSE
end
in cm3cfg.common and libunicode/src/m3makefile

and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile?


I would have likely used a function returning byte size.



 - Jay


________________________________
From: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Subject: RE: [M3devel] build problems with libunicode
Date: Fri, 30 May 2014 00:07:11 +0000
Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile


do something to filter itself out from building with a compiler that won't work?

Can you add a builtin quake function
WideCharByteSize() or some other name

that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?



 - Jay

> From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
> To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Date: Thu, 29 May 2014 21:37:59 +0000
> Subject: Re: [M3devel] build problems with libunicode
>
> Rodney:
>
> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.
>
> So, not sure why libunicode is trying to build on Windows (NT386).
>
> --Randy Coleburn
>
> -----Original Message-----
> From: Coleburn, Randy
> Sent: Thursday, May 29, 2014 4:55 PM
> To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: Re: [M3devel] build problems with libunicode
>
> Rodney:
>
> Thanks very much for your response.
>
> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.
>
> I'll take a look at your release notes.
>
> Thanks,
> Randy Coleburn
>
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop]
> Sent: Thursday, May 29, 2014 11:27 AM
> To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: EXT:Re: [M3devel] build problems with libunicode
>
>
>
> On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
> >
> > The m3-libs\libunicode package fails to build (see errors below).
> >
> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
> >
> > The problem module is: UnsafeUniCodec.m3
> >
> > Thanks,
> >
> > Randy Coleburn
> >
>
> I am responsible for libunicode.
>
> 1. libunicode won't and is not designed to build unless the compiler is
> configured to make WIDECHAR have full unicode range, which, by default,
> it is not.
>
> 2. The simplest way to thus configure the compiler is to add the line
> Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
> everything, starting with m3core.
>
> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode
>
> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.
>
> We can change the default if there is consensus to do so. Most code should not be affected, but some lower-level things will be. There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:
>
> cm3/README-unicode-summary
> cm3/README-unicode
> cm3/scripts/README-build-unicode
>
> Rodney Bates
> rodney.m.bates at acm.org<mailto:rodney.m.bates at acm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/59bbf6ba/attachment-0001.html>

From estellnb at elstel.org  Fri May 30 10:00:00 2014
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Fri, 30 May 2014 10:00:00 +0200
Subject: [M3devel] build problems with libunicode
In-Reply-To: <538751AD.8080206@lcwb.coop>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
	<538751AD.8080206@lcwb.coop>
Message-ID: <D3148A49-F24C-4F8C-ADA8-B6449DA9868D@elstel.org>


Am 29.05.2014 um 17:26 schrieb Rodney M. Bates:

> 
> I am responsible for libunicode.
> 
> 1. libunicode won't and is not designed to build unless the compiler is
>   configured to make WIDECHAR have full unicode range, which, by default,
>   it is not.
> 
> I put libunicode in a separate package for that reason, and left the compiler
> configured by default for the existing 16-bit range of WIDECHAR, so there
> would be no perturbation to anybody's code unless you take some action.
> 
> We can change the default if there is consensus to do so.  Most code should
> not be affected, but some lower-level things will be.  

Well, the program I wanna port would actually profit from both types:
* a 16-bit unicode type for interfacing with gtk & qt
* a 32-bit unicode type for the program level user input function yielding math & greek letters

Will it be possible to simply declare BITS 16 FOR WIDECHAR when unicode support is enabled?
What complications to the Text library will that cause if we have a 16-bit and a 32-bit character 
type at the same time?
What would you think about leaving WIDECHAR as 16-bit and rather introducing UCHAR as 
32-bit character type? I believe this would be the best solution as it does not break any existing
code.

Best Regards,
Elmar Stellnberger

> 
> Rodney Bates
> rodney.m.bates at acm.org
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/59d2aacc/attachment-0001.html>

From dragisha at m3w.org  Fri May 30 13:50:17 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 30 May 2014 13:50:17 +0200
Subject: [M3devel] Git, a call for participation - AGAIN
In-Reply-To: <688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF925D0BFD@ATLEX04-SRV.SCIRES.LOCAL>,
	<A297D619-A23C-4583-82DD-FED9716EC843@m3w.org>
	<C7E469CD-A4A1-4CAD-BF27-AEC6E7EE22CF@SCIRES.COM>
	<688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
Message-ID: <BBA0A7FF-4D15-47CC-A9A3-F2A34962D623@m3w.org>

I am making latest CVS repo conversion. Please send your github usernames to me.

dd

On 19 Feb 2014, at 23:34, Dragi?a Duri? <dragisha at m3w.org> wrote:

> You will need separate working directory. With git, you will have whole cm3 repository cloned in toplevel .git folder. With svn you have .svn folders around, and CVS folders with cvs.
> 
> On 19 Feb 2014, at 18:05, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
> 
>> Sorry, I should rephrase the question:  Do I need to create a separate folder tree for my local copy of the cm3 source code tree for use with Git, or can I reuse the existing folder tree that I use with CVS?
>> 
>> --Randy Coleburn
>> 
>> On Feb 19, 2014, at 2:10 AM, "Dragi?a Duri?" <dragisha at m3w.org> wrote:
>> 
>>> Email was for conversion process and it is all set-up.
>>> 
>>> Github account, and request to me (dragisha) on github for cm3 repository is separate step.
>>> 
>>> You don?t really need TortoiseGit. Github has it?s GUI shell, but everything is doable just well with Git Bash console. I will share my Git on Windows experience as we progress with migration. 
>>> 
>>> Sandbox? Meaning virtual machine or?
>>> 
>>> dd
>>> 
>>> On 18 Feb 2014, at 01:30, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>> 
>>>> I have ssh set up with existing repository.  Do I need a different ssh for the Git, or will we use the existing one?
>>>> I seem to recall providing you with my email earlier for the authors file.
>>>> I can install TortoiseGit at some point and run a test when you are ready.
>>>> BTW, do I need to create a separate sandbox for Git, or can I just reuse existing CVS sandbox?
>>>> --Randy
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 6:05 PM
>>>> To: Coleburn, Randy
>>>> Cc: m3devel
>>>> Subject: EXT:Re: [M3devel] Git, a call for participation
>>>>  
>>>> Randy,
>>>>  
>>>> You don?t need to install anything on your computer to participate in Github project. If you have ssh enabled, you are ready to go. If not, then problem can be with corporate proxies running NTLM authentication. My company enabled github and bitbucket access without NTLM so I don?t have experience solving it, but I know it is possible.
>>>>  
>>>> dd
>>>> 
>>>> On 17 Feb 2014, at 16:24, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>>> 
>>>> 
>>>> Dragi?a:
>>>>  
>>>> I am not currently a member of GitHub.  From what I understand, this site provides some social networking functionality and requires that software supporting this functionality be installed on your computer.
>>>>  
>>>> 1.      Is it possible to take advantage of Git for source code checkin/checkout WITHOUT also becoming a member of GitHub?  
>>>> If so, what, if any, are the limitations of not being a member wrt the future of the CM3 repository?
>>>> 
>>>> 
>>>> 2.      What are the security concerns with installing the GitHub software?
>>>>  
>>>> My company severely restricts use of social media (it is blocked via the various firewalls), so that may make use of GitHub more difficult in my situation.
>>>>  
>>>> I think I should be able to use TortoiseGit for source code checkin/out, since I currently use TortoiseCVS; however, I have not used TortoiseGit before, so there will be a slight learning curve for me I?m sure.
>>>>  
>>>> Thanks,
>>>> Randy Coleburn
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 2:52 AM
>>>> To: m3devel
>>>> Subject: EXT:[M3devel] Git, a call for participation
>>>>  
>>>> Hi,
>>>>  
>>>> To proceed with planned conversion, I need developers to join github and connect me there (dragisha @ github). Once we have developers connected there, we can proceed and switch.
>>>>  
>>>> TIA, 
>>>> --
>>>> Dragi?a Duri?
>>>> dragisha at m3w.org
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/a6409f28/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/a6409f28/attachment-0001.sig>

From rodney_bates at lcwb.coop  Fri May 30 19:08:26 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 30 May 2014 12:08:26 -0500
Subject: [M3devel] build problems with libunicode
In-Reply-To: <COL130-W839E8D0F54961D3CD30386E6270@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>
	<COL130-W839E8D0F54961D3CD30386E6270@phx.gbl>
Message-ID: <5388BB0A.6040603@lcwb.coop>

Hmm, fix it in the m3makefile and just not mess with the do-cm3-*.sh scripts at all.
That shouldn't be too hard.  The m3makfile could emit a loud warning that UniCodec
was not a working version.

Or maybe not build even UniCodec's interface, which would no doubt entail not building
anything in the library at all.  None of it will be of much use without full Unicode
WIDECHAR.

On 05/29/2014 08:12 PM, Jay K wrote:
> I guess Unicode_WIDECHAR = TRUE is what you picked, so:
>
> if not defined("Unicode_WIDECHAR")
>   Unicode_WIDECHAR = FALSE
> end
> in cm3cfg.common and libunicode/src/m3makefile
>
> and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile?
>
>
> I would have likely used a function returning byte size.
>
>
>
>   - Jay
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 --
> From: jay.krell at cornell.edu
> To: rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] build problems with libunicode
> Date: Fri, 30 May 2014 00:07:11 +0000
>
> Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile
>
>
> do something to filter itself out from building with a compiler that won't work?
>
> Can you add a builtin quake function
> WideCharByteSize() or some other name
>
> that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
> and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?
>
>
>
>   - Jay
>
>
-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Fri May 30 21:49:29 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 30 May 2014 14:49:29 -0500
Subject: [M3devel] No short-circuit "or" and "and" in Quake
Message-ID: <5388E0C9.1030500@lcwb.coop>

I just discovered by accident, an undocumented peculiarity in Quake.
The "or" boolean operator (and, presumably "and" too) do not have the
usual short-circuit property.  So, for example, you can't write:

if not defined("Unicode_WIDECHAR")
    or empty (Unicode_WIDECHAR)

If it's undefined, Quake will still evaluate and crash on the second
condition.


-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Fri May 30 18:39:39 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 30 May 2014 11:39:39 -0500
Subject: [M3devel] build problems with libunicode
In-Reply-To: <D3148A49-F24C-4F8C-ADA8-B6449DA9868D@elstel.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
	<538751AD.8080206@lcwb.coop>
	<D3148A49-F24C-4F8C-ADA8-B6449DA9868D@elstel.org>
Message-ID: <5388B44B.2000602@lcwb.coop>



On 05/30/2014 03:00 AM, Elmar Stellnberger wrote:
>
> Am 29.05.2014 um 17:26 schrieb Rodney M. Bates:
>
>>
>> I am responsible for libunicode.
>>
>> 1. libunicode won't and is not designed to build unless the compiler is
>>   configured to make WIDECHAR have full unicode range, which, by default,
>>   it is not.
>>
>> I put libunicode in a separate package for that reason, and left the compiler
>> configured by default for the existing 16-bit range of WIDECHAR, so there
>> would be no perturbation to anybody's code unless you take some action.
>>
>> We can change the default if there is consensus to do so.  Most code should
>> not be affected, but some lower-level things will be.
>
> Well, the program I wanna port would actually profit from both types:
> * a 16-bit unicode type for interfacing with gtk & qt
> * a 32-bit unicode type for the program level user input function yielding math & greek letters
>
> Will it be possible to simply declare BITS 16 FOR WIDECHAR when unicode support is enabled?

This would not compile, as BITS FOR must be enough bits to hold the value set of the type.
But BITS 16 FOR [FIRST(WIDECHAR)..VAL(16_FFFF),WIDECHAR] would give you what you need to
pass in and out of a library that uses a 16-bit character.  You could either keep your
characters in this type or assign back and forth between this and WIDECHAR, which would
do runtime value checks where necessary.

But do gtk and qt actually treat all characters as 16-bit fixed-size code points, or do they
actually use UTF16, with the 16-bit value being a code unit, not a code point?  In the
latter case, using UniWr and UniRd to do the encoding/decoding would be a much cleaner
option.

> What complications to the Text library will that cause if we have a 16-bit and a 32-bit character
> type at the same time?

The Text library already has two sizes: CHAR (8) and WIDECHAR (either 16 or 32).  A third would require more
code.  Pickles and network objects would need quite a bit of additional code, and they are quite
a bit more complicated than Text, because they have to handle values written by different compilers.

> What would you think about leaving WIDECHAR as 16-bit and rather introducing UCHAR as
> 32-bit character type? I believe this would be the best solution as it does not break any existing
> code.
>
> Best Regards,
> Elmar Stellnberger
>
>>
>> Rodney Bates
>> rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>
>>
>

-- 
Rodney Bates
rodney.m.bates at acm.org


From dragisha at m3w.org  Fri May 30 22:48:31 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 30 May 2014 22:48:31 +0200
Subject: [M3devel] Git, a call for participation
In-Reply-To: <688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF925D0BFD@ATLEX04-SRV.SCIRES.LOCAL>,
	<A297D619-A23C-4583-82DD-FED9716EC843@m3w.org>
	<C7E469CD-A4A1-4CAD-BF27-AEC6E7EE22CF@SCIRES.COM>
	<688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
Message-ID: <610A2ACE-7BE8-4546-98AB-7690D7CC010B@m3w.org>

My plan:

* Do a conversion to Git, place it on github.
* As m3devel people identify/communicate with me on github, access rights will be granted one by one.
* Alternatively we can use pull-request mechanism. We can also extend jenkins to do non-canonical builds/testing. Canonical being a master branch of repo from first item.
* Install Jenkins on my server box, connect to donated slave instances, do builds, distribute results over some (yet undefined) public server. I don?t have bandwidth for big file distribution.
* Move pieces to better locations, as they become available.

Any suggestions?

On 19 Feb 2014, at 23:34, Dragi?a Duri? <dragisha at m3w.org> wrote:

> You will need separate working directory. With git, you will have whole cm3 repository cloned in toplevel .git folder. With svn you have .svn folders around, and CVS folders with cvs.
> 
> On 19 Feb 2014, at 18:05, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
> 
>> Sorry, I should rephrase the question:  Do I need to create a separate folder tree for my local copy of the cm3 source code tree for use with Git, or can I reuse the existing folder tree that I use with CVS?
>> 
>> --Randy Coleburn
>> 
>> On Feb 19, 2014, at 2:10 AM, "Dragi?a Duri?" <dragisha at m3w.org> wrote:
>> 
>>> Email was for conversion process and it is all set-up.
>>> 
>>> Github account, and request to me (dragisha) on github for cm3 repository is separate step.
>>> 
>>> You don?t really need TortoiseGit. Github has it?s GUI shell, but everything is doable just well with Git Bash console. I will share my Git on Windows experience as we progress with migration. 
>>> 
>>> Sandbox? Meaning virtual machine or?
>>> 
>>> dd
>>> 
>>> On 18 Feb 2014, at 01:30, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>> 
>>>> I have ssh set up with existing repository.  Do I need a different ssh for the Git, or will we use the existing one?
>>>> I seem to recall providing you with my email earlier for the authors file.
>>>> I can install TortoiseGit at some point and run a test when you are ready.
>>>> BTW, do I need to create a separate sandbox for Git, or can I just reuse existing CVS sandbox?
>>>> --Randy
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 6:05 PM
>>>> To: Coleburn, Randy
>>>> Cc: m3devel
>>>> Subject: EXT:Re: [M3devel] Git, a call for participation
>>>>  
>>>> Randy,
>>>>  
>>>> You don?t need to install anything on your computer to participate in Github project. If you have ssh enabled, you are ready to go. If not, then problem can be with corporate proxies running NTLM authentication. My company enabled github and bitbucket access without NTLM so I don?t have experience solving it, but I know it is possible.
>>>>  
>>>> dd
>>>> 
>>>> On 17 Feb 2014, at 16:24, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>>> 
>>>> 
>>>> Dragi?a:
>>>>  
>>>> I am not currently a member of GitHub.  From what I understand, this site provides some social networking functionality and requires that software supporting this functionality be installed on your computer.
>>>>  
>>>> 1.      Is it possible to take advantage of Git for source code checkin/checkout WITHOUT also becoming a member of GitHub?  
>>>> If so, what, if any, are the limitations of not being a member wrt the future of the CM3 repository?
>>>> 
>>>> 
>>>> 2.      What are the security concerns with installing the GitHub software?
>>>>  
>>>> My company severely restricts use of social media (it is blocked via the various firewalls), so that may make use of GitHub more difficult in my situation.
>>>>  
>>>> I think I should be able to use TortoiseGit for source code checkin/out, since I currently use TortoiseCVS; however, I have not used TortoiseGit before, so there will be a slight learning curve for me I?m sure.
>>>>  
>>>> Thanks,
>>>> Randy Coleburn
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 2:52 AM
>>>> To: m3devel
>>>> Subject: EXT:[M3devel] Git, a call for participation
>>>>  
>>>> Hi,
>>>>  
>>>> To proceed with planned conversion, I need developers to join github and connect me there (dragisha @ github). Once we have developers connected there, we can proceed and switch.
>>>>  
>>>> TIA, 
>>>> --
>>>> Dragi?a Duri?
>>>> dragisha at m3w.org
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/3f720996/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/3f720996/attachment-0001.sig>

From jay.krell at cornell.edu  Sat May 31 01:13:48 2014
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 30 May 2014 23:13:48 +0000
Subject: [M3devel] No short-circuit "or" and "and" in Quake
In-Reply-To: <5388E0C9.1030500@lcwb.coop>
References: <5388E0C9.1030500@lcwb.coop>
Message-ID: <COL130-W31F76F5445BA76A31EA982E6270@phx.gbl>

Yes, I know, it is unfortunate and counterintuitive. I workaround it all the time.
 
 - Jay

 
> Date: Fri, 30 May 2014 14:49:29 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: [M3devel] No short-circuit "or" and "and" in Quake
> 
> I just discovered by accident, an undocumented peculiarity in Quake.
> The "or" boolean operator (and, presumably "and" too) do not have the
> usual short-circuit property.  So, for example, you can't write:
> 
> if not defined("Unicode_WIDECHAR")
>     or empty (Unicode_WIDECHAR)
> 
> If it's undefined, Quake will still evaluate and crash on the second
> condition.
> 
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/907ee3a4/attachment-0001.html>

From wagner at elegosoft.com  Sat May 31 10:50:03 2014
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 31 May 2014 10:50:03 +0200
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <20140531105003.c365f974ec13b9f47b5fda34@elegosoft.com>

On Fri, 30 May 2014 01:38:01 +0000
"Coleburn, Randy" <rcolebur at SCIRES.COM> wrote:

> Jay / Rodney:
> 
> For the elego\prjm package, I'm not sure whether it is supposed to be buildable on Windows.  If not, I can just exclude it, or we can modify the m3makefile to prevent it from building on Windows.  Obviously, I never used this package before.

All the packages from Elego used to build on Windows, Linux, BSD
and Solaris platforms. However, I don't think anything depends
on this that you will need so you should be safe to exclude
all the stuff in the elego directory.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


From wagner at elegosoft.com  Sat May 31 11:38:52 2014
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 31 May 2014 11:38:52 +0200
Subject: [M3devel] CVS to GIT migration -- shutdown of elego's CVS services
	for M3
Message-ID: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com>

Hello all,

with the possibility of the CM3 project being hosted on Github,
where it can be continued safely and with much more and better
hardware resources than elego could ever provide, elego will
stop providing the legacy CVS service for the source code as
soon as possible. This does not mean that we will stop all of
our support, and we certainly won't remove access to the sources
before easy access to them at another provider is established.
But we would like to urge all the developers to help with the
migration and ensure that the use and development of Modula-3
will continue as seamlessly as possible.

The WWW service can stay online some time longer, though
I think all the stuff available there should be reviewed
and moved to a Wiki with easy access for all the developers.

13 months ago I set up this Wiki page at the M3 Trac
instance to allocate all the things that I thought should
be done and considered, but nobody else has contributed
to that, so that has probably not been the right approach: 

https://cm3-bugs.elegosoft.com/cm3/wiki/CvsToGitMigration

However, I think a clean migration to git should be no
big problem, and it should also improve the visibility
and ease of use of the assets, so it will be all for the
best of the project.

Some personal notes:

After the huge amount of time I spent in preparing, testing
and bundling the last release of CM3 several years ago,
I was not able to sustain any noticable contribution to
the M3 development. Both private and business matters
claimed so much attention that I was not able to provide
the necessary time to even keep all the infrastructure
-- WWW, scripts, CI etc. -- in proper and usable shape.
And I'm afraid that this won't change soon, so there is
no hope for much contribution from my side for the
foreseeable future. 

I would dearly like to see the use of Modula-3 spread and
the project prosper and thrive and I'll try to support
this as much as I can. Embarrassing desasters like
heartbleed could easily have been prevented by the use
of Modula-3 or the application of the sound principles
and techniques that are its base. I still believe that
using a safe language for large projects should be a
inevitable decision from an engineering point of view,
but keeping the users and developers of M3 in a kind of
enclave won't help in the large run.

So please see my decision to discontinue the repository
support as a friendly push to start moving in the right
direction.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


From schlepptop at henning-thielemann.de  Sat May 31 11:53:19 2014
From: schlepptop at henning-thielemann.de (Henning Thielemann)
Date: Sat, 31 May 2014 11:53:19 +0200
Subject: [M3devel] CVS to GIT migration -- shutdown of elego's CVS
 services for M3
In-Reply-To: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com>
References: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com>
Message-ID: <5389A68F.1070003@henning-thielemann.de>

Am 31.05.2014 11:38, schrieb Olaf Wagner:

> The WWW service can stay online some time longer, though
> I think all the stuff available there should be reviewed
> and moved to a Wiki with easy access for all the developers.

Btw. I like Wikis that you can edit offline, like gitit.



From bruce.axtens at gmail.com  Sat May 31 16:05:49 2014
From: bruce.axtens at gmail.com (Bruce M. Axtens)
Date: Sat, 31 May 2014 22:05:49 +0800
Subject: [M3devel] Problem building on Win7
In-Reply-To: <53898228.9010807@elego.de>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>	<5384B209.3080504@marino.st>	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>	<5385A122.4020205@marino.st>	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>	<20140528182503.087801A2095@async.async.caltech.edu>	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>	<20140528203218.658CC1A2096@async.async.caltech.edu>	<5386B98C.7040904@gmail.com>
	<CAA4N+4aiaLGcbJ3GwhyAtbkOWELHQ=fvR4xMSFOMe2RD9y7foA@mail.gmail.com>
	<53898228.9010807@elego.de>
Message-ID: <5389E1BD.4030603@gmail.com>

G'day everyone

I downloaded cm3-bin-core-NT386-5.8.6-REL.tgz and ran cminstall.exe. I 
then changed directory to c:\cm3\examples\hello\src and tried to build 
the example, viz

    C:\cm3\examples\hello\src>cm3
    --- building in ..\NT386 ---

    new source -> compiling Hello.m3
      -> linking hello.exe
    "C:\cm3\bin/config\NT386.common", line 969: quake runtime error:
    link failed, see C:\cm3\examples\hello\NT386\hello.lst for more
    information


    --procedure--  -line-  -file---
    error              --  <builtin>
    m3_link           969  C:\cm3\bin/config\NT386.common
    program            --  <builtin>
    include_dir        27 C:\cm3\examples\hello\src\m3makefile
                         4 C:\cm3\examples\hello\NT386\m3make.args


    Fatal Error: procedure "m3_link" defined in "C:\cm3\bin\cm3.cfg" failed.


    C:\cm3\examples\hello\src>type ..\NT386\hello.lst
    Microsoft (R) Incremental Linker Version 10.00.40219.01
    Copyright (C) Microsoft Corporation.  All rights reserved.

    -out:hello.exe
    -subsystem:console
    -entry:mainCRTStartup
    -nodefaultlib
    -debug
    -incremental:no
    -opt:ref
    -delayload:wsock32.dll
    -delayload:advapi32.dll
    -delayload:gdi32.dll
    -delayload:netapi32.dll
    -delayload:user32.dll
    -delayload:comctl32.dll
    delayimp.lib
    _m3main.obj
    Hello.mo
    C:\cm3\pkg\libm3\NT386\m3.lib
    C:\cm3\pkg\m3core\NT386\m3core.lib
    winspool.lib
    comctl32.lib
    wsock32.lib
    comdlg32.lib
    netapi32.lib
    gdi32.lib
    user32.lib
    advapi32.lib
    kernel32.lib
    msvcrt.lib
    C:\cm3\bin\..\lib\hand.obj
    LINK : fatal error LNK1181: cannot open input file 'delayimp.lib'

delayimp.lib is nowhere to be found in the c:\cm3 tree. So I downloaded 
the CVS tree in the expectation that I'd find it in there, but It's NOT 
there.

Where do I go from here?

Kind regards,
Bruce M. Axtens


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/2039f6b6/attachment-0001.html>

From bruce.axtens at gmail.com  Sat May 31 16:33:50 2014
From: bruce.axtens at gmail.com (Bruce M. Axtens)
Date: Sat, 31 May 2014 22:33:50 +0800
Subject: [M3devel] Starting out with CM3
In-Reply-To: <53893F74.1040608@gmail.com>
References: <53893F74.1040608@gmail.com>
Message-ID: <5389E84E.10407@gmail.com>

G'day everyone

I've slurped down the full CVS tree. How do I build for Windows 7 ... 
from scratch? Is there a readme/faq for this somewhere?

Kind regards,
Bruce.





From bruce.axtens at gmail.com  Sat May 31 16:34:47 2014
From: bruce.axtens at gmail.com (Bruce M. Axtens)
Date: Sat, 31 May 2014 22:34:47 +0800
Subject: [M3devel] Starting out with CM3
In-Reply-To: <53893F74.1040608@gmail.com>
References: <53893F74.1040608@gmail.com>
Message-ID: <5389E887.5050405@gmail.com>

Oh and while I'm at it, seeing as I have a recent MinGW here, how do I 
build for MinGW?

Bruce.



From jay.krell at cornell.edu  Sat May 31 18:47:34 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:47:34 +0000
Subject: [M3devel] Problem building on Win7
In-Reply-To: <5389E1BD.4030603@gmail.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>	<5384B209.3080504@marino.st>
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<20140528182503.087801A2095@async.async.caltech.edu>
	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
	<20140528203218.658CC1A2096@async.async.caltech.edu>
	<5386B98C.7040904@gmail.com>,
	<CAA4N+4aiaLGcbJ3GwhyAtbkOWELHQ=fvR4xMSFOMe2RD9y7foA@mail.gmail.com>,
	<53898228.9010807@elego.de>, <5389E1BD.4030603@gmail.com>
Message-ID: <COL130-W931C4DEDBF0FDA3E034326E6260@phx.gbl>

delayimp.lib comes with Visual C++. We could without it though.
i.e. remove it and all the:
-delayload:wsock32.dll
-delayload:advapi32.dll
-delayload:gdi32.dll
-delayload:netapi32.dll
-delayload:user32.dll
-delayload:comctl32.dll
 
will work, albeit with extra .dll loads.

- Jay
 
Date: Sat, 31 May 2014 22:05:49 +0800
From: bruce.axtens at gmail.com
To: m3devel at elegosoft.com
Subject: [M3devel] Problem building on Win7


  
    
  
  
    G'day everyone

    
      
         

          I downloaded cm3-bin-core-NT386-5.8.6-REL.tgz and ran
          cminstall.exe. I then changed directory to
          c:\cm3\examples\hello\src and tried to build the example, viz

          C:\cm3\examples\hello\src>cm3

                --- building in ..\NT386 ---

                

                new source -> compiling Hello.m3

                 -> linking hello.exe

                "C:\cm3\bin/config\NT386.common", line 969: quake
                runtime error: link failed, see
                C:\cm3\examples\hello\NT386\hello.lst for more
                information

                

                

                --procedure--  -line-  -file---

                error              --  <builtin>

                m3_link           969  C:\cm3\bin/config\NT386.common

                program            --  <builtin>

                include_dir        27 
                C:\cm3\examples\hello\src\m3makefile

                                    4 
                C:\cm3\examples\hello\NT386\m3make.args

                

                

                Fatal Error: procedure "m3_link" defined in
                "C:\cm3\bin\cm3.cfg" failed.

                

                

                C:\cm3\examples\hello\src>type ..\NT386\hello.lst

                Microsoft (R) Incremental Linker Version 10.00.40219.01

                Copyright (C) Microsoft Corporation.  All rights
                reserved.

                

                -out:hello.exe

                -subsystem:console

                -entry:mainCRTStartup

                -nodefaultlib

                -debug

                -incremental:no

                -opt:ref

                -delayload:wsock32.dll

                -delayload:advapi32.dll

                -delayload:gdi32.dll

                -delayload:netapi32.dll

                -delayload:user32.dll

                -delayload:comctl32.dll

                delayimp.lib

                _m3main.obj

                Hello.mo

                C:\cm3\pkg\libm3\NT386\m3.lib

                C:\cm3\pkg\m3core\NT386\m3core.lib

                winspool.lib

                comctl32.lib

                wsock32.lib

                comdlg32.lib

                netapi32.lib

                gdi32.lib

                user32.lib

                advapi32.lib

                kernel32.lib

                msvcrt.lib

                C:\cm3\bin\..\lib\hand.obj

                LINK : fatal error LNK1181: cannot open input file
                'delayimp.lib'

            

          
          delayimp.lib is nowhere to be found in the c:\cm3 tree. So I
          downloaded the CVS tree in the expectation that I'd find it in
          there, but It's NOT there. 

          

          Where do I go from here?

          

          Kind regards,

          Bruce M. Axtens

          

        
      
      

     		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/d8852449/attachment-0001.html>

From jay.krell at cornell.edu  Sat May 31 18:53:14 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:53:14 +0000
Subject: [M3devel] Starting out with CM3
In-Reply-To: <5389E84E.10407@gmail.com>
References: <53893F74.1040608@gmail.com>,<5389E84E.10407@gmail.com>
Message-ID: <COL130-W2D53D27D3ED6A677231B9E6260@phx.gbl>

You have to start with a minimal working toolset: cm3, m3core, libm3, C compiler/linker.
And then scripts/python/upgrade.py && scripts/python/do-cm3-all.py.
Optionally you can cross-build to start -- but still need working cm3 on host, and C compiler/linker, preferably on target.
 
 - Jay

 
> Date: Sat, 31 May 2014 22:33:50 +0800
> From: bruce.axtens at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Starting out with CM3
> 
> G'day everyone
> 
> I've slurped down the full CVS tree. How do I build for Windows 7 ... 
> from scratch? Is there a readme/faq for this somewhere?
> 
> Kind regards,
> Bruce.
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/abc9934d/attachment-0001.html>

From jay.krell at cornell.edu  Sat May 31 18:53:23 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:53:23 +0000
Subject: [M3devel] Starting out with CM3
In-Reply-To: <5389E84E.10407@gmail.com>
References: <53893F74.1040608@gmail.com>,<5389E84E.10407@gmail.com>
Message-ID: <COL130-W2E7FA119353D9CCFA0AD4E6260@phx.gbl>

You have to start with a minimal working toolset: cm3, m3core, libm3, C compiler/linker.
And then scripts/python/upgrade.py && scripts/python/do-cm3-all.py.
Optionally you can cross-build to start -- but still need working cm3 on host, and C compiler/linker, preferably on target.
 
 - Jay

 
> Date: Sat, 31 May 2014 22:33:50 +0800
> From: bruce.axtens at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Starting out with CM3
> 
> G'day everyone
> 
> I've slurped down the full CVS tree. How do I build for Windows 7 ... 
> from scratch? Is there a readme/faq for this somewhere?
> 
> Kind regards,
> Bruce.
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/b81e477c/attachment-0001.html>

From jay.krell at cornell.edu  Sat May 31 18:53:25 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:53:25 +0000
Subject: [M3devel] Starting out with CM3
In-Reply-To: <5389E84E.10407@gmail.com>
References: <53893F74.1040608@gmail.com>,<5389E84E.10407@gmail.com>
Message-ID: <COL130-W2AEDFC48A2FB8E4FD5367E6260@phx.gbl>

You have to start with a minimal working toolset: cm3, m3core, libm3, C compiler/linker.
And then scripts/python/upgrade.py && scripts/python/do-cm3-all.py.
Optionally you can cross-build to start -- but still need working cm3 on host, and C compiler/linker, preferably on target.
 
 - Jay

 
> Date: Sat, 31 May 2014 22:33:50 +0800
> From: bruce.axtens at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Starting out with CM3
> 
> G'day everyone
> 
> I've slurped down the full CVS tree. How do I build for Windows 7 ... 
> from scratch? Is there a readme/faq for this somewhere?
> 
> Kind regards,
> Bruce.
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/a8619162/attachment-0001.html>

From dragisha at m3w.org  Sat May 31 21:56:13 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 31 May 2014 21:56:13 +0200
Subject: [M3devel] Git synchronized to CVS@May30
Message-ID: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>

https://github.com/dragisha/cm3

Please let me have your usernames on github.

I am continuing now through Jenkins setup. I hope to have few platforms happily building from tomorrow on.

dd



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/781db7e3/attachment-0001.sig>

From dragisha at m3w.org  Sat May 31 23:01:17 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 31 May 2014 23:01:17 +0200
Subject: [M3devel] Git synchronized to CVS@May30
In-Reply-To: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>
References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>
Message-ID: <F952131C-30FB-47CA-BEC4-9888B76E7ABA@m3w.org>

I have added Rodney and Anthony for now. And I am waiting for few other people to give me exact data. And everybody else to give me any data :)

What I need is short form show on github, to be sure it is you I am adding. Thanks in advance!

dd

On 31 May 2014, at 21:56, Dragi?a Duri? <dragisha at m3w.org> wrote:

> https://github.com/dragisha/cm3
> 
> Please let me have your usernames on github.
> 
> I am continuing now through Jenkins setup. I hope to have few platforms happily building from tomorrow on.
> 
> dd
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/90ad439d/attachment-0001.sig>

From dragisha at m3w.org  Thu May  1 19:49:28 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 1 May 2014 19:49:28 +0200
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <535FA2B2.70108@gmail.com>
References: <535FA2B2.70108@gmail.com>
Message-ID: <A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>

It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.
--
Dragi?a Duri?
dragisha at m3w.org



On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:

> I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty? When I try to install it with Ubuntu Software Centre I get told the following:
> 
> Lintian check results for /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:
> Can't use an undefined value as an ARRAY reference at /usr/share/perl5/
> Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.
> 
> Is this a Perl issue or an installer issue?
> 
> -- Bruce
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140501/835298de/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140501/835298de/attachment-0002.sig>

From rcolebur at SCIRES.COM  Sat May 24 06:57:36 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 24 May 2014 04:57:36 +0000
Subject: [M3devel] compilation problems with assertions in RTCollector.m3
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF9269F8F6@ATLEX04-SRV.SCIRES.LOCAL>

I updated my sandbox to be current with the HEAD branch via CVS, then tried to rebuild everything.

I first built a minimal distribution on Windows XP.  Everything seemed to work fine.

Now, using my newly rebuilt cm3.exe, I decided to rebuild everything.  Unfortunately, now I'm running into problems even in the first stage.

Here are some examples of the errors I am getting.  These runtime errors happen compiling various packages.  (I've tried rebuilding several times.)

I show 3 separate incidents below and the last one has a partial stack trace.  In each case, there is an assertion failure in the RTCollector while running the compiler:

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 699
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x12f374   0x6ca19e  CleanBetween + 0x22 in ..\src\runtime\common\RTCollector.m3
0x12f3ac   0x6ca031  CopySome + 0xeb in ..\src\runtime\common\RTCollector.m3
0x12f3b8   0x6c9b02  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3
0x12f3c8   0x6c94d6  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3
0x12f40c   0x6c916a  CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3
0x12f44c   0x6dc586  AllocTraced + 0xd3 in ..\src\runtime\common\RTAllocator.m3
0x12f480   0x6dbbd8  GetTracedObj + 0x86 in ..\src\runtime\common\RTAllocator.m3
0x12f49c   0x6db70c  AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3
0x12f4d0   0x529913  Init_chars + 0x20b in ..\src\misc\CG.m3
0x12f4f8   0x4f948b  Init_chars + 0xb9 in ..\src\misc\M3String.m3
.........  .........  ... more frames ...

WARNING:  Encountered an error when processing package "m3-sys\m3front" for "-build".

Any help in solving this problem would be appreciated.

Thanks,
Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140524/2b9cb0f6/attachment-0002.html>

From wagner at elegosoft.com  Sun May 25 18:36:16 2014
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 25 May 2014 18:36:16 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
Message-ID: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>

On Sun, 25 May 2014 22:35:09 +0800
Bruce Axtens <bruce.axtens at gmail.com> wrote:

> Dear Sir
> 
> Should I assume that CM3 is alive, in palliative care or dead? The trac
> system is full of spam and the roadmap hasn't moved for 3 years.
> 
> I had a long and fruitful relationship with Modula-2 years ago and thought
> that perhaps I could restart things with CM3.

There is certainly some activity in M3 development recently, though
the community is rather small.
The trac system has never been much used by the community members;
and the WWW presentation and regression testing system has lacked
my support, as I couldn't spent any time on these topics for
almost 3 years.

You should check the m3devel mailing list for news though:
https://mail.elegosoft.com/pipermail/m3devel

There has been a lot of activity at the beginning of this year;
it has ceased again during recent weeks.

All CVS commits can be found here:
https://mail.elegosoft.com/pipermail/m3commit

A new release is long overdue; I'm afraid I cannot do the release
engineering this time.

There has been some effort on moving the CVS repositories to git;
I'm not sure what the status is there, too.

Any help wrt. documentation, presentation or software is greatly
appreciated ;-)

Regards,

Olaf Wagner
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


From mika at async.caltech.edu  Mon May 26 21:22:46 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 12:22:46 -0700
Subject: [M3devel] problems on FreeBSD 10.0-RELEASE
Message-ID: <20140526192247.0A2D71A209C@async.async.caltech.edu>

Hi m3devel,

The usual story.. new computer, new OS, trying to set up CM3.

I installed the binary snapshot 

cm3-bin-core-AMD64_FREEBSD-d5.9.0-x86_64-unknown-freebsd8.3-2013-10-15-17-59-51.tgz

cvs synced against current as of today

ran ./upgrade.sh and got various errors.  (See below.)  Versions...

root at pluto:/home/mika/cm3/cm3/scripts # uname -a
FreeBSD pluto 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

root at pluto:/home/mika/cm3/cm3/scripts # gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc47/gcc/x86_64-portbld-freebsd10.0/4.7.3/lto-wrapper
Target: x86_64-portbld-freebsd10.0
Configured with: ./../gcc-4.7.3/configure --disable-bootstrap --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc47 --libexecdir=/usr/local/libexec/gcc47 --program-suffix=47 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc47/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc47 --build=x86_64-portbld-freebsd10.0
Thread model: posix
gcc version 4.7.3 (FreeBSD Ports Collection) 
root at pluto:/home/mika/cm3/cm3/scripts # 

Any ideas?  It looks like gcc is having trouble compiling gcc?

     Mika


build/gcov-iov '4.7.1' '' \
    > tmp-gcov-iov.h
/bin/sh ../../gcc-4.7/gcc/../move-if-change tmp-gcov-iov.h gcov-iov.h
echo timestamp > s-iov
gcc -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7/gcc -I../../gcc-4.7/gcc/. -I../../gcc-4.7/gcc/../include -I../../gcc-4.7/gcc/../libcpp/include -I/usr/local/include ../../gcc-4.7/gcc/attribs.c -o attribs.o
gcc -c   -g -O2 -DIN_GCC  -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7/gcc -I../../gcc-4.7/gcc/. -I../../gcc-4.7/gcc/../include -I../../gcc-4.7/gcc/../libcpp/include -I/usr/local/include ../../gcc-4.7/gcc/main.c -o main.o
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:46:
In file included from ../../gcc-4.7/gcc/tree.h:30:
../../gcc-4.7/gcc/statistics.h:48:46: error: reference to 'function' is ambiguous
extern void statistics_counter_event (struct function *, const char *, int);
                                             ^
../../gcc-4.7/gcc/statistics.h:41:8: note: candidate found by name lookup is 'function'
struct function;
       ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:46:
In file included from ../../gcc-4.7/gcc/tree.h:30:
../../gcc-4.7/gcc/statistics.h:49:48: error: reference to 'function' is ambiguous
extern void statistics_histogram_event (struct function *, const char *, int);
                                               ^
../../gcc-4.7/gcc/statistics.h:41:8: note: candidate found by name lookup is 'function'
struct function;
       ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
gcc -c   -g -O2 -DIN_GCC  -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7/gcc -I../../gcc-4.7/gcc/. -I../../gcc-4.7/gcc/../include -I../../gcc-4.7/gcc/../libcpp/include -I/usr/local/include ../../gcc-4.7/gcc/tree-browser.c -o tree-browser.o
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:46:
../../gcc-4.7/gcc/tree.h:3547:10: error: reference to 'function' is ambiguous
  struct function *f;
         ^
../../gcc-4.7/gcc/tree.h:2653:8: note: candidate found by name lookup is 'function'
struct function;
       ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:643:24: error: reference to 'function' is ambiguous
add_local_decl (struct function *fun, tree d)
                       ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:657:23: error: reference to 'function' is ambiguous
extern GTY(()) struct function *cfun;
                      ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:693:30: error: reference to 'function' is ambiguous
extern void set_cfun (struct function *new_cfun);
                             ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:694:31: error: reference to 'function' is ambiguous
extern void push_cfun (struct function *new_cfun);
                              ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:732:40: error: reference to 'function' is ambiguous
extern void free_after_parsing (struct function *);
                                       ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:733:44: error: reference to 'function' is ambiguous
extern void free_after_compilation (struct function *);
                                           ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:764:50: error: reference to 'function' is ambiguous
extern bool optimize_function_for_size_p (struct function *);
                                                 ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
In file included from ../../gcc-4.7/gcc/basic-block.h:26:
../../gcc-4.7/gcc/function.h:765:51: error: reference to 'function' is ambiguous
extern bool optimize_function_for_speed_p (struct function *);
                                                  ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:53:
In file included from ../../gcc-4.7/gcc/gimple.h:32:
../../gcc-4.7/gcc/basic-block.h:779:31: error: reference to 'function' is ambiguous
extern void init_flow (struct function *);
                              ^../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:59:
../../gcc-4.7/gcc/output.h:137:6: warning: 'format' attribute argument not supported: __asm_fprintf__ [-Wignored-attributes]
     ATTRIBUTE_ASM_FPRINTF(2, 3);
     ^
../../gcc-4.7/gcc/output.h:123:53: note: expanded from macro 'ATTRIBUTE_ASM_FPRINTF'
#define ATTRIBUTE_ASM_FPRINTF(m, n) __attribute__ ((__format__ (__asm_fprintf__, m, n))) ATTRIBUTE_NONNULL(m)
                                                    ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:63:
../../gcc-4.7/gcc/langhooks-def.h:40:38: error: reference to 'function' is ambiguous
extern void lhd_do_nothing_f (struct function *);
                                     ^
../../gcc-4.7/gcc/function.h:503:16: note: candidate found by name lookup is 'function'
struct GTY(()) function {
               ^
/usr/include/c++/v1/__functional_03:206:44: note: candidate found by name lookup is 'std::__1::function'
template<class _Fp> class _LIBCPP_TYPE_VIS function; // undefined
                                           ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:69:
In file included from ../../gcc-4.7/gcc/expr.h:28:
In file included from ../../gcc-4.7/gcc/rtl.h:2244:
./genrtl.h:385:3: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
  XWINT (rt, 1) = arg1;
  ^          ~
../../gcc-4.7/gcc/rtl.h:633:29: note: expanded from macro 'XWINT'
#define XWINT(RTX, N)               ((RTX)->u.hwint[N])
                                     ^
../../gcc-4.7/gcc/rtl.h:344:5: note: array 'hwint' declared here
    HOST_WIDE_INT hwint[1];
    ^
../../gcc-4.7/gcc/hwint.h:64:26: note: expanded from macro 'HOST_WIDE_INT'
#   define HOST_WIDE_INT long
                         ^
In file included from ../../gcc-4.7/gcc/m3cg/parse.c:69:
In file included from ../../gcc-4.7/gcc/expr.h:28:
In file included from ../../gcc-4.7/gcc/rtl.h:2244:
./genrtl.h:386:3: warning: array index 2 is past the end of the array (which contains 1 element) [-Warray-bounds]
  XWINT (rt, 2) = arg2;
  ^          ~
../../gcc-4.7/gcc/rtl.h:633:29: note: expanded from macro 'XWINT'
#define XWINT(RTX, N)               ((RTX)->u.hwint[N])
                                     ^
../../gcc-4.7/gcc/rtl.h:344:5: note: array 'hwint' declared here
    HOST_WIDE_INT hwint[1];
    ^../../gcc-4.7/gcc/hwint.h:64:26: note: expanded from macro 'HOST_WIDE_INT'
#   define HOST_WIDE_INT long
                         ^
3 warnings and 13 errors generated.
gmake: *** [m3cg/parse.o] Error 1
gmake: *** Waiting for unfinished jobs....
/bin/sh ../../gcc-4.7/gcc/../move-if-change tmp-attrtab.c insn-attrtab.c
echo timestamp > s-attrtab
/bin/sh ../../gcc-4.7/gcc/../move-if-change tmp-automata.c insn-automata.c
echo timestamp > s-automata
"/usr/home/mika/cm3/cm3/m3-sys/m3cc/src/m3makefile", line 327: quake runtime error: exit 2: cd ../AMD64_FREEBSD && cd gcc && gmake  MAKE="gmake -j4  "  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: -j4  s-modes insn-config.h m3cg

--procedure--  -line-  -file---
exec               --  <builtin>
m3cc_Run          327  /usr/home/mika/cm3/cm3/m3-sys/m3cc/src/m3makefile
include_dir       577  /usr/home/mika/cm3/cm3/m3-sys/m3cc/src/m3makefile
                    6  /usr/home/mika/cm3/cm3/m3-sys/m3cc/AMD64_FREEBSD/m3make.args

Fatal Error: package build failed
 ==> /home/mika/cm3/cm3/m3-sys/m3cc done

Critical Mass Modula-3 version d5.9.0
  last updated: 2010-07-21
  compiled: 2014-05-26 19:11:28
  configuration: /usr/local/cm3/bin/cm3.cfg
  host: AMD64_FREEBSD
quake runtime error: "/usr/local/cm3/bin/cm3.cfg", line 2: quake runtime error: undefined variable: SL

--procedure--  -line-  -file---
                    2  /usr/local/cm3/bin/cm3.cfg
  target: 

./upgrade.sh: /home/mika/cm3/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg: not found
root at pluto:/home/mika/cm3/cm3/scripts # 



From adacore at marino.st  Mon May 26 21:37:55 2014
From: adacore at marino.st (John Marino)
Date: Mon, 26 May 2014 21:37:55 +0200
Subject: [M3devel] problems on FreeBSD 10.0-RELEASE
In-Reply-To: <20140526192247.0A2D71A209C@async.async.caltech.edu>
References: <20140526192247.0A2D71A209C@async.async.caltech.edu>
Message-ID: <53839813.3020406@marino.st>

On 5/26/2014 21:22, mika at async.caltech.edu wrote:
> Hi m3devel,
> 
> The usual story.. new computer, new OS, trying to set up CM3.
> 
> I installed the binary snapshot 
> 
> cm3-bin-core-AMD64_FREEBSD-d5.9.0-x86_64-unknown-freebsd8.3-2013-10-15-17-59-51.tgz
> 
> cvs synced against current as of today
> 

Did you know that modula3 is can be built from ports or installed as a
prebuilt binary on FreeBSD?

http://www.freshports.org/lang/modula3


If you don't need the binary snapshot specifically, maybe the ports M3
is good enough.

John


From mika at async.caltech.edu  Tue May 27 00:22:27 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 15:22:27 -0700
Subject: [M3devel] freebsd 10
Message-ID: <20140526222227.A66181A209C@async.async.caltech.edu>


Thanks so much for the reminder that Modula-3 is in FreeBSD ports.
That's great!  I've used it on FreeBSD since 1999 (was that FreeBSD
2?) and this is definitely the easiest install ever.

But the default configuration uses pthreads.  Pthreads support in Modula-3
is broken.

root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # AMD64_FREEBSD/threadtest 
Writing file...done
Creating read threads...done
Creating fork threads...done
Creating alloc threads...done
Creating lock threads...done
running...printing oldest/median age/newest
.

***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
***

Abort (core dumped)
root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # 

I wonder what the best way of reconfiguring this installation to use
user threads (which always work right, in my experience) is...

    Mika


From adacore at marino.st  Tue May 27 00:35:46 2014
From: adacore at marino.st (John Marino)
Date: Tue, 27 May 2014 00:35:46 +0200
Subject: [M3devel] freebsd 10
In-Reply-To: <20140526222227.A66181A209C@async.async.caltech.edu>
References: <20140526222227.A66181A209C@async.async.caltech.edu>
Message-ID: <5383C1C2.9040002@marino.st>

On 5/27/2014 00:22, mika at async.caltech.edu wrote:
> Thanks so much for the reminder that Modula-3 is in FreeBSD ports.
> That's great!  I've used it on FreeBSD since 1999 (was that FreeBSD
> 2?) and this is definitely the easiest install ever.

Actually it was gone for many years, it only came back a few months ago
after a long hiatus.


> But the default configuration uses pthreads.  Pthreads support in Modula-3
> is broken.

Really?  I didn't know that.  That's not good.

> 
> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # AMD64_FREEBSD/threadtest 
> Writing file...done
> Creating read threads...done
> Creating fork threads...done
> Creating alloc threads...done
> Creating lock threads...done
> running...printing oldest/median age/newest
> .
> 
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
> ***
> 
> Abort (core dumped)
> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # 
> 
> I wonder what the best way of reconfiguring this installation to use
> user threads (which always work right, in my experience) is...
> 

Probably adding something to the build environment but I don't know
what.  How does one normally build "user threads" over posix threads?


John




From mika at async.caltech.edu  Tue May 27 01:40:21 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 16:40:21 -0700
Subject: [M3devel] freebsd 10
In-Reply-To: <5383C1C2.9040002@marino.st>
References: <20140526222227.A66181A209C@async.async.caltech.edu>
	<5383C1C2.9040002@marino.st>
Message-ID: <20140526234021.98E721A209C@async.async.caltech.edu>

John Marino writes:
>On 5/27/2014 00:22, mika at async.caltech.edu wrote:
>> Thanks so much for the reminder that Modula-3 is in FreeBSD ports.
>> That's great!  I've used it on FreeBSD since 1999 (was that FreeBSD
>> 2?) and this is definitely the easiest install ever.
>
>Actually it was gone for many years, it only came back a few months ago
>after a long hiatus.

You mean from FreeBSD ports, specifically, right?  I've always been able
to run up-to-date Modula-3 on FreeBSD but it's been a bit of a hassle
installing things (from DECSRC, Polytechnique de Montreal, or elego).
Having it in ports definitely makes things much much easier.

>
>
>> But the default configuration uses pthreads.  Pthreads support in Modula-3
>> is broken.
>
>Really?  I didn't know that.  That's not good.
>
>> 
>> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # AMD64_FREEBSD/threadtest 
>> Writing file...done
>> Creating read threads...done
>> Creating fork threads...done
>> Creating alloc threads...done
>> Creating lock threads...done
>> running...printing oldest/median age/newest
>> .
>> 
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>> ***
>> 
>> Abort (core dumped)
>> root at pluto:/home/mika/cm3/cm3/m3-libs/m3core/tests/thread # 
>> 
>> I wonder what the best way of reconfiguring this installation to use
>> user threads (which always work right, in my experience) is...
>> 
>
>Probably adding something to the build environment but I don't know
>what.  How does one normally build "user threads" over posix threads?

Peter's following email suggests we "just" need an upgrade.

Otherwise the procedure is, if I remember right, to change a flag in
m3core/threads, rebuild m3core, then rebuild the compiler, then rebuild
everything else.

    Mika

>
>
>John
>


From mika at async.caltech.edu  Tue May 27 01:49:16 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Mon, 26 May 2014 16:49:16 -0700
Subject: [M3devel] freebsd 10
In-Reply-To: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
References: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
Message-ID: <20140526234916.864741A209C@async.async.caltech.edu>


Peter, have you/someone run the thread tester exhaustively?

I did this:

#!/bin/csh

while ( 1 ) 
        limit cputime 5
        rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
end

With what's in FreeBSD's ports I get a variety of failures:


1.
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
***

2.
running...printing oldest/median age/newest
.Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.

3. (most common)
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
***

4.
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
***

5. (letting it run a bit longer)
!!! lock Thread 23 appears starved or deadlocked !!!

This is all running in a single-cpu instance (M3.medium) of EC2...  usually things get worse with more processors.

FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
    root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
XEN: Hypervisor version 4.2 detected.
CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e  Stepping = 4
  Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  Standard Extended Features=0x200<ENHMOVSB>
real memory  = 4026531840 (3840 MB)
avail memory = 3872776192 (3693 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <Xen HVM>




>>>>>

Hi

I think tony put a fix into the collector that fixes that problem. The scheduler with pthreads is more agressive and under high load the mutator could have a newly allocated page collected before the object was initalised. would be good if you check it . There was a report of an assert failure a few days ago in the region of code affected, if we could find out which assert failed I could take a look. 
The only other problem is the odd failure in forking. Seems to occur in the child process in initstackbase which initiates a collection which then finds a weak ref to a mutex which is in a thread that does not exist in the child. Not sure what to do about that.
The pthreads seems pretty stable at least on linux. 

Peter 



From dragisha at m3w.org  Tue May 27 17:34:15 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 27 May 2014 17:34:15 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
Message-ID: <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>

You can count on me for release engineering, Git migration? Maybe CI, if I have resources. Problem is - feedback is poor from core developers wrt Git migration. I am ready for long time now.

On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:

> On Sun, 25 May 2014 22:35:09 +0800
> Bruce Axtens <bruce.axtens at gmail.com> wrote:
> 
>> Dear Sir
>> 
>> Should I assume that CM3 is alive, in palliative care or dead? The trac
>> system is full of spam and the roadmap hasn't moved for 3 years.
>> 
>> I had a long and fruitful relationship with Modula-2 years ago and thought
>> that perhaps I could restart things with CM3.
> 
> There is certainly some activity in M3 development recently, though
> the community is rather small.
> The trac system has never been much used by the community members;
> and the WWW presentation and regression testing system has lacked
> my support, as I couldn't spent any time on these topics for
> almost 3 years.
> 
> You should check the m3devel mailing list for news though:
> https://mail.elegosoft.com/pipermail/m3devel
> 
> There has been a lot of activity at the beginning of this year;
> it has ceased again during recent weeks.
> 
> All CVS commits can be found here:
> https://mail.elegosoft.com/pipermail/m3commit
> 
> A new release is long overdue; I'm afraid I cannot do the release
> engineering this time.
> 
> There has been some effort on moving the CVS repositories to git;
> I'm not sure what the status is there, too.
> 
> Any help wrt. documentation, presentation or software is greatly
> appreciated ;-)
> 
> Regards,
> 
> Olaf Wagner
> -- 
> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140527/6354fe6f/attachment-0002.sig>

From adacore at marino.st  Tue May 27 17:40:57 2014
From: adacore at marino.st (John Marino)
Date: Tue, 27 May 2014 17:40:57 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
Message-ID: <5384B209.3080504@marino.st>

On 5/27/2014 17:34, Dragi?a Duri? wrote:
> You can count on me for release engineering, Git migration? Maybe CI,
> if I have resources. Problem is - feedback is poor from core
> developers wrt Git migration. I am ready for long time now.


This might be a good time to remind that I've been waiting for a release
that feature C-backend support for both FreeBSD and DragonFly (new).
The version in FreeBSD ports is 4 years old, but there's not been a
release since then.  The last time I was active on the list we discussed
the needs of FreeBSD and for porting M3 to DragonFly and something was
supposed to happen code-wise (and then release-wise) but I don't think
anything did in the end.

I was extremely busy with other projects but was planning on pinging on
this topic soon anyway.

John


> 
> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
> 
>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
>> <bruce.axtens at gmail.com> wrote:
>> 
>>> Dear Sir
>>> 
>>> Should I assume that CM3 is alive, in palliative care or dead?
>>> The trac system is full of spam and the roadmap hasn't moved for
>>> 3 years.
>>> 
>>> I had a long and fruitful relationship with Modula-2 years ago
>>> and thought that perhaps I could restart things with CM3.
>> 
>> There is certainly some activity in M3 development recently,
>> though the community is rather small. The trac system has never
>> been much used by the community members; and the WWW presentation
>> and regression testing system has lacked my support, as I couldn't
>> spent any time on these topics for almost 3 years.
>> 
>> You should check the m3devel mailing list for news though: 
>> https://mail.elegosoft.com/pipermail/m3devel
>> 
>> There has been a lot of activity at the beginning of this year; it
>> has ceased again during recent weeks.
>> 
>> All CVS commits can be found here: 
>> https://mail.elegosoft.com/pipermail/m3commit
>> 
>> A new release is long overdue; I'm afraid I cannot do the release 
>> engineering this time.
>> 
>> There has been some effort on moving the CVS repositories to git; 
>> I'm not sure what the status is there, too.
>> 
>> Any help wrt. documentation, presentation or software is greatly 
>> appreciated ;-)
>> 
>> Regards,
>> 
>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
>> | USt-IdNr: DE163214194
> 


From hosking at cs.purdue.edu  Tue May 27 17:56:49 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2014 11:56:49 -0400
Subject: [M3devel] compilation problems with assertions in RTCollector.m3
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF9269F8F6@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF9269F8F6@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <B36B7B19-18BA-4B8A-9BA2-245188D6CDF8@cs.purdue.edu>

Just committed a (hopeful) fix.  Please give it a try.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





On May 24, 2014, at 12:57 AM, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:

> I updated my sandbox to be current with the HEAD branch via CVS, then tried to rebuild everything.
>  
> I first built a minimal distribution on Windows XP.  Everything seemed to work fine.
>  
> Now, using my newly rebuilt cm3.exe, I decided to rebuild everything.  Unfortunately, now I?m running into problems even in the first stage.
>  
> Here are some examples of the errors I am getting.  These runtime errors happen compiling various packages.  (I?ve tried rebuilding several times.)
>  
> I show 3 separate incidents below and the last one has a partial stack trace.  In each case, there is an assertion failure in the RTCollector while running the compiler:
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\runtime\common\RTCollector.m3", line 1092
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\runtime\common\RTCollector.m3", line 699
> ***
>  
> ***
> *** runtime error:
> ***    <*ASSERT*> failed.
> ***    file "..\src\runtime\common\RTCollector.m3", line 1092
> ***
>  
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x12f374   0x6ca19e  CleanBetween + 0x22 in ..\src\runtime\common\RTCollector.m3
> 0x12f3ac   0x6ca031  CopySome + 0xeb in ..\src\runtime\common\RTCollector.m3
> 0x12f3b8   0x6c9b02  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3
> 0x12f3c8   0x6c94d6  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3
> 0x12f40c   0x6c916a  CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3
> 0x12f44c   0x6dc586  AllocTraced + 0xd3 in ..\src\runtime\common\RTAllocator.m3
> 0x12f480   0x6dbbd8  GetTracedObj + 0x86 in ..\src\runtime\common\RTAllocator.m3
> 0x12f49c   0x6db70c  AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3
> 0x12f4d0   0x529913  Init_chars + 0x20b in ..\src\misc\CG.m3
> 0x12f4f8   0x4f948b  Init_chars + 0xb9 in ..\src\misc\M3String.m3
> .........  .........  ... more frames ...
>  
> WARNING:  Encountered an error when processing package "m3-sys\m3front" for "-build".
>  
> Any help in solving this problem would be appreciated.
>  
> Thanks,
> Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140527/8b621349/attachment-0002.html>

From mika at async.caltech.edu  Tue May 27 18:07:23 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Tue, 27 May 2014 09:07:23 -0700
Subject: [M3devel] freebsd 10
In-Reply-To: <CAEy6uxpCcLmoMf-C6caZUFNDmGWdqyyL6xMNchhnWkYeRnDGCA@mail.gmail.com>
References: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
	<20140526234916.864741A209C@async.async.caltech.edu>
	<CAEy6uxpCcLmoMf-C6caZUFNDmGWdqyyL6xMNchhnWkYeRnDGCA@mail.gmail.com>
Message-ID: <20140527160723.1296A1A2096@async.async.caltech.edu>


Peter, there's nothing here that constitutes a bug in the thread tester
itself, right?  These are all errors in the runtime (garbage collector,
threading system, Rd/Wr possibly)?

    Mika

Peter McKinna writes:
>--089e0122f628a8285004fa56cf42
>Content-Type: text/plain; charset=UTF-8
>
>Yeah I did a fair bit of testing that program it was annoying me. If you
>run it as threadtest -n 6 -tests alloc  you are just testing allocations
>and it should not crash . However if you put a diagnostic check of the
>retuned array in that test every now and again every element will be non
>zero and the same number corresponding to gray flag of the object header in
>the collector. ( this is from memory havent looked atvthe code for a while
>)  if you have -tests read, alloc  then it will probably crash since the
>read test allocates obects which are dereferenced either in FileRd or in
>the collector in move. If you examine the obect in gdb after the crash all
>fields of the object have the same value as in the alloc test I think its
>2^22 . Your crashes 1 and 4 are the same . Your 2nd example only occurs if
>you have the fork test in the set of tests. It actually crashes the child
>process via an abort after printing that message although that is not
>apparent . You might argue that the error can be ignored since the child
>usually does an exec straight after fork.
>
>Peter
>On 27/05/2014 9:49 AM, <mika at async.caltech.edu> wrote:
>
>>
>> Peter, have you/someone run the thread tester exhaustively?
>>
>> I did this:
>>
>> #!/bin/csh
>>
>> while ( 1 )
>>         limit cputime 5
>>         rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
>> end
>>
>> With what's in FreeBSD's ports I get a variety of failures:
>>
>>
>> 1.
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>> ***
>>
>> 2.
>> running...printing oldest/median age/newest
>> .Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete,
>> file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>>
>> 3. (most common)
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>> ***
>>
>> 4.
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>> ***
>>
>> 5. (letting it run a bit longer)
>> !!! lock Thread 23 appears starved or deadlocked !!!
>>
>> This is all running in a single-cpu instance (M3.medium) of EC2...
>>  usually things get worse with more processors.
>>
>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>>     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>> XEN: Hypervisor version 4.2 detected.
>> CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
>>   Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e
>>  Stepping = 4
>>
>> Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>>
>> Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,H
>V>
>>   AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
>>   AMD Features2=0x1<LAHF>
>>   Standard Extended Features=0x200<ENHMOVSB>
>> real memory  = 4026531840 (3840 MB)
>> avail memory = 3872776192 (3693 MB)
>> Event timer "LAPIC" quality 400
>> ACPI APIC Table: <Xen HVM>
>>
>>
>>
>>
>> >>>>>
>>
>> Hi
>>
>> I think tony put a fix into the collector that fixes that problem. The
>> scheduler with pthreads is more agressive and under high load the mutator
>> could have a newly allocated page collected before the object was
>> initalised. would be good if you check it . There was a report of an assert
>> failure a few days ago in the region of code affected, if we could find out
>> which assert failed I could take a look.
>> The only other problem is the odd failure in forking. Seems to occur in
>> the child process in initstackbase which initiates a collection which then
>> finds a weak ref to a mutex which is in a thread that does not exist in the
>> child. Not sure what to do about that.
>> The pthreads seems pretty stable at least on linux.
>>
>> Peter
>>
>>
>
>--089e0122f628a8285004fa56cf42
>Content-Type: text/html; charset=UTF-8
>Content-Transfer-Encoding: quoted-printable
>
><p dir=3D"ltr">Yeah I did a fair bit of testing that program it was annoyin=
>g me. If you run it as threadtest -n 6 -tests alloc=C2=A0 you are just test=
>ing allocations and it should not crash . However if you put a diagnostic c=
>heck of the retuned array in that test every now and again every element wi=
>ll be non zero and the same number corresponding to gray flag of the object=
> header in the collector. ( this is from memory havent looked atvthe code f=
>or a while )=C2=A0 if you have -tests read, alloc=C2=A0 then it will probab=
>ly crash since the read test allocates obects which are dereferenced either=
> in FileRd or in the collector in move. If you examine the obect in gdb aft=
>er the crash all fields of the object have the same value as in the alloc t=
>est I think its 2^22 . Your crashes 1 and 4 are the same . Your 2nd example=
> only occurs if you have the fork test in the set of tests. It actually cra=
>shes the child process via an abort after printing that message although th=
>at is not apparent . You might argue that the error can be ignored since th=
>e child usually does an exec straight after fork.</p>
>
><p dir=3D"ltr">Peter</p>
><div class=3D"gmail_quote">On 27/05/2014 9:49 AM,  &lt;<a href=3D"mailto:mi=
>ka at async.caltech.edu">mika at async.caltech.edu</a>&gt; wrote:<br type=3D"attr=
>ibution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
>r-left:1px #ccc solid;padding-left:1ex">
><br>
>Peter, have you/someone run the thread tester exhaustively?<br>
><br>
>I did this:<br>
><br>
>#!/bin/csh<br>
><br>
>while ( 1 )<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr=
>eadtest<br>
>end<br>
><br>
>With what&#39;s in FreeBSD&#39;s ports I get a variety of failures:<br>
><br>
><br>
>1.<br>
>***<br>
>*** runtime error:<br>
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>IL<br>
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>***<br>
><br>
>2.<br>
>running...printing oldest/median age/newest<br>
>.Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele=
>te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.<br>
><br>
>3. (most common)<br>
>***<br>
>*** runtime error:<br>
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>IL<br>
>*** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R=
>TCollector.m3<br>
>***<br>
><br>
>4.<br>
>***<br>
>*** runtime error:<br>
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>IL<br>
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>***<br>
><br>
>5. (letting it run a bit longer)<br>
>!!! lock Thread 23 appears starved or deadlocked !!!<br>
><br>
>This is all running in a single-cpu instance (M3.medium) of EC2... =C2=A0us=
>ually things get worse with more processors.<br>
><br>
>FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014<br>
>=C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER=
>IC amd64<br>
>FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610<br>
>XEN: Hypervisor version 4.2 detected.<br>
>CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)<b=
>r>
>=C2=A0 Origin =3D &quot;GenuineIntel&quot; =C2=A0Id =3D 0x306e4 =C2=A0Famil=
>y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4<br>
>=C2=A0 Features=3D0x1783fbff&lt;FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP=
>,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT&gt;<br>
>=C2=A0 Features2=3D0xffba2203&lt;SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4=
>.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV&gt;<br>
>=C2=A0 AMD Features=3D0x28100800&lt;SYSCALL,NX,RDTSCP,LM&gt;<br>
>=C2=A0 AMD Features2=3D0x1&lt;LAHF&gt;<br>
>=C2=A0 Standard Extended Features=3D0x200&lt;ENHMOVSB&gt;<br>
>real memory =C2=A0=3D 4026531840 (3840 MB)<br>
>avail memory =3D 3872776192 (3693 MB)<br>
>Event timer &quot;LAPIC&quot; quality 400<br>
>ACPI APIC Table: &lt;Xen HVM&gt;<br>
><br>
><br>
><br>
><br>
>&gt;&gt;&gt;&gt;&gt;<br>
><br>
>Hi<br>
><br>
>I think tony put a fix into the collector that fixes that problem. The sche=
>duler with pthreads is more agressive and under high load the mutator could=
> have a newly allocated page collected before the object was initalised. wo=
>uld be good if you check it . There was a report of an assert failure a few=
> days ago in the region of code affected, if we could find out which assert=
> failed I could take a look.<br>
>
>The only other problem is the odd failure in forking. Seems to occur in the=
> child process in initstackbase which initiates a collection which then fin=
>ds a weak ref to a mutex which is in a thread that does not exist in the ch=
>ild. Not sure what to do about that.<br>
>
>The pthreads seems pretty stable at least on linux.<br>
><br>
>Peter<br>
><br>
></blockquote></div>
>
>--089e0122f628a8285004fa56cf42--


From hosking at cs.purdue.edu  Tue May 27 18:24:50 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2014 12:24:50 -0400
Subject: [M3devel] freebsd 10
In-Reply-To: <20140527160723.1296A1A2096@async.async.caltech.edu>
References: <uumpg01t9k2ldjx6dd8vj9uv.1401143640998@email.android.com>
	<20140526234916.864741A209C@async.async.caltech.edu>
	<CAEy6uxpCcLmoMf-C6caZUFNDmGWdqyyL6xMNchhnWkYeRnDGCA@mail.gmail.com>
	<20140527160723.1296A1A2096@async.async.caltech.edu>
Message-ID: <81669A74-4D31-442A-A8AE-7B14BF8E1AC2@cs.purdue.edu>

I would love to get a read on whether Peter?s suggested fix (which I put in a few weeks ago and just revised slightly) has narrowed the set of problems the thread test program illuminates.  Re fork, I?d like to understand that problem a little better to see if we can find a fix.

On May 27, 2014, at 12:07 PM, mika at async.caltech.edu wrote:

> 
> Peter, there's nothing here that constitutes a bug in the thread tester
> itself, right?  These are all errors in the runtime (garbage collector,
> threading system, Rd/Wr possibly)?
> 
>    Mika
> 
> Peter McKinna writes:
>> --089e0122f628a8285004fa56cf42
>> Content-Type: text/plain; charset=UTF-8
>> 
>> Yeah I did a fair bit of testing that program it was annoying me. If you
>> run it as threadtest -n 6 -tests alloc  you are just testing allocations
>> and it should not crash . However if you put a diagnostic check of the
>> retuned array in that test every now and again every element will be non
>> zero and the same number corresponding to gray flag of the object header in
>> the collector. ( this is from memory havent looked atvthe code for a while
>> )  if you have -tests read, alloc  then it will probably crash since the
>> read test allocates obects which are dereferenced either in FileRd or in
>> the collector in move. If you examine the obect in gdb after the crash all
>> fields of the object have the same value as in the alloc test I think its
>> 2^22 . Your crashes 1 and 4 are the same . Your 2nd example only occurs if
>> you have the fork test in the set of tests. It actually crashes the child
>> process via an abort after printing that message although that is not
>> apparent . You might argue that the error can be ignored since the child
>> usually does an exec straight after fork.
>> 
>> Peter
>> On 27/05/2014 9:49 AM, <mika at async.caltech.edu> wrote:
>> 
>>> 
>>> Peter, have you/someone run the thread tester exhaustively?
>>> 
>>> I did this:
>>> 
>>> #!/bin/csh
>>> 
>>> while ( 1 )
>>>        limit cputime 5
>>>        rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
>>> end
>>> 
>>> With what's in FreeBSD's ports I get a variety of failures:
>>> 
>>> 
>>> 1.
>>> ***
>>> *** runtime error:
>>> ***    Segmentation violation - possible attempt to dereference NIL
>>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>>> ***
>>> 
>>> 2.
>>> running...printing oldest/median age/newest
>>> .Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete,
>>> file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>>> 
>>> 3. (most common)
>>> ***
>>> *** runtime error:
>>> ***    Segmentation violation - possible attempt to dereference NIL
>>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>>> ***
>>> 
>>> 4.
>>> ***
>>> *** runtime error:
>>> ***    Segmentation violation - possible attempt to dereference NIL
>>> ***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
>>> ***
>>> 
>>> 5. (letting it run a bit longer)
>>> !!! lock Thread 23 appears starved or deadlocked !!!
>>> 
>>> This is all running in a single-cpu instance (M3.medium) of EC2...
>>> usually things get worse with more processors.
>>> 
>>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>>>    root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>>> XEN: Hypervisor version 4.2 detected.
>>> CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
>>>  Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e
>>> Stepping = 4
>>> 
>>> Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>>> 
>>> Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,H
>> V>
>>>  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
>>>  AMD Features2=0x1<LAHF>
>>>  Standard Extended Features=0x200<ENHMOVSB>
>>> real memory  = 4026531840 (3840 MB)
>>> avail memory = 3872776192 (3693 MB)
>>> Event timer "LAPIC" quality 400
>>> ACPI APIC Table: <Xen HVM>
>>> 
>>> 
>>> 
>>> 
>>>>>>>> 
>>> 
>>> Hi
>>> 
>>> I think tony put a fix into the collector that fixes that problem. The
>>> scheduler with pthreads is more agressive and under high load the mutator
>>> could have a newly allocated page collected before the object was
>>> initalised. would be good if you check it . There was a report of an assert
>>> failure a few days ago in the region of code affected, if we could find out
>>> which assert failed I could take a look.
>>> The only other problem is the odd failure in forking. Seems to occur in
>>> the child process in initstackbase which initiates a collection which then
>>> finds a weak ref to a mutex which is in a thread that does not exist in the
>>> child. Not sure what to do about that.
>>> The pthreads seems pretty stable at least on linux.
>>> 
>>> Peter
>>> 
>>> 
>> 
>> --089e0122f628a8285004fa56cf42
>> Content-Type: text/html; charset=UTF-8
>> Content-Transfer-Encoding: quoted-printable
>> 
>> <p dir=3D"ltr">Yeah I did a fair bit of testing that program it was annoyin=
>> g me. If you run it as threadtest -n 6 -tests alloc=C2=A0 you are just test=
>> ing allocations and it should not crash . However if you put a diagnostic c=
>> heck of the retuned array in that test every now and again every element wi=
>> ll be non zero and the same number corresponding to gray flag of the object=
>> header in the collector. ( this is from memory havent looked atvthe code f=
>> or a while )=C2=A0 if you have -tests read, alloc=C2=A0 then it will probab=
>> ly crash since the read test allocates obects which are dereferenced either=
>> in FileRd or in the collector in move. If you examine the obect in gdb aft=
>> er the crash all fields of the object have the same value as in the alloc t=
>> est I think its 2^22 . Your crashes 1 and 4 are the same . Your 2nd example=
>> only occurs if you have the fork test in the set of tests. It actually cra=
>> shes the child process via an abort after printing that message although th=
>> at is not apparent . You might argue that the error can be ignored since th=
>> e child usually does an exec straight after fork.</p>
>> 
>> <p dir=3D"ltr">Peter</p>
>> <div class=3D"gmail_quote">On 27/05/2014 9:49 AM,  &lt;<a href=3D"mailto:mi=
>> ka at async.caltech.edu">mika at async.caltech.edu</a>&gt; wrote:<br type=3D"attr=
>> ibution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
>> r-left:1px #ccc solid;padding-left:1ex">
>> <br>
>> Peter, have you/someone run the thread tester exhaustively?<br>
>> <br>
>> I did this:<br>
>> <br>
>> #!/bin/csh<br>
>> <br>
>> while ( 1 )<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr=
>> eadtest<br>
>> end<br>
>> <br>
>> With what&#39;s in FreeBSD&#39;s ports I get a variety of failures:<br>
>> <br>
>> <br>
>> 1.<br>
>> ***<br>
>> *** runtime error:<br>
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>> IL<br>
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>> ***<br>
>> <br>
>> 2.<br>
>> running...printing oldest/median age/newest<br>
>> .Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele=
>> te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.<br>
>> <br>
>> 3. (most common)<br>
>> ***<br>
>> *** runtime error:<br>
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>> IL<br>
>> *** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R=
>> TCollector.m3<br>
>> ***<br>
>> <br>
>> 4.<br>
>> ***<br>
>> *** runtime error:<br>
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N=
>> IL<br>
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3<br>
>> ***<br>
>> <br>
>> 5. (letting it run a bit longer)<br>
>> !!! lock Thread 23 appears starved or deadlocked !!!<br>
>> <br>
>> This is all running in a single-cpu instance (M3.medium) of EC2... =C2=A0us=
>> ually things get worse with more processors.<br>
>> <br>
>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014<br>
>> =C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER=
>> IC amd64<br>
>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610<br>
>> XEN: Hypervisor version 4.2 detected.<br>
>> CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)<b=
>> r>
>> =C2=A0 Origin =3D &quot;GenuineIntel&quot; =C2=A0Id =3D 0x306e4 =C2=A0Famil=
>> y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4<br>
>> =C2=A0 Features=3D0x1783fbff&lt;FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP=
>> ,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT&gt;<br>
>> =C2=A0 Features2=3D0xffba2203&lt;SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4=
>> .2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV&gt;<br>
>> =C2=A0 AMD Features=3D0x28100800&lt;SYSCALL,NX,RDTSCP,LM&gt;<br>
>> =C2=A0 AMD Features2=3D0x1&lt;LAHF&gt;<br>
>> =C2=A0 Standard Extended Features=3D0x200&lt;ENHMOVSB&gt;<br>
>> real memory =C2=A0=3D 4026531840 (3840 MB)<br>
>> avail memory =3D 3872776192 (3693 MB)<br>
>> Event timer &quot;LAPIC&quot; quality 400<br>
>> ACPI APIC Table: &lt;Xen HVM&gt;<br>
>> <br>
>> <br>
>> <br>
>> <br>
>> &gt;&gt;&gt;&gt;&gt;<br>
>> <br>
>> Hi<br>
>> <br>
>> I think tony put a fix into the collector that fixes that problem. The sche=
>> duler with pthreads is more agressive and under high load the mutator could=
>> have a newly allocated page collected before the object was initalised. wo=
>> uld be good if you check it . There was a report of an assert failure a few=
>> days ago in the region of code affected, if we could find out which assert=
>> failed I could take a look.<br>
>> 
>> The only other problem is the odd failure in forking. Seems to occur in the=
>> child process in initstackbase which initiates a collection which then fin=
>> ds a weak ref to a mutex which is in a thread that does not exist in the ch=
>> ild. Not sure what to do about that.<br>
>> 
>> The pthreads seems pretty stable at least on linux.<br>
>> <br>
>> Peter<br>
>> <br>
>> </blockquote></div>
>> 
>> --089e0122f628a8285004fa56cf42--



Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484







From hosking at cs.purdue.edu  Tue May 27 18:49:12 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2014 12:49:12 -0400
Subject: [M3devel] Status of CM3
In-Reply-To: <5384B209.3080504@marino.st>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
	<5384B209.3080504@marino.st>
Message-ID: <A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>

Jay might comment on C backend status for those platforms.

On May 27, 2014, at 11:40 AM, John Marino <adacore at marino.st> wrote:

> On 5/27/2014 17:34, Dragi?a Duri? wrote:
>> You can count on me for release engineering, Git migration? Maybe CI,
>> if I have resources. Problem is - feedback is poor from core
>> developers wrt Git migration. I am ready for long time now.
> 
> 
> This might be a good time to remind that I've been waiting for a release
> that feature C-backend support for both FreeBSD and DragonFly (new).
> The version in FreeBSD ports is 4 years old, but there's not been a
> release since then.  The last time I was active on the list we discussed
> the needs of FreeBSD and for porting M3 to DragonFly and something was
> supposed to happen code-wise (and then release-wise) but I don't think
> anything did in the end.
> 
> I was extremely busy with other projects but was planning on pinging on
> this topic soon anyway.
> 
> John
> 
> 
>> 
>> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
>> 
>>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
>>> <bruce.axtens at gmail.com> wrote:
>>> 
>>>> Dear Sir
>>>> 
>>>> Should I assume that CM3 is alive, in palliative care or dead?
>>>> The trac system is full of spam and the roadmap hasn't moved for
>>>> 3 years.
>>>> 
>>>> I had a long and fruitful relationship with Modula-2 years ago
>>>> and thought that perhaps I could restart things with CM3.
>>> 
>>> There is certainly some activity in M3 development recently,
>>> though the community is rather small. The trac system has never
>>> been much used by the community members; and the WWW presentation
>>> and regression testing system has lacked my support, as I couldn't
>>> spent any time on these topics for almost 3 years.
>>> 
>>> You should check the m3devel mailing list for news though: 
>>> https://mail.elegosoft.com/pipermail/m3devel
>>> 
>>> There has been a lot of activity at the beginning of this year; it
>>> has ceased again during recent weeks.
>>> 
>>> All CVS commits can be found here: 
>>> https://mail.elegosoft.com/pipermail/m3commit
>>> 
>>> A new release is long overdue; I'm afraid I cannot do the release 
>>> engineering this time.
>>> 
>>> There has been some effort on moving the CVS repositories to git; 
>>> I'm not sure what the status is there, too.
>>> 
>>> Any help wrt. documentation, presentation or software is greatly 
>>> appreciated ;-)
>>> 
>>> Regards,
>>> 
>>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
>>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
>>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
>>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
>>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
>>> | USt-IdNr: DE163214194
>> 



Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484







From jay.krell at cornell.edu  Wed May 28 08:20:10 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 06:20:10 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
Message-ID: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>

 Sorry, my life has really changed and I have hardly any time now..
 I still hope to come back. 



The C backend works quite well.
I was able to cross-to and self-world-build many platforms.
Including bring up new platform: AMD64_NT.
There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.
jmpbuf remains a platform-specificity in the frontend.


 I believe we had mostly good experience with Linux/arm and maybe Dragonfly? 
 Not sure.


 Going through C source and C compiler is noticable slower. 


The "levelness" of the output is near what I was aiming for, for the first go.
 - records all have fields; you can view them in standard debuggers -- good! 
    This took me a while but I got there. 
 - but globals are not viewable -- all offsets into particular records 
 - all locals/parameters get numbers on the end to disambiguate
    from "nearby" name clashes, though usually it isn't needed;
    this is near the top of the things to fix


The "levelness" is still low in that the word size and posix vs. NT is baked in.
If you want "one source release", you really need to make about 6 currently:
  posix 32bit little endian (many systems)  
  posix 32bit big endian (rare: sparc32_solaris, ppc_darwin) 
  posix 64bit little endian (many systems)  
  posix 64bit big endian (rare: sparc64_solaris, ppc64_darwin)  
  nt 32bit little endian 
  nt 64bit little endian 


 There is one recent outstanding bug report where the generated C is invalid. 


 Besides jmpbuf, I'd like to see endianness factored out.
 There is approx one instance of endian specificity in the frontend
 I'd like to see removed. And then htos/htol/stoh/ltoh moved to C.


I'd also like to see exception handling optionally implemented on top of C++ exception
handling or NT C exception handling (also maybe VMS/Tru64/Ultrix C exception handling...).


For a release though, most of this isn't needed.
Mainly: fix the one bug, decide if performance and debugability is adequate.


 - Jay



> From: hosking at cs.purdue.edu
> Date: Tue, 27 May 2014 12:49:12 -0400
> To: adacore at marino.st; jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
> Subject: Re: [M3devel] Status of CM3
> 
> Jay might comment on C backend status for those platforms.
> 
> On May 27, 2014, at 11:40 AM, John Marino <adacore at marino.st> wrote:
> 
> > On 5/27/2014 17:34, Dragi?a Duri? wrote:
> >> You can count on me for release engineering, Git migration. Maybe CI,
> >> if I have resources. Problem is - feedback is poor from core
> >> developers wrt Git migration. I am ready for long time now.
> > 
> > 
> > This might be a good time to remind that I've been waiting for a release
> > that feature C-backend support for both FreeBSD and DragonFly (new).
> > The version in FreeBSD ports is 4 years old, but there's not been a
> > release since then.  The last time I was active on the list we discussed
> > the needs of FreeBSD and for porting M3 to DragonFly and something was
> > supposed to happen code-wise (and then release-wise) but I don't think
> > anything did in the end.
> > 
> > I was extremely busy with other projects but was planning on pinging on
> > this topic soon anyway.
> > 
> > John
> > 
> > 
> >> 
> >> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
> >> 
> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
> >>> <bruce.axtens at gmail.com> wrote:
> >>> 
> >>>> Dear Sir
> >>>> 
> >>>> Should I assume that CM3 is alive, in palliative care or dead?
> >>>> The trac system is full of spam and the roadmap hasn't moved for
> >>>> 3 years.
> >>>> 
> >>>> I had a long and fruitful relationship with Modula-2 years ago
> >>>> and thought that perhaps I could restart things with CM3.
> >>> 
> >>> There is certainly some activity in M3 development recently,
> >>> though the community is rather small. The trac system has never
> >>> been much used by the community members; and the WWW presentation
> >>> and regression testing system has lacked my support, as I couldn't
> >>> spent any time on these topics for almost 3 years.
> >>> 
> >>> You should check the m3devel mailing list for news though: 
> >>> https://mail.elegosoft.com/pipermail/m3devel
> >>> 
> >>> There has been a lot of activity at the beginning of this year; it
> >>> has ceased again during recent weeks.
> >>> 
> >>> All CVS commits can be found here: 
> >>> https://mail.elegosoft.com/pipermail/m3commit
> >>> 
> >>> A new release is long overdue; I'm afraid I cannot do the release 
> >>> engineering this time.
> >>> 
> >>> There has been some effort on moving the CVS repositories to git; 
> >>> I'm not sure what the status is there, too.
> >>> 
> >>> Any help wrt. documentation, presentation or software is greatly 
> >>> appreciated ;-)
> >>> 
> >>> Regards,
> >>> 
> >>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
> >>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> >>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
> >>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
> >>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
> >>> | USt-IdNr: DE163214194
> >> 
> 
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +1 765 427 5484
> 
> 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/f5d9fc88/attachment-0002.html>

From jay.krell at cornell.edu  Wed May 28 08:33:14 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 06:33:14 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>,
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, ,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, ,
	<5384B209.3080504@marino.st>, ,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>,
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
Message-ID: <COL130-W2013AC1C6E95C966ADE57BE6250@phx.gbl>

sorry, a correction: because of the jmpbuf matter, there is far more "variety" in the output C than the six I listed.
It isn't quite that every platform is unique, but close enough.

Anyway, the C backend is in very good shape relative to its goals.

 - Jay


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; adacore at marino.st
Date: Wed, 28 May 2014 06:20:10 +0000
CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
Subject: Re: [M3devel] Status of CM3




 Sorry, my life has really changed and I have hardly any time now..
 I still hope to come back. 



The C backend works quite well.
I was able to cross-to and self-world-build many platforms.
Including bring up new platform: AMD64_NT.
There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.
jmpbuf remains a platform-specificity in the frontend.


 I believe we had mostly good experience with Linux/arm and maybe Dragonfly? 
 Not sure.


 Going through C source and C compiler is noticable slower. 


The "levelness" of the output is near what I was aiming for, for the first go.
 - records all have fields; you can view them in standard debuggers -- good! 
    This took me a while but I got there. 
 - but globals are not viewable -- all offsets into particular records 
 - all locals/parameters get numbers on the end to disambiguate
    from "nearby" name clashes, though usually it isn't needed;
    this is near the top of the things to fix


The "levelness" is still low in that the word size and posix vs. NT is baked in.
If you want "one source release", you really need to make about 6 currently:
  posix 32bit little endian (many systems)  
  posix 32bit big endian (rare: sparc32_solaris, ppc_darwin) 
  posix 64bit little endian (many systems)  
  posix 64bit big endian (rare: sparc64_solaris, ppc64_darwin)  
  nt 32bit little endian 
  nt 64bit little endian 


 There is one recent outstanding bug report where the generated C is invalid. 


 Besides jmpbuf, I'd like to see endianness factored out.
 There is approx one instance of endian specificity in the frontend
 I'd like to see removed. And then htos/htol/stoh/ltoh moved to C.


I'd also like to see exception handling optionally implemented on top of C++ exception
handling or NT C exception handling (also maybe VMS/Tru64/Ultrix C exception handling...).


For a release though, most of this isn't needed.
Mainly: fix the one bug, decide if performance and debugability is adequate.


 - Jay



> From: hosking at cs.purdue.edu
> Date: Tue, 27 May 2014 12:49:12 -0400
> To: adacore at marino.st; jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
> Subject: Re: [M3devel] Status of CM3
> 
> Jay might comment on C backend status for those platforms.
> 
> On May 27, 2014, at 11:40 AM, John Marino <adacore at marino.st> wrote:
> 
> > On 5/27/2014 17:34, Dragi?a Duri? wrote:
> >> You can count on me for release engineering, Git migration. Maybe CI,
> >> if I have resources. Problem is - feedback is poor from core
> >> developers wrt Git migration. I am ready for long time now.
> > 
> > 
> > This might be a good time to remind that I've been waiting for a release
> > that feature C-backend support for both FreeBSD and DragonFly (new).
> > The version in FreeBSD ports is 4 years old, but there's not been a
> > release since then.  The last time I was active on the list we discussed
> > the needs of FreeBSD and for porting M3 to DragonFly and something was
> > supposed to happen code-wise (and then release-wise) but I don't think
> > anything did in the end.
> > 
> > I was extremely busy with other projects but was planning on pinging on
> > this topic soon anyway.
> > 
> > John
> > 
> > 
> >> 
> >> On 25 May 2014, at 18:36, Olaf Wagner <wagner at elegosoft.com> wrote:
> >> 
> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens
> >>> <bruce.axtens at gmail.com> wrote:
> >>> 
> >>>> Dear Sir
> >>>> 
> >>>> Should I assume that CM3 is alive, in palliative care or dead?
> >>>> The trac system is full of spam and the roadmap hasn't moved for
> >>>> 3 years.
> >>>> 
> >>>> I had a long and fruitful relationship with Modula-2 years ago
> >>>> and thought that perhaps I could restart things with CM3.
> >>> 
> >>> There is certainly some activity in M3 development recently,
> >>> though the community is rather small. The trac system has never
> >>> been much used by the community members; and the WWW presentation
> >>> and regression testing system has lacked my support, as I couldn't
> >>> spent any time on these topics for almost 3 years.
> >>> 
> >>> You should check the m3devel mailing list for news though: 
> >>> https://mail.elegosoft.com/pipermail/m3devel
> >>> 
> >>> There has been a lot of activity at the beginning of this year; it
> >>> has ceased again during recent weeks.
> >>> 
> >>> All CVS commits can be found here: 
> >>> https://mail.elegosoft.com/pipermail/m3commit
> >>> 
> >>> A new release is long overdue; I'm afraid I cannot do the release 
> >>> engineering this time.
> >>> 
> >>> There has been some effort on moving the CVS repositories to git; 
> >>> I'm not sure what the status is there, too.
> >>> 
> >>> Any help wrt. documentation, presentation or software is greatly 
> >>> appreciated ;-)
> >>> 
> >>> Regards,
> >>> 
> >>> Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH --
> >>> http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355
> >>> Berlin, Germany phone: +49 30 23 45 86 96  mobile: +49 177 2345 869
> >>> fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner
> >>> | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719
> >>> | USt-IdNr: DE163214194
> >> 
> 
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +1 765 427 5484
> 
> 
> 
> 
> 
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/aff2833b/attachment-0002.html>

From jay.krell at cornell.edu  Wed May 28 08:42:33 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 06:42:33 +0000
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>
References: <535FA2B2.70108@gmail.com>,
	<A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>
Message-ID: <COL130-W1019248A16E06F580E4D88E6250@phx.gbl>

.deb is just a .tar.gz or .tar.bz2 or .tar.xz with a little bit more around it.
They can be fancy but ours is not, it is just a compressed .tar.
Can you just crack it open and install the underlying parts?
It is likely "position independent" and you can extract it anywhere in your file system -- /usr/local/cm3, $HOME/cm3, etc.

I build them pretty "manually" see here:
https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/pylib.py  
the function MakeDebianPackage
Ok, it is an actually an "ar" file, and inside the main thing is data.tar with some compression like .gz or .xz.

 - Jay

From: dragisha at m3w.org
Date: Thu, 1 May 2014 19:49:28 +0200
To: bruceax at gmail.com
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr

It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.

--Dragi?a Duri?dragisha at m3w.org



On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:
  

    
  
  
    I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty?
    When I try to install it with Ubuntu Software Centre I get told the
    following:

    

    Lintian check results for
      /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:

      Can't use an undefined value as an ARRAY reference at
      /usr/share/perl5/

      Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.

    
    

    Is this a Perl issue or an installer issue?

    

    -- Bruce

    

  


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/3b4c0333/attachment-0002.html>

From estellnb at elstel.org  Wed May 28 10:03:21 2014
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Wed, 28 May 2014 10:03:21 +0200
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <COL130-W1019248A16E06F580E4D88E6250@phx.gbl>
References: <535FA2B2.70108@gmail.com>,
	<A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>
	<COL130-W1019248A16E06F580E4D88E6250@phx.gbl>
Message-ID: <8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org>

If it is a true .deb you need to apply 
> ar x xy.deb
and then
> tar -xvJ <~/aux/data.tar.xz

(A real  .deb will also contain a control .tar.gz with control, shlibs, md5sums, postinst, etc.)

It should be built with
> pushd BUILD
> dpkg-buildpackage -sa -kmy at email.org
> popd
and checked with
> lintian -EvIL +pedantic my.dsc


Am 28.05.2014 um 08:42 schrieb Jay K:

> .deb is just a .tar.gz or .tar.bz2 or .tar.xz with a little bit more around it.
> They can be fancy but ours is not, it is just a compressed .tar.
> Can you just crack it open and install the underlying parts?
> It is likely "position independent" and you can extract it anywhere in your file system -- /usr/local/cm3, $HOME/cm3, etc.
> 
> I build them pretty "manually" see here:
> https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/pylib.py  
> the function MakeDebianPackage
> Ok, it is an actually an "ar" file, and inside the main thing is data.tar with some compression like .gz or .xz.
> 
>  - Jay
> 
> From: dragisha at m3w.org
> Date: Thu, 1 May 2014 19:49:28 +0200
> To: bruceax at gmail.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr
> 
> It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.
> --
> Dragi?a Duri?
> dragisha at m3w.org
> 
> 
> 
> On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:
> 
> I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty? When I try to install it with Ubuntu Software Centre I get told the following:
> 
> Lintian check results for /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:
> Can't use an undefined value as an ARRAY reference at /usr/share/perl5/
> Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.
> 
> Is this a Perl issue or an installer issue?
> 
> -- Bruce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/d6e4ec51/attachment-0002.html>

From estellnb at elstel.org  Wed May 28 10:40:34 2014
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Wed, 28 May 2014 10:40:34 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
Message-ID: <8400B243-1D27-4651-84AB-071E26329507@elstel.org>

A new release would be great!
I have been waiting to get all the qt and gtk libraries packed with a new release.
If I wanna do some end user application development like the CoAN simulator in Modula-3 it will actually need to work with a release because I can not demand the users of my applications to compile the compiler first (That would harshly drop the usage rates).

Concerning a contribution from my side for a new CM3 release I could perhaps manage to get everything packed into .deb and .rpm package in summer as I do already have some experience in this field.

Regards,
Elmar
 

Am 25.05.2014 um 18:36 schrieb Olaf Wagner:

> On Sun, 25 May 2014 22:35:09 +0800
> Bruce Axtens <bruce.axtens at gmail.com> wrote:
> 
>> Dear Sir
>> 
>> Should I assume that CM3 is alive, in palliative care or dead? The trac
>> system is full of spam and the roadmap hasn't moved for 3 years.
>> 
>> I had a long and fruitful relationship with Modula-2 years ago and thought
>> that perhaps I could restart things with CM3.
> 
> There is certainly some activity in M3 development recently, though
> the community is rather small.
> The trac system has never been much used by the community members;
> and the WWW presentation and regression testing system has lacked
> my support, as I couldn't spent any time on these topics for
> almost 3 years.
> 
> You should check the m3devel mailing list for news though:
> https://mail.elegosoft.com/pipermail/m3devel
> 
> There has been a lot of activity at the beginning of this year;
> it has ceased again during recent weeks.
> 
> All CVS commits can be found here:
> https://mail.elegosoft.com/pipermail/m3commit
> 
> A new release is long overdue; I'm afraid I cannot do the release
> engineering this time.
> 
> There has been some effort on moving the CVS repositories to git;
> I'm not sure what the status is there, too.
> 
> Any help wrt. documentation, presentation or software is greatly
> appreciated ;-)
> 
> Regards,
> 
> Olaf Wagner
> -- 
> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 



From adacore at marino.st  Wed May 28 10:41:06 2014
From: adacore at marino.st (John Marino)
Date: Wed, 28 May 2014 10:41:06 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
Message-ID: <5385A122.4020205@marino.st>

On 5/28/2014 08:20, Jay K wrote:
>  Sorry, my life has really changed and I have hardly any time now..
>  I still hope to come back.
> 
> 
> 
> The C backend works quite well.
> I was able to cross-to and self-world-build many platforms.
> Including bring up new platform: AMD64_NT.
> There is a jmpbuf alignment problem on AMD64_NT worked around by using
> libcmt.lib instead of msvcrt.dll.
> jmpbuf remains a platform-specificity in the frontend.
> 
> 
>  I believe we had mostly good experience with Linux/arm and maybe
> Dragonfly?
>  Not sure.


Hi Jay,
The assumptions I was working on was this:
A) There has been no release
B) We want to convert FreeBSD to c-backend
C) There is no support for DragonFly, we want to add that
D) We want to do B+C before the next release

So I thought there was some build-framework stuff that needed to happen
for FreeBSD and DragonFly prior to the release, otherwise we'd just have
to patch it all up and we were trying to avoid needing those patches.

I am not even at the point of evaluating the C-Backend.
Maybe if there was a release candidate then I could figure out what's
missing a provide patches.

At the very, very least we could have CM3 on github and build from a
specific tag.  I am not wild about that, but it's better than what's
available now.  (FreeBSD ports can build straight from github although
it's not really encouraged)

So if for no other reason, I'd like to see CM3 migrate to github ASAP.

Regards,
John


From jay.krell at cornell.edu  Wed May 28 19:08:31 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 17:08:31 +0000
Subject: [M3devel] Installing on Ubuntu Trusty Tahr
In-Reply-To: <8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org>
References: <535FA2B2.70108@gmail.com>, ,
	<A81F3A2D-A99C-4C29-81C5-6EFDA6D1BC98@m3w.org>,
	<COL130-W1019248A16E06F580E4D88E6250@phx.gbl>,
	<8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org>
Message-ID: <COL130-W8356F05B7DCCB173BE7B78E6250@phx.gbl>

The .debs do have other files, at least one. See the code I pointed at.
I don't make them with the usual tools,
for an eaiser potential cross build story -- fewer dependencies.
It worked at the time.
 
 
# Debian architecture strings:
# see http://www.debian.org/doc/debian-policy/footnotes.html#f73

DebianArchitecture = {
  "LINUXLIBC6" : "i386",
  "FreeBSD4" : "i386",
  "NT386" : "i386",
  "I386" : "i386",
  "IA64" : "ia64",
  "ALPHA" : "alpha",
  "AMD64" : "amd64",
  "HPPA" : "hppa",
  "PA32" : "hppa",
  "PA64" : "hppa",
  "MIPS" : "mips",
  "MIPS32" : "mips",
  "MIPS64" : "mips",
  "PPC" : "powerpc",
  "PPC32" : "powerpc",
  "PPC64" : "ppc",
  "SOLsun" : "sparc",
  "SOLgnu" : "sparc",
  "SPARC" : "sparc",
  "SPARC32" : "sparc",
  "SPARC64" : "sparc",
  }

def MakeDebianPackage(input, prefix):
#
# .deb file format:
# an ar archive containing (I think the order matters):
#   debian-binary:
#     text file that just says "2.0\n"
#   control.tar.gz:
#     metadata, minimum is control file
#   data.tar.gz or .bz2 or .lzma
#     payload
# User has no choice where the install goes.
#
    if SearchPath("lzma"):
        compresser = "lzma"
        compressed_extension = "lzma"
    elif isfile("/home/jkrell/bin/lzma"):
        compresser = "/home/jkrell/bin/lzma"
        compressed_extension = "lzma"
    else:
        compresser = "gzip"
        compressed_extension = "gz"
    # while testing, gzip is much faster
    # compresser = "gzip"
    # compressed_extension = "gz"
    print("cd " + input)
    os.chdir(input)
    CreateDirectory("./debian")
    MoveSkel(prefix)
    newline = "\012" # take no chances
    open("./debian-binary", "w").write("2.0" + newline)
    os.chdir("./debian")
    architecture = DebianArchitecture.get(Target) or DebianArchitecture.get(Target[:Target.index("_")])
    control = (
      "Package: cm3-" + Target + "-" + CM3VERSION + newline
    + "Version: 1.0" + newline
    + "Maintainer: somebody at somewhere.com" + newline
    + "Architecture: " + architecture + newline
    + "Description: good stuff" + newline)
    print("control:" + control)
    open("./control", "w").write(control)

    command = "tar cf ../control.tar ."
    print(command)
    os.system(command)

    command = "gzip ../control.tar"
    print(command)
    os.system(command)

    os.chdir(input)
    command = "tar cf data.tar ." + prefix
    if isfile("data.tar." + compressed_extension) or isfile("data.tar"):
        print("skipping " + command)
    else:
        print(command)
        os.system(command)
    command = compresser + " data.tar"
    if isfile("data.tar." + compressed_extension):
        print("skipping " + command)
    else:
        print(command)
        os.system(command)

    command = "ar cr " + input + ".deb debian-binary control.tar.gz data.tar." + compressed_extension
    print(command)
    os.system(command)
    RestoreSkel(prefix)

 
 - Jay


 
From: estellnb at elstel.org
Date: Wed, 28 May 2014 10:03:21 +0200
To: jay.krell at cornell.edu; dragisha at m3w.org; bruceax at gmail.com
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr

If it is a true .deb you need to apply > ar x xy.deband then> tar -xvJ <~/aux/data.tar.xz
(A real  .deb will also contain a control .tar.gz with control, shlibs, md5sums, postinst, etc.)
It should be built with> pushd BUILD> dpkg-buildpackage -sa -kmy at email.org> popdand checked with> lintian -EvIL +pedantic my.dsc

Am 28.05.2014 um 08:42 schrieb Jay K:.deb is just a .tar.gz or .tar.bz2 or .tar.xz with a little bit more around it.
They can be fancy but ours is not, it is just a compressed .tar.
Can you just crack it open and install the underlying parts?
It is likely "position independent" and you can extract it anywhere in your file system -- /usr/local/cm3, $HOME/cm3, etc.

I build them pretty "manually" see here:
https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/pylib.py  
the function MakeDebianPackage
Ok, it is an actually an "ar" file, and inside the main thing is data.tar with some compression like .gz or .xz.

 - Jay

From: dragisha at m3w.org
Date: Thu, 1 May 2014 19:49:28 +0200
To: bruceax at gmail.com
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Installing on Ubuntu Trusty Tahr

It looks like it is external to cm3 anything. But maybe .deb is incorrect in some subtle way.
--Dragi?a Duri?dragisha at m3w.org

On 29 Apr 2014, at 15:01, bruce axtens <bruceax at gmail.com> wrote:I am having difficulty installing cm3-LINUXLIBC6-REL.deb on Trusty? When I try to install it with Ubuntu Software Centre I get told the following:

Lintian check results for /home/bruce/Downloads/cm3-LINUXLIBC6-REL.deb:
Can't use an undefined value as an ARRAY reference at /usr/share/perl5/
Lintian/Collect/Package.pm line 513, <$_[...]> line 7562.

Is this a Perl issue or an installer issue?

-- Bruce
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/cca064e6/attachment-0002.html>

From jay.krell at cornell.edu  Wed May 28 19:31:43 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 17:31:43 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <5385A122.4020205@marino.st>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
Message-ID: <COL130-W77F293FE76307E7C81612DE6250@phx.gbl>

 > A) There has been no release

 
There has been no release.
 
 
> B) We want to convert FreeBSD to c-backend


I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
 
 
Specifically, I no longer have shelves full of a myriad of computers, but I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux, OpenBSD, FreeBSD, NetBSD), I have the Solaris opencsw sparc32/sparc64/x86/amd64 machines, I have the Mac, I have Windows, I have the Elego Debian/amd64 maybe Debian/x86 machine and I tested many/all of these successfully. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't offer the thread/suspend/getcontext stuff -- something cooperative suspend will fix eventually.
 
 
Adding new platforms is fairly straightforward. Far more than it used to be.
You just make few scattered easy edits.
My pseudo goal is to drive that down to be easier and easier.
Several platforms have been relatively recently brought back or brought up or at least shown to work completely or almost to me.
 
What remains unclear to me is the consensus decision on exactly what the switch looks like.
  1) unconditionally switch all targets  
  2) leave it as some sort of user option  
  3) have new targets only supported using the C backend 
 
 
There are downsides to the C backend. Specifically:
  1) On systems that support m3gdb, debugging is not as good as with m3gdb 
   m3gdb is an old fork of gdb, doesn't work on all platforms (e.g. Darwin, HP-UX, NT), but does work on many. 
  2) Compilation is noticeably slower. 
  3) The output is not necessarily ABI compatible with the non-C backend. 
 
 
My inclination is unconditional switch to C backend for all targets that use m3cc, leave m3cc to bit-rot.
Think more about the integrated backend. In reality, given more time, I'd like to extend the integrated backend to support more targets. But that so far seems beyond most of our scopes.
 
The safe thing is user-option. But it is also confusing.
Given the ABI variation, do we double all the platforms?
I386_LINUX and I386_LINUX_C?
 
 
 And then later POSIX_32BIT_LITTLEENDIAN_C? 
 And then later GENERIC_C? 
 
Do we switch the existing ones, and introduce I386_LINUX_M3CC?
 
 
 > C) There is no support for DragonFly, we want to add that
 
This is easy.

> D) We want to do B+C before the next release
 
C is easy. B requires a decision/consensus.
 
Thanks,
 - Jay


 
> Date: Wed, 28 May 2014 10:41:06 +0200
> From: adacore at marino.st
> To: jay.krell at cornell.edu; hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; bruce.axtens at gmail.com
> Subject: Re: [M3devel] Status of CM3
> 
> On 5/28/2014 08:20, Jay K wrote:
> >  Sorry, my life has really changed and I have hardly any time now..
> >  I still hope to come back.
> > 
> > 
> > 
> > The C backend works quite well.
> > I was able to cross-to and self-world-build many platforms.
> > Including bring up new platform: AMD64_NT.
> > There is a jmpbuf alignment problem on AMD64_NT worked around by using
> > libcmt.lib instead of msvcrt.dll.
> > jmpbuf remains a platform-specificity in the frontend.
> > 
> > 
> >  I believe we had mostly good experience with Linux/arm and maybe
> > Dragonfly?
> >  Not sure.
> 
> 
> Hi Jay,
> The assumptions I was working on was this:
> A) There has been no release
> B) We want to convert FreeBSD to c-backend
> C) There is no support for DragonFly, we want to add that
> D) We want to do B+C before the next release
> 
> So I thought there was some build-framework stuff that needed to happen
> for FreeBSD and DragonFly prior to the release, otherwise we'd just have
> to patch it all up and we were trying to avoid needing those patches.
> 
> I am not even at the point of evaluating the C-Backend.
> Maybe if there was a release candidate then I could figure out what's
> missing a provide patches.
> 
> At the very, very least we could have CM3 on github and build from a
> specific tag.  I am not wild about that, but it's better than what's
> available now.  (FreeBSD ports can build straight from github although
> it's not really encouraged)
> 
> So if for no other reason, I'd like to see CM3 migrate to github ASAP.
> 
> Regards,
> John
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/21fbcbf9/attachment-0002.html>

From mika at async.caltech.edu  Wed May 28 20:04:38 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Wed, 28 May 2014 11:04:38 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
Message-ID: <20140528180438.09C0F1A2097@async.async.caltech.edu>


Yes it worked pretty well as far as I remember.  There was still some
issue with a segfault we never debugged, but that was compiling all the
CM3 stuff plus my own big repository.  You were able to help me bootstrap
the regular compiler on ARM so that is what the regular ARM_LINUX is now
(for Raspberry Pi).

     Mika

---

Jay wrote:
The C backend works quite well.
I was able to cross-to and self-world-build many platforms.
Including bring up new platform: AMD64_NT.
There is a jmpbuf alignment problem on AMD64_NT worked around by using libcmt.lib instead of msvcrt.dll.
jmpbuf remains a platform-specificity in the frontend.


 I believe we had mostly good experience with Linux/arm and maybe Dragonfly? 
 Not sure.


 Going through C source and C compiler is noticable slower. 




From adacore at marino.st  Wed May 28 20:24:06 2014
From: adacore at marino.st (John Marino)
Date: Wed, 28 May 2014 20:24:06 +0200
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
Message-ID: <538629C6.9070200@marino.st>

On 5/28/2014 19:31, Jay K wrote:
>> B) We want to convert FreeBSD to c-backend
> 
> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>  
>  > C) There is no support for DragonFly, we want to add that
>  
> This is easy.
> 
>> D) We want to do B+C before the next release
>  
> C is easy. B requires a decision/consensus.
>  

Hi Jay,
B requires a decision if it replaces m3cc on FreeBSD.
However if FreeBSD can keep m3cc but also be configured to build with
C-backend, then it shouldn't need a consensus as everyone wins.

I realize that that the real question is not about FreeBSD, but rather a
project-wide decision, however.

John


From mika at async.caltech.edu  Wed May 28 20:25:03 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Wed, 28 May 2014 11:25:03 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
Message-ID: <20140528182503.087801A2095@async.async.caltech.edu>

Jay K writes:
>--_af0f88f0-4e39-4643-873b-5267a8c2a602_
...
>> B) We want to convert FreeBSD to c-backend
>
>
>I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>=20
>=20
>Specifically=2C I no longer have shelves full of a myriad of computers=2C b=
>ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux=2C Open=
>BSD=2C FreeBSD=2C NetBSD)=2C I have the Solaris opencsw sparc32/sparc64/x86=
>/amd64 machines=2C I have the Mac=2C I have Windows=2C I have the Elego Deb=
>ian/amd64 maybe Debian/x86 machine and I tested many/all of these successfu=
>lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't of=
>fer the thread/suspend/getcontext stuff -- something cooperative suspend wi=
>ll fix eventually.
...

I don't think the C backend is perfect.  If you want to switch
unconditionally, I'll have to make time to help debug it.  My fuzzy 
memory, as I mentioned, is that there's some unexplained segfault.
Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
Something like that?  Ring a bell for anyone?

I quite like the native backends.  The code is more compact than
the C backend's.  I haven't done a performance comparison... I know
performance of Modula-3 code has in general been sliding backwards
through the versions.  Things just get slower and slower and slower
with time.  I think it's a shame because Modula-3's niche (well the one
I am interested in) is to be "almost the performance and simplicity of
C with the safety of Java (and some cool software engineering stuff)".
CM3 definitely compromised this, and while they added some cool new
features, most of them (e.g., dynamic relinking of running programs) as
far as I know are not being used.  The work on cleaning up TEXTs has 
gone a ways to remedying the situation but I think there's much else.
Ok now I'm off on a tangent...

    Mika


From hosking at cs.purdue.edu  Wed May 28 21:32:40 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 28 May 2014 15:32:40 -0400
Subject: [M3devel] Status of CM3
In-Reply-To: <20140528182503.087801A2095@async.async.caltech.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<20140528182503.087801A2095@async.async.caltech.edu>
Message-ID: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>

What is really needed is some time and attention put in to bring the CM3 runtime up to date with respect to advances in the field of runtime systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" locking), cooperative GC safepoints, integration with a modern code generator (LLVM!), on-the-fly GC (avoiding the need for stopping the world).

It would be wonderful to attack these, but they are also somewhat interrelated (on-the-fly depends on per-thread safepoint handshakes, biased locking requires compiler work, etc.).  So they cannot be simply carved off independently.

On May 28, 2014, at 2:25 PM, mika at async.caltech.edu wrote:

> Jay K writes:
>> --_af0f88f0-4e39-4643-873b-5267a8c2a602_
> ...
>>> B) We want to convert FreeBSD to c-backend
>> 
>> 
>> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>> =20
>> =20
>> Specifically=2C I no longer have shelves full of a myriad of computers=2C b=
>> ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux=2C Open=
>> BSD=2C FreeBSD=2C NetBSD)=2C I have the Solaris opencsw sparc32/sparc64/x86=
>> /amd64 machines=2C I have the Mac=2C I have Windows=2C I have the Elego Deb=
>> ian/amd64 maybe Debian/x86 machine and I tested many/all of these successfu=
>> lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't of=
>> fer the thread/suspend/getcontext stuff -- something cooperative suspend wi=
>> ll fix eventually.
> ...
> 
> I don't think the C backend is perfect.  If you want to switch
> unconditionally, I'll have to make time to help debug it.  My fuzzy 
> memory, as I mentioned, is that there's some unexplained segfault.
> Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
> Something like that?  Ring a bell for anyone?
> 
> I quite like the native backends.  The code is more compact than
> the C backend's.  I haven't done a performance comparison... I know
> performance of Modula-3 code has in general been sliding backwards
> through the versions.  Things just get slower and slower and slower
> with time.  I think it's a shame because Modula-3's niche (well the one
> I am interested in) is to be "almost the performance and simplicity of
> C with the safety of Java (and some cool software engineering stuff)".
> CM3 definitely compromised this, and while they added some cool new
> features, most of them (e.g., dynamic relinking of running programs) as
> far as I know are not being used.  The work on cleaning up TEXTs has 
> gone a ways to remedying the situation but I think there's much else.
> Ok now I'm off on a tangent...
> 
>   Mika

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/2368d3c9/attachment-0002.html>

From jay.krell at cornell.edu  Wed May 28 22:13:56 2014
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 28 May 2014 20:13:56 +0000
Subject: [M3devel] Status of CM3
In-Reply-To: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>,
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, ,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, ,
	<5384B209.3080504@marino.st>, ,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>,
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>, ,
	<5385A122.4020205@marino.st>,
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>,
	<20140528182503.087801A2095@async.async.caltech.edu>,
	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
Message-ID: <COL130-W29A4F6A942B48899A58222E6250@phx.gbl>

I'd be happy with:
  - cooperative GC, for portability, it'd remove a lot of our #ifdefs, fix PPC_DARWIN under Rosetta, and address a nagging concern I have for even NT/x86 on AMD64 wrt SuspendThread near-in-time to syscalls.
  - no-stop-the-world, for scaling 
 
Aren't they fairly standalone?
I could do without LLVM at this point. C/C++ backend is more portable.
I'd like to hope/depend that underlying pthreads/win32 does a good job with locking.
 
 - Jay

 
From: hosking at cs.purdue.edu
Date: Wed, 28 May 2014 15:32:40 -0400
To: mika at async.caltech.edu
CC: m3devel at elegosoft.com; jay.krell at cornell.edu
Subject: Re: [M3devel] Status of CM3

What is really needed is some time and attention put in to bring the CM3 runtime up to date with respect to advances in the field of runtime systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" locking), cooperative GC safepoints, integration with a modern code generator (LLVM!), on-the-fly GC (avoiding the need for stopping the world).

It would be wonderful to attack these, but they are also somewhat interrelated (on-the-fly depends on per-thread safepoint handshakes, biased locking requires compiler work, etc.).  So they cannot be simply carved off independently.

On May 28, 2014, at 2:25 PM, mika at async.caltech.edu wrote:

Jay K writes:
--_af0f88f0-4e39-4643-873b-5267a8c2a602_
...
B) We want to convert FreeBSD to c-backend


I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
=20
=20
Specifically=2C I no longer have shelves full of a myriad of computers=2C b=
ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. Linux=2C Open=
BSD=2C FreeBSD=2C NetBSD)=2C I have the Solaris opencsw sparc32/sparc64/x86=
/amd64 machines=2C I have the Mac=2C I have Windows=2C I have the Elego Deb=
ian/amd64 maybe Debian/x86 machine and I tested many/all of these successfu=
lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta doesn't of=
fer the thread/suspend/getcontext stuff -- something cooperative suspend wi=
ll fix eventually.
...

I don't think the C backend is perfect.  If you want to switch
unconditionally, I'll have to make time to help debug it.  My fuzzy 
memory, as I mentioned, is that there's some unexplained segfault.
Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
Something like that?  Ring a bell for anyone?

I quite like the native backends.  The code is more compact than
the C backend's.  I haven't done a performance comparison... I know
performance of Modula-3 code has in general been sliding backwards
through the versions.  Things just get slower and slower and slower
with time.  I think it's a shame because Modula-3's niche (well the one
I am interested in) is to be "almost the performance and simplicity of
C with the safety of Java (and some cool software engineering stuff)".
CM3 definitely compromised this, and while they added some cool new
features, most of them (e.g., dynamic relinking of running programs) as
far as I know are not being used.  The work on cleaning up TEXTs has 
gone a ways to remedying the situation but I think there's much else.
Ok now I'm off on a tangent...

   Mika


Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140528/c8543840/attachment-0002.html>

From mika at async.caltech.edu  Wed May 28 22:32:18 2014
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Wed, 28 May 2014 13:32:18 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>,
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>,
	<5384B209.3080504@marino.st>,
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>,
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<20140528182503.087801A2095@async.async.caltech.edu>
	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
Message-ID: <20140528203218.658CC1A2096@async.async.caltech.edu>


All that stuff is important but sometimes you just want a fast
single-threaded parser (or whatever)...

I *think* that if I write a program using ARRAY OF CHAR and hand-code everything 
not to allocate memory, etc., I get about as good performance in native CM3 as
I used to see in PM3.  It shouldn't be any slower than C, whether that is true
or not I don't know.

It is easier to write such (old-fashioned) programs in Modula-3 than in C, which
is one of the reasons I really like this programming language...

It would be nice if the performance loss in going to TEXT (for example) were not
that great.  Partly that has to do with some of the issues you talk about (GC/locking),
of course.

Tony Hosking writes:
>
>--Apple-Mail=_0963FC1A-17A1-4B57-93C6-C196F4ECCDC1
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=us-ascii
>
>What is really needed is some time and attention put in to bring the CM3 =
>runtime up to date with respect to advances in the field of runtime =
>systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" =
>locking), cooperative GC safepoints, integration with a modern code =
>generator (LLVM!), on-the-fly GC (avoiding the need for stopping the =
>world).
>
>It would be wonderful to attack these, but they are also somewhat =
>interrelated (on-the-fly depends on per-thread safepoint handshakes, =
>biased locking requires compiler work, etc.).  So they cannot be simply =
>carved off independently.
>
>On May 28, 2014, at 2:25 PM, mika at async.caltech.edu wrote:
>
>> Jay K writes:
>>> --_af0f88f0-4e39-4643-873b-5267a8c2a602_
>> ...
>>>> B) We want to convert FreeBSD to c-backend
>>>=20
>>>=20
>>> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C =
>backend.
>>> =3D20
>>> =3D20
>>> Specifically=3D2C I no longer have shelves full of a myriad of =
>computers=3D2C b=3D
>>> ut I have x86 and AMD64 VMs on a Mac readily accessible (i.e. =
>Linux=3D2C Open=3D
>>> BSD=3D2C FreeBSD=3D2C NetBSD)=3D2C I have the Solaris opencsw =
>sparc32/sparc64/x86=3D
>>> /amd64 machines=3D2C I have the Mac=3D2C I have Windows=3D2C I have =
>the Elego Deb=3D
>>> ian/amd64 maybe Debian/x86 machine and I tested many/all of these =
>successfu=3D
>>> lly. PPC/Mac can't entirely be tested on x86/Mac because Rosetta =
>doesn't of=3D
>>> fer the thread/suspend/getcontext stuff -- something cooperative =
>suspend wi=3D
>>> ll fix eventually.
>> ...
>>=20
>> I don't think the C backend is perfect.  If you want to switch
>> unconditionally, I'll have to make time to help debug it.  My fuzzy=20
>> memory, as I mentioned, is that there's some unexplained segfault.
>> Ah it was with Juno, I think.  Trestle?  Overflow in window resizing?
>> Something like that?  Ring a bell for anyone?
>>=20
>> I quite like the native backends.  The code is more compact than
>> the C backend's.  I haven't done a performance comparison... I know
>> performance of Modula-3 code has in general been sliding backwards
>> through the versions.  Things just get slower and slower and slower
>> with time.  I think it's a shame because Modula-3's niche (well the =
>one
>> I am interested in) is to be "almost the performance and simplicity of
>> C with the safety of Java (and some cool software engineering stuff)".
>> CM3 definitely compromised this, and while they added some cool new
>> features, most of them (e.g., dynamic relinking of running programs) =
>as
>> far as I know are not being used.  The work on cleaning up TEXTs has=20=
>
>> gone a ways to remedying the situation but I think there's much else.
>> Ok now I'm off on a tangent...
>>=20
>>   Mika
>
>Antony Hosking | Associate Professor | Computer Science | Purdue =
>University
>305 N. University Street | West Lafayette | IN 47907 | USA
>Mobile +1 765 427 5484
>
>
>
>
>
>
>--Apple-Mail=_0963FC1A-17A1-4B57-93C6-C196F4ECCDC1
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/html;
>	charset=us-ascii
>
><html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
>charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">What =
>is really needed is some time and attention put in to bring the CM3 =
>runtime up to date with respect to advances in the field of runtime =
>systems (as witnessed by Java, Go, etc.): lightweight locking ("biased" =
>locking), cooperative GC safepoints, integration with a modern code =
>generator (LLVM!), on-the-fly GC (avoiding the need for stopping the =
>world).<br><br>It would be wonderful to attack these, but they are also =
>somewhat interrelated (on-the-fly depends on per-thread safepoint =
>handshakes, biased locking requires compiler work, etc.). &nbsp;So they =
>cannot be simply carved off independently.<br><br>On May 28, 2014, at =
>2:25 PM, <a =
>href=3D"mailto:mika at async.caltech.edu">mika at async.caltech.edu</a> =
>wrote:<br><br><blockquote type=3D"cite">Jay K writes:<br><blockquote =
>type=3D"cite">--_af0f88f0-4e39-4643-873b-5267a8c2a602_<br></blockquote>...=
><br><blockquote type=3D"cite"><blockquote type=3D"cite">B) We want to =
>convert FreeBSD to c-backend<br></blockquote><br><br>I believe I tested =
>FreeBSD/x86 and/or FreeBSD/amd64 with the C =
>backend.<br>=3D20<br>=3D20<br>Specifically=3D2C I no longer have shelves =
>full of a myriad of computers=3D2C b=3D<br>ut I have x86 and AMD64 VMs =
>on a Mac readily accessible (i.e. Linux=3D2C Open=3D<br>BSD=3D2C =
>FreeBSD=3D2C NetBSD)=3D2C I have the Solaris opencsw =
>sparc32/sparc64/x86=3D<br>/amd64 machines=3D2C I have the Mac=3D2C I =
>have Windows=3D2C I have the Elego Deb=3D<br>ian/amd64 maybe Debian/x86 =
>machine and I tested many/all of these successfu=3D<br>lly. PPC/Mac =
>can't entirely be tested on x86/Mac because Rosetta doesn't of=3D<br>fer =
>the thread/suspend/getcontext stuff -- something cooperative suspend =
>wi=3D<br>ll fix eventually.<br></blockquote>...<br><br>I don't think the =
>C backend is perfect. &nbsp;If you want to switch<br>unconditionally, =
>I'll have to make time to help debug it. &nbsp;My fuzzy <br>memory, as I =
>mentioned, is that there's some unexplained segfault.<br>Ah it was with =
>Juno, I think. &nbsp;Trestle? &nbsp;Overflow in window =
>resizing?<br>Something like that? &nbsp;Ring a bell for anyone?<br><br>I =
>quite like the native backends. &nbsp;The code is more compact =
>than<br>the C backend's. &nbsp;I haven't done a performance =
>comparison... I know<br>performance of Modula-3 code has in general been =
>sliding backwards<br>through the versions. &nbsp;Things just get slower =
>and slower and slower<br>with time. &nbsp;I think it's a shame because =
>Modula-3's niche (well the one<br>I am interested in) is to be "almost =
>the performance and simplicity of<br>C with the safety of Java (and some =
>cool software engineering stuff)".<br>CM3 definitely compromised this, =
>and while they added some cool new<br>features, most of them (e.g., =
>dynamic relinking of running programs) as<br>far as I know are not being =
>used. &nbsp;The work on cleaning up TEXTs has <br>gone a ways to =
>remedying the situation but I think there's much else.<br>Ok now I'm off =
>on a tangent...<br><br> &nbsp;&nbsp;Mika<br></blockquote><br><div>
><span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
>0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
>0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0px;  "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
>Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
>font-weight: normal; letter-spacing: normal; line-height: normal; =
>orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
>break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
>after-white-space; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF"><font =
>class=3D"Apple-style-span" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Antony =
>Hosking</span></span></font></font><font class=3D"Apple-style-span" =
>face=3D"Gill Sans"><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-converted-space">&nbsp;</span>|<span =
>class=3D"Apple-converted-space">&nbsp;</span></span></span><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; "><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; =
>">Associate Professor</span></span><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; "><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; ">&nbsp;| Computer Science | Purdue =
>University</span></span></font></div><div><font class=3D"Apple-style-span"=
> face=3D"GillSans-Light"><span class=3D"Apple-style-span" =
>style=3D"font-family: GillSans-Light; ">305 N. University Street | West =
>Lafayette | IN 47907 | USA</span></font></div><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Mobile</span></span></font><font =
>class=3D"Apple-style-span" face=3D"GillSans-Light"><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-converted-space">&nbsp;</span>+1 765 427 =
>5484</span></span></font></div><div><font class=3D"Apple-style-span" =
>face=3D"GillSans-Light"><br =
>class=3D"khtml-block-placeholder"></font></div></span></span></span></span=
>></span></span></span><br =
>class=3D"Apple-interchange-newline"></span></div></span></div></span><br =
>class=3D"Apple-interchange-newline"></span><br =
>class=3D"Apple-interchange-newline">
></div>
><br></body></html>=
>
>--Apple-Mail=_0963FC1A-17A1-4B57-93C6-C196F4ECCDC1--


From rcolebur at SCIRES.COM  Thu May 29 05:12:25 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 03:12:25 +0000
Subject: [M3devel] compilation problems with assertions in RTCollector.m3
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6C9B@ATLEX04-SRV.SCIRES.LOCAL>

Tony:

There is an error in "cm3\m3-libs\m3core\src\runtime\common\RTCollector.m3" at line 593.
"hdr" is not defined.
>From context, I'm not sure if it should be "h" or "he", but I've taken a guess on my local copy and changed it to "h".
I'm now running into additional problems.

So, I'll let you make the appropriate fix in the repository.

new source -> compiling RTCollector.m3
"..\src\runtime\common\RTCollector.m3", line 593: undefined (hdr)

Thanks,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Tuesday, May 27, 2014 11:57 AM
To: Coleburn, Randy
Cc: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] compilation problems with assertions in RTCollector.m3

Just committed a (hopeful) fix.  Please give it a try.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484






On May 24, 2014, at 12:57 AM, Coleburn, Randy <rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>> wrote:


I updated my sandbox to be current with the HEAD branch via CVS, then tried to rebuild everything.

I first built a minimal distribution on Windows XP.  Everything seemed to work fine.

Now, using my newly rebuilt cm3.exe, I decided to rebuild everything.  Unfortunately, now I'm running into problems even in the first stage.

Here are some examples of the errors I am getting.  These runtime errors happen compiling various packages.  (I've tried rebuilding several times.)

I show 3 separate incidents below and the last one has a partial stack trace.  In each case, there is an assertion failure in the RTCollector while running the compiler:

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 699
***

***
*** runtime error:
***    <*ASSERT*> failed.
***    file "..\src\runtime\common\RTCollector.m3", line 1092
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x12f374   0x6ca19e  CleanBetween + 0x22 in ..\src\runtime\common\RTCollector.m3
0x12f3ac   0x6ca031  CopySome + 0xeb in ..\src\runtime\common\RTCollector.m3
0x12f3b8   0x6c9b02  CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3
0x12f3c8   0x6c94d6  CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3
0x12f40c   0x6c916a  CollectEnough + 0x9b in ..\src\runtime\common\RTCollector.m3
0x12f44c   0x6dc586  AllocTraced + 0xd3 in ..\src\runtime\common\RTAllocator.m3
0x12f480   0x6dbbd8  GetTracedObj + 0x86 in ..\src\runtime\common\RTAllocator.m3
0x12f49c   0x6db70c  AllocateTracedObj + 0x15 in ..\src\runtime\common\RTAllocator.m3
0x12f4d0   0x529913  Init_chars + 0x20b in ..\src\misc\CG.m3
0x12f4f8   0x4f948b  Init_chars + 0xb9 in ..\src\misc\M3String.m3
.........  .........  ... more frames ...

WARNING:  Encountered an error when processing package "m3-sys\m3front" for "-build".

Any help in solving this problem would be appreciated.

Thanks,
Randy Coleburn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/abd55109/attachment-0002.html>

From rcolebur at SCIRES.COM  Thu May 29 07:35:13 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 05:35:13 +0000
Subject: [M3devel] good news on Thread Tester program
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EA8@ATLEX04-SRV.SCIRES.LOCAL>

Tony & Mika:

I have good news to report about the Thread Tester program on Windows XP.

After making the change to RTCollector.m3" at line 593 from "hdr" to "h" and rebuilding everything again, I am now able FOR THE FIRST TIME EVER to get the Thread Tester program to run to completion!

See output below, including verbose mode.  I've also run with "-tests ALL" and it still runs to completion.

So, I think Tony's last round of changes may have been instrumental in fixing a problem with the collector, or either my edit did something weird in which case this may give Tony another clue to the puzzle.

--Randy Coleburn

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread>NT386\threadtest.exe
Writing file...done
Creating read threads...done
Creating fork threads...done
Creating alloc threads...done
Creating lock threads...done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
All tests complete.  Congratulations.


C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread>NT386\threadtest.exe -verbose
Writing file...done
Creating read threads...
   read=0
   read=1
   read=2
done
Creating fork threads...
   fork=9
   fork=10
   fork=11
done
Creating alloc threads...
   alloc=15
   alloc=16
   alloc=17
done
Creating lock threads...
   lock=21
   lock=22
   lock=23
done
running...printing oldest/median age/newest
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 54 loops.
   read Thread 1 completed 59 loops.
   read Thread 2 completed 74 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 4 loops.
   alloc Thread 15 completed 4713 loops.
   alloc Thread 16 completed 2190 loops.
   alloc Thread 17 completed 2292 loops.
   lock Thread 21 completed 1684145 loops.
   lock Thread 22 completed 3063707 loops.
   lock Thread 23 completed 3541711 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 60 loops.
   read Thread 1 completed 111 loops.
   read Thread 2 completed 64 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 6 loops.
   alloc Thread 15 completed 3280 loops.
   alloc Thread 16 completed 2470 loops.
   alloc Thread 17 completed 1307 loops.
   lock Thread 21 completed 2317559 loops.
   lock Thread 22 completed 3341857 loops.
   lock Thread 23 completed 3498231 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 19 loops.
   read Thread 1 completed 40 loops.
   read Thread 2 completed 56 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 2100 loops.
   alloc Thread 16 completed 1227 loops.
   alloc Thread 17 completed 1612 loops.
   lock Thread 21 completed 2281438 loops.
   lock Thread 22 completed 3874612 loops.
   lock Thread 23 completed 3777331 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 65 loops.
   read Thread 1 completed 67 loops.
   read Thread 2 completed 58 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 3860 loops.
   alloc Thread 16 completed 1897 loops.
   alloc Thread 17 completed 1261 loops.
   lock Thread 21 completed 2422432 loops.
   lock Thread 22 completed 3524236 loops.
   lock Thread 23 completed 3381697 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 62 loops.
   read Thread 1 completed 78 loops.
   read Thread 2 completed 105 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 8 loops.
   alloc Thread 15 completed 3659 loops.
   alloc Thread 16 completed 2552 loops.
   alloc Thread 17 completed 1838 loops.
   lock Thread 21 completed 1202534 loops.
   lock Thread 22 completed 2055904 loops.
   lock Thread 23 completed 2086094 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 57 loops.
   read Thread 1 completed 77 loops.
   read Thread 2 completed 64 loops.
   fork Thread 9 completed 8 loops.
   fork Thread 10 completed 9 loops.
   fork Thread 11 completed 8 loops.
   alloc Thread 15 completed 4430 loops.
   alloc Thread 16 completed 3199 loops.
   alloc Thread 17 completed 4229 loops.
   lock Thread 21 completed 1143292 loops.
   lock Thread 22 completed 1630285 loops.
   lock Thread 23 completed 2056873 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 36 loops.
   read Thread 1 completed 32 loops.
   read Thread 2 completed 61 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 2025 loops.
   alloc Thread 16 completed 669 loops.
   alloc Thread 17 completed 1874 loops.
   lock Thread 21 completed 2457649 loops.
   lock Thread 22 completed 4119545 loops.
   lock Thread 23 completed 3744966 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 19 loops.
   read Thread 1 completed 22 loops.
   read Thread 2 completed 23 loops.
   fork Thread 9 completed 4 loops.
   fork Thread 10 completed 4 loops.
   fork Thread 11 completed 5 loops.
   alloc Thread 15 completed 2785 loops.
   alloc Thread 16 completed 1408 loops.
   alloc Thread 17 completed 1687 loops.
   lock Thread 21 completed 2406833 loops.
   lock Thread 22 completed 4204846 loops.
   lock Thread 23 completed 4080463 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 34 loops.
   read Thread 1 completed 66 loops.
   read Thread 2 completed 70 loops.
   fork Thread 9 completed 6 loops.
   fork Thread 10 completed 6 loops.
   fork Thread 11 completed 6 loops.
   alloc Thread 15 completed 2967 loops.
   alloc Thread 16 completed 1514 loops.
   alloc Thread 17 completed 1045 loops.
   lock Thread 21 completed 2094655 loops.
   lock Thread 22 completed 3280113 loops.
   lock Thread 23 completed 3632821 loops.
..........laziest thread is 0/0/0 (tests: read 0/0/0 fork 0/0/0 alloc 0/0/0 lock 0/0/0)
   read Thread 0 completed 61 loops.
   read Thread 1 completed 14 loops.
   read Thread 2 completed 26 loops.
   fork Thread 9 completed 7 loops.
   fork Thread 10 completed 7 loops.
   fork Thread 11 completed 7 loops.
   alloc Thread 15 completed 3055 loops.
   alloc Thread 16 completed 1943 loops.
   alloc Thread 17 completed 915 loops.
   lock Thread 21 completed 2255832 loops.
   lock Thread 22 completed 3704985 loops.
   lock Thread 23 completed 3691192 loops.
All tests complete.  Congratulations.

C:\cm3\Sandbox\cm3\m3-libs\m3core\tests\thread>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/439c02ae/attachment-0002.html>

From rcolebur at SCIRES.COM  Thu May 29 07:40:15 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 05:40:15 +0000
Subject: [M3devel] build problems with libunicode
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>

I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).

The m3-libs\libunicode package fails to build (see errors below).

I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.

The problem module is: UnsafeUniCodec.m3

Thanks,
Randy Coleburn

C:\cm3\Sandbox\cm3\m3-libs\libunicode>cm3
--- building in NT386 ---

new source -> compiling UnsafeUniCodec.m3
"..\src\UnsafeUniCodec.m3", line 81: warning: not used (Sink)
"..\src\UnsafeUniCodec.m3", line 81: warning: not used (Wch)
"..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: UniCodec.Range
"..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Wr.Failure
"..\src\UnsafeUniCodec.m3", line 88: warning: not used (Source)
"..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.EndOfFile
"..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.Failure
"..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 96: warning: not used (Sink)
"..\src\UnsafeUniCodec.m3", line 96: warning: not used (Wch)
"..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: UniCodec.Range
"..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Wr.Failure
"..\src\UnsafeUniCodec.m3", line 105: warning: not used (Source)
"..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.EndOfFile
"..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.Failure
"..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Thread.Alerted
"..\src\UnsafeUniCodec.m3", line 126: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 154: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 155: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 195: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 196: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 237: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 238: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 280: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 679: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 680: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 681: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 682: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 736: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 737: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 738: LOOPHOLE: expression's size differs from type's
"..\src\UnsafeUniCodec.m3", line 739: LOOPHOLE: expression's size differs from type's
16 errors and 18 warnings encountered
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/3c462f6e/attachment-0002.html>

From rcolebur at SCIRES.COM  Thu May 29 07:44:29 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 05:44:29 +0000
Subject: [M3devel] build problems with "elego\prjm"
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6F20@ATLEX04-SRV.SCIRES.LOCAL>

I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).

The "elego\prjm" package fails to build (see errors below).

I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone wants to work on a solution.

Thanks,
Randy Coleburn

--- processing package "elego\prjm" ---
--- purging derived files from NT386 ---

--- cleaning NT386 ---

ignoring ..\src\m3overrides

--- building in NT386 ---

ignoring ..\src\m3overrides

C:\cm3\bin\m3bundle -name ProjectManagerBundle -element UsageHelp ..\src\UsageHelp -element compactrc ..\src\compactrc -element ShortUsageHelp ..\src\ShortUsageHelp
new source -> compiling ProjectManagerBundle.i3
new source -> compiling ProjectManagerBundle.m3
new source -> compiling Creation.i3
new source -> compiling Creation.m3

Fatal Error: bad version stamps: TimePrjDescTbl.i3

missing export: LongrealType.T imported by TimePrjDescTbl.i3
missing export: LongrealType.Brand imported by TimePrjDescTbl.i3

WARNING:  Encountered an error when processing package "elego\prjm" for "-build".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/b2ebf95c/attachment-0002.html>

From jay.krell at cornell.edu  Thu May 29 09:26:07 2014
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 29 May 2014 07:26:07 +0000
Subject: [M3devel] build problems with "elego\prjm"
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6F20@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6F20@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL130-W811DED36FA9471989BC550E6240@phx.gbl>

This might be a "builder" incrementality problem,
related to that this module was moved from libm3
to m3core, a while ago.

I don't think we cope with such movement correctly.
 
Can you be sure to clean rebuild m3core, libm3,
and prjm, and maybe everything else?

Given the unicode problem, maybe not.
 
Thanks,
 - Jay



 
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Thu, 29 May 2014 05:44:29 +0000
Subject: [M3devel] build problems with "elego\prjm"









I?ve been rebuilding everything from the HEAD branch on Windows XP (32-bit).
 
The ?elego\prjm? package fails to build (see errors below).
 
I haven?t taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone wants to work on a solution.
 
Thanks,
Randy Coleburn
 
--- processing package "elego\prjm" ---
--- purging derived files from NT386 ---
 
--- cleaning NT386 ---
 
ignoring ..\src\m3overrides
 
--- building in NT386 ---
 
ignoring ..\src\m3overrides
 
C:\cm3\bin\m3bundle -name ProjectManagerBundle -element UsageHelp ..\src\UsageHelp -element compactrc ..\src\compactrc -element ShortUsageHelp ..\src\ShortUsageHelp
new source -> compiling ProjectManagerBundle.i3
new source -> compiling ProjectManagerBundle.m3
new source -> compiling Creation.i3
new source -> compiling Creation.m3
 
Fatal Error: bad version stamps: TimePrjDescTbl.i3
 
missing export: LongrealType.T imported by TimePrjDescTbl.i3
missing export: LongrealType.Brand imported by TimePrjDescTbl.i3
 
WARNING:  Encountered an error when processing package "elego\prjm" for "-build".
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/281f1505/attachment-0002.html>

From jay.krell at cornell.edu  Thu May 29 02:26:24 2014
From: jay.krell at cornell.edu (Jay)
Date: Wed, 28 May 2014 17:26:24 -0700
Subject: [M3devel] Status of CM3
In-Reply-To: <538629C6.9070200@marino.st>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>
	<5384B209.3080504@marino.st>
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>
	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<538629C6.9070200@marino.st>
Message-ID: <310E0B12-3444-4235-9157-A677C642F5F8@gmail.com>

I'm afraid offering both will lead to disuse of one and/or double test matrix.

Btw though FreeBSD and Dragonfly -- no relationship from our point of view. 

The C backend runs on any host & whether or not it is used can be a per target decision.

 - Jay

On May 28, 2014, at 11:24 AM, John Marino <adacore at marino.st> wrote:

> On 5/28/2014 19:31, Jay K wrote:
>>> B) We want to convert FreeBSD to c-backend
>> 
>> I believe I tested FreeBSD/x86 and/or FreeBSD/amd64 with the C backend.
>> 
>>> C) There is no support for DragonFly, we want to add that
>> 
>> This is easy.
>> 
>>> D) We want to do B+C before the next release
>> 
>> C is easy. B requires a decision/consensus.
> 
> Hi Jay,
> B requires a decision if it replaces m3cc on FreeBSD.
> However if FreeBSD can keep m3cc but also be configured to build with
> C-backend, then it shouldn't need a consensus as everyone wins.
> 
> I realize that that the real question is not about FreeBSD, but rather a
> project-wide decision, however.
> 
> John


From hosking at cs.purdue.edu  Thu May 29 15:40:54 2014
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 29 May 2014 09:40:54 -0400
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <9C6CB9C2-D5D1-4D1B-8A5F-8DCCA3F3E0FE@cs.purdue.edu>

Jay?

On May 29, 2014, at 1:40 AM, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:

> I?ve been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>  
> The m3-libs\libunicode package fails to build (see errors below).
>  
> I haven?t taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>  
> The problem module is: UnsafeUniCodec.m3
>  
> Thanks,
> Randy Coleburn
>  
> C:\cm3\Sandbox\cm3\m3-libs\libunicode>cm3
> --- building in NT386 ---
>  
> new source -> compiling UnsafeUniCodec.m3
> "..\src\UnsafeUniCodec.m3", line 81: warning: not used (Sink)
> "..\src\UnsafeUniCodec.m3", line 81: warning: not used (Wch)
> "..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: UniCodec.Range
> "..\src\UnsafeUniCodec.m3", line 82: warning: exception is never raised: Wr.Failure
> "..\src\UnsafeUniCodec.m3", line 88: warning: not used (Source)
> "..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.EndOfFile
> "..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Rd.Failure
> "..\src\UnsafeUniCodec.m3", line 89: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 96: warning: not used (Sink)
> "..\src\UnsafeUniCodec.m3", line 96: warning: not used (Wch)
> "..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: UniCodec.Range
> "..\src\UnsafeUniCodec.m3", line 97: warning: exception is never raised: Wr.Failure
> "..\src\UnsafeUniCodec.m3", line 105: warning: not used (Source)
> "..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.EndOfFile
> "..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Rd.Failure
> "..\src\UnsafeUniCodec.m3", line 106: warning: exception is never raised: Thread.Alerted
> "..\src\UnsafeUniCodec.m3", line 126: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 154: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 155: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 195: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 196: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 237: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 238: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 280: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 679: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 680: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 681: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 682: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 736: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 737: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 738: LOOPHOLE: expression's size differs from type's
> "..\src\UnsafeUniCodec.m3", line 739: LOOPHOLE: expression's size differs from type's
> 16 errors and 18 warnings encountered

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/df0eb5a2/attachment-0002.html>

From rodney_bates at lcwb.coop  Thu May 29 17:26:37 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 29 May 2014 10:26:37 -0500
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <538751AD.8080206@lcwb.coop>



On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> I?ve been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>
> The m3-libs\libunicode package fails to build (see errors below).
>
> I haven?t taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>
> The problem module is: UnsafeUniCodec.m3
>
> Thanks,
>
> Randy Coleburn
>

I am responsible for libunicode.

1. libunicode won't and is not designed to build unless the compiler is
    configured to make WIDECHAR have full unicode range, which, by default,
    it is not.

2. The simplest way to thus configure the compiler is to add the line
    Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
    everything, starting with m3core.

You can bootstrap all of this using the release compiler, see
cm3/scripts/README-build-unicode

I put libunicode in a separate package for that reason, and left the compiler
configured by default for the existing 16-bit range of WIDECHAR, so there
would be no perturbation to anybody's code unless you take some action.

We can change the default if there is consensus to do so.  Most code should
not be affected, but some lower-level things will be.  There is lots of info
on this subject, including what you get from it and what kinds of code might
be affected in:

cm3/README-unicode-summary
cm3/README-unicode
cm3/scripts/README-build-unicode

Rodney Bates
rodney.m.bates at acm.org


From rcolebur at SCIRES.COM  Thu May 29 22:54:55 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 20:54:55 +0000
Subject: [M3devel] build problems with libunicode
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>

Rodney:

Thanks very much for your response.

As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.

I'll take a look at your release notes.

Thanks,
Randy Coleburn

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Thursday, May 29, 2014 11:27 AM
To: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] build problems with libunicode



On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>
> The m3-libs\libunicode package fails to build (see errors below).
>
> I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>
> The problem module is: UnsafeUniCodec.m3
>
> Thanks,
>
> Randy Coleburn
>

I am responsible for libunicode.

1. libunicode won't and is not designed to build unless the compiler is
    configured to make WIDECHAR have full unicode range, which, by default,
    it is not.

2. The simplest way to thus configure the compiler is to add the line
    Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
    everything, starting with m3core.

You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode

I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.

We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:

cm3/README-unicode-summary
cm3/README-unicode
cm3/scripts/README-build-unicode

Rodney Bates
rodney.m.bates at acm.org


From rcolebur at SCIRES.COM  Thu May 29 23:37:59 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 21:37:59 +0000
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>

Rodney:

I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.

So, not sure why libunicode is trying to build on Windows (NT386).

--Randy Coleburn

-----Original Message-----
From: Coleburn, Randy 
Sent: Thursday, May 29, 2014 4:55 PM
To: m3devel at elegosoft.com
Subject: Re: [M3devel] build problems with libunicode

Rodney:

Thanks very much for your response.

As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.

I'll take a look at your release notes.

Thanks,
Randy Coleburn

-----Original Message-----
From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
Sent: Thursday, May 29, 2014 11:27 AM
To: m3devel at elegosoft.com
Subject: EXT:Re: [M3devel] build problems with libunicode



On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
>
> The m3-libs\libunicode package fails to build (see errors below).
>
> I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
>
> The problem module is: UnsafeUniCodec.m3
>
> Thanks,
>
> Randy Coleburn
>

I am responsible for libunicode.

1. libunicode won't and is not designed to build unless the compiler is
    configured to make WIDECHAR have full unicode range, which, by default,
    it is not.

2. The simplest way to thus configure the compiler is to add the line
    Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
    everything, starting with m3core.

You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode

I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.

We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:

cm3/README-unicode-summary
cm3/README-unicode
cm3/scripts/README-build-unicode

Rodney Bates
rodney.m.bates at acm.org


From rcolebur at SCIRES.COM  Thu May 29 23:42:09 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Thu, 29 May 2014 21:42:09 +0000
Subject: [M3devel] build problems with "elego\prjm"
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8AB1@ATLEX04-SRV.SCIRES.LOCAL>

Jay:

I've performed a clean rebuild of everything, but I still get the same error with "elego\prjm".
I'm also finding that "libunicode" is trying to build, yet there is no "Unicode_WIDECHAR" definition in the cm3.cfg files.
BTW, my target is NT386.

--Randy Coleburn

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, May 29, 2014 3:26 AM
To: Coleburn, Randy; m3devel
Subject: EXT:RE: [M3devel] build problems with "elego\prjm"

This might be a "builder" incrementality problem,
related to that this module was moved from libm3
to m3core, a while ago.

I don't think we cope with such movement correctly.

Can you be sure to clean rebuild m3core, libm3,
and prjm, and maybe everything else?

Given the unicode problem, maybe not.

Thanks,
 - Jay




________________________________
From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Date: Thu, 29 May 2014 05:44:29 +0000
Subject: [M3devel] build problems with "elego\prjm"
I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).

The "elego\prjm" package fails to build (see errors below).

I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone wants to work on a solution.

Thanks,
Randy Coleburn

--- processing package "elego\prjm" ---
--- purging derived files from NT386 ---

--- cleaning NT386 ---

ignoring ..\src\m3overrides

--- building in NT386 ---

ignoring ..\src\m3overrides

C:\cm3\bin\m3bundle -name ProjectManagerBundle -element UsageHelp ..\src\UsageHelp -element compactrc ..\src\compactrc -element ShortUsageHelp ..\src\ShortUsageHelp
new source -> compiling ProjectManagerBundle.i3
new source -> compiling ProjectManagerBundle.m3
new source -> compiling Creation.i3
new source -> compiling Creation.m3

Fatal Error: bad version stamps: TimePrjDescTbl.i3

missing export: LongrealType.T imported by TimePrjDescTbl.i3
missing export: LongrealType.Brand imported by TimePrjDescTbl.i3

WARNING:  Encountered an error when processing package "elego\prjm" for "-build".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140529/749b6377/attachment-0002.html>

From jay.krell at cornell.edu  Fri May 30 02:07:11 2014
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 30 May 2014 00:07:11 +0000
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>

Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile
 
 
do something to filter itself out from building with a compiler that won't work?
 
Can you add a builtin quake function
WideCharByteSize() or some other name
 
that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?
 
 
 
 - Jay


> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Thu, 29 May 2014 21:37:59 +0000
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.
> 
> So, not sure why libunicode is trying to build on Windows (NT386).
> 
> --Randy Coleburn
> 
> -----Original Message-----
> From: Coleburn, Randy 
> Sent: Thursday, May 29, 2014 4:55 PM
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> Thanks very much for your response.
> 
> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.
> 
> I'll take a look at your release notes.
> 
> Thanks,
> Randy Coleburn
> 
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
> Sent: Thursday, May 29, 2014 11:27 AM
> To: m3devel at elegosoft.com
> Subject: EXT:Re: [M3devel] build problems with libunicode
> 
> 
> 
> On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
> >
> > The m3-libs\libunicode package fails to build (see errors below).
> >
> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
> >
> > The problem module is: UnsafeUniCodec.m3
> >
> > Thanks,
> >
> > Randy Coleburn
> >
> 
> I am responsible for libunicode.
> 
> 1. libunicode won't and is not designed to build unless the compiler is
>     configured to make WIDECHAR have full unicode range, which, by default,
>     it is not.
> 
> 2. The simplest way to thus configure the compiler is to add the line
>     Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
>     everything, starting with m3core.
> 
> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode
> 
> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.
> 
> We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:
> 
> cm3/README-unicode-summary
> cm3/README-unicode
> cm3/scripts/README-build-unicode
> 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/d4f41ef9/attachment-0002.html>

From jay.krell at cornell.edu  Fri May 30 03:12:12 2014
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 30 May 2014 01:12:12 +0000
Subject: [M3devel] build problems with libunicode
In-Reply-To: <COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>
Message-ID: <COL130-W839E8D0F54961D3CD30386E6270@phx.gbl>

I guess Unicode_WIDECHAR = TRUE is what you picked, so:
 
if not defined("Unicode_WIDECHAR")
 Unicode_WIDECHAR = FALSE
end
in cm3cfg.common and libunicode/src/m3makefile
 
and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile?
 
 
I would have likely used a function returning byte size.
 
 
 
 - Jay

 
From: jay.krell at cornell.edu
To: rcolebur at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] build problems with libunicode
Date: Fri, 30 May 2014 00:07:11 +0000




Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile
 
 
do something to filter itself out from building with a compiler that won't work?
 
Can you add a builtin quake function
WideCharByteSize() or some other name
 
that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?
 
 
 
 - Jay


> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Thu, 29 May 2014 21:37:59 +0000
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.
> 
> So, not sure why libunicode is trying to build on Windows (NT386).
> 
> --Randy Coleburn
> 
> -----Original Message-----
> From: Coleburn, Randy 
> Sent: Thursday, May 29, 2014 4:55 PM
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] build problems with libunicode
> 
> Rodney:
> 
> Thanks very much for your response.
> 
> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.
> 
> I'll take a look at your release notes.
> 
> Thanks,
> Randy Coleburn
> 
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] 
> Sent: Thursday, May 29, 2014 11:27 AM
> To: m3devel at elegosoft.com
> Subject: EXT:Re: [M3devel] build problems with libunicode
> 
> 
> 
> On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
> >
> > The m3-libs\libunicode package fails to build (see errors below).
> >
> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
> >
> > The problem module is: UnsafeUniCodec.m3
> >
> > Thanks,
> >
> > Randy Coleburn
> >
> 
> I am responsible for libunicode.
> 
> 1. libunicode won't and is not designed to build unless the compiler is
>     configured to make WIDECHAR have full unicode range, which, by default,
>     it is not.
> 
> 2. The simplest way to thus configure the compiler is to add the line
>     Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
>     everything, starting with m3core.
> 
> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode
> 
> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.
> 
> We can change the default if there is consensus to do so.  Most code should not be affected, but some lower-level things will be.  There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:
> 
> cm3/README-unicode-summary
> cm3/README-unicode
> cm3/scripts/README-build-unicode
> 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/1fdba61b/attachment-0002.html>

From rcolebur at SCIRES.COM  Fri May 30 03:38:01 2014
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 30 May 2014 01:38:01 +0000
Subject: [M3devel] build problems with libunicode
Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL>

Jay / Rodney:

Well I didn't "pick" anything, but it appears that since I chose to rebuild everything based on pkginfo.txt that is why libunicode is now trying to build on my Windows box.

I have several options:

1.      Using my build scripts, I could choose to exclude libunicode (I have an option for that).

2.      We could modify the cm3.cfg and m3makefile as Jay suggests to prevent libunicode from trying to build unless Unicode_WIDECHAR is defined and TRUE.

3.      Etc.

For the short term, I think I'll try #1.
Then, I'll think about some mods for #2 and commit them if they test out.  That way, the Unicode_WIDECHAR could be used to turn this feature on and off as Rodney suggested.

For the elego\prjm package, I'm not sure whether it is supposed to be buildable on Windows.  If not, I can just exclude it, or we can modify the m3makefile to prevent it from building on Windows.  Obviously, I never used this package before.

Thanks for your help!

Thanks,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, May 29, 2014 9:12 PM
To: Coleburn, Randy; m3devel
Subject: EXT:RE: [M3devel] build problems with libunicode

I guess Unicode_WIDECHAR = TRUE is what you picked, so:

if not defined("Unicode_WIDECHAR")
 Unicode_WIDECHAR = FALSE
end
in cm3cfg.common and libunicode/src/m3makefile

and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile?


I would have likely used a function returning byte size.



 - Jay


________________________________
From: jay.krell at cornell.edu<mailto:jay.krell at cornell.edu>
To: rcolebur at scires.com<mailto:rcolebur at scires.com>; m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
Subject: RE: [M3devel] build problems with libunicode
Date: Fri, 30 May 2014 00:07:11 +0000
Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile


do something to filter itself out from building with a compiler that won't work?

Can you add a builtin quake function
WideCharByteSize() or some other name

that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?



 - Jay

> From: rcolebur at SCIRES.COM<mailto:rcolebur at SCIRES.COM>
> To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Date: Thu, 29 May 2014 21:37:59 +0000
> Subject: Re: [M3devel] build problems with libunicode
>
> Rodney:
>
> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it.
>
> So, not sure why libunicode is trying to build on Windows (NT386).
>
> --Randy Coleburn
>
> -----Original Message-----
> From: Coleburn, Randy
> Sent: Thursday, May 29, 2014 4:55 PM
> To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: Re: [M3devel] build problems with libunicode
>
> Rodney:
>
> Thanks very much for your response.
>
> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build.
>
> I'll take a look at your release notes.
>
> Thanks,
> Randy Coleburn
>
> -----Original Message-----
> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop]
> Sent: Thursday, May 29, 2014 11:27 AM
> To: m3devel at elegosoft.com<mailto:m3devel at elegosoft.com>
> Subject: EXT:Re: [M3devel] build problems with libunicode
>
>
>
> On 05/29/2014 12:40 AM, Coleburn, Randy wrote:
> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit).
> >
> > The m3-libs\libunicode package fails to build (see errors below).
> >
> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix.
> >
> > The problem module is: UnsafeUniCodec.m3
> >
> > Thanks,
> >
> > Randy Coleburn
> >
>
> I am responsible for libunicode.
>
> 1. libunicode won't and is not designed to build unless the compiler is
> configured to make WIDECHAR have full unicode range, which, by default,
> it is not.
>
> 2. The simplest way to thus configure the compiler is to add the line
> Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild
> everything, starting with m3core.
>
> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode
>
> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action.
>
> We can change the default if there is consensus to do so. Most code should not be affected, but some lower-level things will be. There is lots of info on this subject, including what you get from it and what kinds of code might be affected in:
>
> cm3/README-unicode-summary
> cm3/README-unicode
> cm3/scripts/README-build-unicode
>
> Rodney Bates
> rodney.m.bates at acm.org<mailto:rodney.m.bates at acm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/59bbf6ba/attachment-0002.html>

From estellnb at elstel.org  Fri May 30 10:00:00 2014
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Fri, 30 May 2014 10:00:00 +0200
Subject: [M3devel] build problems with libunicode
In-Reply-To: <538751AD.8080206@lcwb.coop>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
	<538751AD.8080206@lcwb.coop>
Message-ID: <D3148A49-F24C-4F8C-ADA8-B6449DA9868D@elstel.org>


Am 29.05.2014 um 17:26 schrieb Rodney M. Bates:

> 
> I am responsible for libunicode.
> 
> 1. libunicode won't and is not designed to build unless the compiler is
>   configured to make WIDECHAR have full unicode range, which, by default,
>   it is not.
> 
> I put libunicode in a separate package for that reason, and left the compiler
> configured by default for the existing 16-bit range of WIDECHAR, so there
> would be no perturbation to anybody's code unless you take some action.
> 
> We can change the default if there is consensus to do so.  Most code should
> not be affected, but some lower-level things will be.  

Well, the program I wanna port would actually profit from both types:
* a 16-bit unicode type for interfacing with gtk & qt
* a 32-bit unicode type for the program level user input function yielding math & greek letters

Will it be possible to simply declare BITS 16 FOR WIDECHAR when unicode support is enabled?
What complications to the Text library will that cause if we have a 16-bit and a 32-bit character 
type at the same time?
What would you think about leaving WIDECHAR as 16-bit and rather introducing UCHAR as 
32-bit character type? I believe this would be the best solution as it does not break any existing
code.

Best Regards,
Elmar Stellnberger

> 
> Rodney Bates
> rodney.m.bates at acm.org
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/59d2aacc/attachment-0002.html>

From dragisha at m3w.org  Fri May 30 13:50:17 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 30 May 2014 13:50:17 +0200
Subject: [M3devel] Git, a call for participation - AGAIN
In-Reply-To: <688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF925D0BFD@ATLEX04-SRV.SCIRES.LOCAL>,
	<A297D619-A23C-4583-82DD-FED9716EC843@m3w.org>
	<C7E469CD-A4A1-4CAD-BF27-AEC6E7EE22CF@SCIRES.COM>
	<688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
Message-ID: <BBA0A7FF-4D15-47CC-A9A3-F2A34962D623@m3w.org>

I am making latest CVS repo conversion. Please send your github usernames to me.

dd

On 19 Feb 2014, at 23:34, Dragi?a Duri? <dragisha at m3w.org> wrote:

> You will need separate working directory. With git, you will have whole cm3 repository cloned in toplevel .git folder. With svn you have .svn folders around, and CVS folders with cvs.
> 
> On 19 Feb 2014, at 18:05, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
> 
>> Sorry, I should rephrase the question:  Do I need to create a separate folder tree for my local copy of the cm3 source code tree for use with Git, or can I reuse the existing folder tree that I use with CVS?
>> 
>> --Randy Coleburn
>> 
>> On Feb 19, 2014, at 2:10 AM, "Dragi?a Duri?" <dragisha at m3w.org> wrote:
>> 
>>> Email was for conversion process and it is all set-up.
>>> 
>>> Github account, and request to me (dragisha) on github for cm3 repository is separate step.
>>> 
>>> You don?t really need TortoiseGit. Github has it?s GUI shell, but everything is doable just well with Git Bash console. I will share my Git on Windows experience as we progress with migration. 
>>> 
>>> Sandbox? Meaning virtual machine or?
>>> 
>>> dd
>>> 
>>> On 18 Feb 2014, at 01:30, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>> 
>>>> I have ssh set up with existing repository.  Do I need a different ssh for the Git, or will we use the existing one?
>>>> I seem to recall providing you with my email earlier for the authors file.
>>>> I can install TortoiseGit at some point and run a test when you are ready.
>>>> BTW, do I need to create a separate sandbox for Git, or can I just reuse existing CVS sandbox?
>>>> --Randy
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 6:05 PM
>>>> To: Coleburn, Randy
>>>> Cc: m3devel
>>>> Subject: EXT:Re: [M3devel] Git, a call for participation
>>>>  
>>>> Randy,
>>>>  
>>>> You don?t need to install anything on your computer to participate in Github project. If you have ssh enabled, you are ready to go. If not, then problem can be with corporate proxies running NTLM authentication. My company enabled github and bitbucket access without NTLM so I don?t have experience solving it, but I know it is possible.
>>>>  
>>>> dd
>>>> 
>>>> On 17 Feb 2014, at 16:24, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>>> 
>>>> 
>>>> Dragi?a:
>>>>  
>>>> I am not currently a member of GitHub.  From what I understand, this site provides some social networking functionality and requires that software supporting this functionality be installed on your computer.
>>>>  
>>>> 1.      Is it possible to take advantage of Git for source code checkin/checkout WITHOUT also becoming a member of GitHub?  
>>>> If so, what, if any, are the limitations of not being a member wrt the future of the CM3 repository?
>>>> 
>>>> 
>>>> 2.      What are the security concerns with installing the GitHub software?
>>>>  
>>>> My company severely restricts use of social media (it is blocked via the various firewalls), so that may make use of GitHub more difficult in my situation.
>>>>  
>>>> I think I should be able to use TortoiseGit for source code checkin/out, since I currently use TortoiseCVS; however, I have not used TortoiseGit before, so there will be a slight learning curve for me I?m sure.
>>>>  
>>>> Thanks,
>>>> Randy Coleburn
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 2:52 AM
>>>> To: m3devel
>>>> Subject: EXT:[M3devel] Git, a call for participation
>>>>  
>>>> Hi,
>>>>  
>>>> To proceed with planned conversion, I need developers to join github and connect me there (dragisha @ github). Once we have developers connected there, we can proceed and switch.
>>>>  
>>>> TIA, 
>>>> --
>>>> Dragi?a Duri?
>>>> dragisha at m3w.org
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/a6409f28/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/a6409f28/attachment-0002.sig>

From rodney_bates at lcwb.coop  Fri May 30 19:08:26 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 30 May 2014 12:08:26 -0500
Subject: [M3devel] build problems with libunicode
In-Reply-To: <COL130-W839E8D0F54961D3CD30386E6270@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>,
	<0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>,
	<COL130-W23DB1DD8F63A9EA700BF2EE6270@phx.gbl>
	<COL130-W839E8D0F54961D3CD30386E6270@phx.gbl>
Message-ID: <5388BB0A.6040603@lcwb.coop>

Hmm, fix it in the m3makefile and just not mess with the do-cm3-*.sh scripts at all.
That shouldn't be too hard.  The m3makfile could emit a loud warning that UniCodec
was not a working version.

Or maybe not build even UniCodec's interface, which would no doubt entail not building
anything in the library at all.  None of it will be of much use without full Unicode
WIDECHAR.

On 05/29/2014 08:12 PM, Jay K wrote:
> I guess Unicode_WIDECHAR = TRUE is what you picked, so:
>
> if not defined("Unicode_WIDECHAR")
>   Unicode_WIDECHAR = FALSE
> end
> in cm3cfg.common and libunicode/src/m3makefile
>
> and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile?
>
>
> I would have likely used a function returning byte size.
>
>
>
>   - Jay
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 --
> From: jay.krell at cornell.edu
> To: rcolebur at scires.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] build problems with libunicode
> Date: Fri, 30 May 2014 00:07:11 +0000
>
> Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile
>
>
> do something to filter itself out from building with a compiler that won't work?
>
> Can you add a builtin quake function
> WideCharByteSize() or some other name
>
> that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2?
> and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined?
>
>
>
>   - Jay
>
>
-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Fri May 30 21:49:29 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 30 May 2014 14:49:29 -0500
Subject: [M3devel] No short-circuit "or" and "and" in Quake
Message-ID: <5388E0C9.1030500@lcwb.coop>

I just discovered by accident, an undocumented peculiarity in Quake.
The "or" boolean operator (and, presumably "and" too) do not have the
usual short-circuit property.  So, for example, you can't write:

if not defined("Unicode_WIDECHAR")
    or empty (Unicode_WIDECHAR)

If it's undefined, Quake will still evaluate and crash on the second
condition.


-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Fri May 30 18:39:39 2014
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 30 May 2014 11:39:39 -0500
Subject: [M3devel] build problems with libunicode
In-Reply-To: <D3148A49-F24C-4F8C-ADA8-B6449DA9868D@elstel.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL>
	<538751AD.8080206@lcwb.coop>
	<D3148A49-F24C-4F8C-ADA8-B6449DA9868D@elstel.org>
Message-ID: <5388B44B.2000602@lcwb.coop>



On 05/30/2014 03:00 AM, Elmar Stellnberger wrote:
>
> Am 29.05.2014 um 17:26 schrieb Rodney M. Bates:
>
>>
>> I am responsible for libunicode.
>>
>> 1. libunicode won't and is not designed to build unless the compiler is
>>   configured to make WIDECHAR have full unicode range, which, by default,
>>   it is not.
>>
>> I put libunicode in a separate package for that reason, and left the compiler
>> configured by default for the existing 16-bit range of WIDECHAR, so there
>> would be no perturbation to anybody's code unless you take some action.
>>
>> We can change the default if there is consensus to do so.  Most code should
>> not be affected, but some lower-level things will be.
>
> Well, the program I wanna port would actually profit from both types:
> * a 16-bit unicode type for interfacing with gtk & qt
> * a 32-bit unicode type for the program level user input function yielding math & greek letters
>
> Will it be possible to simply declare BITS 16 FOR WIDECHAR when unicode support is enabled?

This would not compile, as BITS FOR must be enough bits to hold the value set of the type.
But BITS 16 FOR [FIRST(WIDECHAR)..VAL(16_FFFF),WIDECHAR] would give you what you need to
pass in and out of a library that uses a 16-bit character.  You could either keep your
characters in this type or assign back and forth between this and WIDECHAR, which would
do runtime value checks where necessary.

But do gtk and qt actually treat all characters as 16-bit fixed-size code points, or do they
actually use UTF16, with the 16-bit value being a code unit, not a code point?  In the
latter case, using UniWr and UniRd to do the encoding/decoding would be a much cleaner
option.

> What complications to the Text library will that cause if we have a 16-bit and a 32-bit character
> type at the same time?

The Text library already has two sizes: CHAR (8) and WIDECHAR (either 16 or 32).  A third would require more
code.  Pickles and network objects would need quite a bit of additional code, and they are quite
a bit more complicated than Text, because they have to handle values written by different compilers.

> What would you think about leaving WIDECHAR as 16-bit and rather introducing UCHAR as
> 32-bit character type? I believe this would be the best solution as it does not break any existing
> code.
>
> Best Regards,
> Elmar Stellnberger
>
>>
>> Rodney Bates
>> rodney.m.bates at acm.org <mailto:rodney.m.bates at acm.org>
>>
>

-- 
Rodney Bates
rodney.m.bates at acm.org


From dragisha at m3w.org  Fri May 30 22:48:31 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 30 May 2014 22:48:31 +0200
Subject: [M3devel] Git, a call for participation
In-Reply-To: <688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF925D0BFD@ATLEX04-SRV.SCIRES.LOCAL>,
	<A297D619-A23C-4583-82DD-FED9716EC843@m3w.org>
	<C7E469CD-A4A1-4CAD-BF27-AEC6E7EE22CF@SCIRES.COM>
	<688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org>
Message-ID: <610A2ACE-7BE8-4546-98AB-7690D7CC010B@m3w.org>

My plan:

* Do a conversion to Git, place it on github.
* As m3devel people identify/communicate with me on github, access rights will be granted one by one.
* Alternatively we can use pull-request mechanism. We can also extend jenkins to do non-canonical builds/testing. Canonical being a master branch of repo from first item.
* Install Jenkins on my server box, connect to donated slave instances, do builds, distribute results over some (yet undefined) public server. I don?t have bandwidth for big file distribution.
* Move pieces to better locations, as they become available.

Any suggestions?

On 19 Feb 2014, at 23:34, Dragi?a Duri? <dragisha at m3w.org> wrote:

> You will need separate working directory. With git, you will have whole cm3 repository cloned in toplevel .git folder. With svn you have .svn folders around, and CVS folders with cvs.
> 
> On 19 Feb 2014, at 18:05, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
> 
>> Sorry, I should rephrase the question:  Do I need to create a separate folder tree for my local copy of the cm3 source code tree for use with Git, or can I reuse the existing folder tree that I use with CVS?
>> 
>> --Randy Coleburn
>> 
>> On Feb 19, 2014, at 2:10 AM, "Dragi?a Duri?" <dragisha at m3w.org> wrote:
>> 
>>> Email was for conversion process and it is all set-up.
>>> 
>>> Github account, and request to me (dragisha) on github for cm3 repository is separate step.
>>> 
>>> You don?t really need TortoiseGit. Github has it?s GUI shell, but everything is doable just well with Git Bash console. I will share my Git on Windows experience as we progress with migration. 
>>> 
>>> Sandbox? Meaning virtual machine or?
>>> 
>>> dd
>>> 
>>> On 18 Feb 2014, at 01:30, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>> 
>>>> I have ssh set up with existing repository.  Do I need a different ssh for the Git, or will we use the existing one?
>>>> I seem to recall providing you with my email earlier for the authors file.
>>>> I can install TortoiseGit at some point and run a test when you are ready.
>>>> BTW, do I need to create a separate sandbox for Git, or can I just reuse existing CVS sandbox?
>>>> --Randy
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 6:05 PM
>>>> To: Coleburn, Randy
>>>> Cc: m3devel
>>>> Subject: EXT:Re: [M3devel] Git, a call for participation
>>>>  
>>>> Randy,
>>>>  
>>>> You don?t need to install anything on your computer to participate in Github project. If you have ssh enabled, you are ready to go. If not, then problem can be with corporate proxies running NTLM authentication. My company enabled github and bitbucket access without NTLM so I don?t have experience solving it, but I know it is possible.
>>>>  
>>>> dd
>>>> 
>>>> On 17 Feb 2014, at 16:24, Coleburn, Randy <rcolebur at SCIRES.COM> wrote:
>>>> 
>>>> 
>>>> Dragi?a:
>>>>  
>>>> I am not currently a member of GitHub.  From what I understand, this site provides some social networking functionality and requires that software supporting this functionality be installed on your computer.
>>>>  
>>>> 1.      Is it possible to take advantage of Git for source code checkin/checkout WITHOUT also becoming a member of GitHub?  
>>>> If so, what, if any, are the limitations of not being a member wrt the future of the CM3 repository?
>>>> 
>>>> 
>>>> 2.      What are the security concerns with installing the GitHub software?
>>>>  
>>>> My company severely restricts use of social media (it is blocked via the various firewalls), so that may make use of GitHub more difficult in my situation.
>>>>  
>>>> I think I should be able to use TortoiseGit for source code checkin/out, since I currently use TortoiseCVS; however, I have not used TortoiseGit before, so there will be a slight learning curve for me I?m sure.
>>>>  
>>>> Thanks,
>>>> Randy Coleburn
>>>>  
>>>> From: Dragi?a Duri? [mailto:dragisha at m3w.org] 
>>>> Sent: Monday, February 17, 2014 2:52 AM
>>>> To: m3devel
>>>> Subject: EXT:[M3devel] Git, a call for participation
>>>>  
>>>> Hi,
>>>>  
>>>> To proceed with planned conversion, I need developers to join github and connect me there (dragisha @ github). Once we have developers connected there, we can proceed and switch.
>>>>  
>>>> TIA, 
>>>> --
>>>> Dragi?a Duri?
>>>> dragisha at m3w.org
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/3f720996/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/3f720996/attachment-0002.sig>

From jay.krell at cornell.edu  Sat May 31 01:13:48 2014
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 30 May 2014 23:13:48 +0000
Subject: [M3devel] No short-circuit "or" and "and" in Quake
In-Reply-To: <5388E0C9.1030500@lcwb.coop>
References: <5388E0C9.1030500@lcwb.coop>
Message-ID: <COL130-W31F76F5445BA76A31EA982E6270@phx.gbl>

Yes, I know, it is unfortunate and counterintuitive. I workaround it all the time.
 
 - Jay

 
> Date: Fri, 30 May 2014 14:49:29 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: [M3devel] No short-circuit "or" and "and" in Quake
> 
> I just discovered by accident, an undocumented peculiarity in Quake.
> The "or" boolean operator (and, presumably "and" too) do not have the
> usual short-circuit property.  So, for example, you can't write:
> 
> if not defined("Unicode_WIDECHAR")
>     or empty (Unicode_WIDECHAR)
> 
> If it's undefined, Quake will still evaluate and crash on the second
> condition.
> 
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140530/907ee3a4/attachment-0002.html>

From wagner at elegosoft.com  Sat May 31 10:50:03 2014
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 31 May 2014 10:50:03 +0200
Subject: [M3devel] build problems with libunicode
In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL>
Message-ID: <20140531105003.c365f974ec13b9f47b5fda34@elegosoft.com>

On Fri, 30 May 2014 01:38:01 +0000
"Coleburn, Randy" <rcolebur at SCIRES.COM> wrote:

> Jay / Rodney:
> 
> For the elego\prjm package, I'm not sure whether it is supposed to be buildable on Windows.  If not, I can just exclude it, or we can modify the m3makefile to prevent it from building on Windows.  Obviously, I never used this package before.

All the packages from Elego used to build on Windows, Linux, BSD
and Solaris platforms. However, I don't think anything depends
on this that you will need so you should be safe to exclude
all the stuff in the elego directory.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


From wagner at elegosoft.com  Sat May 31 11:38:52 2014
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 31 May 2014 11:38:52 +0200
Subject: [M3devel] CVS to GIT migration -- shutdown of elego's CVS services
	for M3
Message-ID: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com>

Hello all,

with the possibility of the CM3 project being hosted on Github,
where it can be continued safely and with much more and better
hardware resources than elego could ever provide, elego will
stop providing the legacy CVS service for the source code as
soon as possible. This does not mean that we will stop all of
our support, and we certainly won't remove access to the sources
before easy access to them at another provider is established.
But we would like to urge all the developers to help with the
migration and ensure that the use and development of Modula-3
will continue as seamlessly as possible.

The WWW service can stay online some time longer, though
I think all the stuff available there should be reviewed
and moved to a Wiki with easy access for all the developers.

13 months ago I set up this Wiki page at the M3 Trac
instance to allocate all the things that I thought should
be done and considered, but nobody else has contributed
to that, so that has probably not been the right approach: 

https://cm3-bugs.elegosoft.com/cm3/wiki/CvsToGitMigration

However, I think a clean migration to git should be no
big problem, and it should also improve the visibility
and ease of use of the assets, so it will be all for the
best of the project.

Some personal notes:

After the huge amount of time I spent in preparing, testing
and bundling the last release of CM3 several years ago,
I was not able to sustain any noticable contribution to
the M3 development. Both private and business matters
claimed so much attention that I was not able to provide
the necessary time to even keep all the infrastructure
-- WWW, scripts, CI etc. -- in proper and usable shape.
And I'm afraid that this won't change soon, so there is
no hope for much contribution from my side for the
foreseeable future. 

I would dearly like to see the use of Modula-3 spread and
the project prosper and thrive and I'll try to support
this as much as I can. Embarrassing desasters like
heartbleed could easily have been prevented by the use
of Modula-3 or the application of the sound principles
and techniques that are its base. I still believe that
using a safe language for large projects should be a
inevitable decision from an engineering point of view,
but keeping the users and developers of M3 in a kind of
enclave won't help in the large run.

So please see my decision to discontinue the repository
support as a friendly push to start moving in the right
direction.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


From schlepptop at henning-thielemann.de  Sat May 31 11:53:19 2014
From: schlepptop at henning-thielemann.de (Henning Thielemann)
Date: Sat, 31 May 2014 11:53:19 +0200
Subject: [M3devel] CVS to GIT migration -- shutdown of elego's CVS
 services for M3
In-Reply-To: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com>
References: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com>
Message-ID: <5389A68F.1070003@henning-thielemann.de>

Am 31.05.2014 11:38, schrieb Olaf Wagner:

> The WWW service can stay online some time longer, though
> I think all the stuff available there should be reviewed
> and moved to a Wiki with easy access for all the developers.

Btw. I like Wikis that you can edit offline, like gitit.



From bruce.axtens at gmail.com  Sat May 31 16:05:49 2014
From: bruce.axtens at gmail.com (Bruce M. Axtens)
Date: Sat, 31 May 2014 22:05:49 +0800
Subject: [M3devel] Problem building on Win7
In-Reply-To: <53898228.9010807@elego.de>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>	<5384B209.3080504@marino.st>	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>	<5385A122.4020205@marino.st>	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>	<20140528182503.087801A2095@async.async.caltech.edu>	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>	<20140528203218.658CC1A2096@async.async.caltech.edu>	<5386B98C.7040904@gmail.com>
	<CAA4N+4aiaLGcbJ3GwhyAtbkOWELHQ=fvR4xMSFOMe2RD9y7foA@mail.gmail.com>
	<53898228.9010807@elego.de>
Message-ID: <5389E1BD.4030603@gmail.com>

G'day everyone

I downloaded cm3-bin-core-NT386-5.8.6-REL.tgz and ran cminstall.exe. I 
then changed directory to c:\cm3\examples\hello\src and tried to build 
the example, viz

    C:\cm3\examples\hello\src>cm3
    --- building in ..\NT386 ---

    new source -> compiling Hello.m3
      -> linking hello.exe
    "C:\cm3\bin/config\NT386.common", line 969: quake runtime error:
    link failed, see C:\cm3\examples\hello\NT386\hello.lst for more
    information


    --procedure--  -line-  -file---
    error              --  <builtin>
    m3_link           969  C:\cm3\bin/config\NT386.common
    program            --  <builtin>
    include_dir        27 C:\cm3\examples\hello\src\m3makefile
                         4 C:\cm3\examples\hello\NT386\m3make.args


    Fatal Error: procedure "m3_link" defined in "C:\cm3\bin\cm3.cfg" failed.


    C:\cm3\examples\hello\src>type ..\NT386\hello.lst
    Microsoft (R) Incremental Linker Version 10.00.40219.01
    Copyright (C) Microsoft Corporation.  All rights reserved.

    -out:hello.exe
    -subsystem:console
    -entry:mainCRTStartup
    -nodefaultlib
    -debug
    -incremental:no
    -opt:ref
    -delayload:wsock32.dll
    -delayload:advapi32.dll
    -delayload:gdi32.dll
    -delayload:netapi32.dll
    -delayload:user32.dll
    -delayload:comctl32.dll
    delayimp.lib
    _m3main.obj
    Hello.mo
    C:\cm3\pkg\libm3\NT386\m3.lib
    C:\cm3\pkg\m3core\NT386\m3core.lib
    winspool.lib
    comctl32.lib
    wsock32.lib
    comdlg32.lib
    netapi32.lib
    gdi32.lib
    user32.lib
    advapi32.lib
    kernel32.lib
    msvcrt.lib
    C:\cm3\bin\..\lib\hand.obj
    LINK : fatal error LNK1181: cannot open input file 'delayimp.lib'

delayimp.lib is nowhere to be found in the c:\cm3 tree. So I downloaded 
the CVS tree in the expectation that I'd find it in there, but It's NOT 
there.

Where do I go from here?

Kind regards,
Bruce M. Axtens


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/2039f6b6/attachment-0002.html>

From bruce.axtens at gmail.com  Sat May 31 16:33:50 2014
From: bruce.axtens at gmail.com (Bruce M. Axtens)
Date: Sat, 31 May 2014 22:33:50 +0800
Subject: [M3devel] Starting out with CM3
In-Reply-To: <53893F74.1040608@gmail.com>
References: <53893F74.1040608@gmail.com>
Message-ID: <5389E84E.10407@gmail.com>

G'day everyone

I've slurped down the full CVS tree. How do I build for Windows 7 ... 
from scratch? Is there a readme/faq for this somewhere?

Kind regards,
Bruce.





From bruce.axtens at gmail.com  Sat May 31 16:34:47 2014
From: bruce.axtens at gmail.com (Bruce M. Axtens)
Date: Sat, 31 May 2014 22:34:47 +0800
Subject: [M3devel] Starting out with CM3
In-Reply-To: <53893F74.1040608@gmail.com>
References: <53893F74.1040608@gmail.com>
Message-ID: <5389E887.5050405@gmail.com>

Oh and while I'm at it, seeing as I have a recent MinGW here, how do I 
build for MinGW?

Bruce.



From jay.krell at cornell.edu  Sat May 31 18:47:34 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:47:34 +0000
Subject: [M3devel] Problem building on Win7
In-Reply-To: <5389E1BD.4030603@gmail.com>
References: <CAA4N+4avvwOgO0SDpusya+NZuUwOtOKMwYXNviWc97goRNxeOg@mail.gmail.com>
	<20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>
	<632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>	<5384B209.3080504@marino.st>
	<A5BA1C10-E4C3-4839-B9CA-20BC0E10BD2A@cs.purdue.edu>
	<COL130-W385EE92D0CABE70C5760B4E6250@phx.gbl>	<5385A122.4020205@marino.st>
	<COL130-W77F293FE76307E7C81612DE6250@phx.gbl>
	<20140528182503.087801A2095@async.async.caltech.edu>
	<598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu>
	<20140528203218.658CC1A2096@async.async.caltech.edu>
	<5386B98C.7040904@gmail.com>,
	<CAA4N+4aiaLGcbJ3GwhyAtbkOWELHQ=fvR4xMSFOMe2RD9y7foA@mail.gmail.com>,
	<53898228.9010807@elego.de>, <5389E1BD.4030603@gmail.com>
Message-ID: <COL130-W931C4DEDBF0FDA3E034326E6260@phx.gbl>

delayimp.lib comes with Visual C++. We could without it though.
i.e. remove it and all the:
-delayload:wsock32.dll
-delayload:advapi32.dll
-delayload:gdi32.dll
-delayload:netapi32.dll
-delayload:user32.dll
-delayload:comctl32.dll
 
will work, albeit with extra .dll loads.

- Jay
 
Date: Sat, 31 May 2014 22:05:49 +0800
From: bruce.axtens at gmail.com
To: m3devel at elegosoft.com
Subject: [M3devel] Problem building on Win7


  
    
  
  
    G'day everyone

    
      
         

          I downloaded cm3-bin-core-NT386-5.8.6-REL.tgz and ran
          cminstall.exe. I then changed directory to
          c:\cm3\examples\hello\src and tried to build the example, viz

          C:\cm3\examples\hello\src>cm3

                --- building in ..\NT386 ---

                

                new source -> compiling Hello.m3

                 -> linking hello.exe

                "C:\cm3\bin/config\NT386.common", line 969: quake
                runtime error: link failed, see
                C:\cm3\examples\hello\NT386\hello.lst for more
                information

                

                

                --procedure--  -line-  -file---

                error              --  <builtin>

                m3_link           969  C:\cm3\bin/config\NT386.common

                program            --  <builtin>

                include_dir        27 
                C:\cm3\examples\hello\src\m3makefile

                                    4 
                C:\cm3\examples\hello\NT386\m3make.args

                

                

                Fatal Error: procedure "m3_link" defined in
                "C:\cm3\bin\cm3.cfg" failed.

                

                

                C:\cm3\examples\hello\src>type ..\NT386\hello.lst

                Microsoft (R) Incremental Linker Version 10.00.40219.01

                Copyright (C) Microsoft Corporation.  All rights
                reserved.

                

                -out:hello.exe

                -subsystem:console

                -entry:mainCRTStartup

                -nodefaultlib

                -debug

                -incremental:no

                -opt:ref

                -delayload:wsock32.dll

                -delayload:advapi32.dll

                -delayload:gdi32.dll

                -delayload:netapi32.dll

                -delayload:user32.dll

                -delayload:comctl32.dll

                delayimp.lib

                _m3main.obj

                Hello.mo

                C:\cm3\pkg\libm3\NT386\m3.lib

                C:\cm3\pkg\m3core\NT386\m3core.lib

                winspool.lib

                comctl32.lib

                wsock32.lib

                comdlg32.lib

                netapi32.lib

                gdi32.lib

                user32.lib

                advapi32.lib

                kernel32.lib

                msvcrt.lib

                C:\cm3\bin\..\lib\hand.obj

                LINK : fatal error LNK1181: cannot open input file
                'delayimp.lib'

            

          
          delayimp.lib is nowhere to be found in the c:\cm3 tree. So I
          downloaded the CVS tree in the expectation that I'd find it in
          there, but It's NOT there. 

          

          Where do I go from here?

          

          Kind regards,

          Bruce M. Axtens

          

        
      
      

     		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/d8852449/attachment-0002.html>

From jay.krell at cornell.edu  Sat May 31 18:53:14 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:53:14 +0000
Subject: [M3devel] Starting out with CM3
In-Reply-To: <5389E84E.10407@gmail.com>
References: <53893F74.1040608@gmail.com>,<5389E84E.10407@gmail.com>
Message-ID: <COL130-W2D53D27D3ED6A677231B9E6260@phx.gbl>

You have to start with a minimal working toolset: cm3, m3core, libm3, C compiler/linker.
And then scripts/python/upgrade.py && scripts/python/do-cm3-all.py.
Optionally you can cross-build to start -- but still need working cm3 on host, and C compiler/linker, preferably on target.
 
 - Jay

 
> Date: Sat, 31 May 2014 22:33:50 +0800
> From: bruce.axtens at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Starting out with CM3
> 
> G'day everyone
> 
> I've slurped down the full CVS tree. How do I build for Windows 7 ... 
> from scratch? Is there a readme/faq for this somewhere?
> 
> Kind regards,
> Bruce.
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/abc9934d/attachment-0002.html>

From jay.krell at cornell.edu  Sat May 31 18:53:23 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:53:23 +0000
Subject: [M3devel] Starting out with CM3
In-Reply-To: <5389E84E.10407@gmail.com>
References: <53893F74.1040608@gmail.com>,<5389E84E.10407@gmail.com>
Message-ID: <COL130-W2E7FA119353D9CCFA0AD4E6260@phx.gbl>

You have to start with a minimal working toolset: cm3, m3core, libm3, C compiler/linker.
And then scripts/python/upgrade.py && scripts/python/do-cm3-all.py.
Optionally you can cross-build to start -- but still need working cm3 on host, and C compiler/linker, preferably on target.
 
 - Jay

 
> Date: Sat, 31 May 2014 22:33:50 +0800
> From: bruce.axtens at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Starting out with CM3
> 
> G'day everyone
> 
> I've slurped down the full CVS tree. How do I build for Windows 7 ... 
> from scratch? Is there a readme/faq for this somewhere?
> 
> Kind regards,
> Bruce.
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/b81e477c/attachment-0002.html>

From jay.krell at cornell.edu  Sat May 31 18:53:25 2014
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 31 May 2014 16:53:25 +0000
Subject: [M3devel] Starting out with CM3
In-Reply-To: <5389E84E.10407@gmail.com>
References: <53893F74.1040608@gmail.com>,<5389E84E.10407@gmail.com>
Message-ID: <COL130-W2AEDFC48A2FB8E4FD5367E6260@phx.gbl>

You have to start with a minimal working toolset: cm3, m3core, libm3, C compiler/linker.
And then scripts/python/upgrade.py && scripts/python/do-cm3-all.py.
Optionally you can cross-build to start -- but still need working cm3 on host, and C compiler/linker, preferably on target.
 
 - Jay

 
> Date: Sat, 31 May 2014 22:33:50 +0800
> From: bruce.axtens at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Starting out with CM3
> 
> G'day everyone
> 
> I've slurped down the full CVS tree. How do I build for Windows 7 ... 
> from scratch? Is there a readme/faq for this somewhere?
> 
> Kind regards,
> Bruce.
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/a8619162/attachment-0002.html>

From dragisha at m3w.org  Sat May 31 21:56:13 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 31 May 2014 21:56:13 +0200
Subject: [M3devel] Git synchronized to CVS@May30
Message-ID: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>

https://github.com/dragisha/cm3

Please let me have your usernames on github.

I am continuing now through Jenkins setup. I hope to have few platforms happily building from tomorrow on.

dd



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/781db7e3/attachment-0002.sig>

From dragisha at m3w.org  Sat May 31 23:01:17 2014
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 31 May 2014 23:01:17 +0200
Subject: [M3devel] Git synchronized to CVS@May30
In-Reply-To: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>
References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>
Message-ID: <F952131C-30FB-47CA-BEC4-9888B76E7ABA@m3w.org>

I have added Rodney and Anthony for now. And I am waiting for few other people to give me exact data. And everybody else to give me any data :)

What I need is short form show on github, to be sure it is you I am adding. Thanks in advance!

dd

On 31 May 2014, at 21:56, Dragi?a Duri? <dragisha at m3w.org> wrote:

> https://github.com/dragisha/cm3
> 
> Please let me have your usernames on github.
> 
> I am continuing now through Jenkins setup. I hope to have few platforms happily building from tomorrow on.
> 
> dd
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140531/90ad439d/attachment-0002.sig>