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: 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 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: -------------- 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: 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: 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: References: Message-ID: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens 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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 -- 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: References: 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 Features2=0xffba2203 AMD Features=0x28100800 AMD Features2=0x1 Standard Extended Features=0x200 real memory = 4026531840 (3840 MB) avail memory = 3872776192 (3693 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: >>>>> 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: <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 wrote: > On Sun, 25 May 2014 22:35:09 +0800 > Bruce Axtens 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: 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: <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 wrote: > >> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens >> 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: 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 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: 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: References: <20140526234916.864741A209C@async.async.caltech.edu> 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, 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 >> >> Features2=0xffba2203V> >> AMD Features=0x28100800 >> AMD Features2=0x1 >> Standard Extended Features=0x200 >> real memory = 4026531840 (3840 MB) >> avail memory = 3872776192 (3693 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> >> >> >> >> >>>>> >> >> 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 > >

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.

> >

Peter

>
On 27/05/2014 9:49 AM, <ka at async.caltech.edu">mika at async.caltech.edu> wrote:
ibution">
r-left:1px #ccc solid;padding-left:1ex"> >
>Peter, have you/someone run the thread tester exhaustively?
>
>I did this:
>
>#!/bin/csh
>
>while ( 1 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr= >eadtest
>end
>
>With what's in FreeBSD's ports I get a variety of failures:
>
>
>1.
>***
>*** runtime error:
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >IL
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3
>***
>
>2.
>running...printing oldest/median age/newest
>.Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele= >te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>
>3. (most common)
>***
>*** runtime error:
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >IL
>*** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R= >TCollector.m3
>***
>
>4.
>***
>*** runtime error:
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >IL
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D 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... =C2=A0us= >ually things get worse with more processors.
>
>FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>=C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER= >IC 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)r> >=C2=A0 Origin =3D "GenuineIntel" =C2=A0Id =3D 0x306e4 =C2=A0Famil= >y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4
>=C2=A0 Features=3D0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP= >,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>=C2=A0 Features2=3D0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4= >.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
>=C2=A0 AMD Features=3D0x28100800<SYSCALL,NX,RDTSCP,LM>
>=C2=A0 AMD Features2=3D0x1<LAHF>
>=C2=A0 Standard Extended Features=3D0x200<ENHMOVSB>
>real memory =C2=A0=3D 4026531840 (3840 MB)
>avail memory =3D 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 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.
> >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.
> >The pthreads seems pretty stable at least on linux.
>
>Peter
>
>
> >--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: <20140526234916.864741A209C@async.async.caltech.edu> <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, 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 >>> >>> Features2=0xffba2203> V> >>> AMD Features=0x28100800 >>> AMD Features2=0x1 >>> Standard Extended Features=0x200 >>> real memory = 4026531840 (3840 MB) >>> avail memory = 3872776192 (3693 MB) >>> Event timer "LAPIC" quality 400 >>> ACPI APIC Table: >>> >>> >>> >>> >>>>>>>> >>> >>> 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 >> >>

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.

>> >>

Peter

>>
On 27/05/2014 9:49 AM, <> ka at async.caltech.edu">mika at async.caltech.edu> wrote:
> ibution">
> r-left:1px #ccc solid;padding-left:1ex"> >>
>> Peter, have you/someone run the thread tester exhaustively?
>>
>> I did this:
>>
>> #!/bin/csh
>>
>> while ( 1 )
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr= >> eadtest
>> end
>>
>> With what's in FreeBSD's ports I get a variety of failures:
>>
>>
>> 1.
>> ***
>> *** runtime error:
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >> IL
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3
>> ***
>>
>> 2.
>> running...printing oldest/median age/newest
>> .Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele= >> te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>>
>> 3. (most common)
>> ***
>> *** runtime error:
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >> IL
>> *** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R= >> TCollector.m3
>> ***
>>
>> 4.
>> ***
>> *** runtime error:
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >> IL
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D 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... =C2=A0us= >> ually things get worse with more processors.
>>
>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>> =C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER= >> IC 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)> r> >> =C2=A0 Origin =3D "GenuineIntel" =C2=A0Id =3D 0x306e4 =C2=A0Famil= >> y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4
>> =C2=A0 Features=3D0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP= >> ,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>> =C2=A0 Features2=3D0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4= >> .2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
>> =C2=A0 AMD Features=3D0x28100800<SYSCALL,NX,RDTSCP,LM>
>> =C2=A0 AMD Features2=3D0x1<LAHF>
>> =C2=A0 Standard Extended Features=3D0x200<ENHMOVSB>
>> real memory =C2=A0=3D 4026531840 (3840 MB)
>> avail memory =3D 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 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.
>> >> 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.
>> >> The pthreads seems pretty stable at least on linux.
>>
>> Peter
>>
>>
>> >> --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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> Message-ID: Jay might comment on C backend status for those platforms. On May 27, 2014, at 11:40 AM, John Marino 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 wrote: >> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens >>> 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, Message-ID: 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 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 wrote: > >> > >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens > >>> 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: 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: References: , <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, , <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, , <5384B209.3080504@marino.st>, , , Message-ID: 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 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 wrote: > >> > >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens > >>> 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: 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: References: <535FA2B2.70108@gmail.com>, Message-ID: .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 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: 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: References: <535FA2B2.70108@gmail.com>, 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 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: 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: <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 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, 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>, , , , <8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org> Message-ID: 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 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> Message-ID: > 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: 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> <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: 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: , <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, , <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, , <5384B209.3080504@marino.st>, , , , , <5385A122.4020205@marino.st>, , <20140528182503.087801A2095@async.async.caltech.edu>, <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> Message-ID: 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> <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 > >charset=3Dus-ascii">-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).

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, href=3D"mailto:mika at async.caltech.edu">mika at async.caltech.edu = >wrote:

Jay K writes:
type=3D"cite">--_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.
=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.
...

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

>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; ">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; ">
break-word; -webkit-nbsp-mode: space; -webkit-line-break: = >after-white-space; ">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; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">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; ">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; ">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; ">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; ">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; ">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; ">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; ">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; ">
class=3D"Apple-style-span" color=3D"#0000FF">class=3D"Apple-style-span" face=3D"Gill Sans">class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = >'Gill Sans'; ">0, 255); font-family: 'Gill Sans'; ">Antony = >Hoskingface=3D"Gill Sans">'Gill Sans'; ">'Gill Sans'; "> |class=3D"Apple-converted-space"> class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; ">class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; = >">Associate Professorstyle=3D"font-family: 'Gill Sans'; ">style=3D"font-family: 'Gill Sans'; "> | Computer Science | Purdue = >University
face=3D"GillSans-Light">style=3D"font-family: GillSans-Light; ">305 N. University Street | West = >Lafayette | IN 47907 | USA
class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans">class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = >'Gill Sans'; ">0, 255); font-family: 'Gill Sans'; ">Mobileclass=3D"Apple-style-span" face=3D"GillSans-Light">class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">class=3D"Apple-converted-space"> +1 765 427 = >5484
face=3D"GillSans-Light">
class=3D"khtml-block-placeholder">
>

class=3D"Apple-interchange-newline">

class=3D"Apple-interchange-newline">

class=3D"Apple-interchange-newline"> >
>
= > >--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 > 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: 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: 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: 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: 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: 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> <5385A122.4020205@marino.st> <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 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 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: 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 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: 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: 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: 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: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: 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: 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 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: 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: 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: 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>, <688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org> Message-ID: 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? 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 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?" 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 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 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: -------------- 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: 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: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>, 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: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL> <538751AD.8080206@lcwb.coop> 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 >> > -- 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>, <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? 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 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?" 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 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 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: -------------- 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: 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: 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: 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" 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> <5385A122.4020205@marino.st> <20140528182503.087801A2095@async.async.caltech.edu> <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> <20140528203218.658CC1A2096@async.async.caltech.edu> <5386B98C.7040904@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 -- m3_link 969 C:\cm3\bin/config\NT386.common program -- 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> <5385A122.4020205@marino.st> <20140528182503.087801A2095@async.async.caltech.edu> <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> <20140528203218.658CC1A2096@async.async.caltech.edu> <5386B98C.7040904@gmail.com>, , <53898228.9010807@elego.de>, <5389E1BD.4030603@gmail.com> Message-ID: 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 -- m3_link 969 C:\cm3\bin/config\NT386.common program -- 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: 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: 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: 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: 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: 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: 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: 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: 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: 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? 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: 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: 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 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: -------------- 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: 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: 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: References: Message-ID: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens 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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 -- 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: References: 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 Features2=0xffba2203 AMD Features=0x28100800 AMD Features2=0x1 Standard Extended Features=0x200 real memory = 4026531840 (3840 MB) avail memory = 3872776192 (3693 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: >>>>> 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: <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 wrote: > On Sun, 25 May 2014 22:35:09 +0800 > Bruce Axtens 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: 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: <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 wrote: > >> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens >> 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: 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 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: 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: References: <20140526234916.864741A209C@async.async.caltech.edu> 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, 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 >> >> Features2=0xffba2203V> >> AMD Features=0x28100800 >> AMD Features2=0x1 >> Standard Extended Features=0x200 >> real memory = 4026531840 (3840 MB) >> avail memory = 3872776192 (3693 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> >> >> >> >> >>>>> >> >> 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 > >

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.

> >

Peter

>
On 27/05/2014 9:49 AM, <ka at async.caltech.edu">mika at async.caltech.edu> wrote:
ibution">
r-left:1px #ccc solid;padding-left:1ex"> >
>Peter, have you/someone run the thread tester exhaustively?
>
>I did this:
>
>#!/bin/csh
>
>while ( 1 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr= >eadtest
>end
>
>With what's in FreeBSD's ports I get a variety of failures:
>
>
>1.
>***
>*** runtime error:
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >IL
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3
>***
>
>2.
>running...printing oldest/median age/newest
>.Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele= >te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>
>3. (most common)
>***
>*** runtime error:
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >IL
>*** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R= >TCollector.m3
>***
>
>4.
>***
>*** runtime error:
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >IL
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D 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... =C2=A0us= >ually things get worse with more processors.
>
>FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>=C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER= >IC 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)r> >=C2=A0 Origin =3D "GenuineIntel" =C2=A0Id =3D 0x306e4 =C2=A0Famil= >y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4
>=C2=A0 Features=3D0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP= >,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>=C2=A0 Features2=3D0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4= >.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
>=C2=A0 AMD Features=3D0x28100800<SYSCALL,NX,RDTSCP,LM>
>=C2=A0 AMD Features2=3D0x1<LAHF>
>=C2=A0 Standard Extended Features=3D0x200<ENHMOVSB>
>real memory =C2=A0=3D 4026531840 (3840 MB)
>avail memory =3D 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 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.
> >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.
> >The pthreads seems pretty stable at least on linux.
>
>Peter
>
>
> >--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: <20140526234916.864741A209C@async.async.caltech.edu> <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, 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 >>> >>> Features2=0xffba2203> V> >>> AMD Features=0x28100800 >>> AMD Features2=0x1 >>> Standard Extended Features=0x200 >>> real memory = 4026531840 (3840 MB) >>> avail memory = 3872776192 (3693 MB) >>> Event timer "LAPIC" quality 400 >>> ACPI APIC Table: >>> >>> >>> >>> >>>>>>>> >>> >>> 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 >> >>

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.

>> >>

Peter

>>
On 27/05/2014 9:49 AM, <> ka at async.caltech.edu">mika at async.caltech.edu> wrote:
> ibution">
> r-left:1px #ccc solid;padding-left:1ex"> >>
>> Peter, have you/someone run the thread tester exhaustively?
>>
>> I did this:
>>
>> #!/bin/csh
>>
>> while ( 1 )
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr= >> eadtest
>> end
>>
>> With what's in FreeBSD's ports I get a variety of failures:
>>
>>
>> 1.
>> ***
>> *** runtime error:
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >> IL
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3
>> ***
>>
>> 2.
>> running...printing oldest/median age/newest
>> .Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele= >> te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>>
>> 3. (most common)
>> ***
>> *** runtime error:
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >> IL
>> *** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R= >> TCollector.m3
>> ***
>>
>> 4.
>> ***
>> *** runtime error:
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >> IL
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D 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... =C2=A0us= >> ually things get worse with more processors.
>>
>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>> =C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER= >> IC 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)> r> >> =C2=A0 Origin =3D "GenuineIntel" =C2=A0Id =3D 0x306e4 =C2=A0Famil= >> y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4
>> =C2=A0 Features=3D0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP= >> ,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>> =C2=A0 Features2=3D0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4= >> .2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
>> =C2=A0 AMD Features=3D0x28100800<SYSCALL,NX,RDTSCP,LM>
>> =C2=A0 AMD Features2=3D0x1<LAHF>
>> =C2=A0 Standard Extended Features=3D0x200<ENHMOVSB>
>> real memory =C2=A0=3D 4026531840 (3840 MB)
>> avail memory =3D 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 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.
>> >> 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.
>> >> The pthreads seems pretty stable at least on linux.
>>
>> Peter
>>
>>
>> >> --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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> Message-ID: Jay might comment on C backend status for those platforms. On May 27, 2014, at 11:40 AM, John Marino 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 wrote: >> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens >>> 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, Message-ID: 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 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 wrote: > >> > >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens > >>> 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: 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: References: , <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, , <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, , <5384B209.3080504@marino.st>, , , Message-ID: 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 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 wrote: > >> > >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens > >>> 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: 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: References: <535FA2B2.70108@gmail.com>, Message-ID: .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 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: 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: References: <535FA2B2.70108@gmail.com>, 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 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: 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: <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 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, 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>, , , , <8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org> Message-ID: 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 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> Message-ID: > 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: 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> <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: 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: , <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, , <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, , <5384B209.3080504@marino.st>, , , , , <5385A122.4020205@marino.st>, , <20140528182503.087801A2095@async.async.caltech.edu>, <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> Message-ID: 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> <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 > >charset=3Dus-ascii">-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).

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, href=3D"mailto:mika at async.caltech.edu">mika at async.caltech.edu = >wrote:

Jay K writes:
type=3D"cite">--_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.
=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.
...

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

>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; ">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; ">
break-word; -webkit-nbsp-mode: space; -webkit-line-break: = >after-white-space; ">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; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">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; ">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; ">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; ">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; ">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; ">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; ">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; ">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; ">
class=3D"Apple-style-span" color=3D"#0000FF">class=3D"Apple-style-span" face=3D"Gill Sans">class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = >'Gill Sans'; ">0, 255); font-family: 'Gill Sans'; ">Antony = >Hoskingface=3D"Gill Sans">'Gill Sans'; ">'Gill Sans'; "> |class=3D"Apple-converted-space"> class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; ">class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; = >">Associate Professorstyle=3D"font-family: 'Gill Sans'; ">style=3D"font-family: 'Gill Sans'; "> | Computer Science | Purdue = >University
face=3D"GillSans-Light">style=3D"font-family: GillSans-Light; ">305 N. University Street | West = >Lafayette | IN 47907 | USA
class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans">class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = >'Gill Sans'; ">0, 255); font-family: 'Gill Sans'; ">Mobileclass=3D"Apple-style-span" face=3D"GillSans-Light">class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">class=3D"Apple-converted-space"> +1 765 427 = >5484
face=3D"GillSans-Light">
class=3D"khtml-block-placeholder">
>

class=3D"Apple-interchange-newline">

class=3D"Apple-interchange-newline">

class=3D"Apple-interchange-newline"> >
>
= > >--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 > 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: 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: 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: 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: 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: 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> <5385A122.4020205@marino.st> <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 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 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: 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 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: 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: 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: 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: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: 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: 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 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: 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: 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: 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>, <688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org> Message-ID: 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? 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 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?" 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 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 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: -------------- 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: 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: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>, 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: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL> <538751AD.8080206@lcwb.coop> 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 >> > -- 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>, <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? 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 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?" 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 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 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: -------------- 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: 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: 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: 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" 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> <5385A122.4020205@marino.st> <20140528182503.087801A2095@async.async.caltech.edu> <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> <20140528203218.658CC1A2096@async.async.caltech.edu> <5386B98C.7040904@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 -- m3_link 969 C:\cm3\bin/config\NT386.common program -- 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> <5385A122.4020205@marino.st> <20140528182503.087801A2095@async.async.caltech.edu> <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> <20140528203218.658CC1A2096@async.async.caltech.edu> <5386B98C.7040904@gmail.com>, , <53898228.9010807@elego.de>, <5389E1BD.4030603@gmail.com> Message-ID: 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 -- m3_link 969 C:\cm3\bin/config\NT386.common program -- 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: 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: 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: 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: 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: 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: 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: 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: 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: 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? 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: 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: 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 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: -------------- 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: 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: 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: References: Message-ID: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens 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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 _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 -- 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: References: 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 Features2=0xffba2203 AMD Features=0x28100800 AMD Features2=0x1 Standard Extended Features=0x200 real memory = 4026531840 (3840 MB) avail memory = 3872776192 (3693 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: >>>>> 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: <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 wrote: > On Sun, 25 May 2014 22:35:09 +0800 > Bruce Axtens 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: 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: <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 wrote: > >> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens >> 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: 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 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: 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: References: <20140526234916.864741A209C@async.async.caltech.edu> 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, 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 >> >> Features2=0xffba2203V> >> AMD Features=0x28100800 >> AMD Features2=0x1 >> Standard Extended Features=0x200 >> real memory = 4026531840 (3840 MB) >> avail memory = 3872776192 (3693 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> >> >> >> >> >>>>> >> >> 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 > >

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.

> >

Peter

>
On 27/05/2014 9:49 AM, <ka at async.caltech.edu">mika at async.caltech.edu> wrote:
ibution">
r-left:1px #ccc solid;padding-left:1ex"> >
>Peter, have you/someone run the thread tester exhaustively?
>
>I did this:
>
>#!/bin/csh
>
>while ( 1 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr= >eadtest
>end
>
>With what's in FreeBSD's ports I get a variety of failures:
>
>
>1.
>***
>*** runtime error:
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >IL
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3
>***
>
>2.
>running...printing oldest/median age/newest
>.Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele= >te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>
>3. (most common)
>***
>*** runtime error:
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >IL
>*** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R= >TCollector.m3
>***
>
>4.
>***
>*** runtime error:
>*** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >IL
>*** =C2=A0 =C2=A0pc =3D 0x417c78 =3D 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... =C2=A0us= >ually things get worse with more processors.
>
>FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>=C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER= >IC 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)r> >=C2=A0 Origin =3D "GenuineIntel" =C2=A0Id =3D 0x306e4 =C2=A0Famil= >y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4
>=C2=A0 Features=3D0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP= >,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>=C2=A0 Features2=3D0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4= >.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
>=C2=A0 AMD Features=3D0x28100800<SYSCALL,NX,RDTSCP,LM>
>=C2=A0 AMD Features2=3D0x1<LAHF>
>=C2=A0 Standard Extended Features=3D0x200<ENHMOVSB>
>real memory =C2=A0=3D 4026531840 (3840 MB)
>avail memory =3D 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 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.
> >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.
> >The pthreads seems pretty stable at least on linux.
>
>Peter
>
>
> >--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: <20140526234916.864741A209C@async.async.caltech.edu> <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, 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 >>> >>> Features2=0xffba2203> V> >>> AMD Features=0x28100800 >>> AMD Features2=0x1 >>> Standard Extended Features=0x200 >>> real memory = 4026531840 (3840 MB) >>> avail memory = 3872776192 (3693 MB) >>> Event timer "LAPIC" quality 400 >>> ACPI APIC Table: >>> >>> >>> >>> >>>>>>>> >>> >>> 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 >> >>

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.

>> >>

Peter

>>
On 27/05/2014 9:49 AM, <> ka at async.caltech.edu">mika at async.caltech.edu> wrote:
> ibution">
> r-left:1px #ccc solid;padding-left:1ex"> >>
>> Peter, have you/someone run the thread tester exhaustively?
>>
>> I did this:
>>
>> #!/bin/csh
>>
>> while ( 1 )
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 limit cputime 5
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/thr= >> eadtest
>> end
>>
>> With what's in FreeBSD's ports I get a variety of failures:
>>
>>
>> 1.
>> ***
>> *** runtime error:
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >> IL
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D Init + 0xe6 in ../src/rw/FileRd.m3
>> ***
>>
>> 2.
>> running...printing oldest/median age/newest
>> .Assertion failed: (e =3D=3D 0), function ThreadPThread__pthread_mutex_dele= >> te, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.
>>
>> 3. (most common)
>> ***
>> *** runtime error:
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >> IL
>> *** =C2=A0 =C2=A0pc =3D 0x4387e8 =3D Move + 0x6a in ../src/runtime/common/R= >> TCollector.m3
>> ***
>>
>> 4.
>> ***
>> *** runtime error:
>> *** =C2=A0 =C2=A0Segmentation violation - possible attempt to dereference N= >> IL
>> *** =C2=A0 =C2=A0pc =3D 0x417c78 =3D 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... =C2=A0us= >> ually things get worse with more processors.
>>
>> FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
>> =C2=A0 =C2=A0 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENER= >> IC 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)> r> >> =C2=A0 Origin =3D "GenuineIntel" =C2=A0Id =3D 0x306e4 =C2=A0Famil= >> y =3D 0x6 =C2=A0Model =3D 0x3e =C2=A0Stepping =3D 4
>> =C2=A0 Features=3D0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP= >> ,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
>> =C2=A0 Features2=3D0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4= >> .2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
>> =C2=A0 AMD Features=3D0x28100800<SYSCALL,NX,RDTSCP,LM>
>> =C2=A0 AMD Features2=3D0x1<LAHF>
>> =C2=A0 Standard Extended Features=3D0x200<ENHMOVSB>
>> real memory =C2=A0=3D 4026531840 (3840 MB)
>> avail memory =3D 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 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.
>> >> 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.
>> >> The pthreads seems pretty stable at least on linux.
>>
>> Peter
>>
>>
>> >> --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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> Message-ID: Jay might comment on C backend status for those platforms. On May 27, 2014, at 11:40 AM, John Marino 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 wrote: >> >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens >>> 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, Message-ID: 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 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 wrote: > >> > >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens > >>> 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: 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: References: , <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, , <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, , <5384B209.3080504@marino.st>, , , Message-ID: 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 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 wrote: > >> > >>> On Sun, 25 May 2014 22:35:09 +0800 Bruce Axtens > >>> 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: 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: References: <535FA2B2.70108@gmail.com>, Message-ID: .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 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: 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: References: <535FA2B2.70108@gmail.com>, 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 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: 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: <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 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, 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>, , , , <8EE34D10-9003-4543-8B18-B9C3B6D218ED@elstel.org> Message-ID: 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 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> Message-ID: > 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: 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> 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: References: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> <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: 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: , <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, , <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, , <5384B209.3080504@marino.st>, , , , , <5385A122.4020205@marino.st>, , <20140528182503.087801A2095@async.async.caltech.edu>, <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> Message-ID: 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com>, <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org>, <5384B209.3080504@marino.st>, , <5385A122.4020205@marino.st> <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 > >charset=3Dus-ascii">-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).

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, href=3D"mailto:mika at async.caltech.edu">mika at async.caltech.edu = >wrote:

Jay K writes:
type=3D"cite">--_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.
=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.
...

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

>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; ">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; ">
break-word; -webkit-nbsp-mode: space; -webkit-line-break: = >after-white-space; ">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; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">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; ">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; ">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; ">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; ">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; ">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; ">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; ">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; ">
class=3D"Apple-style-span" color=3D"#0000FF">class=3D"Apple-style-span" face=3D"Gill Sans">class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = >'Gill Sans'; ">0, 255); font-family: 'Gill Sans'; ">Antony = >Hoskingface=3D"Gill Sans">'Gill Sans'; ">'Gill Sans'; "> |class=3D"Apple-converted-space"> class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; ">class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; = >">Associate Professorstyle=3D"font-family: 'Gill Sans'; ">style=3D"font-family: 'Gill Sans'; "> | Computer Science | Purdue = >University
face=3D"GillSans-Light">style=3D"font-family: GillSans-Light; ">305 N. University Street | West = >Lafayette | IN 47907 | USA
class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans">class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = >'Gill Sans'; ">0, 255); font-family: 'Gill Sans'; ">Mobileclass=3D"Apple-style-span" face=3D"GillSans-Light">class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">class=3D"Apple-converted-space"> +1 765 427 = >5484
face=3D"GillSans-Light">
class=3D"khtml-block-placeholder">
>

class=3D"Apple-interchange-newline">

class=3D"Apple-interchange-newline">

class=3D"Apple-interchange-newline"> >
>
= > >--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 > 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: 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: 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: 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: 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: 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> <5385A122.4020205@marino.st> <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 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 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: 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 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: 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: 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: 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: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>, Message-ID: 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: 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 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: 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: 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: 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>, <688E1E2E-D298-4FD3-84DD-2F2F60E4D0A6@m3w.org> Message-ID: 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? 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 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?" 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 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 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: -------------- 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: 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: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A88D1@ATLEX04-SRV.SCIRES.LOCAL>, <0BB8FA59C2932741A3A2941A8B9D8BFF926A8A29@ATLEX04-SRV.SCIRES.LOCAL>, 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: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL> <538751AD.8080206@lcwb.coop> 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 >> > -- 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>, <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? 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 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?" 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 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 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: -------------- 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: 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: 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: 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" 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> <5385A122.4020205@marino.st> <20140528182503.087801A2095@async.async.caltech.edu> <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> <20140528203218.658CC1A2096@async.async.caltech.edu> <5386B98C.7040904@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 -- m3_link 969 C:\cm3\bin/config\NT386.common program -- 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: 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: <20140525183616.41f7ad1ad5d978580f0ef286@elegosoft.com> <632FF432-5CEC-4F30-BC06-9D5505800518@m3w.org> <5384B209.3080504@marino.st> <5385A122.4020205@marino.st> <20140528182503.087801A2095@async.async.caltech.edu> <598FAEAD-793F-4D6A-B1D2-5210E3BF9B28@cs.purdue.edu> <20140528203218.658CC1A2096@async.async.caltech.edu> <5386B98C.7040904@gmail.com>, , <53898228.9010807@elego.de>, <5389E1BD.4030603@gmail.com> Message-ID: 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 -- m3_link 969 C:\cm3\bin/config\NT386.common program -- 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: 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: 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: 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: 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: 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: 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: 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: 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: 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? 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: