From rodney_bates at lcwb.coop Tue Nov 5 18:47:13 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 05 Nov 2013 11:47:13 -0600 Subject: [M3devel] How to run m3cggen? Message-ID: <52792F21.6020802@lcwb.coop> I need to rebuild m3cc after changes to m3middle/src/M3CG_Binary.i3 and m3cggen/src/Main. I can see that at a minimum, I have to recompile m3cggen first, then run it and place its output appropriately, before compiling m3cc. m3cggen comes after m3cc in pkginfo.txt, so the do-cm3-*.sh scripts can't work here. A massive recursive grep of everything for "m3cggen" doesn't appear to turn up anything in a script, makefile, or m3makefile, other than disconnected building of m3cggen itself. However, there is so much false output here, that it's a needle in a haystack. So is there any script, makefile, etc. that takes care of this, or is it all manual? Are there any other generated source files or similar steps that also need to be redone that I can't easily find? m3cg.h (The result of this process) is a CVS file, which at least hints that this is just being done manually. Slightly related, I found out the hard way that the parse.c in the gcc version you are compiling is actually, sometimes, overlaid during building, by the one in gcc/gcc/m3cg. What is the complete set of source files that, like this, are not where one would expect them to be? Is it everything in the m3cg subdirectory? Just parse.c? Some other subset? From jay.krell at cornell.edu Tue Nov 5 19:55:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Nov 2013 18:55:38 +0000 Subject: [M3devel] How to run m3cggen? In-Reply-To: <52792F21.6020802@lcwb.coop> References: <52792F21.6020802@lcwb.coop> Message-ID: Right. I hit the same problem at some point and wasn't satisfied either. I fixed it, or almost fixed it. Building it in a list of other stuff is correct, not a false hit, part of the solution. upgrade.sh and ugprade.py both handle this, almost. upgrade.sh: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain if [ "x${GCC_BACKEND}" = xyes ]; then # Continue with the backend, if needed. Deliberately don't ship it! # "$root/m3-sys/m3cggen/${TARGET}/m3cggen" > "$root/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" "$root/scripts/do-pkg.sh" "$@" "build" m3cc || exit 1 fi upgrade.py: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/upgrade.py?rev=1.39;content-type=text%2Fplain a = Root + "/m3-sys/m3cggen/" + Target + "/m3cggen > " + Root + "/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" print(a) # os.system(a) FilterPackages([ "m3cc" ]) and DoPackage(argv_BuildShip, [ "m3cc" ]) Those two lines should be uncommented. Or, more likely, they should redirect elsewhere and do a "move if change". In the python case, "elsewhere" should be read the pipe into a variable in memory. It isn't supposed to change if there are no local edits, but streamlining it is very good to have. Maybe that is why I left it commented out. Only approx. 3 of us have changed this probably in 10 years. Tony probably doesn't use any of the scripts. I do and almost fixed it. You are #3. Can you make it so or shall I? m3cggen is "standalone" for this reason, or should be. > gcc/gcc/m3cg. > What is the complete set of source files that, like this, are not where one would > expect them to be? Is it everything in the m3cg subdirectory? Just parse.c? The list is whatever the source does. The alternative would be to have several almost identical copies and disconnected history. It is a little confusing, but the alternative isn't great either. For parse.c, and related, look in m3-sys/src/m3makefile. For example, we also sometimes have to make links for gmp/mpfr/mpc. - Jay > Date: Tue, 5 Nov 2013 11:47:13 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] How to run m3cggen? > > I need to rebuild m3cc after changes to m3middle/src/M3CG_Binary.i3 and m3cggen/src/Main. > I can see that at a minimum, I have to recompile m3cggen first, then run it and place > its output appropriately, before compiling m3cc. m3cggen comes after m3cc in pkginfo.txt, > so the do-cm3-*.sh scripts can't work here. > > A massive recursive grep of everything for "m3cggen" doesn't appear to turn up anything in > a script, makefile, or m3makefile, other than disconnected building of m3cggen itself. > However, there is so much false output here, that it's a needle in a haystack. > > So is there any script, makefile, etc. that takes care of this, or is it all manual? > Are there any other generated source files or similar steps that also need to be redone > that I can't easily find? > > m3cg.h (The result of this process) is a CVS file, which at least hints that this is > just being done manually. > > Slightly related, I found out the hard way that the parse.c in the gcc version you are > compiling is actually, sometimes, overlaid during building, by the one in gcc/gcc/m3cg. > What is the complete set of source files that, like this, are not where one would > expect them to be? Is it everything in the m3cg subdirectory? Just parse.c? > Some other subset? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Nov 10 18:48:22 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 10 Nov 2013 18:48:22 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks Message-ID: Anybody doing it? 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 Mon Nov 11 08:09:23 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 11 Nov 2013 07:09:23 +0000 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: Message-ID: I'm still hanging back on a version that supports PowerPC/Rosetta. ?:)? ?Our system is very portable.? ? Consider helloWorld. And users of pthreads (or Win32 threads). ? ?And we hope/trust Apple and co. to maintain a certain level of compatibility.? ?For example. the HPUX man pages decree that get/set/make/swapcontext may? ? not be compatible across releases. We use them, sometimes, for user threads only.? If you find there is any problem, please let us know. Anything you find is likely surmountable by a cross build. ?- Jay ________________________________ > From: dragisha at m3w.org > Date: Sun, 10 Nov 2013 18:48:22 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] AMD64_DARWIN with OSX Mavericks > > Anybody doing it? > > TIA, > -- > Dragi?a Duri? > dragisha at m3w.org From dragisha at m3w.org Wed Nov 13 10:03:15 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 10:03:15 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: Message-ID: I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common SYSTEM_LIBS = { "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" ], "LEX-YACC" : [ "-ll" ], "FLEX-BISON" : [ "-lfl" ], "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], "TCP" : [ ] % below: X11, ODBC, POSTGRES95, MOTIF } My current AMD64_DARWIN configuration continues to work. -- Dragi?a Duri? dragisha at m3w.org On 11 Nov 2013, at 08:09, Jay K wrote: > I'm still hanging back on a version that supports PowerPC/Rosetta. :) > > Our system is very portable. > Consider helloWorld. And users of pthreads (or Win32 threads). > > And we hope/trust Apple and co. to maintain a certain level of compatibility. > > For example. the HPUX man pages decree that get/set/make/swapcontext may > not be compatible across releases. We use them, sometimes, for user threads only. > > > If you find there is any problem, please let us know. > Anything you find is likely surmountable by a cross build. > > > - Jay > > ________________________________ >> From: dragisha at m3w.org >> Date: Sun, 10 Nov 2013 18:48:22 +0100 >> To: m3devel at elegosoft.com >> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >> >> Anybody doing it? >> >> 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 Wed Nov 13 10:53:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 13 Nov 2013 09:53:17 +0000 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: , Message-ID: Is that really needed? Doesn't this work? hello.c: #include int main() { return !!printf("hello\n"); } cc hello.c If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) - Jay Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks From: dragisha at m3w.org Date: Wed, 13 Nov 2013 10:03:15 +0100 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common SYSTEM_LIBS = { "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" ], "LEX-YACC" : [ "-ll" ], "FLEX-BISON" : [ "-lfl" ], "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], "TCP" : [ ]% below: X11, ODBC, POSTGRES95, MOTIF} My current AMD64_DARWIN configuration continues to work.--Dragi?a Duri?dragisha at m3w.org On 11 Nov 2013, at 08:09, Jay K wrote:I'm still hanging back on a version that supports PowerPC/Rosetta. :) Our system is very portable. Consider helloWorld. And users of pthreads (or Win32 threads). And we hope/trust Apple and co. to maintain a certain level of compatibility. For example. the HPUX man pages decree that get/set/make/swapcontext may not be compatible across releases. We use them, sometimes, for user threads only. If you find there is any problem, please let us know. Anything you find is likely surmountable by a cross build. - Jay ________________________________ From: dragisha at m3w.org Date: Sun, 10 Nov 2013 18:48:22 +0100 To: m3devel at elegosoft.com Subject: [M3devel] AMD64_DARWIN with OSX Mavericks Anybody doing it? TIA, -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Nov 13 11:08:47 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 11:08:47 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: , Message-ID: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 10:53, Jay K wrote: > Is that really needed? > > Doesn't this work? > > hello.c: > #include > int main() { return !!printf("hello\n"); } > > cc hello.c > > If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) > > - Jay > > > > > Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks > From: dragisha at m3w.org > Date: Wed, 13 Nov 2013 10:03:15 +0100 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common > > SYSTEM_LIBS = { > "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", > "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" > ], > "LEX-YACC" : [ "-ll" ], > "FLEX-BISON" : [ "-lfl" ], > "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, > "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], > "TCP" : [ ] > % below: X11, ODBC, POSTGRES95, MOTIF > } > > My current AMD64_DARWIN configuration continues to work. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 11 Nov 2013, at 08:09, Jay K wrote: > > I'm still hanging back on a version that supports PowerPC/Rosetta. :) > > Our system is very portable. > Consider helloWorld. And users of pthreads (or Win32 threads). > > And we hope/trust Apple and co. to maintain a certain level of compatibility. > > For example. the HPUX man pages decree that get/set/make/swapcontext may > not be compatible across releases. We use them, sometimes, for user threads only. > > > If you find there is any problem, please let us know. > Anything you find is likely surmountable by a cross build. > > > - Jay > > ________________________________ > From: dragisha at m3w.org > Date: Sun, 10 Nov 2013 18:48:22 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] AMD64_DARWIN with OSX Mavericks > > Anybody doing it? > > 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 dragisha at m3w.org Wed Nov 13 11:25:43 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 11:25:43 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> References: , <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> Message-ID: <0548803B-A685-420A-8C84-B1C365257775@m3w.org> Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. Xcode I have installed is version 4.6.x, and cm3 works as always. -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: > There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 10:53, Jay K wrote: > >> Is that really needed? >> >> Doesn't this work? >> >> hello.c: >> #include >> int main() { return !!printf("hello\n"); } >> >> cc hello.c >> >> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >> >> - Jay >> >> >> >> >> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >> From: dragisha at m3w.org >> Date: Wed, 13 Nov 2013 10:03:15 +0100 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >> >> SYSTEM_LIBS = { >> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >> ], >> "LEX-YACC" : [ "-ll" ], >> "FLEX-BISON" : [ "-lfl" ], >> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >> "TCP" : [ ] >> % below: X11, ODBC, POSTGRES95, MOTIF >> } >> >> My current AMD64_DARWIN configuration continues to work. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 11 Nov 2013, at 08:09, Jay K wrote: >> >> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >> >> Our system is very portable. >> Consider helloWorld. And users of pthreads (or Win32 threads). >> >> And we hope/trust Apple and co. to maintain a certain level of compatibility. >> >> For example. the HPUX man pages decree that get/set/make/swapcontext may >> not be compatible across releases. We use them, sometimes, for user threads only. >> >> >> If you find there is any problem, please let us know. >> Anything you find is likely surmountable by a cross build. >> >> >> - Jay >> >> ________________________________ >> From: dragisha at m3w.org >> Date: Sun, 10 Nov 2013 18:48:22 +0100 >> To: m3devel at elegosoft.com >> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >> >> Anybody doing it? >> >> 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 dragisha at m3w.org Wed Nov 13 19:27:20 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 19:27:20 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <0548803B-A685-420A-8C84-B1C365257775@m3w.org> References: , <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> Message-ID: <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> After Xcode 5.0.2 install, it works no more :) new source -> compiling Main.m3 clang: warning: argument unused during compilation: '-fPIC' Main.ms:1:9: error: unsupported directive '.stabs' .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 ^ -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote: > Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. > > Xcode I have installed is version 4.6.x, and cm3 works as always. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: > >> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 10:53, Jay K wrote: >> >>> Is that really needed? >>> >>> Doesn't this work? >>> >>> hello.c: >>> #include >>> int main() { return !!printf("hello\n"); } >>> >>> cc hello.c >>> >>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>> >>> - Jay >>> >>> >>> >>> >>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>> From: dragisha at m3w.org >>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>> CC: m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>> >>> SYSTEM_LIBS = { >>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>> ], >>> "LEX-YACC" : [ "-ll" ], >>> "FLEX-BISON" : [ "-lfl" ], >>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>> "TCP" : [ ] >>> % below: X11, ODBC, POSTGRES95, MOTIF >>> } >>> >>> My current AMD64_DARWIN configuration continues to work. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 11 Nov 2013, at 08:09, Jay K wrote: >>> >>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>> >>> Our system is very portable. >>> Consider helloWorld. And users of pthreads (or Win32 threads). >>> >>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>> >>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>> not be compatible across releases. We use them, sometimes, for user threads only. >>> >>> >>> If you find there is any problem, please let us know. >>> Anything you find is likely surmountable by a cross build. >>> >>> >>> - Jay >>> >>> ________________________________ >>> From: dragisha at m3w.org >>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>> >>> Anybody doing it? >>> >>> 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 dragisha at m3w.org Wed Nov 13 19:38:07 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 19:38:07 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <5705AEB1-3476-44BD-BAE5-3EA14D34E6F4@gmail.com> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> <5705AEB1-3476-44BD-BAE5-3EA14D34E6F4@gmail.com> Message-ID: AFAIK, automake/autoconf is big pain? of C world. Whole build systems were devised/built, just to bypass autowhatever. I don?t see any reason to envy current C build systems. But, if you are looking for a model, then also look at Maven/Gradle of Java world. Convention over configuration paradigm (very accepted, and which looks very much like cm3 config + m3makefile ) is so far away from autowhatever as possible. -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 18:11, Jay wrote: > I do repeatedly wonder if we should be a thin layer over automake/autoconf/pkg-config/libtool. I look into them every so often. What bugs me, maybe not pkg-config, is that they seem slow and have to generate files. I want something that usually makes fast decisions for every run. Optionally recording them in a file for bootstrapping or overridability. Cm3 was ahead of its time, kinda, but those tools solve much of the same problem, with other people maintaining them and more "dynamism"/"manifestation" -- I can't think of the word, but throw together a random posixish platform and autoconf can probe it and piece it together. There is no need to record static platform definitions and local configuration details are inferred/deduced at build-time, and there is good cross build support. > -------------- 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 Thu Nov 14 04:04:34 2013 From: jay.krell at cornell.edu (Jay) Date: Wed, 13 Nov 2013 19:04:34 -0800 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> Message-ID: <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> Try the C backed? Edit the g/stabs flag in the config file? - Jay On Nov 13, 2013, at 10:27 AM, Dragi?a Duri? wrote: > After Xcode 5.0.2 install, it works no more :) > > new source -> compiling Main.m3 > clang: warning: argument unused during compilation: '-fPIC' > Main.ms:1:9: error: unsupported directive '.stabs' > .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 > ^ > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote: > >> Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. >> >> Xcode I have installed is version 4.6.x, and cm3 works as always. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: >> >>> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 13 Nov 2013, at 10:53, Jay K wrote: >>> >>>> Is that really needed? >>>> >>>> Doesn't this work? >>>> >>>> hello.c: >>>> #include >>>> int main() { return !!printf("hello\n"); } >>>> >>>> cc hello.c >>>> >>>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>>> From: dragisha at m3w.org >>>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>>> CC: m3devel at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>>> >>>> SYSTEM_LIBS = { >>>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>>> ], >>>> "LEX-YACC" : [ "-ll" ], >>>> "FLEX-BISON" : [ "-lfl" ], >>>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>>> "TCP" : [ ] >>>> % below: X11, ODBC, POSTGRES95, MOTIF >>>> } >>>> >>>> My current AMD64_DARWIN configuration continues to work. >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On 11 Nov 2013, at 08:09, Jay K wrote: >>>> >>>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>>> >>>> Our system is very portable. >>>> Consider helloWorld. And users of pthreads (or Win32 threads). >>>> >>>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>>> >>>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>>> not be compatible across releases. We use them, sometimes, for user threads only. >>>> >>>> >>>> If you find there is any problem, please let us know. >>>> Anything you find is likely surmountable by a cross build. >>>> >>>> >>>> - Jay >>>> >>>> ________________________________ >>>> From: dragisha at m3w.org >>>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>>> To: m3devel at elegosoft.com >>>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>>> >>>> Anybody doing it? >>>> >>>> TIA, >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 14 05:30:42 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 14 Nov 2013 04:30:42 +0000 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> References: , , , , <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org>, <0548803B-A685-420A-8C84-B1C365257775@m3w.org>, <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org>, <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> Message-ID: > AFAIK, automake/autoconf is big pain. of C world. > Whole build systems were devised/built, just to bypass autowhatever. Yes but my research suggests nobody has matched it, in particular for cross builds and in particular autoconf's ability to work with brand new systems, as long as they can be composed from preexisting variables -- which are probed for. But I don't like layers and layers of generated files, Bourne shell, and m4. C and C++ aren't so bad. They do have positive and negatives. Lack of a good module system is one of their negatives. And therefore build speed and incremental builds. cm3 resembles the ideal user interface of automake, but without generating files. Where I most want autoX/libtool/pkg-config is to determine how to run the C compiler/assembler/linker for given packages. I think pkg-config addresses one of our weakest point. The point in the config files that list "ODBC" or "POSTGRES" and such. That part has never seemed great, not even with cminstall. The problem with cminstall is that packages can be installed and uninstalled in any order. I kinda think we could support it within cm3, easily enough, in one of a few ways: meta-syntax in the config file to indicate we should run pkg-config --libs and add that to the link command or we could try it unconditionally or we could find the .pc files ourselves, conditionally or unconditionally. see http://linux.die.net/man/1/pkg-config Someday maybe we'll generate .h files to interfacing with Modula-3, and then we could create .pc files also.. libtool I also want, because we duplicate a lot of it. Better to punt to another project. Though the wide availability of gcc combined with convergence to not that many OSes makes it not too difficult to do it yourself, which is what we do... - Jay From: jay.krell at cornell.edu Date: Wed, 13 Nov 2013 19:04:34 -0800 To: dragisha at m3w.org CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks Try the C backed? Edit the g/stabs flag in the config file? - Jay On Nov 13, 2013, at 10:27 AM, Dragi?a Duri? wrote: After Xcode 5.0.2 install, it works no more :) new source -> compiling Main.m3clang: warning: argument unused during compilation: '-fPIC'Main.ms:1:9: error: unsupported directive '.stabs' .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 ^ --Dragi?a Duri?dragisha at m3w.org On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote:Site is https://developer.apple.com/downloads, package is named "Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013" and cm3 I've used since Snow Leopard, all through Lion. works again without previous hack. Xcode I have installed is version 4.6.x, and cm3 works as always. --Dragi?a Duri?dragisha at m3w.org On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote:There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. --Dragi?a Duri?dragisha at m3w.org On 13 Nov 2013, at 10:53, Jay K wrote:Is that really needed? Doesn't this work? hello.c: #include int main() { return !!printf("hello\n"); } cc hello.c If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) - Jay Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks From: dragisha at m3w.org Date: Wed, 13 Nov 2013 10:03:15 +0100 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common SYSTEM_LIBS = { "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" ], "LEX-YACC" : [ "-ll" ], "FLEX-BISON" : [ "-lfl" ], "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], "TCP" : [ ]% below: X11, ODBC, POSTGRES95, MOTIF} My current AMD64_DARWIN configuration continues to work.--Dragi?a Duri?dragisha at m3w.org On 11 Nov 2013, at 08:09, Jay K wrote:I'm still hanging back on a version that supports PowerPC/Rosetta. :) Our system is very portable. Consider helloWorld. And users of pthreads (or Win32 threads). And we hope/trust Apple and co. to maintain a certain level of compatibility. For example. the HPUX man pages decree that get/set/make/swapcontext may not be compatible across releases. We use them, sometimes, for user threads only. If you find there is any problem, please let us know. Anything you find is likely surmountable by a cross build. - Jay ________________________________ From: dragisha at m3w.org Date: Sun, 10 Nov 2013 18:48:22 +0100 To: m3devel at elegosoft.com Subject: [M3devel] AMD64_DARWIN with OSX Mavericks Anybody doing it? TIA, -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Nov 13 18:11:22 2013 From: jay.krell at cornell.edu (Jay) Date: Wed, 13 Nov 2013 09:11:22 -0800 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <0548803B-A685-420A-8C84-B1C365257775@m3w.org> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> Message-ID: <5705AEB1-3476-44BD-BAE5-3EA14D34E6F4@gmail.com> I do repeatedly wonder if we should be a thin layer over automake/autoconf/pkg-config/libtool. I look into them every so often. What bugs me, maybe not pkg-config, is that they seem slow and have to generate files. I want something that usually makes fast decisions for every run. Optionally recording them in a file for bootstrapping or overridability. Cm3 was ahead of its time, kinda, but those tools solve much of the same problem, with other people maintaining them and more "dynamism"/"manifestation" -- I can't think of the word, but throw together a random posixish platform and autoconf can probe it and piece it together. There is no need to record static platform definitions and local configuration details are inferred/deduced at build-time, and there is good cross build support. I've considered coding up similar in M3/Python/C/C++. I do put some runtime tests in the config files. I suppose pkg-config is what we miss most, and we could read its files in cm3??? I.e. this is the part of the config files that are the most site-specific, and worse, need to change as surrounding packages are installed/uninstalled? What autoconf is "really" for, we get very far with light dependencies ("the functions are assumed all present"), light ifdefing (m3core's preemptive suspend), and light "practicality" (I.e. picking out integer types). Automake we basically have our own. Libtool I believe works through static knowledge, like us. And pkg-config, we miss out on largely. - Jay On Nov 13, 2013, at 2:25 AM, Dragi?a Duri? wrote: > Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. > > Xcode I have installed is version 4.6.x, and cm3 works as always. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: > >> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 10:53, Jay K wrote: >> >>> Is that really needed? >>> >>> Doesn't this work? >>> >>> hello.c: >>> #include >>> int main() { return !!printf("hello\n"); } >>> >>> cc hello.c >>> >>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>> >>> - Jay >>> >>> >>> >>> >>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>> From: dragisha at m3w.org >>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>> CC: m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>> >>> SYSTEM_LIBS = { >>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>> ], >>> "LEX-YACC" : [ "-ll" ], >>> "FLEX-BISON" : [ "-lfl" ], >>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>> "TCP" : [ ] >>> % below: X11, ODBC, POSTGRES95, MOTIF >>> } >>> >>> My current AMD64_DARWIN configuration continues to work. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 11 Nov 2013, at 08:09, Jay K wrote: >>> >>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>> >>> Our system is very portable. >>> Consider helloWorld. And users of pthreads (or Win32 threads). >>> >>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>> >>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>> not be compatible across releases. We use them, sometimes, for user threads only. >>> >>> >>> If you find there is any problem, please let us know. >>> Anything you find is likely surmountable by a cross build. >>> >>> >>> - Jay >>> >>> ________________________________ >>> From: dragisha at m3w.org >>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>> >>> Anybody doing it? >>> >>> TIA, >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Nov 14 12:14:34 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 14 Nov 2013 12:14:34 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> Message-ID: <7F9E43C8-CF1B-422C-88B9-14B576CEDC76@m3w.org> I will, time permitting :). Right now, working recipe is - Xcode 4.6.3 downgrade, alreay mentioned command line utils installed. It works like it always had. -- Dragi?a Duri? dragisha at m3w.org On 14 Nov 2013, at 04:04, Jay wrote: > Try the C backed? > > > Edit the g/stabs flag in the config file? > > > - Jay > > On Nov 13, 2013, at 10:27 AM, Dragi?a Duri? wrote: > >> After Xcode 5.0.2 install, it works no more :) >> >> new source -> compiling Main.m3 >> clang: warning: argument unused during compilation: '-fPIC' >> Main.ms:1:9: error: unsupported directive '.stabs' >> .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 >> ^ >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote: >> >>> Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. >>> >>> Xcode I have installed is version 4.6.x, and cm3 works as always. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: >>> >>>> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On 13 Nov 2013, at 10:53, Jay K wrote: >>>> >>>>> Is that really needed? >>>>> >>>>> Doesn't this work? >>>>> >>>>> hello.c: >>>>> #include >>>>> int main() { return !!printf("hello\n"); } >>>>> >>>>> cc hello.c >>>>> >>>>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> >>>>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>>>> From: dragisha at m3w.org >>>>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>>>> CC: m3devel at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> >>>>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>>>> >>>>> SYSTEM_LIBS = { >>>>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>>>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>>>> ], >>>>> "LEX-YACC" : [ "-ll" ], >>>>> "FLEX-BISON" : [ "-lfl" ], >>>>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>>>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>>>> "TCP" : [ ] >>>>> % below: X11, ODBC, POSTGRES95, MOTIF >>>>> } >>>>> >>>>> My current AMD64_DARWIN configuration continues to work. >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On 11 Nov 2013, at 08:09, Jay K wrote: >>>>> >>>>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>>>> >>>>> Our system is very portable. >>>>> Consider helloWorld. And users of pthreads (or Win32 threads). >>>>> >>>>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>>>> >>>>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>>>> not be compatible across releases. We use them, sometimes, for user threads only. >>>>> >>>>> >>>>> If you find there is any problem, please let us know. >>>>> Anything you find is likely surmountable by a cross build. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> ________________________________ >>>>> From: dragisha at m3w.org >>>>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>>>> To: m3devel at elegosoft.com >>>>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>>>> >>>>> Anybody doing it? >>>>> >>>>> 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 rcolebur at SCIRES.COM Sat Nov 16 17:38:08 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sat, 16 Nov 2013 16:38:08 +0000 Subject: [M3devel] pickle2 compilation error Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF924B950A@ATLEX04-SRV.SCIRES.LOCAL> I'm getting a compilation error for pickles v2 on Windows XP: unable to open file for reading: ..\src\pickle\ver2\PklFpMap.i3: ErrorCode=2: The system cannot find the file specified. I've updated from head branch, so perhaps this is due to a recent change. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Nov 16 19:17:23 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 16 Nov 2013 12:17:23 -0600 Subject: [M3devel] pickle2 compilation error In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF924B950A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924B950A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <5287B6B3.2080307@lcwb.coop> Oops, sorry, I apparently didn't get PklFpMap.[im]3 added in the head. They should be there now. On 11/16/2013 10:38 AM, Coleburn, Randy wrote: > I?m getting a compilation error for pickles v2 on Windows XP: > > unable to open file for reading: ..\src\pickle\ver2\PklFpMap.i3: ErrorCode=2: The system cannot find the file specified. > > I?ve updated from head branch, so perhaps this is due to a recent change. > > --Randy > From dragisha at m3w.org Sun Nov 17 20:49:53 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 17 Nov 2013 20:49:53 +0100 Subject: [M3devel] GC deadlock Message-ID: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack #0 0x00130416 in __kernel_vsyscall () #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 another: #0 0x00130416 in __kernel_vsyscall () #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 and others: #0 0x00130416 in __kernel_vsyscall () #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) at ../src/thread/PTHREAD/ThreadPThread.m3:1205 #4 #5 0x00130416 in __kernel_vsyscall () #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? -- 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 dragisha at m3w.org Sun Nov 17 22:45:33 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 17 Nov 2013 22:45:33 +0100 Subject: [M3devel] GC deadlock In-Reply-To: References: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> Message-ID: <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> Good. I will try same cases with more recent one ASAP. -- Dragi?a Duri? dragisha at m3w.org On 17 Nov 2013, at 21:40, Antony Hosking wrote: > I know 5.8.6 had problems. > > On Nov 17, 2013, at 2:49 PM, Dragi?a Duri? wrote: > >> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack >> >> #0 0x00130416 in __kernel_vsyscall () >> #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 >> #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 >> #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 >> #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 >> #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 >> >> another: >> #0 0x00130416 in __kernel_vsyscall () >> #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 >> #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 >> #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 >> #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 >> #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 >> #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 >> #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >> #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >> >> and others: >> #0 0x00130416 in __kernel_vsyscall () >> #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 >> #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 >> #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) >> at ../src/thread/PTHREAD/ThreadPThread.m3:1205 >> #4 >> #5 0x00130416 in __kernel_vsyscall () >> #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >> >> Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? >> >> -- >> 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 rcolebur at SCIRES.COM Wed Nov 20 00:47:28 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 19 Nov 2013 23:47:28 +0000 Subject: [M3devel] compiler build problem Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF924CBE81@ATLEX04-SRV.SCIRES.LOCAL> I'm running into a new problem. I've updated from the HEAD branch and rebuilding everything on Windows XP again. Building of the package group "front" in stage 1 goes well and I install the new cm3.exe. Then, when I try to build in stage 2 using the new cm3.exe, I get the following error when invoking cm3.exe: *** *** runtime error: *** A compile-time type is missing. *** file "..\src\Utils.m3" *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12fea0 0x6d6c76 Fail + 0x79 in ..\src\runtime\common\RTType.m3 0x12fecc 0x6d5ea3 ResolveTypeLink + 0x50 in ..\src\runtime\common\RTType.m3 0x12fef8 0x6c242b ResolveTypeLinks + 0x57 in ..\src\runtime\common\RTLinker.m3 0x12ff2c 0x6c21ab FixTypes + 0x107 in ..\src\runtime\common\RTLinker.m3 0x12ff40 0x6c1c9d AddUnitI + 0xe2 in ..\src\runtime\common\RTLinker.m3 0x12ff60 0x6c1d56 AddUnit + 0x9c in ..\src\runtime\common\RTLinker.m3 0x12ff7c 0x401038 0x12ffc0 0x70d738 RTTypeMap_M3 + 0x4d6 in ..\src\runtime\common\RTTypeMap.m3 ......... ......... ... more frames ... Any ideas on what is wrong? Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Nov 20 03:13:07 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Nov 2013 20:13:07 -0600 Subject: [M3devel] compiler build problem In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF924CBE81@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924CBE81@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <528C1AB3.3010009@lcwb.coop> I don't know for sure what is going on in your case, but I have several times found this error disappearing after exhaustive cm3 -realclean or do-cm3-*.sh realclean, followed by recompiling everything from scratch. I think I recall one time even vetting this and finding some package that was present in different versions in the link closure, or something similar. The declaration-granularity automatic recompilation in the compiler only pretends to work within a package. Inter-package, you are on your own to make sure everything is compiled in the right order and consistently. Sorry, I don't have any help on what order that is. But I think the order of packages in pkginfo.txt is, at least mostly, right, if you use the do-cm3-*.sh scripts. On 11/19/2013 05:47 PM, Coleburn, Randy wrote: > I?m running into a new problem. > > I?ve updated from the HEAD branch and rebuilding everything on Windows XP again. > > Building of the package group ?front? in stage 1 goes well and I install the new cm3.exe. > > Then, when I try to build in stage 2 using the new cm3.exe, I get the following error when invoking cm3.exe: > > *** > > *** runtime error: > > *** A compile-time type is missing. > > *** file "..\src\Utils.m3" > > *** > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12fea0 0x6d6c76 Fail + 0x79 in ..\src\runtime\common\RTType.m3 > > 0x12fecc 0x6d5ea3 ResolveTypeLink + 0x50 in ..\src\runtime\common\RTType.m3 > > 0x12fef8 0x6c242b ResolveTypeLinks + 0x57 in ..\src\runtime\common\RTLinker.m3 > > 0x12ff2c 0x6c21ab FixTypes + 0x107 in ..\src\runtime\common\RTLinker.m3 > > 0x12ff40 0x6c1c9d AddUnitI + 0xe2 in ..\src\runtime\common\RTLinker.m3 > > 0x12ff60 0x6c1d56 AddUnit + 0x9c in ..\src\runtime\common\RTLinker.m3 > > 0x12ff7c 0x401038 > > 0x12ffc0 0x70d738 RTTypeMap_M3 + 0x4d6 in ..\src\runtime\common\RTTypeMap.m3 > > ......... ......... ... more frames ... > > Any ideas on what is wrong? > > Thanks, > > Randy Coleburn > From rodney_bates at lcwb.coop Fri Nov 22 16:44:28 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 Nov 2013 09:44:28 -0600 Subject: [M3devel] How to compile m3cc with -O0 Message-ID: <528F7BDC.8020005@lcwb.coop> Before I track this down laboriously, does anybody know right off hand where to put the optimization flag -O0 for compiling m3cc? There are dozens of CFLAGS and similar in quake variables, make variables, environment variables, etc., getting passed all over the place. Naive replacements of "-O2" by "-O0" so far aren't getting through to the compilation. From dragisha at m3w.org Fri Nov 22 23:31:28 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 22 Nov 2013 23:31:28 +0100 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? Message-ID: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org> + ./scripts/do-pkg.sh buildship m3core libm3 tcp /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc === package m3-libs/m3core === +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling WinBase.i3 "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) -- 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 dragisha at m3w.org Fri Nov 22 23:55:23 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 22 Nov 2013 23:55:23 +0100 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org> References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org> Message-ID: <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> Yes, it was in a memo? Sorry for disruption :). On 22 Nov 2013, at 23:31, Dragi?a Duri? wrote: > + ./scripts/do-pkg.sh buildship m3core libm3 tcp > /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc > === package m3-libs/m3core === > +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling WinBase.i3 > "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) > > -- > 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 Nov 23 12:17:47 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 23 Nov 2013 11:17:47 +0000 Subject: [M3devel] How to compile m3cc with -O0 In-Reply-To: <528F7BDC.8020005@lcwb.coop> References: <528F7BDC.8020005@lcwb.coop> Message-ID: Yes? But anyone, na?ve replacement should work, as long as it a little extra thorough. :) Look in m3cc/gcc-*/Makefile*.in m3cc/gcc-*/gcc/Makefile*.in You could also do in in src/m3makefile via CFLAGS=-O0 or such. There is a reason it is tricky though, and that is because of bootstrapping. And I gather they really like libgcc to be optimized, so give it separate flags to avoid being hit by the other. We don't use libgcc so no matter. Why? Because it takes too long to build optimized? Yes, that is annoying. Because it hard to debug? Yes, that is lame. The C compilers should do better there. If you are focusing on debugging very particular code, you can also often sprinkle in volatile to defeat the optimizer. or "make foo.o", copy/paste what it runs, run it yourself edited, and then make to continue. Also a bit annoying. - Jay > Date: Fri, 22 Nov 2013 09:44:28 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] How to compile m3cc with -O0 > > Before I track this down laboriously, does anybody know right off hand where > to put the optimization flag -O0 for compiling m3cc? There are dozens of > CFLAGS and similar in quake variables, make variables, environment variables, etc., > getting passed all over the place. Naive replacements of "-O2" by "-O0" so > far aren't getting through to the compilation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 23 12:13:43 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 23 Nov 2013 11:13:43 +0000 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org>, <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> Message-ID: This is deliberate, and slightly useful, and the warnings shouldn't occur in the head, for several years now. Please upgrade more frequently. In particular: - It is useful because "much" of the interfaces are describing types, and types aren't just for function parameters, for functions that aren't available, but they are used as part of files, and you can, hypothetically, use them in your own functions (heck, you can write a Win32-on-Posix compatibility layer and provide the functions..). In particular, mklib uses these types and is fairly portable. It might have endian/alignment problems though, esp. endian. I do have a plan to get rid of mklib though...i was slow to realize it because mklib exports too much and I wanted a replacement wthout that flaw, but just matching it is adequate. The frontend/backends shall output the .def files instead of mklib. And then the usual lib/ar/link can/should make the libraries. If anyone wants to use LTCG on NT with the C backend, this is the way (or put everything in one source file via the backend, not a bad idea).. - In the past 20 years or so, there is only one widely used platform that made the mistake of having multiple calling conventions and that is NT/x86. Not NT in general, but NT/x86 specifically. I expect nobody will make this mistake again. I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake. On NT/x86, the calling convention does not bifurcate the entire target and force building everything multiple times, because you can sprinkle it around and each "type" can call each "type". This is good and bad. The other OS/processor combinations with multiple calling conventions define it as multiple ABIs with I believe no offical interop (except at the kernel level, for some of them). Therefore, callling conventions can be safely ignored on all platforms except NT/x86. Nobody will have any names to use here, overlapping the NT/x86 names or not. If the day comes where I am wrong and some target has multiple conventions, we should change the pragma to accept multiple. If the names overlap with NT/x86, we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3 and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost the same, but for one little difference that could be handled another way, they go duplicated. That pattern bugs me. - Jay From: dragisha at m3w.org Date: Fri, 22 Nov 2013 23:55:23 +0100 To: m3devel at elegosoft.com Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase? Yes, it was in a memo. Sorry for disruption :). On 22 Nov 2013, at 23:31, Dragi?a Duri? wrote:+ ./scripts/do-pkg.sh buildship m3core libm3 tcp/root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc=== package m3-libs/m3core === +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++--- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling WinBase.i3"../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Nov 23 18:06:00 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 Nov 2013 18:06:00 +0100 Subject: [M3devel] GC deadlock... crash this time In-Reply-To: <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> References: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> Message-ID: Ok.. Now I am at HEAD, literraly: *** *** runtime error: *** An array subscript was out of range. *** file "../src/runtime/common/RTCollector.m3", line 418 *** #32 0x003dbe44 in _m3_fault (M3_AcxOUs_arg=) from /usr/local/cm3/bin/../lib/libm3core.so.5 #33 0x003d3807 in RTCollector__Move (M3_BVudqN_self=, M3_AJWxb1_cp=) at ../src/runtime/common/RTCollector.m3:418 #34 0x003cfb86 in RTHeapMap__Walk (M3_AJWxb1_x=, M3_AJWxb1_pc=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:202 #35 0x003cf471 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:62 #36 0x003cf448 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:57 #37 0x003cf3ee in RTHeapMap__WalkRef (M3_Edk2y1_h=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:47 #38 0x003d58b6 in RTCollector__CleanBetween (M3_Edk2y1_h=, M3_Edk2y1_he=, M3_AicXUJ_clean=) at ../src/runtime/common/RTCollector.m3:1091 #39 0x003d56d7 in RTCollector__CleanPage (M3_BtgLOI_page=) at ../src/runtime/common/RTCollector.m3:1064 #40 0x003d4ed2 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 #41 0x003d476a in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #42 0x003d444a in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #43 0x003cd245 in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=, M3_Cwb5VA_dataAlignment=, M3_B1GO5V_thread=) at ../src/runtime/common/RTAllocator.m3:367 #44 0x003cc3cc in RTAllocator__GetTracedRef (M3_Eic7CK_def=) at ../src/runtime/common/RTAllocator.m3:202 #45 0x003cc027 in RTHooks__AllocateTracedRef (M3_AJWxb1_defn=) at ../src/runtime/common/RTAllocator.m3:115 #46 0x002fcb05 in IntRefTbl__Put (M3_C1DLtw_tbl=, M3_EN2A1V_key=, M3_EKuYlT_val=) at ../LINUXLIBC6/IntRefTbl.m3 => ../src/table/Table.mg:126 On 17 Nov 2013, at 22:45, Dragi?a Duri? wrote: > Good. I will try same cases with more recent one ASAP. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 17 Nov 2013, at 21:40, Antony Hosking wrote: > >> I know 5.8.6 had problems. >> >> On Nov 17, 2013, at 2:49 PM, Dragi?a Duri? wrote: >> >>> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack >>> >>> #0 0x00130416 in __kernel_vsyscall () >>> #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 >>> #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 >>> #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 >>> #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 >>> #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 >>> >>> another: >>> #0 0x00130416 in __kernel_vsyscall () >>> #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 >>> #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 >>> #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 >>> #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 >>> #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 >>> #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 >>> #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >>> #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >>> >>> and others: >>> #0 0x00130416 in __kernel_vsyscall () >>> #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 >>> #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 >>> #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:1205 >>> #4 >>> #5 0x00130416 in __kernel_vsyscall () >>> #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >>> >>> Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? >>> >>> -- >>> 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 Sat Nov 23 21:33:51 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 23 Nov 2013 14:33:51 -0600 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org>, <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> Message-ID: <5291112F.5040102@lcwb.coop> On 11/23/2013 05:13 AM, Jay K wrote: > This is deliberate, and slightly useful, and the warnings shouldn't occur in the head, > for several years now. Please upgrade more frequently. > > I feel very strongly that the latest release compiler should always build the head. We have all too few Modula-3 users anyway. If we don''t have this ability, then we become an exclusive club with unreasonable barriers to outsiders. There is hardly a better way to keep the community shrinking. I know it can be a pain to maintain compatibility, but we really must do it. Until we get a new release with a compiler that won't choke on WINAPI, we need to keep different versions of the source. Actually, I thought I had removed all occurrences of this problem a few months ago. How did I miss this one? > In particular: > > > - It is useful because "much" of the interfaces are describing types, > and types aren't just for function parameters, for functions that > aren't available, but they are used as part of files, and you can, > hypothetically, use them in your own functions (heck, you can > write a Win32-on-Posix compatibility layer and provide the functions..). > > > In particular, mklib uses these types and is fairly portable. > It might have endian/alignment problems though, esp. endian. > > > I do have a plan to get rid of mklib though...i was slow to realize it > because mklib exports too much and I wanted a replacement wthout that flaw, > but just matching it is adequate. The frontend/backends shall output > the .def files instead of mklib. And then the usual lib/ar/link can/should > make the libraries. If anyone wants to use LTCG on NT with the C backend, > this is the way (or put everything in one source file via the backend, not a bad idea).. > > > - In the past 20 years or so, there is only one widely used > platform that made the mistake of having multiple calling conventions > and that is NT/x86. Not NT in general, but NT/x86 specifically. > I expect nobody will make this mistake again. > I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake. > On NT/x86, the calling convention does not bifurcate the entire target > and force building everything multiple times, because you can sprinkle it around and > each "type" can call each "type". This is good and bad. > The other OS/processor combinations with multiple calling conventions > define it as multiple ABIs with I believe no offical interop (except at the > kernel level, for some of them). > > > Therefore, callling conventions can be safely ignored on all platforms except NT/x86. > Nobody will have any names to use here, overlapping the NT/x86 names or not. > If the day comes where I am wrong and some target has multiple conventions, > we should change the pragma to accept multiple. If the names overlap with NT/x86, > we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3 > and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost > the same, but for one little difference that could be handled another way, they go duplicated. > That pattern bugs me. > > > - Jay > > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > From: dragisha at m3w.org > Date: Fri, 22 Nov 2013 23:55:23 +0100 > To: m3devel at elegosoft.com > Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase? > > Yes, it was in a memo. Sorry for disruption :). > > On 22 Nov 2013, at 23:31, Dragi?a Duri? > wrote: > > + ./scripts/do-pkg.sh buildship m3core libm3 tcp > /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc > === package m3-libs/m3core === > +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling WinBase.i3 > "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > From dragisha at m3w.org Sat Nov 23 23:30:06 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 Nov 2013 23:30:06 +0100 Subject: [M3devel] GC deadlock... crash this time In-Reply-To: <9E8E3A08-047F-45D2-BD1E-C473DC2E6E54@purdue.edu> References: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> <9E8E3A08-047F-45D2-BD1E-C473DC2E6E54@purdue.edu> Message-ID: <6EE7FE7E-A8F5-496C-8033-F761DEF87A59@m3w.org> There is UNSAFE code, few LOOPHOLEs, nothing much, and I am not loopholing anything untraced over. And yes, this is x86_32, some old dual Xeon machine. If it happens again, I will definitely try @M3paranoidgc. While here.. What are prospects of Atomic ops? TIA, dd On 23 Nov 2013, at 20:33, Antony Hosking wrote: > These issues are best diagnosed by running with @M3paranoidgc. That will perform extensive checking of heap integrity after each GC cycle. It would appear that some sort of heap corruption has occurred. Does your application have much unsafe code? Unfortunately, UNSAFE code can arbitrarily confuse the GC. > > Also, what platform is this on? x86_64 or x86_32? Looks like LINUXLIBC6 which I believe is still x86_32. > > On Nov 23, 2013, at 12:06 PM, Dragi?a Duri? wrote: > >> Ok.. Now I am at HEAD, literraly: >> >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "../src/runtime/common/RTCollector.m3", line 418 >> *** >> >> #32 0x003dbe44 in _m3_fault (M3_AcxOUs_arg=) from /usr/local/cm3/bin/../lib/libm3core.so.5 >> #33 0x003d3807 in RTCollector__Move (M3_BVudqN_self=, M3_AJWxb1_cp=) >> at ../src/runtime/common/RTCollector.m3:418 >> #34 0x003cfb86 in RTHeapMap__Walk (M3_AJWxb1_x=, M3_AJWxb1_pc=, M3_Deq2V9_v=) >> at ../src/runtime/common/RTHeapMap.m3:202 >> #35 0x003cf471 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) >> at ../src/runtime/common/RTHeapMap.m3:62 >> #36 0x003cf448 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) >> at ../src/runtime/common/RTHeapMap.m3:57 >> #37 0x003cf3ee in RTHeapMap__WalkRef (M3_Edk2y1_h=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:47 >> #38 0x003d58b6 in RTCollector__CleanBetween (M3_Edk2y1_h=, M3_Edk2y1_he=, >> M3_AicXUJ_clean=) at ../src/runtime/common/RTCollector.m3:1091 >> #39 0x003d56d7 in RTCollector__CleanPage (M3_BtgLOI_page=) at ../src/runtime/common/RTCollector.m3:1064 >> #40 0x003d4ed2 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 >> #41 0x003d476a in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >> #42 0x003d444a in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >> #43 0x003cd245 in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=, M3_Cwb5VA_dataAlignment=, >> M3_B1GO5V_thread=) at ../src/runtime/common/RTAllocator.m3:367 >> #44 0x003cc3cc in RTAllocator__GetTracedRef (M3_Eic7CK_def=) at ../src/runtime/common/RTAllocator.m3:202 >> #45 0x003cc027 in RTHooks__AllocateTracedRef (M3_AJWxb1_defn=) at ../src/runtime/common/RTAllocator.m3:115 >> #46 0x002fcb05 in IntRefTbl__Put (M3_C1DLtw_tbl=, M3_EN2A1V_key=, M3_EKuYlT_val=) >> at ../LINUXLIBC6/IntRefTbl.m3 => ../src/table/Table.mg:126 >> >> On 17 Nov 2013, at 22:45, Dragi?a Duri? wrote: >> >>> Good. I will try same cases with more recent one ASAP. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 17 Nov 2013, at 21:40, Antony Hosking wrote: >>> >>>> I know 5.8.6 had problems. >>>> >>>> On Nov 17, 2013, at 2:49 PM, Dragi?a Duri? wrote: >>>> >>>>> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack >>>>> >>>>> #0 0x00130416 in __kernel_vsyscall () >>>>> #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 >>>>> #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 >>>>> #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 >>>>> #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 >>>>> #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 >>>>> >>>>> another: >>>>> #0 0x00130416 in __kernel_vsyscall () >>>>> #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 >>>>> #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 >>>>> #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 >>>>> #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 >>>>> #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 >>>>> #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 >>>>> #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >>>>> #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >>>>> >>>>> and others: >>>>> #0 0x00130416 in __kernel_vsyscall () >>>>> #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 >>>>> #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 >>>>> #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) >>>>> at ../src/thread/PTHREAD/ThreadPThread.m3:1205 >>>>> #4 >>>>> #5 0x00130416 in __kernel_vsyscall () >>>>> #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >>>>> >>>>> Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? >>>>> >>>>> -- >>>>> 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 dragisha at m3w.org Sat Nov 23 23:32:39 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 Nov 2013 23:32:39 +0100 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: <5291112F.5040102@lcwb.coop> References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org>, <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> <5291112F.5040102@lcwb.coop> Message-ID: <977737CA-F2B7-4940-860D-5B56D64B658A@m3w.org> I think some interim release, of ?get on with Modula-3 fast? kind, is better idea than to slow progress. And I don?t dislike this current state. As for sommunity shrinking? Maybe some web facelift would be good idea? Anybody willing? dd On 23 Nov 2013, at 21:33, Rodney M. Bates wrote: > > > On 11/23/2013 05:13 AM, Jay K wrote: >> This is deliberate, and slightly useful, and the warnings shouldn't occur in the head, >> for several years now. Please upgrade more frequently. >> >> > > I feel very strongly that the latest release compiler should always build the head. > We have all too few Modula-3 users anyway. If we don''t have this ability, > then we become an exclusive club with unreasonable barriers to outsiders. > There is hardly a better way to keep the community shrinking. > > I know it can be a pain to maintain compatibility, but we really must do it. > Until we get a new release with a compiler that won't choke on WINAPI, we > need to keep different versions of the source. > > Actually, I thought I had removed all occurrences of this problem a few > months ago. How did I miss this one? > > >> In particular: >> >> >> - It is useful because "much" of the interfaces are describing types, >> and types aren't just for function parameters, for functions that >> aren't available, but they are used as part of files, and you can, >> hypothetically, use them in your own functions (heck, you can >> write a Win32-on-Posix compatibility layer and provide the functions..). >> >> >> In particular, mklib uses these types and is fairly portable. >> It might have endian/alignment problems though, esp. endian. >> >> >> I do have a plan to get rid of mklib though...i was slow to realize it >> because mklib exports too much and I wanted a replacement wthout that flaw, >> but just matching it is adequate. The frontend/backends shall output >> the .def files instead of mklib. And then the usual lib/ar/link can/should >> make the libraries. If anyone wants to use LTCG on NT with the C backend, >> this is the way (or put everything in one source file via the backend, not a bad idea).. >> >> >> - In the past 20 years or so, there is only one widely used >> platform that made the mistake of having multiple calling conventions >> and that is NT/x86. Not NT in general, but NT/x86 specifically. >> I expect nobody will make this mistake again. >> I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake. >> On NT/x86, the calling convention does not bifurcate the entire target >> and force building everything multiple times, because you can sprinkle it around and >> each "type" can call each "type". This is good and bad. >> The other OS/processor combinations with multiple calling conventions >> define it as multiple ABIs with I believe no offical interop (except at the >> kernel level, for some of them). >> >> >> Therefore, callling conventions can be safely ignored on all platforms except NT/x86. >> Nobody will have any names to use here, overlapping the NT/x86 names or not. >> If the day comes where I am wrong and some target has multiple conventions, >> we should change the pragma to accept multiple. If the names overlap with NT/x86, >> we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3 >> and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost >> the same, but for one little difference that could be handled another way, they go duplicated. >> That pattern bugs me. >> >> >> - Jay >> >> >> >> >> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > -- >> From: dragisha at m3w.org >> Date: Fri, 22 Nov 2013 23:55:23 +0100 >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase? >> >> Yes, it was in a memo. Sorry for disruption :). >> >> On 22 Nov 2013, at 23:31, Dragi?a Duri? > wrote: >> >> + ./scripts/do-pkg.sh buildship m3core libm3 tcp >> /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc >> === package m3-libs/m3core === >> +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ >> --- building in LINUXLIBC6 --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling WinBase.i3 >> "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) >> >> -- >> 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 wagner at elegosoft.com Thu Nov 28 07:47:55 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Nov 2013 07:47:55 +0100 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 Message-ID: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> I know that there have been controverse discussions about the right way to do unicode support. Is there any way to help Elmar Stellnberger with a quick solution? Olaf Begin forwarded message: Date: Wed, 27 Nov 2013 20:13:54 +0100 From: Elmar Stellnberger To: m3-support at elego.de Subject: UTF-16: Greek alphabet with CM3 Dear Supporters of CM3, Elegosoft Wanting to make use of CM3s new UTF-16 feature I have tried to use greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is beta in the unicode table. However I soon had to notice that outputing widechars is not supported by Trestle which still seems to be based on X11R4. Some analysis of the problem has shown that TextVBT calls VBT.PaintText which does however use the CHAR type internally rather than Widechar calling PaintSub to output text instead of the X11R6 function XDrawString16. Is it true that you plan real unicode support for CM3 or is there any way to hack the trestle toolkit into allowing X11R6 functions? If yes or no how could I convert current X11R6 includes for being used with Modula-3? Nonetheless I would really welcome true native utf-16 support (as nowadays given by the iso10646-1 X core fonts like also 'fixed') because that would be the only way to make use of utf-16 for Windows ports. Otherwise I will have to consider whether I can use Modula-3 at all for my current project which is about converting the automaton simulator www.elstel.org/coan from Object Pascal into a currently supported language and publishing it as open source. Thanks a lot for your effort! Yours, Elmar Stellnberger -- 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 dabenavidesd at yahoo.es Fri Nov 29 02:41:18 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> Message-ID: <1385689278.60242.YahooMailNeo@web171905.mail.ir2.yahoo.com> Hi all: I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? http://www.ascii-codes.com/cp869.html Thanks in advance PD: I? will have time In January, if you want I can help port your app (if it doens't have too much goto's) El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner escribi?: I know that there have been controverse discussions about the right way to do unicode support. Is there any way to help Elmar Stellnberger with a quick solution? Olaf Begin forwarded message: Date: Wed, 27 Nov 2013 20:13:54 +0100 From: Elmar Stellnberger To: m3-support at elego.de Subject: UTF-16: Greek alphabet with CM3 Dear Supporters of CM3, Elegosoft ? Wanting to make use of CM3s new UTF-16 feature I have tried to use greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is beta in the unicode table. However I soon had to notice that outputing widechars is not supported by Trestle which still seems to be based on X11R4. Some analysis of the problem has shown that TextVBT calls VBT.PaintText which does however use the CHAR type internally rather than Widechar calling PaintSub to output text instead of the X11R6 function XDrawString16. Is it true that you plan real unicode support for CM3 or is there any way to hack the trestle toolkit into allowing X11R6 functions? If yes or no how could I convert current X11R6 includes for being used with Modula-3? Nonetheless I would really welcome true native utf-16 support (as nowadays given by the iso10646-1 X core fonts like also 'fixed') because that would be the only way to make use of utf-16 for Windows ports. Otherwise I will have to consider whether I can use Modula-3 at all for my current project which is about converting the automaton simulator www.elstel.org/coan from Object Pascal into a currently supported language and publishing it as open source. Thanks a lot for your effort! Yours, Elmar Stellnberger -- 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 -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Nov 29 07:44:49 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 Nov 2013 07:44:49 +0100 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 Message-ID: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> Hi Elmar Stellnberger, I've forwarded your question to the m3devel mailing list; there has only been one answer so far though (see below). Daniel is talking about using some ISO-charset variant; I'm not sure if that is an option for you. I myself would think it should not be too much work to adapt Trestle and X for Unicode support, but then I haven't had a close look at the code and surely won't have the time to do that. I'm also unsure if UTF-8 might not be the way to go, Olaf Begin forwarded message: Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) From: "Daniel Alejandro Benavides D." To: Olaf Wagner , "m3devel at elegosoft.com" Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 Hi all: I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? http://www.ascii-codes.com/cp869.html Thanks in advance PD: I? will have time In January, if you want I can help port your app (if it doens't have too much goto's) El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner escribi?: I know that there have been controverse discussions about the right way to do unicode support. Is there any way to help Elmar Stellnberger with a quick solution? Olaf Begin forwarded message: Date: Wed, 27 Nov 2013 20:13:54 +0100 From: Elmar Stellnberger To: m3-support at elego.de Subject: UTF-16: Greek alphabet with CM3 Dear Supporters of CM3, Elegosoft ? Wanting to make use of CM3s new UTF-16 feature I have tried to use greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is beta in the unicode table. However I soon had to notice that outputing widechars is not supported by Trestle which still seems to be based on X11R4. Some analysis of the problem has shown that TextVBT calls VBT.PaintText which does however use the CHAR type internally rather than Widechar calling PaintSub to output text instead of the X11R6 function XDrawString16. Is it true that you plan real unicode support for CM3 or is there any way to hack the trestle toolkit into allowing X11R6 functions? If yes or no how could I convert current X11R6 includes for being used with Modula-3? Nonetheless I would really welcome true native utf-16 support (as nowadays given by the iso10646-1 X core fonts like also 'fixed') because that would be the only way to make use of utf-16 for Windows ports. Otherwise I will have to consider whether I can use Modula-3 at all for my current project which is about converting the automaton simulator www.elstel.org/coan from Object Pascal into a currently supported language and publishing it as open source. Thanks a lot for your effort! Yours, Elmar Stellnberger -- 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 -- 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 estellnb at elstel.org Fri Nov 29 17:05:45 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 Nov 2013 16:05:45 +0000 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> Message-ID: <5298BB59.3080703@elstel.org> Am 29.11.2013 06:44, schrieb Olaf Wagner: > Hi Elmar Stellnberger, > > I've forwarded your question to the m3devel mailing list; there has only > been one answer so far though (see below). Daniel is talking about using > some ISO-charset variant; I'm not sure if that is an option for you. > > I myself would think it should not be too much work to adapt Trestle > and X for Unicode support, but then I haven't had a close look at the > code and surely won't have the time to do that. > > I'm also unsure if UTF-8 might not be the way to go, > > Olaf > > Begin forwarded message: > > Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) > From: "Daniel Alejandro Benavides D." > To: Olaf Wagner , "m3devel at elegosoft.com" > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > Hi all: > I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? > http://www.ascii-codes.com/cp869.html Unfortunately I am in need of an entire Greek alphabet because automatons that have already been created with this program should continue to work and be displayed correctly. > > > Thanks in advance > > > PD: I will have time In January, if you want I can help port your app (if it doens't have too much goto's) Great! If you could guarantee me your assistance at least for the Trestle/VBT issues in support of 16bit wide characters I would start to work on a Modula-3 port. The thing is that I will need the port for my studies and I do hardly want to take the risk in failing to hack Trestle/VBT though the thing should not be that hard to do as Olaf has already indicated. As far as I have researched things all that would need to be done is add an additional painting operation to the PaintPrivate interface; or perhaps a second one for drawing elliptical arcs rather than just using Path.CurveTo and to make these new operations be used by the respective painting primitives. Additionally I would welcome some styling of buttons and bevels that goes ahead of pure black and white X-windows. Some Qt-like or at least a Windows 3.1 like button and menu styling might not be unimportant for the acceptance of the application. Nonetheless up to now I can not verify the impact of new painting operations on ports for Windows and MacOS which I am not confident with. No, it does not have a single goto; I`d consider it well structured as it uses classes, objects, method variables and nested procedures and can easily be extended for new automatons. At the moment I am still reading into Trestle. > > > > > El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner escribi?: > > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? > > Olaf P.S.: I have already programmed a module converting between UTF-16 and UTF-8 for console usage and am ready to publish it under BSD or any non-infective license allowing to re-license under any license. I would consider it really a pity if CM3 had good internal UTF-16 support but no interface to make use of it in practice. Additionally I could upload my still existent VIM environment for hacking Modula-3 including syntax highlighting, a treeview buffer and a backtrace analyzer to http://www.elstel.org/modula3 if anyone is interested in it. Elmar From dmuysers at hotmail.com Fri Nov 29 17:52:09 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 29 Nov 2013 17:52:09 +0100 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298BB59.3080703@elstel.org> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> Message-ID: Forget Trestle/VBT and Cie. Modern GUI systems all offer platform look and feel. The easiest solution is to create an import library for IUP (http://www.tecgraf.puc-rio.br/iup/). IUP is a compact (about a 100 "C" functions), portable and platform rendered GUI library. BTW, it uses (since version 3.9) UTF-8 text. I still find that the split of the character set into chars and wides was a very bad decision. It is always stupid to follow the Microsoft trail, the most incompetent software company (IMHO) in the world. -----Original Message----- From: Elmar Stellnberger Sent: Friday, November 29, 2013 5:05 PM To: dabenavidesd at yahoo.es Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 Am 29.11.2013 06:44, schrieb Olaf Wagner: > Hi Elmar Stellnberger, > > I've forwarded your question to the m3devel mailing list; there has only > been one answer so far though (see below). Daniel is talking about using > some ISO-charset variant; I'm not sure if that is an option for you. > > I myself would think it should not be too much work to adapt Trestle > and X for Unicode support, but then I haven't had a close look at the > code and surely won't have the time to do that. > > I'm also unsure if UTF-8 might not be the way to go, > > Olaf > > Begin forwarded message: > > Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) > From: "Daniel Alejandro Benavides D." > To: Olaf Wagner , "m3devel at elegosoft.com" > > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > Hi all: > I'm retired for Modula-3 work for now, but the ASCII table had codes for > Greek alphabet are you sure you can't print that with ASCII? > http://www.ascii-codes.com/cp869.html Unfortunately I am in need of an entire Greek alphabet because automatons that have already been created with this program should continue to work and be displayed correctly. > > > Thanks in advance > > > PD: I will have time In January, if you want I can help port your app (if > it doens't have too much goto's) Great! If you could guarantee me your assistance at least for the Trestle/VBT issues in support of 16bit wide characters I would start to work on a Modula-3 port. The thing is that I will need the port for my studies and I do hardly want to take the risk in failing to hack Trestle/VBT though the thing should not be that hard to do as Olaf has already indicated. As far as I have researched things all that would need to be done is add an additional painting operation to the PaintPrivate interface; or perhaps a second one for drawing elliptical arcs rather than just using Path.CurveTo and to make these new operations be used by the respective painting primitives. Additionally I would welcome some styling of buttons and bevels that goes ahead of pure black and white X-windows. Some Qt-like or at least a Windows 3.1 like button and menu styling might not be unimportant for the acceptance of the application. Nonetheless up to now I can not verify the impact of new painting operations on ports for Windows and MacOS which I am not confident with. No, it does not have a single goto; I`d consider it well structured as it uses classes, objects, method variables and nested procedures and can easily be extended for new automatons. At the moment I am still reading into Trestle. > > > > > El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner > escribi?: > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? > > Olaf P.S.: I have already programmed a module converting between UTF-16 and UTF-8 for console usage and am ready to publish it under BSD or any non-infective license allowing to re-license under any license. I would consider it really a pity if CM3 had good internal UTF-16 support but no interface to make use of it in practice. Additionally I could upload my still existent VIM environment for hacking Modula-3 including syntax highlighting, a treeview buffer and a backtrace analyzer to http://www.elstel.org/modula3 if anyone is interested in it. Elmar From estellnb at elstel.org Fri Nov 29 18:21:57 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 Nov 2013 17:21:57 +0000 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> Message-ID: <5298CD35.10200@elstel.org> As said the difference between UTF-8 and UTF-16 should not matter as long as we just use 16bit characters and as I plan to use a 'tr' function like in qt in order to convert into the current local language which will also handle things like character encoding. As far as I can remember we had something that could convert C interfaces into Modula-3. Is that correct, Olaf? Also; wasn`t there once an attempt to also convert GTK? Nonetheless converting a light weight toolkit may be easier and sufficient for the given purpose. If any of the mentioned languages supported nested procedures and objects at the same time that would allow me to convert existing Object Pascal code without wrapper objects which I would personally like to avoid. C and C++ do not have this feature apart from a very different syntax which would make a converter basing on an LL1 parser necessary. I don`t know that much about Lua and LED. However something that compiles would be fine as well. Elmar Am 29.11.2013 16:52, schrieb dirk muysers: > Forget Trestle/VBT and Cie. Modern GUI systems all offer platform > look and feel. The easiest solution is to create an import library for > IUP (http://www.tecgraf.puc-rio.br/iup/). IUP is a compact (about > a 100 "C" functions), portable and platform rendered GUI library. > BTW, it uses (since version 3.9) UTF-8 text. I still find that the > split of the character set into chars and wides was a very bad > decision. It is always stupid to follow the Microsoft trail, the > most incompetent software company (IMHO) in the world. > > -----Original Message----- From: Elmar Stellnberger > Sent: Friday, November 29, 2013 5:05 PM > To: dabenavidesd at yahoo.es > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 > > > Am 29.11.2013 06:44, schrieb Olaf Wagner: >> Hi Elmar Stellnberger, >> >> I've forwarded your question to the m3devel mailing list; there has only >> been one answer so far though (see below). Daniel is talking about using >> some ISO-charset variant; I'm not sure if that is an option for you. >> >> I myself would think it should not be too much work to adapt Trestle >> and X for Unicode support, but then I haven't had a close look at the >> code and surely won't have the time to do that. >> >> I'm also unsure if UTF-8 might not be the way to go, >> >> Olaf >> >> Begin forwarded message: >> >> Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) >> From: "Daniel Alejandro Benavides D." >> To: Olaf Wagner , "m3devel at elegosoft.com" >> >> Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 >> >> >> Hi all: >> I'm retired for Modula-3 work for now, but the ASCII table had codes >> for Greek alphabet are you sure you can't print that with ASCII? >> http://www.ascii-codes.com/cp869.html > Unfortunately I am in need of an entire Greek alphabet because > automatons that have already been created with this program should > continue to work and be displayed correctly. > >> >> >> Thanks in advance >> >> >> PD: I will have time In January, if you want I can help port your >> app (if it doens't have too much goto's) > Great! > If you could guarantee me your assistance at least for the Trestle/VBT > issues in support of 16bit wide characters I would start to work on a > Modula-3 port. The thing is that I will need the port for my studies and > I do hardly want to take the risk in failing to hack Trestle/VBT though > the thing should not be that hard to do as Olaf has already indicated. > As far as I have researched things all that would need to be done is add > an additional painting operation to the PaintPrivate interface; or > perhaps a second one for drawing elliptical arcs rather than just using > Path.CurveTo and to make these new operations be used by the respective > painting primitives. Additionally I would welcome some styling of > buttons and bevels that goes ahead of pure black and white X-windows. > Some Qt-like or at least a Windows 3.1 like button and menu styling > might not be unimportant for the acceptance of the application. > Nonetheless up to now I can not verify the impact of new painting > operations on ports for Windows and MacOS which I am not confident with. > > No, it does not have a single goto; I`d consider it well structured as > it uses classes, objects, method variables and nested procedures and can > easily be extended for new automatons. At the moment I am still reading > into Trestle. > >> >> >> >> >> El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner >> escribi?: >> I know that there have been controverse discussions about the right >> way to do unicode support. >> >> Is there any way to help Elmar Stellnberger with a quick solution? >> >> Olaf > P.S.: I have already programmed a module converting between UTF-16 and > UTF-8 for console usage and am ready to publish it under BSD or any > non-infective license allowing to re-license under any license. I would > consider it really a pity if CM3 had good internal UTF-16 support but no > interface to make use of it in practice. > > Additionally I could upload my still existent VIM environment for > hacking Modula-3 including syntax highlighting, a treeview buffer and a > backtrace analyzer to http://www.elstel.org/modula3 if anyone is > interested in it. > > Elmar > > From dmuysers at hotmail.com Fri Nov 29 18:43:58 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 29 Nov 2013 18:43:58 +0100 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298CD35.10200@elstel.org> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> <5298CD35.10200@elstel.org> Message-ID: No need to use a tool for that. Just write a IUP.i3 file and use the <*EXTERNAL*> pragma. Also a mechanical translation will not do. One must be creative here and use some intermediate code, e.g. have look at . > As far as I can remember we had something that could convert > C interfaces into Modula-3. Is that correct, Olaf? > Also; wasn`t there once an attempt to also convert GTK? > Nonetheless converting a light weight toolkit may be easier and > sufficient for the given purpose. From lemming at henning-thielemann.de Fri Nov 29 18:55:17 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 29 Nov 2013 18:55:17 +0100 (CET) Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298CD35.10200@elstel.org> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> <5298CD35.10200@elstel.org> Message-ID: On Fri, 29 Nov 2013, Elmar Stellnberger wrote: > As far as I can remember we had something that could convert C > interfaces into Modula-3. Is that correct, Olaf? I extended SWIG with Modula-3 support. From jay.krell at cornell.edu Sat Nov 30 04:50:50 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 Nov 2013 03:50:50 +0000 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com>, <5298BB59.3080703@elstel.org>, , <5298CD35.10200@elstel.org>, Message-ID: > Wanting to make use of CM3s new UTF-16 feature Cm3 has had 16bit WIDECHAR for over 10 years now. This is plenty to support most languages. Yes, I know, these days Unicode is a I think a 20bit encoding. I don't like Trestle either, but how we convert it take widen any TEXT to WIDECHARs (16 or 32bits then truncate to 16bits and use the "16" stuff in X?) - Jay > Date: Fri, 29 Nov 2013 18:55:17 +0100 > From: lemming at henning-thielemann.de > To: estellnb at elstel.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 > > > On Fri, 29 Nov 2013, Elmar Stellnberger wrote: > > > As far as I can remember we had something that could convert C > > interfaces into Modula-3. Is that correct, Olaf? > > I extended SWIG with Modula-3 support. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Nov 30 06:35:07 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 00:35:07 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <1385689278.60242.YahooMailNeo@web171905.mail.ir2.yahoo.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <1385689278.60242.YahooMailNeo@web171905.mail.ir2.yahoo.com> Message-ID: <20131130053507.GA20380@topoi.pooq.com> On Fri, Nov 29, 2013 at 01:41:18AM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? > http://www.ascii-codes.com/cp869.html Perhaps not ASCII, but there must have been a Greek national veriant of the ISO code back when it was still an eight-bit code. Thatnwould be a matter of sspecifying the right environment variables at run time. -- hendrik From hendrik at topoi.pooq.com Sat Nov 30 06:46:55 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 00:46:55 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> Message-ID: <20131130054655.GB20380@topoi.pooq.com> On Thu, Nov 28, 2013 at 07:47:55AM +0100, Olaf Wagner wrote: > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? See http://en.wikipedia.org/wiki/ISO/IEC_8859-7 It seems there's an eight-bit code that's enough for the Greek language. So in theory all you need to do is set the right environment variables to specify a Greek character set. In practice you might have to define the geometry fot the Greek characters for Trestle. Unless it manages to use the underlying OS support for this. -- hendrik > > Olaf > > Begin forwarded message: > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > From: Elmar Stellnberger > To: m3-support at elego.de > Subject: UTF-16: Greek alphabet with CM3 > > > Dear Supporters of CM3, Elegosoft > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > beta in the unicode table. However I soon had to notice that outputing > widechars is not supported by Trestle which still seems to be based on > X11R4. Some analysis of the problem has shown that TextVBT calls > VBT.PaintText which does however use the CHAR type internally rather > than Widechar calling PaintSub to output text instead of the X11R6 > function XDrawString16. Is it true that you plan real unicode support > for CM3 or is there any way to hack the trestle toolkit into allowing > X11R6 functions? If yes or no how could I convert current X11R6 includes > for being used with Modula-3? Nonetheless I would really welcome true > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > like also 'fixed') because that would be the only way to make use of > utf-16 for Windows ports. Otherwise I will have to consider whether I > can use Modula-3 at all for my current project which is about converting > the automaton simulator www.elstel.org/coan from Object Pascal into a > currently supported language and publishing it as open source. > Thanks a lot for your effort! > > Yours, > Elmar Stellnberger > -- > 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 jay.krell at cornell.edu Sat Nov 30 09:26:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 Nov 2013 08:26:29 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131130054655.GB20380@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> Message-ID: Right, In this respect, everything probably just works and always has. Just don't try to display any two non-English languages in a GUI at once. I think we should port Trestle to use 16 bit characters always internally. Even going so far as to double the memory use of common English strings. Can anyone vouch for XDrawString16 generally being implemented and working? - Jay > Date: Sat, 30 Nov 2013 00:46:55 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > On Thu, Nov 28, 2013 at 07:47:55AM +0100, Olaf Wagner wrote: > > I know that there have been controverse discussions about the right > > way to do unicode support. > > > > Is there any way to help Elmar Stellnberger with a quick solution? > > See http://en.wikipedia.org/wiki/ISO/IEC_8859-7 > It seems there's an eight-bit code that's enough for the Greek language. > So in theory all you need to do is set the right environment variables > to specify a Greek character set. In practice you might have to define > the geometry fot the Greek characters for Trestle. Unless it manages > to use the underlying OS support for this. > > -- hendrik > > > > > > Olaf > > > > Begin forwarded message: > > > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > > From: Elmar Stellnberger > > To: m3-support at elego.de > > Subject: UTF-16: Greek alphabet with CM3 > > > > > > Dear Supporters of CM3, Elegosoft > > > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > > beta in the unicode table. However I soon had to notice that outputing > > widechars is not supported by Trestle which still seems to be based on > > X11R4. Some analysis of the problem has shown that TextVBT calls > > VBT.PaintText which does however use the CHAR type internally rather > > than Widechar calling PaintSub to output text instead of the X11R6 > > function XDrawString16. Is it true that you plan real unicode support > > for CM3 or is there any way to hack the trestle toolkit into allowing > > X11R6 functions? If yes or no how could I convert current X11R6 includes > > for being used with Modula-3? Nonetheless I would really welcome true > > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > > like also 'fixed') because that would be the only way to make use of > > utf-16 for Windows ports. Otherwise I will have to consider whether I > > can use Modula-3 at all for my current project which is about converting > > the automaton simulator www.elstel.org/coan from Object Pascal into a > > currently supported language and publishing it as open source. > > Thanks a lot for your effort! > > > > Yours, > > Elmar Stellnberger > > -- > > 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 -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 30 10:06:03 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 Nov 2013 09:06:03 +0000 Subject: [M3devel] how to represent a 16bit char? Message-ID: 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? 2) Are we really certain that redefining WIDECHAR is the way to go? Not, say, introduce a new time, CHAR32 or UCHAR32? And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? Or do people now advocate: get rid of WIDECHAR leave 8 bit CHAR with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? ?? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Nov 30 10:34:47 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Sat, 30 Nov 2013 10:34:47 +0100 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: References: Message-ID: Yes, I think UTF-8 CHAR is the way to go. Nearly all recent Un*x libraries use it by now. Only Microsoft sticks to CHAR16 nowadays. I have a UTF-8 TEXT implementation in the making and don?t have the time, these days, to complete it. It has a constant time cursor to sequentially access this encoding, support for character properties, dynamic text building and formatting, and NLS (National Language support), and will have an XML reader. Finished: TEXT implementation, and char props. Partially finished: Dynamic buffer and NLS. Unfinished so far: Formatting and XML. The software is called libunicode. As for Win32, most software use dynamic translation to CHAR16, when required, eg Component Pascal for .Net, GTK, golang etc. leaving it the craggy island it is. From: Jay K Sent: Saturday, November 30, 2013 10:06 AM To: m3devel Subject: [M3devel] how to represent a 16bit char? 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? 2) Are we really certain that redefining WIDECHAR is the way to go? Not, say, introduce a new time, CHAR32 or UCHAR32? And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? Or do people now advocate: get rid of WIDECHAR leave 8 bit CHAR with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? ?? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Nov 30 11:41:42 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 30 Nov 2013 11:41:42 +0100 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: References: Message-ID: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> Are we really sure about this Xlib interfacing? There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? -- Dragi?a Duri? dragisha at m3w.org On 30 Nov 2013, at 10:06, Jay K wrote: > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? > 2) Are we really certain that redefining WIDECHAR is the way to go? > Not, say, introduce a new time, CHAR32 or UCHAR32? > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? > > Or do people now advocate: > get rid of WIDECHAR > leave 8 bit CHAR > with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? > ?? > > Thank you, > - Jay -------------- 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 dragisha at m3w.org Sat Nov 30 11:52:22 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 30 Nov 2013 11:52:22 +0100 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> References: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> Message-ID: And yes, Cairo uses UTF-8 natively, even on Windows. On 30 Nov 2013, at 11:41, Dragi?a Duri? wrote: > Are we really sure about this Xlib interfacing? > > There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 30 Nov 2013, at 10:06, Jay K wrote: > >> 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >> 2) Are we really certain that redefining WIDECHAR is the way to go? >> Not, say, introduce a new time, CHAR32 or UCHAR32? >> And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >> >> Or do people now advocate: >> get rid of WIDECHAR >> leave 8 bit CHAR >> with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? >> ?? >> >> Thank you, >> - Jay > -------------- 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 dragisha at m3w.org Sat Nov 30 12:02:03 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 30 Nov 2013 12:02:03 +0100 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> Message-ID: <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> I think this would be a major error. Choose 16bit route when only Windows does this, and everybody else is using UTF-8 is not a logical decision. -- Dragi?a Duri? dragisha at m3w.org On 30 Nov 2013, at 09:26, Jay K wrote: > Right, In this respect, everything probably just works and always has. > Just don't try to display any two non-English languages in a GUI at once. > > I think we should port Trestle to use 16 bit characters always internally. > Even going so far as to double the memory use of common English strings. > > Can anyone vouch for XDrawString16 generally being implemented and working? > > - Jay > > > > Date: Sat, 30 Nov 2013 00:46:55 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > > On Thu, Nov 28, 2013 at 07:47:55AM +0100, Olaf Wagner wrote: > > > I know that there have been controverse discussions about the right > > > way to do unicode support. > > > > > > Is there any way to help Elmar Stellnberger with a quick solution? > > > > See http://en.wikipedia.org/wiki/ISO/IEC_8859-7 > > It seems there's an eight-bit code that's enough for the Greek language. > > So in theory all you need to do is set the right environment variables > > to specify a Greek character set. In practice you might have to define > > the geometry fot the Greek characters for Trestle. Unless it manages > > to use the underlying OS support for this. > > > > -- hendrik > > > > > > > > > > Olaf > > > > > > Begin forwarded message: > > > > > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > > > From: Elmar Stellnberger > > > To: m3-support at elego.de > > > Subject: UTF-16: Greek alphabet with CM3 > > > > > > > > > Dear Supporters of CM3, Elegosoft > > > > > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > > > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > > > beta in the unicode table. However I soon had to notice that outputing > > > widechars is not supported by Trestle which still seems to be based on > > > X11R4. Some analysis of the problem has shown that TextVBT calls > > > VBT.PaintText which does however use the CHAR type internally rather > > > than Widechar calling PaintSub to output text instead of the X11R6 > > > function XDrawString16. Is it true that you plan real unicode support > > > for CM3 or is there any way to hack the trestle toolkit into allowing > > > X11R6 functions? If yes or no how could I convert current X11R6 includes > > > for being used with Modula-3? Nonetheless I would really welcome true > > > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > > > like also 'fixed') because that would be the only way to make use of > > > utf-16 for Windows ports. Otherwise I will have to consider whether I > > > can use Modula-3 at all for my current project which is about converting > > > the automaton simulator www.elstel.org/coan from Object Pascal into a > > > currently supported language and publishing it as open source. > > > Thanks a lot for your effort! > > > > > > Yours, > > > Elmar Stellnberger > > > -- > > > 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 -------------- 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 estellnb at elstel.org Sat Nov 30 12:25:31 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 11:25:31 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> Message-ID: <5299CB2B.9090008@elstel.org> > Right, In this respect, everything probably just works and always has. > Just don't try to display any two non-English languages in a GUI at once. That was exactly the requirement: use greek and latin characters at the same time to display mathematical expressions > I think we should port Trestle to use 16 bit characters always internally. > Even going so far as to double the memory use of common English strings. No, that does not double the memory usage. I have just inserted a Text.IsWide function to let a future version of VBT.PaintText select whether it wants to use XDrawString16 or its eight bit counterpart. > Can anyone vouch for XDrawString16 generally being implemented and working? Yes it is shipped with X11R4 - Jay > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? > 2) Are we really certain that redefining WIDECHAR is the way to go? > Not, say, introduce a new time, CHAR32 or UCHAR32? > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: first you would have to upgrade the whole Trestle kit to X11R6 you would have to use the very heavy weight X11R6 XIM interface to make use of WideChar32 then you would finally have to change the internal representation of the Text type. Am 30.11.2013 11:02, schrieb Dragi?a Duri?: > I think this would be a major error. Choose 16bit route when only > Windows does this, and everybody else is using UTF-8 is not a logical > decision. I do not consent. WideChar32 will come with the additional benefit of some additionally supported languages. That is all it would be good for. If we ever upgraded to use XIM which will be a major effort as I have already tried to point out we can still consider WC32 though converting between UTF-8 and UTF-16 is no big deal (I have an implementation which I could give you.). i.e. X11R4 uses WC16 X11R6-XIM uses WC32 I do not want to speak against WC32; Nonetheless it basically depends on how much effort you are willing to invest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat Nov 30 12:34:42 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 11:34:42 +0000 Subject: [M3devel] use CM3_INSTALL_PREFIX to ship to a different target Message-ID: <5299CD52.8020207@elstel.org> As far as I have tested it cm3 -ship ignores CM3_INSTALL_PREFIX so that I can not ship to any directory different from /usr/local/cm3. I always had a different source and target compiler in the times when I was working with PM3 so that things could not get messed up easily. On desire I could compile the compiler with itself. So in a short: Is there any way to make cm3 ship to another directory than /usr/local/cm3 but still compile with /usr/local/cm3 Sorry; I haven` t found out yet how to do that. Perhaps it simply was not implemented. From estellnb at elstel.org Sat Nov 30 12:40:41 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 11:40:41 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5299CB2B.9090008@elstel.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> Message-ID: <5299CEB9.7010508@elstel.org> I do not know about the internals of Trestle but I have some knowledge of the X core protocol and thus I know that everything related to XIM is very complicated though usage of XIM rather than just XDrawString16 would enable user input of Asian languages. Elmar Am 30.11.2013 11:25, schrieb Elmar Stellnberger: > > Right, In this respect, everything probably just works and always has. > > Just don't try to display any two non-English languages in a GUI at > once. > > That was exactly the requirement: use greek and latin characters at > the same time to display mathematical expressions > > > I think we should port Trestle to use 16 bit characters always > internally. > > Even going so far as to double the memory use of common English strings. > > No, that does not double the memory usage. I have just inserted a > Text.IsWide function to let a future > version of VBT.PaintText select whether it wants to use XDrawString16 > or its eight bit counterpart. > > > Can anyone vouch for XDrawString16 generally being implemented and > working? > > Yes it is shipped with X11R4 > > - Jay > > > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I > use where WIDECHAR used to be correct? > > 2) Are we really certain that redefining WIDECHAR is the way to go? > > Not, say, introduce a new time, CHAR32 or UCHAR32? > > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type > that nobody will ever consider changing? > > upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: > first you would have to upgrade the whole Trestle kit to X11R6 > you would have to use the very heavy weight X11R6 XIM interface to > make use of WideChar32 > then you would finally have to change the internal representation of > the Text type. > > > > Am 30.11.2013 11:02, schrieb Dragi?a Duri?: >> I think this would be a major error. Choose 16bit route when only >> Windows does this, and everybody else is using UTF-8 is not a logical >> decision. > I do not consent. WideChar32 will come with the additional benefit of > some additionally supported languages. That is all it would be good for. > If we ever upgraded to use XIM which will be a major effort as I have > already tried to point out we can still consider WC32 though converting > between UTF-8 and UTF-16 is no big deal (I have an implementation > which I could give you.). > > i.e. X11R4 uses WC16 > X11R6-XIM uses WC32 > > I do not want to speak against WC32; Nonetheless > it basically depends on how much effort you are willing to invest. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat Nov 30 13:24:29 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 12:24:29 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5299CB2B.9090008@elstel.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> Message-ID: <5299D8FD.6090809@elstel.org> Actually the devil is in the details: Continuing to use 16bit characters outputting strings would be easy. However when it comes to adjust the input function there is no XKeySymToKeyCode16 function which means that you would either have to implement one on your own or the other way upgrade to X11R6, use XIM and convert from UTF-32 to UTF-16. Well there is a possibility to use XIM functions right the way as an XKeySymToKeyCode32 function would work without any input or status reflection. In order to use XOM for outputting 32 bit characters you would have to use 'font sets' on the other hand which I personally have never done. Elmar Am 30.11.2013 11:25, schrieb Elmar Stellnberger: > > Right, In this respect, everything probably just works and always has. > > Just don't try to display any two non-English languages in a GUI at > once. > > That was exactly the requirement: use greek and latin characters at > the same time to display mathematical expressions > > > I think we should port Trestle to use 16 bit characters always > internally. > > Even going so far as to double the memory use of common English strings. > > No, that does not double the memory usage. I have just inserted a > Text.IsWide function to let a future > version of VBT.PaintText select whether it wants to use XDrawString16 > or its eight bit counterpart. > > > Can anyone vouch for XDrawString16 generally being implemented and > working? > > Yes it is shipped with X11R4 > > - Jay > > > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I > use where WIDECHAR used to be correct? > > 2) Are we really certain that redefining WIDECHAR is the way to go? > > Not, say, introduce a new time, CHAR32 or UCHAR32? > > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type > that nobody will ever consider changing? > > upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: > first you would have to upgrade the whole Trestle kit to X11R6 > you would have to use the very heavy weight X11R6 XIM interface to > make use of WideChar32 > then you would finally have to change the internal representation of > the Text type. > > > > Am 30.11.2013 11:02, schrieb Dragi?a Duri?: >> I think this would be a major error. Choose 16bit route when only >> Windows does this, and everybody else is using UTF-8 is not a logical >> decision. > I do not consent. WideChar32 will come with the additional benefit of > some additionally supported languages. That is all it would be good for. > If we ever upgraded to use XIM which will be a major effort as I have > already tried to point out we can still consider WC32 though converting > between UTF-8 and UTF-16 is no big deal (I have an implementation > which I could give you.). > > i.e. X11R4 uses WC16 > X11R6-XIM uses WC32 > > I do not want to speak against WC32; Nonetheless > it basically depends on how much effort you are willing to invest. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Nov 30 17:52:44 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 Nov 2013 10:52:44 -0600 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5299D8FD.6090809@elstel.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> Message-ID: <529A17DC.3080906@lcwb.coop> Another devilish detail to be aware of: UTF-16 is _not_ the same as the current Modula-3 16-bit WIDECHAR, even when restricted to values <= 16_FFFF. Current Wr/Rd library code just writes/reads exactly 16 bits in two bytes, with whatever code point is in the WIDECHAR variable. In contrast, UTF-16 will encode code points greater than UFFFF as a pair of 16-bit code units with surrogate values in them. Then to make this work right, the surrogate values are not allowed in unencoded variables. So attempting to encode a surrogate in UTF-16 is an error, and decoding a surrogate that is not part of a proper first-surrogate/second-surrogate pair is "ill formed" and usually decodes to UFFFD. You could get by with treating these as interchangeable only be being careful to ensure there is never either a surrogate code nor a code point > UFFFF, in either input or output. Also, current Wr/Rd always write/read only in little-endian byte order, whereas there are both little- and big-endian variants of UTF-16. I have no idea which endianness of UTF-16 is used by various GUI libraries, but it would have to be little for this to work. On 11/30/2013 06:24 AM, Elmar Stellnberger wrote: > Actually the devil is in the details: > Continuing to use 16bit characters outputting strings would be easy. > However when it comes to adjust the input function there is no > XKeySymToKeyCode16 function which means that you would either > have to implement one on your own or the other way upgrade to > X11R6, use XIM and convert from UTF-32 to UTF-16. Well there is > a possibility to use XIM functions right the way as an > XKeySymToKeyCode32 function would work without any input > or status reflection. > In order to use XOM for outputting 32 bit characters you would > have to use 'font sets' on the other hand which I personally have > never done. > > Elmar > > > Am 30.11.2013 11:25, schrieb Elmar Stellnberger: >> > Right, In this respect, everything probably just works and always has. >> > Just don't try to display any two non-English languages in a GUI at once. >> >> That was exactly the requirement: use greek and latin characters at the same time to display mathematical expressions >> >> > I think we should port Trestle to use 16 bit characters always internally. >> > Even going so far as to double the memory use of common English strings. >> >> No, that does not double the memory usage. I have just inserted a Text.IsWide function to let a future >> version of VBT.PaintText select whether it wants to use XDrawString16 or its eight bit counterpart. >> >> > Can anyone vouch for XDrawString16 generally being implemented and working? >> >> Yes it is shipped with X11R4 >> >> - Jay >> >> > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >> > 2) Are we really certain that redefining WIDECHAR is the way to go? >> > Not, say, introduce a new time, CHAR32 or UCHAR32? >> > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >> >> upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: >> first you would have to upgrade the whole Trestle kit to X11R6 >> you would have to use the very heavy weight X11R6 XIM interface to make use of WideChar32 >> then you would finally have to change the internal representation of the Text type. >> >> >> >> Am 30.11.2013 11:02, schrieb Dragi?a Duri?: >>> I think this would be a major error. Choose 16bit route when only Windows does this, and everybody else is using UTF-8 is not a logical decision. >> I do not consent. WideChar32 will come with the additional benefit of some additionally supported languages. That is all it would be good for. >> If we ever upgraded to use XIM which will be a major effort as I have already tried to point out we can still consider WC32 though converting >> between UTF-8 and UTF-16 is no big deal (I have an implementation which I could give you.). >> >> i.e. X11R4 uses WC16 >> X11R6-XIM uses WC32 >> >> I do not want to speak against WC32; Nonetheless >> it basically depends on how much effort you are willing to invest. >> >> >> > From rodney_bates at lcwb.coop Sat Nov 30 18:02:30 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 Nov 2013 11:02:30 -0600 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298E46D.2020209@lcwb.coop> References: <5298E46D.2020209@lcwb.coop> Message-ID: <529A1A26.6010007@lcwb.coop> The first post of this seems to have disappeared into cyberspace. -------- Original Message -------- Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 Date: Fri, 29 Nov 2013 13:01:01 -0600 From: Rodney M. Bates To: m3devel at elegosoft.com, estellnb at elstel.org I have created a CVS branch (devel_unicode) that changes WIDECHAR to a big enough value range to handle all 16_110000 Unicode code points. I think this may be mostly orthogonal to what you need, as I am sure the Greek letters are in the BMP (first 16_10000) code points of Unicode, and thus representable by the current WIDECHAR. What might be useful to you though, in interfacing to Trestle or any other GUI system, is that it contains encoders/decoders for all of the Unicode-specified encodings (UTF-8, UTF-16-BE/LE, and UTF-32-BE/LE), as well as what I think are the older UCS2-BE/LE, and Modula-3's current ISO-Latin-1 and WIDECHAR encodings. The way these work is that WIDECHARs in memory, including within a TEXT, are fixed sized and are pure Unicode code points, preserving the way original CHAR works, especially, allowing efficient random access by character number, not byte number. But the en/decoding is done while reading/writing streams (Wr.T, Rd,t), which are, as originally, sequential, and thus suited to the variable-length encodings. Of course, you could do unusual things, for example, write with UTF-8 encoding to a pipe and decode with Ascii, thus getting the individual characters of UTF-8 into a TEXT or ARRAY OF CHAR, where you could mess with the encoded bytes in memory, rather than treating them as code points. The en/decoders are available in one-code-point-per-call forms, as well as in filters that are semantically almost identical to Wr and Rd, which work on whole streams, with a constant encoding. The latter, in front of TextWr/TextRd would probably make it easy to interface to any GUI library that uses in-memory UTF-8, etc. It also would not be hard to make these work with 16-bit WIDECHAR, with any input coded beyond UFFFF converted to the standard Unicode replacement UFFFD. It sounds like you would be unlikely to use such values. How soon do you need to start? On 11/28/2013 12:47 AM, Olaf Wagner wrote: > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? > > Olaf > > Begin forwarded message: > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > From: Elmar Stellnberger > To: m3-support at elego.de > Subject: UTF-16: Greek alphabet with CM3 > > > Dear Supporters of CM3, Elegosoft > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > beta in the unicode table. However I soon had to notice that outputing > widechars is not supported by Trestle which still seems to be based on > X11R4. Some analysis of the problem has shown that TextVBT calls > VBT.PaintText which does however use the CHAR type internally rather > than Widechar calling PaintSub to output text instead of the X11R6 > function XDrawString16. Is it true that you plan real unicode support > for CM3 or is there any way to hack the trestle toolkit into allowing > X11R6 functions? If yes or no how could I convert current X11R6 includes > for being used with Modula-3? Nonetheless I would really welcome true > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > like also 'fixed') because that would be the only way to make use of > utf-16 for Windows ports. Otherwise I will have to consider whether I > can use Modula-3 at all for my current project which is about converting > the automaton simulator www.elstel.org/coan from Object Pascal into a > currently supported language and publishing it as open source. > Thanks a lot for your effort! > > Yours, > Elmar Stellnberger > From hendrik at topoi.pooq.com Sat Nov 30 18:29:06 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 12:29:06 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529A17DC.3080906@lcwb.coop> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> Message-ID: <20131130172906.GA28372@topoi.pooq.com> On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > Another devilish detail to be aware of: UTF-16 is _not_ the same as > the current Modula-3 16-bit WIDECHAR, even when restricted to values > <= 16_FFFF. Current Wr/Rd library code just writes/reads > exactly 16 bits in two bytes, with whatever code point is in the > WIDECHAR variable. > > In contrast, UTF-16 will encode code points greater than > UFFFF as a pair of 16-bit code units with surrogate values in them. > Then to make this work right, the surrogate values are not > allowed in unencoded variables. So attempting to encode a surrogate > in UTF-16 is an error, and decoding a surrogate that is not part of a > proper first-surrogate/second-surrogate pair is "ill formed" and usually > decodes to UFFFD. > > You could get by with treating these as interchangeable only be being > careful to ensure there is never either a surrogate code nor a code > point > UFFFF, in either input or output. > > Also, current Wr/Rd always write/read only in little-endian byte order, > whereas there are both little- and big-endian variants of UTF-16. > I have no idea which endianness of UTF-16 is used by various GUI > libraries, but it would have to be little for this to work. It lools as if one might as well use UTF-8 if one is going to consider UTF-16. I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have been superseded by SCIM, I don't know the status of uim, except that it has a uim bridge. It does look as if SCIM (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended as a simple way to interface to many other input methods, such as XIM. It may be worth a look. --- hendrik From rodney_bates at lcwb.coop Sat Nov 30 20:59:47 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 Nov 2013 13:59:47 -0600 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131130172906.GA28372@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> Message-ID: <529A43B3.2090803@lcwb.coop> On 11/30/2013 11:29 AM, Hendrik Boom wrote: > On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: >> Another devilish detail to be aware of: UTF-16 is _not_ the same as >> the current Modula-3 16-bit WIDECHAR, even when restricted to values >> <= 16_FFFF. Current Wr/Rd library code just writes/reads >> exactly 16 bits in two bytes, with whatever code point is in the >> WIDECHAR variable. >> >> In contrast, UTF-16 will encode code points greater than >> UFFFF as a pair of 16-bit code units with surrogate values in them. >> Then to make this work right, the surrogate values are not >> allowed in unencoded variables. So attempting to encode a surrogate >> in UTF-16 is an error, and decoding a surrogate that is not part of a >> proper first-surrogate/second-surrogate pair is "ill formed" and usually >> decodes to UFFFD. >> >> You could get by with treating these as interchangeable only be being >> careful to ensure there is never either a surrogate code nor a code >> point > UFFFF, in either input or output. >> >> Also, current Wr/Rd always write/read only in little-endian byte order, >> whereas there are both little- and big-endian variants of UTF-16. >> I have no idea which endianness of UTF-16 is used by various GUI >> libraries, but it would have to be little for this to work. > > It lools as if one might as well use UTF-8 if one is going to consider UTF-16. Hmm. Actually, *if* one could live with the restrictions on values above, passing the same strings back and forth, with the GUI considering them UTF-16LE and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have the advantage that the M3 app code could deal naturally in characters, rather than varying numbers of fragments of characters. UTF-8 would require the latter. > > I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > been superseded by SCIM, I don't know the status of uim, except that > it has a uim bridge. > > It does look as if SCIM > (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > as a simple way to interface to many other input methods, such as XIM. > It may be worth a look. > > --- hendrik > > From rodney_bates at lcwb.coop Tue Nov 5 18:47:13 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 05 Nov 2013 11:47:13 -0600 Subject: [M3devel] How to run m3cggen? Message-ID: <52792F21.6020802@lcwb.coop> I need to rebuild m3cc after changes to m3middle/src/M3CG_Binary.i3 and m3cggen/src/Main. I can see that at a minimum, I have to recompile m3cggen first, then run it and place its output appropriately, before compiling m3cc. m3cggen comes after m3cc in pkginfo.txt, so the do-cm3-*.sh scripts can't work here. A massive recursive grep of everything for "m3cggen" doesn't appear to turn up anything in a script, makefile, or m3makefile, other than disconnected building of m3cggen itself. However, there is so much false output here, that it's a needle in a haystack. So is there any script, makefile, etc. that takes care of this, or is it all manual? Are there any other generated source files or similar steps that also need to be redone that I can't easily find? m3cg.h (The result of this process) is a CVS file, which at least hints that this is just being done manually. Slightly related, I found out the hard way that the parse.c in the gcc version you are compiling is actually, sometimes, overlaid during building, by the one in gcc/gcc/m3cg. What is the complete set of source files that, like this, are not where one would expect them to be? Is it everything in the m3cg subdirectory? Just parse.c? Some other subset? From jay.krell at cornell.edu Tue Nov 5 19:55:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Nov 2013 18:55:38 +0000 Subject: [M3devel] How to run m3cggen? In-Reply-To: <52792F21.6020802@lcwb.coop> References: <52792F21.6020802@lcwb.coop> Message-ID: Right. I hit the same problem at some point and wasn't satisfied either. I fixed it, or almost fixed it. Building it in a list of other stuff is correct, not a false hit, part of the solution. upgrade.sh and ugprade.py both handle this, almost. upgrade.sh: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain if [ "x${GCC_BACKEND}" = xyes ]; then # Continue with the backend, if needed. Deliberately don't ship it! # "$root/m3-sys/m3cggen/${TARGET}/m3cggen" > "$root/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" "$root/scripts/do-pkg.sh" "$@" "build" m3cc || exit 1 fi upgrade.py: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/upgrade.py?rev=1.39;content-type=text%2Fplain a = Root + "/m3-sys/m3cggen/" + Target + "/m3cggen > " + Root + "/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" print(a) # os.system(a) FilterPackages([ "m3cc" ]) and DoPackage(argv_BuildShip, [ "m3cc" ]) Those two lines should be uncommented. Or, more likely, they should redirect elsewhere and do a "move if change". In the python case, "elsewhere" should be read the pipe into a variable in memory. It isn't supposed to change if there are no local edits, but streamlining it is very good to have. Maybe that is why I left it commented out. Only approx. 3 of us have changed this probably in 10 years. Tony probably doesn't use any of the scripts. I do and almost fixed it. You are #3. Can you make it so or shall I? m3cggen is "standalone" for this reason, or should be. > gcc/gcc/m3cg. > What is the complete set of source files that, like this, are not where one would > expect them to be? Is it everything in the m3cg subdirectory? Just parse.c? The list is whatever the source does. The alternative would be to have several almost identical copies and disconnected history. It is a little confusing, but the alternative isn't great either. For parse.c, and related, look in m3-sys/src/m3makefile. For example, we also sometimes have to make links for gmp/mpfr/mpc. - Jay > Date: Tue, 5 Nov 2013 11:47:13 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] How to run m3cggen? > > I need to rebuild m3cc after changes to m3middle/src/M3CG_Binary.i3 and m3cggen/src/Main. > I can see that at a minimum, I have to recompile m3cggen first, then run it and place > its output appropriately, before compiling m3cc. m3cggen comes after m3cc in pkginfo.txt, > so the do-cm3-*.sh scripts can't work here. > > A massive recursive grep of everything for "m3cggen" doesn't appear to turn up anything in > a script, makefile, or m3makefile, other than disconnected building of m3cggen itself. > However, there is so much false output here, that it's a needle in a haystack. > > So is there any script, makefile, etc. that takes care of this, or is it all manual? > Are there any other generated source files or similar steps that also need to be redone > that I can't easily find? > > m3cg.h (The result of this process) is a CVS file, which at least hints that this is > just being done manually. > > Slightly related, I found out the hard way that the parse.c in the gcc version you are > compiling is actually, sometimes, overlaid during building, by the one in gcc/gcc/m3cg. > What is the complete set of source files that, like this, are not where one would > expect them to be? Is it everything in the m3cg subdirectory? Just parse.c? > Some other subset? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Nov 10 18:48:22 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 10 Nov 2013 18:48:22 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks Message-ID: Anybody doing it? 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 Mon Nov 11 08:09:23 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 11 Nov 2013 07:09:23 +0000 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: Message-ID: I'm still hanging back on a version that supports PowerPC/Rosetta. ?:)? ?Our system is very portable.? ? Consider helloWorld. And users of pthreads (or Win32 threads). ? ?And we hope/trust Apple and co. to maintain a certain level of compatibility.? ?For example. the HPUX man pages decree that get/set/make/swapcontext may? ? not be compatible across releases. We use them, sometimes, for user threads only.? If you find there is any problem, please let us know. Anything you find is likely surmountable by a cross build. ?- Jay ________________________________ > From: dragisha at m3w.org > Date: Sun, 10 Nov 2013 18:48:22 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] AMD64_DARWIN with OSX Mavericks > > Anybody doing it? > > TIA, > -- > Dragi?a Duri? > dragisha at m3w.org From dragisha at m3w.org Wed Nov 13 10:03:15 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 10:03:15 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: Message-ID: I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common SYSTEM_LIBS = { "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" ], "LEX-YACC" : [ "-ll" ], "FLEX-BISON" : [ "-lfl" ], "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], "TCP" : [ ] % below: X11, ODBC, POSTGRES95, MOTIF } My current AMD64_DARWIN configuration continues to work. -- Dragi?a Duri? dragisha at m3w.org On 11 Nov 2013, at 08:09, Jay K wrote: > I'm still hanging back on a version that supports PowerPC/Rosetta. :) > > Our system is very portable. > Consider helloWorld. And users of pthreads (or Win32 threads). > > And we hope/trust Apple and co. to maintain a certain level of compatibility. > > For example. the HPUX man pages decree that get/set/make/swapcontext may > not be compatible across releases. We use them, sometimes, for user threads only. > > > If you find there is any problem, please let us know. > Anything you find is likely surmountable by a cross build. > > > - Jay > > ________________________________ >> From: dragisha at m3w.org >> Date: Sun, 10 Nov 2013 18:48:22 +0100 >> To: m3devel at elegosoft.com >> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >> >> Anybody doing it? >> >> 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 Wed Nov 13 10:53:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 13 Nov 2013 09:53:17 +0000 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: , Message-ID: Is that really needed? Doesn't this work? hello.c: #include int main() { return !!printf("hello\n"); } cc hello.c If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) - Jay Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks From: dragisha at m3w.org Date: Wed, 13 Nov 2013 10:03:15 +0100 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common SYSTEM_LIBS = { "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" ], "LEX-YACC" : [ "-ll" ], "FLEX-BISON" : [ "-lfl" ], "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], "TCP" : [ ]% below: X11, ODBC, POSTGRES95, MOTIF} My current AMD64_DARWIN configuration continues to work.--Dragi?a Duri?dragisha at m3w.org On 11 Nov 2013, at 08:09, Jay K wrote:I'm still hanging back on a version that supports PowerPC/Rosetta. :) Our system is very portable. Consider helloWorld. And users of pthreads (or Win32 threads). And we hope/trust Apple and co. to maintain a certain level of compatibility. For example. the HPUX man pages decree that get/set/make/swapcontext may not be compatible across releases. We use them, sometimes, for user threads only. If you find there is any problem, please let us know. Anything you find is likely surmountable by a cross build. - Jay ________________________________ From: dragisha at m3w.org Date: Sun, 10 Nov 2013 18:48:22 +0100 To: m3devel at elegosoft.com Subject: [M3devel] AMD64_DARWIN with OSX Mavericks Anybody doing it? TIA, -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Nov 13 11:08:47 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 11:08:47 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: , Message-ID: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 10:53, Jay K wrote: > Is that really needed? > > Doesn't this work? > > hello.c: > #include > int main() { return !!printf("hello\n"); } > > cc hello.c > > If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) > > - Jay > > > > > Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks > From: dragisha at m3w.org > Date: Wed, 13 Nov 2013 10:03:15 +0100 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common > > SYSTEM_LIBS = { > "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", > "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" > ], > "LEX-YACC" : [ "-ll" ], > "FLEX-BISON" : [ "-lfl" ], > "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, > "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], > "TCP" : [ ] > % below: X11, ODBC, POSTGRES95, MOTIF > } > > My current AMD64_DARWIN configuration continues to work. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 11 Nov 2013, at 08:09, Jay K wrote: > > I'm still hanging back on a version that supports PowerPC/Rosetta. :) > > Our system is very portable. > Consider helloWorld. And users of pthreads (or Win32 threads). > > And we hope/trust Apple and co. to maintain a certain level of compatibility. > > For example. the HPUX man pages decree that get/set/make/swapcontext may > not be compatible across releases. We use them, sometimes, for user threads only. > > > If you find there is any problem, please let us know. > Anything you find is likely surmountable by a cross build. > > > - Jay > > ________________________________ > From: dragisha at m3w.org > Date: Sun, 10 Nov 2013 18:48:22 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] AMD64_DARWIN with OSX Mavericks > > Anybody doing it? > > 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 dragisha at m3w.org Wed Nov 13 11:25:43 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 11:25:43 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> References: , <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> Message-ID: <0548803B-A685-420A-8C84-B1C365257775@m3w.org> Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. Xcode I have installed is version 4.6.x, and cm3 works as always. -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: > There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 10:53, Jay K wrote: > >> Is that really needed? >> >> Doesn't this work? >> >> hello.c: >> #include >> int main() { return !!printf("hello\n"); } >> >> cc hello.c >> >> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >> >> - Jay >> >> >> >> >> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >> From: dragisha at m3w.org >> Date: Wed, 13 Nov 2013 10:03:15 +0100 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >> >> SYSTEM_LIBS = { >> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >> ], >> "LEX-YACC" : [ "-ll" ], >> "FLEX-BISON" : [ "-lfl" ], >> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >> "TCP" : [ ] >> % below: X11, ODBC, POSTGRES95, MOTIF >> } >> >> My current AMD64_DARWIN configuration continues to work. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 11 Nov 2013, at 08:09, Jay K wrote: >> >> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >> >> Our system is very portable. >> Consider helloWorld. And users of pthreads (or Win32 threads). >> >> And we hope/trust Apple and co. to maintain a certain level of compatibility. >> >> For example. the HPUX man pages decree that get/set/make/swapcontext may >> not be compatible across releases. We use them, sometimes, for user threads only. >> >> >> If you find there is any problem, please let us know. >> Anything you find is likely surmountable by a cross build. >> >> >> - Jay >> >> ________________________________ >> From: dragisha at m3w.org >> Date: Sun, 10 Nov 2013 18:48:22 +0100 >> To: m3devel at elegosoft.com >> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >> >> Anybody doing it? >> >> 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 dragisha at m3w.org Wed Nov 13 19:27:20 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 19:27:20 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <0548803B-A685-420A-8C84-B1C365257775@m3w.org> References: , <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> Message-ID: <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> After Xcode 5.0.2 install, it works no more :) new source -> compiling Main.m3 clang: warning: argument unused during compilation: '-fPIC' Main.ms:1:9: error: unsupported directive '.stabs' .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 ^ -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote: > Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. > > Xcode I have installed is version 4.6.x, and cm3 works as always. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: > >> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 10:53, Jay K wrote: >> >>> Is that really needed? >>> >>> Doesn't this work? >>> >>> hello.c: >>> #include >>> int main() { return !!printf("hello\n"); } >>> >>> cc hello.c >>> >>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>> >>> - Jay >>> >>> >>> >>> >>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>> From: dragisha at m3w.org >>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>> CC: m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>> >>> SYSTEM_LIBS = { >>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>> ], >>> "LEX-YACC" : [ "-ll" ], >>> "FLEX-BISON" : [ "-lfl" ], >>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>> "TCP" : [ ] >>> % below: X11, ODBC, POSTGRES95, MOTIF >>> } >>> >>> My current AMD64_DARWIN configuration continues to work. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 11 Nov 2013, at 08:09, Jay K wrote: >>> >>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>> >>> Our system is very portable. >>> Consider helloWorld. And users of pthreads (or Win32 threads). >>> >>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>> >>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>> not be compatible across releases. We use them, sometimes, for user threads only. >>> >>> >>> If you find there is any problem, please let us know. >>> Anything you find is likely surmountable by a cross build. >>> >>> >>> - Jay >>> >>> ________________________________ >>> From: dragisha at m3w.org >>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>> >>> Anybody doing it? >>> >>> 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 dragisha at m3w.org Wed Nov 13 19:38:07 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 19:38:07 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <5705AEB1-3476-44BD-BAE5-3EA14D34E6F4@gmail.com> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> <5705AEB1-3476-44BD-BAE5-3EA14D34E6F4@gmail.com> Message-ID: AFAIK, automake/autoconf is big pain? of C world. Whole build systems were devised/built, just to bypass autowhatever. I don?t see any reason to envy current C build systems. But, if you are looking for a model, then also look at Maven/Gradle of Java world. Convention over configuration paradigm (very accepted, and which looks very much like cm3 config + m3makefile ) is so far away from autowhatever as possible. -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 18:11, Jay wrote: > I do repeatedly wonder if we should be a thin layer over automake/autoconf/pkg-config/libtool. I look into them every so often. What bugs me, maybe not pkg-config, is that they seem slow and have to generate files. I want something that usually makes fast decisions for every run. Optionally recording them in a file for bootstrapping or overridability. Cm3 was ahead of its time, kinda, but those tools solve much of the same problem, with other people maintaining them and more "dynamism"/"manifestation" -- I can't think of the word, but throw together a random posixish platform and autoconf can probe it and piece it together. There is no need to record static platform definitions and local configuration details are inferred/deduced at build-time, and there is good cross build support. > -------------- 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 Thu Nov 14 04:04:34 2013 From: jay.krell at cornell.edu (Jay) Date: Wed, 13 Nov 2013 19:04:34 -0800 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> Message-ID: <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> Try the C backed? Edit the g/stabs flag in the config file? - Jay On Nov 13, 2013, at 10:27 AM, Dragi?a Duri? wrote: > After Xcode 5.0.2 install, it works no more :) > > new source -> compiling Main.m3 > clang: warning: argument unused during compilation: '-fPIC' > Main.ms:1:9: error: unsupported directive '.stabs' > .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 > ^ > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote: > >> Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. >> >> Xcode I have installed is version 4.6.x, and cm3 works as always. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: >> >>> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 13 Nov 2013, at 10:53, Jay K wrote: >>> >>>> Is that really needed? >>>> >>>> Doesn't this work? >>>> >>>> hello.c: >>>> #include >>>> int main() { return !!printf("hello\n"); } >>>> >>>> cc hello.c >>>> >>>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>>> From: dragisha at m3w.org >>>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>>> CC: m3devel at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>>> >>>> SYSTEM_LIBS = { >>>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>>> ], >>>> "LEX-YACC" : [ "-ll" ], >>>> "FLEX-BISON" : [ "-lfl" ], >>>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>>> "TCP" : [ ] >>>> % below: X11, ODBC, POSTGRES95, MOTIF >>>> } >>>> >>>> My current AMD64_DARWIN configuration continues to work. >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On 11 Nov 2013, at 08:09, Jay K wrote: >>>> >>>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>>> >>>> Our system is very portable. >>>> Consider helloWorld. And users of pthreads (or Win32 threads). >>>> >>>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>>> >>>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>>> not be compatible across releases. We use them, sometimes, for user threads only. >>>> >>>> >>>> If you find there is any problem, please let us know. >>>> Anything you find is likely surmountable by a cross build. >>>> >>>> >>>> - Jay >>>> >>>> ________________________________ >>>> From: dragisha at m3w.org >>>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>>> To: m3devel at elegosoft.com >>>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>>> >>>> Anybody doing it? >>>> >>>> TIA, >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 14 05:30:42 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 14 Nov 2013 04:30:42 +0000 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> References: , , , , <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org>, <0548803B-A685-420A-8C84-B1C365257775@m3w.org>, <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org>, <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> Message-ID: > AFAIK, automake/autoconf is big pain. of C world. > Whole build systems were devised/built, just to bypass autowhatever. Yes but my research suggests nobody has matched it, in particular for cross builds and in particular autoconf's ability to work with brand new systems, as long as they can be composed from preexisting variables -- which are probed for. But I don't like layers and layers of generated files, Bourne shell, and m4. C and C++ aren't so bad. They do have positive and negatives. Lack of a good module system is one of their negatives. And therefore build speed and incremental builds. cm3 resembles the ideal user interface of automake, but without generating files. Where I most want autoX/libtool/pkg-config is to determine how to run the C compiler/assembler/linker for given packages. I think pkg-config addresses one of our weakest point. The point in the config files that list "ODBC" or "POSTGRES" and such. That part has never seemed great, not even with cminstall. The problem with cminstall is that packages can be installed and uninstalled in any order. I kinda think we could support it within cm3, easily enough, in one of a few ways: meta-syntax in the config file to indicate we should run pkg-config --libs and add that to the link command or we could try it unconditionally or we could find the .pc files ourselves, conditionally or unconditionally. see http://linux.die.net/man/1/pkg-config Someday maybe we'll generate .h files to interfacing with Modula-3, and then we could create .pc files also.. libtool I also want, because we duplicate a lot of it. Better to punt to another project. Though the wide availability of gcc combined with convergence to not that many OSes makes it not too difficult to do it yourself, which is what we do... - Jay From: jay.krell at cornell.edu Date: Wed, 13 Nov 2013 19:04:34 -0800 To: dragisha at m3w.org CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks Try the C backed? Edit the g/stabs flag in the config file? - Jay On Nov 13, 2013, at 10:27 AM, Dragi?a Duri? wrote: After Xcode 5.0.2 install, it works no more :) new source -> compiling Main.m3clang: warning: argument unused during compilation: '-fPIC'Main.ms:1:9: error: unsupported directive '.stabs' .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 ^ --Dragi?a Duri?dragisha at m3w.org On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote:Site is https://developer.apple.com/downloads, package is named "Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013" and cm3 I've used since Snow Leopard, all through Lion. works again without previous hack. Xcode I have installed is version 4.6.x, and cm3 works as always. --Dragi?a Duri?dragisha at m3w.org On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote:There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. --Dragi?a Duri?dragisha at m3w.org On 13 Nov 2013, at 10:53, Jay K wrote:Is that really needed? Doesn't this work? hello.c: #include int main() { return !!printf("hello\n"); } cc hello.c If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) - Jay Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks From: dragisha at m3w.org Date: Wed, 13 Nov 2013 10:03:15 +0100 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common SYSTEM_LIBS = { "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" ], "LEX-YACC" : [ "-ll" ], "FLEX-BISON" : [ "-lfl" ], "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], "TCP" : [ ]% below: X11, ODBC, POSTGRES95, MOTIF} My current AMD64_DARWIN configuration continues to work.--Dragi?a Duri?dragisha at m3w.org On 11 Nov 2013, at 08:09, Jay K wrote:I'm still hanging back on a version that supports PowerPC/Rosetta. :) Our system is very portable. Consider helloWorld. And users of pthreads (or Win32 threads). And we hope/trust Apple and co. to maintain a certain level of compatibility. For example. the HPUX man pages decree that get/set/make/swapcontext may not be compatible across releases. We use them, sometimes, for user threads only. If you find there is any problem, please let us know. Anything you find is likely surmountable by a cross build. - Jay ________________________________ From: dragisha at m3w.org Date: Sun, 10 Nov 2013 18:48:22 +0100 To: m3devel at elegosoft.com Subject: [M3devel] AMD64_DARWIN with OSX Mavericks Anybody doing it? TIA, -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Nov 13 18:11:22 2013 From: jay.krell at cornell.edu (Jay) Date: Wed, 13 Nov 2013 09:11:22 -0800 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <0548803B-A685-420A-8C84-B1C365257775@m3w.org> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> Message-ID: <5705AEB1-3476-44BD-BAE5-3EA14D34E6F4@gmail.com> I do repeatedly wonder if we should be a thin layer over automake/autoconf/pkg-config/libtool. I look into them every so often. What bugs me, maybe not pkg-config, is that they seem slow and have to generate files. I want something that usually makes fast decisions for every run. Optionally recording them in a file for bootstrapping or overridability. Cm3 was ahead of its time, kinda, but those tools solve much of the same problem, with other people maintaining them and more "dynamism"/"manifestation" -- I can't think of the word, but throw together a random posixish platform and autoconf can probe it and piece it together. There is no need to record static platform definitions and local configuration details are inferred/deduced at build-time, and there is good cross build support. I've considered coding up similar in M3/Python/C/C++. I do put some runtime tests in the config files. I suppose pkg-config is what we miss most, and we could read its files in cm3??? I.e. this is the part of the config files that are the most site-specific, and worse, need to change as surrounding packages are installed/uninstalled? What autoconf is "really" for, we get very far with light dependencies ("the functions are assumed all present"), light ifdefing (m3core's preemptive suspend), and light "practicality" (I.e. picking out integer types). Automake we basically have our own. Libtool I believe works through static knowledge, like us. And pkg-config, we miss out on largely. - Jay On Nov 13, 2013, at 2:25 AM, Dragi?a Duri? wrote: > Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. > > Xcode I have installed is version 4.6.x, and cm3 works as always. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: > >> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 10:53, Jay K wrote: >> >>> Is that really needed? >>> >>> Doesn't this work? >>> >>> hello.c: >>> #include >>> int main() { return !!printf("hello\n"); } >>> >>> cc hello.c >>> >>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>> >>> - Jay >>> >>> >>> >>> >>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>> From: dragisha at m3w.org >>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>> CC: m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>> >>> SYSTEM_LIBS = { >>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>> ], >>> "LEX-YACC" : [ "-ll" ], >>> "FLEX-BISON" : [ "-lfl" ], >>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>> "TCP" : [ ] >>> % below: X11, ODBC, POSTGRES95, MOTIF >>> } >>> >>> My current AMD64_DARWIN configuration continues to work. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 11 Nov 2013, at 08:09, Jay K wrote: >>> >>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>> >>> Our system is very portable. >>> Consider helloWorld. And users of pthreads (or Win32 threads). >>> >>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>> >>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>> not be compatible across releases. We use them, sometimes, for user threads only. >>> >>> >>> If you find there is any problem, please let us know. >>> Anything you find is likely surmountable by a cross build. >>> >>> >>> - Jay >>> >>> ________________________________ >>> From: dragisha at m3w.org >>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>> >>> Anybody doing it? >>> >>> TIA, >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Nov 14 12:14:34 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 14 Nov 2013 12:14:34 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> Message-ID: <7F9E43C8-CF1B-422C-88B9-14B576CEDC76@m3w.org> I will, time permitting :). Right now, working recipe is - Xcode 4.6.3 downgrade, alreay mentioned command line utils installed. It works like it always had. -- Dragi?a Duri? dragisha at m3w.org On 14 Nov 2013, at 04:04, Jay wrote: > Try the C backed? > > > Edit the g/stabs flag in the config file? > > > - Jay > > On Nov 13, 2013, at 10:27 AM, Dragi?a Duri? wrote: > >> After Xcode 5.0.2 install, it works no more :) >> >> new source -> compiling Main.m3 >> clang: warning: argument unused during compilation: '-fPIC' >> Main.ms:1:9: error: unsupported directive '.stabs' >> .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 >> ^ >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote: >> >>> Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. >>> >>> Xcode I have installed is version 4.6.x, and cm3 works as always. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: >>> >>>> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On 13 Nov 2013, at 10:53, Jay K wrote: >>>> >>>>> Is that really needed? >>>>> >>>>> Doesn't this work? >>>>> >>>>> hello.c: >>>>> #include >>>>> int main() { return !!printf("hello\n"); } >>>>> >>>>> cc hello.c >>>>> >>>>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> >>>>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>>>> From: dragisha at m3w.org >>>>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>>>> CC: m3devel at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> >>>>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>>>> >>>>> SYSTEM_LIBS = { >>>>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>>>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>>>> ], >>>>> "LEX-YACC" : [ "-ll" ], >>>>> "FLEX-BISON" : [ "-lfl" ], >>>>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>>>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>>>> "TCP" : [ ] >>>>> % below: X11, ODBC, POSTGRES95, MOTIF >>>>> } >>>>> >>>>> My current AMD64_DARWIN configuration continues to work. >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On 11 Nov 2013, at 08:09, Jay K wrote: >>>>> >>>>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>>>> >>>>> Our system is very portable. >>>>> Consider helloWorld. And users of pthreads (or Win32 threads). >>>>> >>>>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>>>> >>>>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>>>> not be compatible across releases. We use them, sometimes, for user threads only. >>>>> >>>>> >>>>> If you find there is any problem, please let us know. >>>>> Anything you find is likely surmountable by a cross build. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> ________________________________ >>>>> From: dragisha at m3w.org >>>>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>>>> To: m3devel at elegosoft.com >>>>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>>>> >>>>> Anybody doing it? >>>>> >>>>> 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 rcolebur at SCIRES.COM Sat Nov 16 17:38:08 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sat, 16 Nov 2013 16:38:08 +0000 Subject: [M3devel] pickle2 compilation error Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF924B950A@ATLEX04-SRV.SCIRES.LOCAL> I'm getting a compilation error for pickles v2 on Windows XP: unable to open file for reading: ..\src\pickle\ver2\PklFpMap.i3: ErrorCode=2: The system cannot find the file specified. I've updated from head branch, so perhaps this is due to a recent change. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Nov 16 19:17:23 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 16 Nov 2013 12:17:23 -0600 Subject: [M3devel] pickle2 compilation error In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF924B950A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924B950A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <5287B6B3.2080307@lcwb.coop> Oops, sorry, I apparently didn't get PklFpMap.[im]3 added in the head. They should be there now. On 11/16/2013 10:38 AM, Coleburn, Randy wrote: > I?m getting a compilation error for pickles v2 on Windows XP: > > unable to open file for reading: ..\src\pickle\ver2\PklFpMap.i3: ErrorCode=2: The system cannot find the file specified. > > I?ve updated from head branch, so perhaps this is due to a recent change. > > --Randy > From dragisha at m3w.org Sun Nov 17 20:49:53 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 17 Nov 2013 20:49:53 +0100 Subject: [M3devel] GC deadlock Message-ID: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack #0 0x00130416 in __kernel_vsyscall () #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 another: #0 0x00130416 in __kernel_vsyscall () #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 and others: #0 0x00130416 in __kernel_vsyscall () #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) at ../src/thread/PTHREAD/ThreadPThread.m3:1205 #4 #5 0x00130416 in __kernel_vsyscall () #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? -- 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 dragisha at m3w.org Sun Nov 17 22:45:33 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 17 Nov 2013 22:45:33 +0100 Subject: [M3devel] GC deadlock In-Reply-To: References: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> Message-ID: <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> Good. I will try same cases with more recent one ASAP. -- Dragi?a Duri? dragisha at m3w.org On 17 Nov 2013, at 21:40, Antony Hosking wrote: > I know 5.8.6 had problems. > > On Nov 17, 2013, at 2:49 PM, Dragi?a Duri? wrote: > >> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack >> >> #0 0x00130416 in __kernel_vsyscall () >> #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 >> #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 >> #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 >> #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 >> #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 >> >> another: >> #0 0x00130416 in __kernel_vsyscall () >> #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 >> #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 >> #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 >> #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 >> #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 >> #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 >> #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >> #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >> >> and others: >> #0 0x00130416 in __kernel_vsyscall () >> #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 >> #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 >> #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) >> at ../src/thread/PTHREAD/ThreadPThread.m3:1205 >> #4 >> #5 0x00130416 in __kernel_vsyscall () >> #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >> >> Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? >> >> -- >> 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 rcolebur at SCIRES.COM Wed Nov 20 00:47:28 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 19 Nov 2013 23:47:28 +0000 Subject: [M3devel] compiler build problem Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF924CBE81@ATLEX04-SRV.SCIRES.LOCAL> I'm running into a new problem. I've updated from the HEAD branch and rebuilding everything on Windows XP again. Building of the package group "front" in stage 1 goes well and I install the new cm3.exe. Then, when I try to build in stage 2 using the new cm3.exe, I get the following error when invoking cm3.exe: *** *** runtime error: *** A compile-time type is missing. *** file "..\src\Utils.m3" *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12fea0 0x6d6c76 Fail + 0x79 in ..\src\runtime\common\RTType.m3 0x12fecc 0x6d5ea3 ResolveTypeLink + 0x50 in ..\src\runtime\common\RTType.m3 0x12fef8 0x6c242b ResolveTypeLinks + 0x57 in ..\src\runtime\common\RTLinker.m3 0x12ff2c 0x6c21ab FixTypes + 0x107 in ..\src\runtime\common\RTLinker.m3 0x12ff40 0x6c1c9d AddUnitI + 0xe2 in ..\src\runtime\common\RTLinker.m3 0x12ff60 0x6c1d56 AddUnit + 0x9c in ..\src\runtime\common\RTLinker.m3 0x12ff7c 0x401038 0x12ffc0 0x70d738 RTTypeMap_M3 + 0x4d6 in ..\src\runtime\common\RTTypeMap.m3 ......... ......... ... more frames ... Any ideas on what is wrong? Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Nov 20 03:13:07 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Nov 2013 20:13:07 -0600 Subject: [M3devel] compiler build problem In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF924CBE81@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924CBE81@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <528C1AB3.3010009@lcwb.coop> I don't know for sure what is going on in your case, but I have several times found this error disappearing after exhaustive cm3 -realclean or do-cm3-*.sh realclean, followed by recompiling everything from scratch. I think I recall one time even vetting this and finding some package that was present in different versions in the link closure, or something similar. The declaration-granularity automatic recompilation in the compiler only pretends to work within a package. Inter-package, you are on your own to make sure everything is compiled in the right order and consistently. Sorry, I don't have any help on what order that is. But I think the order of packages in pkginfo.txt is, at least mostly, right, if you use the do-cm3-*.sh scripts. On 11/19/2013 05:47 PM, Coleburn, Randy wrote: > I?m running into a new problem. > > I?ve updated from the HEAD branch and rebuilding everything on Windows XP again. > > Building of the package group ?front? in stage 1 goes well and I install the new cm3.exe. > > Then, when I try to build in stage 2 using the new cm3.exe, I get the following error when invoking cm3.exe: > > *** > > *** runtime error: > > *** A compile-time type is missing. > > *** file "..\src\Utils.m3" > > *** > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12fea0 0x6d6c76 Fail + 0x79 in ..\src\runtime\common\RTType.m3 > > 0x12fecc 0x6d5ea3 ResolveTypeLink + 0x50 in ..\src\runtime\common\RTType.m3 > > 0x12fef8 0x6c242b ResolveTypeLinks + 0x57 in ..\src\runtime\common\RTLinker.m3 > > 0x12ff2c 0x6c21ab FixTypes + 0x107 in ..\src\runtime\common\RTLinker.m3 > > 0x12ff40 0x6c1c9d AddUnitI + 0xe2 in ..\src\runtime\common\RTLinker.m3 > > 0x12ff60 0x6c1d56 AddUnit + 0x9c in ..\src\runtime\common\RTLinker.m3 > > 0x12ff7c 0x401038 > > 0x12ffc0 0x70d738 RTTypeMap_M3 + 0x4d6 in ..\src\runtime\common\RTTypeMap.m3 > > ......... ......... ... more frames ... > > Any ideas on what is wrong? > > Thanks, > > Randy Coleburn > From rodney_bates at lcwb.coop Fri Nov 22 16:44:28 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 Nov 2013 09:44:28 -0600 Subject: [M3devel] How to compile m3cc with -O0 Message-ID: <528F7BDC.8020005@lcwb.coop> Before I track this down laboriously, does anybody know right off hand where to put the optimization flag -O0 for compiling m3cc? There are dozens of CFLAGS and similar in quake variables, make variables, environment variables, etc., getting passed all over the place. Naive replacements of "-O2" by "-O0" so far aren't getting through to the compilation. From dragisha at m3w.org Fri Nov 22 23:31:28 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 22 Nov 2013 23:31:28 +0100 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? Message-ID: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org> + ./scripts/do-pkg.sh buildship m3core libm3 tcp /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc === package m3-libs/m3core === +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling WinBase.i3 "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) -- 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 dragisha at m3w.org Fri Nov 22 23:55:23 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 22 Nov 2013 23:55:23 +0100 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org> References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org> Message-ID: <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> Yes, it was in a memo? Sorry for disruption :). On 22 Nov 2013, at 23:31, Dragi?a Duri? wrote: > + ./scripts/do-pkg.sh buildship m3core libm3 tcp > /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc > === package m3-libs/m3core === > +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling WinBase.i3 > "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) > > -- > 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 Nov 23 12:17:47 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 23 Nov 2013 11:17:47 +0000 Subject: [M3devel] How to compile m3cc with -O0 In-Reply-To: <528F7BDC.8020005@lcwb.coop> References: <528F7BDC.8020005@lcwb.coop> Message-ID: Yes? But anyone, na?ve replacement should work, as long as it a little extra thorough. :) Look in m3cc/gcc-*/Makefile*.in m3cc/gcc-*/gcc/Makefile*.in You could also do in in src/m3makefile via CFLAGS=-O0 or such. There is a reason it is tricky though, and that is because of bootstrapping. And I gather they really like libgcc to be optimized, so give it separate flags to avoid being hit by the other. We don't use libgcc so no matter. Why? Because it takes too long to build optimized? Yes, that is annoying. Because it hard to debug? Yes, that is lame. The C compilers should do better there. If you are focusing on debugging very particular code, you can also often sprinkle in volatile to defeat the optimizer. or "make foo.o", copy/paste what it runs, run it yourself edited, and then make to continue. Also a bit annoying. - Jay > Date: Fri, 22 Nov 2013 09:44:28 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] How to compile m3cc with -O0 > > Before I track this down laboriously, does anybody know right off hand where > to put the optimization flag -O0 for compiling m3cc? There are dozens of > CFLAGS and similar in quake variables, make variables, environment variables, etc., > getting passed all over the place. Naive replacements of "-O2" by "-O0" so > far aren't getting through to the compilation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 23 12:13:43 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 23 Nov 2013 11:13:43 +0000 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org>, <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> Message-ID: This is deliberate, and slightly useful, and the warnings shouldn't occur in the head, for several years now. Please upgrade more frequently. In particular: - It is useful because "much" of the interfaces are describing types, and types aren't just for function parameters, for functions that aren't available, but they are used as part of files, and you can, hypothetically, use them in your own functions (heck, you can write a Win32-on-Posix compatibility layer and provide the functions..). In particular, mklib uses these types and is fairly portable. It might have endian/alignment problems though, esp. endian. I do have a plan to get rid of mklib though...i was slow to realize it because mklib exports too much and I wanted a replacement wthout that flaw, but just matching it is adequate. The frontend/backends shall output the .def files instead of mklib. And then the usual lib/ar/link can/should make the libraries. If anyone wants to use LTCG on NT with the C backend, this is the way (or put everything in one source file via the backend, not a bad idea).. - In the past 20 years or so, there is only one widely used platform that made the mistake of having multiple calling conventions and that is NT/x86. Not NT in general, but NT/x86 specifically. I expect nobody will make this mistake again. I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake. On NT/x86, the calling convention does not bifurcate the entire target and force building everything multiple times, because you can sprinkle it around and each "type" can call each "type". This is good and bad. The other OS/processor combinations with multiple calling conventions define it as multiple ABIs with I believe no offical interop (except at the kernel level, for some of them). Therefore, callling conventions can be safely ignored on all platforms except NT/x86. Nobody will have any names to use here, overlapping the NT/x86 names or not. If the day comes where I am wrong and some target has multiple conventions, we should change the pragma to accept multiple. If the names overlap with NT/x86, we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3 and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost the same, but for one little difference that could be handled another way, they go duplicated. That pattern bugs me. - Jay From: dragisha at m3w.org Date: Fri, 22 Nov 2013 23:55:23 +0100 To: m3devel at elegosoft.com Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase? Yes, it was in a memo. Sorry for disruption :). On 22 Nov 2013, at 23:31, Dragi?a Duri? wrote:+ ./scripts/do-pkg.sh buildship m3core libm3 tcp/root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc=== package m3-libs/m3core === +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++--- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling WinBase.i3"../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Nov 23 18:06:00 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 Nov 2013 18:06:00 +0100 Subject: [M3devel] GC deadlock... crash this time In-Reply-To: <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> References: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> Message-ID: Ok.. Now I am at HEAD, literraly: *** *** runtime error: *** An array subscript was out of range. *** file "../src/runtime/common/RTCollector.m3", line 418 *** #32 0x003dbe44 in _m3_fault (M3_AcxOUs_arg=) from /usr/local/cm3/bin/../lib/libm3core.so.5 #33 0x003d3807 in RTCollector__Move (M3_BVudqN_self=, M3_AJWxb1_cp=) at ../src/runtime/common/RTCollector.m3:418 #34 0x003cfb86 in RTHeapMap__Walk (M3_AJWxb1_x=, M3_AJWxb1_pc=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:202 #35 0x003cf471 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:62 #36 0x003cf448 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:57 #37 0x003cf3ee in RTHeapMap__WalkRef (M3_Edk2y1_h=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:47 #38 0x003d58b6 in RTCollector__CleanBetween (M3_Edk2y1_h=, M3_Edk2y1_he=, M3_AicXUJ_clean=) at ../src/runtime/common/RTCollector.m3:1091 #39 0x003d56d7 in RTCollector__CleanPage (M3_BtgLOI_page=) at ../src/runtime/common/RTCollector.m3:1064 #40 0x003d4ed2 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 #41 0x003d476a in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #42 0x003d444a in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #43 0x003cd245 in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=, M3_Cwb5VA_dataAlignment=, M3_B1GO5V_thread=) at ../src/runtime/common/RTAllocator.m3:367 #44 0x003cc3cc in RTAllocator__GetTracedRef (M3_Eic7CK_def=) at ../src/runtime/common/RTAllocator.m3:202 #45 0x003cc027 in RTHooks__AllocateTracedRef (M3_AJWxb1_defn=) at ../src/runtime/common/RTAllocator.m3:115 #46 0x002fcb05 in IntRefTbl__Put (M3_C1DLtw_tbl=, M3_EN2A1V_key=, M3_EKuYlT_val=) at ../LINUXLIBC6/IntRefTbl.m3 => ../src/table/Table.mg:126 On 17 Nov 2013, at 22:45, Dragi?a Duri? wrote: > Good. I will try same cases with more recent one ASAP. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 17 Nov 2013, at 21:40, Antony Hosking wrote: > >> I know 5.8.6 had problems. >> >> On Nov 17, 2013, at 2:49 PM, Dragi?a Duri? wrote: >> >>> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack >>> >>> #0 0x00130416 in __kernel_vsyscall () >>> #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 >>> #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 >>> #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 >>> #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 >>> #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 >>> >>> another: >>> #0 0x00130416 in __kernel_vsyscall () >>> #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 >>> #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 >>> #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 >>> #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 >>> #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 >>> #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 >>> #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >>> #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >>> >>> and others: >>> #0 0x00130416 in __kernel_vsyscall () >>> #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 >>> #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 >>> #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:1205 >>> #4 >>> #5 0x00130416 in __kernel_vsyscall () >>> #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >>> >>> Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? >>> >>> -- >>> 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 Sat Nov 23 21:33:51 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 23 Nov 2013 14:33:51 -0600 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org>, <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> Message-ID: <5291112F.5040102@lcwb.coop> On 11/23/2013 05:13 AM, Jay K wrote: > This is deliberate, and slightly useful, and the warnings shouldn't occur in the head, > for several years now. Please upgrade more frequently. > > I feel very strongly that the latest release compiler should always build the head. We have all too few Modula-3 users anyway. If we don''t have this ability, then we become an exclusive club with unreasonable barriers to outsiders. There is hardly a better way to keep the community shrinking. I know it can be a pain to maintain compatibility, but we really must do it. Until we get a new release with a compiler that won't choke on WINAPI, we need to keep different versions of the source. Actually, I thought I had removed all occurrences of this problem a few months ago. How did I miss this one? > In particular: > > > - It is useful because "much" of the interfaces are describing types, > and types aren't just for function parameters, for functions that > aren't available, but they are used as part of files, and you can, > hypothetically, use them in your own functions (heck, you can > write a Win32-on-Posix compatibility layer and provide the functions..). > > > In particular, mklib uses these types and is fairly portable. > It might have endian/alignment problems though, esp. endian. > > > I do have a plan to get rid of mklib though...i was slow to realize it > because mklib exports too much and I wanted a replacement wthout that flaw, > but just matching it is adequate. The frontend/backends shall output > the .def files instead of mklib. And then the usual lib/ar/link can/should > make the libraries. If anyone wants to use LTCG on NT with the C backend, > this is the way (or put everything in one source file via the backend, not a bad idea).. > > > - In the past 20 years or so, there is only one widely used > platform that made the mistake of having multiple calling conventions > and that is NT/x86. Not NT in general, but NT/x86 specifically. > I expect nobody will make this mistake again. > I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake. > On NT/x86, the calling convention does not bifurcate the entire target > and force building everything multiple times, because you can sprinkle it around and > each "type" can call each "type". This is good and bad. > The other OS/processor combinations with multiple calling conventions > define it as multiple ABIs with I believe no offical interop (except at the > kernel level, for some of them). > > > Therefore, callling conventions can be safely ignored on all platforms except NT/x86. > Nobody will have any names to use here, overlapping the NT/x86 names or not. > If the day comes where I am wrong and some target has multiple conventions, > we should change the pragma to accept multiple. If the names overlap with NT/x86, > we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3 > and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost > the same, but for one little difference that could be handled another way, they go duplicated. > That pattern bugs me. > > > - Jay > > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > From: dragisha at m3w.org > Date: Fri, 22 Nov 2013 23:55:23 +0100 > To: m3devel at elegosoft.com > Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase? > > Yes, it was in a memo. Sorry for disruption :). > > On 22 Nov 2013, at 23:31, Dragi?a Duri? > wrote: > > + ./scripts/do-pkg.sh buildship m3core libm3 tcp > /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc > === package m3-libs/m3core === > +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling WinBase.i3 > "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > From dragisha at m3w.org Sat Nov 23 23:30:06 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 Nov 2013 23:30:06 +0100 Subject: [M3devel] GC deadlock... crash this time In-Reply-To: <9E8E3A08-047F-45D2-BD1E-C473DC2E6E54@purdue.edu> References: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> <9E8E3A08-047F-45D2-BD1E-C473DC2E6E54@purdue.edu> Message-ID: <6EE7FE7E-A8F5-496C-8033-F761DEF87A59@m3w.org> There is UNSAFE code, few LOOPHOLEs, nothing much, and I am not loopholing anything untraced over. And yes, this is x86_32, some old dual Xeon machine. If it happens again, I will definitely try @M3paranoidgc. While here.. What are prospects of Atomic ops? TIA, dd On 23 Nov 2013, at 20:33, Antony Hosking wrote: > These issues are best diagnosed by running with @M3paranoidgc. That will perform extensive checking of heap integrity after each GC cycle. It would appear that some sort of heap corruption has occurred. Does your application have much unsafe code? Unfortunately, UNSAFE code can arbitrarily confuse the GC. > > Also, what platform is this on? x86_64 or x86_32? Looks like LINUXLIBC6 which I believe is still x86_32. > > On Nov 23, 2013, at 12:06 PM, Dragi?a Duri? wrote: > >> Ok.. Now I am at HEAD, literraly: >> >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "../src/runtime/common/RTCollector.m3", line 418 >> *** >> >> #32 0x003dbe44 in _m3_fault (M3_AcxOUs_arg=) from /usr/local/cm3/bin/../lib/libm3core.so.5 >> #33 0x003d3807 in RTCollector__Move (M3_BVudqN_self=, M3_AJWxb1_cp=) >> at ../src/runtime/common/RTCollector.m3:418 >> #34 0x003cfb86 in RTHeapMap__Walk (M3_AJWxb1_x=, M3_AJWxb1_pc=, M3_Deq2V9_v=) >> at ../src/runtime/common/RTHeapMap.m3:202 >> #35 0x003cf471 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) >> at ../src/runtime/common/RTHeapMap.m3:62 >> #36 0x003cf448 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) >> at ../src/runtime/common/RTHeapMap.m3:57 >> #37 0x003cf3ee in RTHeapMap__WalkRef (M3_Edk2y1_h=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:47 >> #38 0x003d58b6 in RTCollector__CleanBetween (M3_Edk2y1_h=, M3_Edk2y1_he=, >> M3_AicXUJ_clean=) at ../src/runtime/common/RTCollector.m3:1091 >> #39 0x003d56d7 in RTCollector__CleanPage (M3_BtgLOI_page=) at ../src/runtime/common/RTCollector.m3:1064 >> #40 0x003d4ed2 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 >> #41 0x003d476a in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >> #42 0x003d444a in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >> #43 0x003cd245 in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=, M3_Cwb5VA_dataAlignment=, >> M3_B1GO5V_thread=) at ../src/runtime/common/RTAllocator.m3:367 >> #44 0x003cc3cc in RTAllocator__GetTracedRef (M3_Eic7CK_def=) at ../src/runtime/common/RTAllocator.m3:202 >> #45 0x003cc027 in RTHooks__AllocateTracedRef (M3_AJWxb1_defn=) at ../src/runtime/common/RTAllocator.m3:115 >> #46 0x002fcb05 in IntRefTbl__Put (M3_C1DLtw_tbl=, M3_EN2A1V_key=, M3_EKuYlT_val=) >> at ../LINUXLIBC6/IntRefTbl.m3 => ../src/table/Table.mg:126 >> >> On 17 Nov 2013, at 22:45, Dragi?a Duri? wrote: >> >>> Good. I will try same cases with more recent one ASAP. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 17 Nov 2013, at 21:40, Antony Hosking wrote: >>> >>>> I know 5.8.6 had problems. >>>> >>>> On Nov 17, 2013, at 2:49 PM, Dragi?a Duri? wrote: >>>> >>>>> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack >>>>> >>>>> #0 0x00130416 in __kernel_vsyscall () >>>>> #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 >>>>> #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 >>>>> #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 >>>>> #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 >>>>> #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 >>>>> >>>>> another: >>>>> #0 0x00130416 in __kernel_vsyscall () >>>>> #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 >>>>> #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 >>>>> #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 >>>>> #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 >>>>> #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 >>>>> #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 >>>>> #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >>>>> #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >>>>> >>>>> and others: >>>>> #0 0x00130416 in __kernel_vsyscall () >>>>> #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 >>>>> #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 >>>>> #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) >>>>> at ../src/thread/PTHREAD/ThreadPThread.m3:1205 >>>>> #4 >>>>> #5 0x00130416 in __kernel_vsyscall () >>>>> #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >>>>> >>>>> Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? >>>>> >>>>> -- >>>>> 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 dragisha at m3w.org Sat Nov 23 23:32:39 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 Nov 2013 23:32:39 +0100 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: <5291112F.5040102@lcwb.coop> References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org>, <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> <5291112F.5040102@lcwb.coop> Message-ID: <977737CA-F2B7-4940-860D-5B56D64B658A@m3w.org> I think some interim release, of ?get on with Modula-3 fast? kind, is better idea than to slow progress. And I don?t dislike this current state. As for sommunity shrinking? Maybe some web facelift would be good idea? Anybody willing? dd On 23 Nov 2013, at 21:33, Rodney M. Bates wrote: > > > On 11/23/2013 05:13 AM, Jay K wrote: >> This is deliberate, and slightly useful, and the warnings shouldn't occur in the head, >> for several years now. Please upgrade more frequently. >> >> > > I feel very strongly that the latest release compiler should always build the head. > We have all too few Modula-3 users anyway. If we don''t have this ability, > then we become an exclusive club with unreasonable barriers to outsiders. > There is hardly a better way to keep the community shrinking. > > I know it can be a pain to maintain compatibility, but we really must do it. > Until we get a new release with a compiler that won't choke on WINAPI, we > need to keep different versions of the source. > > Actually, I thought I had removed all occurrences of this problem a few > months ago. How did I miss this one? > > >> In particular: >> >> >> - It is useful because "much" of the interfaces are describing types, >> and types aren't just for function parameters, for functions that >> aren't available, but they are used as part of files, and you can, >> hypothetically, use them in your own functions (heck, you can >> write a Win32-on-Posix compatibility layer and provide the functions..). >> >> >> In particular, mklib uses these types and is fairly portable. >> It might have endian/alignment problems though, esp. endian. >> >> >> I do have a plan to get rid of mklib though...i was slow to realize it >> because mklib exports too much and I wanted a replacement wthout that flaw, >> but just matching it is adequate. The frontend/backends shall output >> the .def files instead of mklib. And then the usual lib/ar/link can/should >> make the libraries. If anyone wants to use LTCG on NT with the C backend, >> this is the way (or put everything in one source file via the backend, not a bad idea).. >> >> >> - In the past 20 years or so, there is only one widely used >> platform that made the mistake of having multiple calling conventions >> and that is NT/x86. Not NT in general, but NT/x86 specifically. >> I expect nobody will make this mistake again. >> I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake. >> On NT/x86, the calling convention does not bifurcate the entire target >> and force building everything multiple times, because you can sprinkle it around and >> each "type" can call each "type". This is good and bad. >> The other OS/processor combinations with multiple calling conventions >> define it as multiple ABIs with I believe no offical interop (except at the >> kernel level, for some of them). >> >> >> Therefore, callling conventions can be safely ignored on all platforms except NT/x86. >> Nobody will have any names to use here, overlapping the NT/x86 names or not. >> If the day comes where I am wrong and some target has multiple conventions, >> we should change the pragma to accept multiple. If the names overlap with NT/x86, >> we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3 >> and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost >> the same, but for one little difference that could be handled another way, they go duplicated. >> That pattern bugs me. >> >> >> - Jay >> >> >> >> >> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > -- >> From: dragisha at m3w.org >> Date: Fri, 22 Nov 2013 23:55:23 +0100 >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase? >> >> Yes, it was in a memo. Sorry for disruption :). >> >> On 22 Nov 2013, at 23:31, Dragi?a Duri? > wrote: >> >> + ./scripts/do-pkg.sh buildship m3core libm3 tcp >> /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc >> === package m3-libs/m3core === >> +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ >> --- building in LINUXLIBC6 --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling WinBase.i3 >> "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) >> >> -- >> 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 wagner at elegosoft.com Thu Nov 28 07:47:55 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Nov 2013 07:47:55 +0100 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 Message-ID: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> I know that there have been controverse discussions about the right way to do unicode support. Is there any way to help Elmar Stellnberger with a quick solution? Olaf Begin forwarded message: Date: Wed, 27 Nov 2013 20:13:54 +0100 From: Elmar Stellnberger To: m3-support at elego.de Subject: UTF-16: Greek alphabet with CM3 Dear Supporters of CM3, Elegosoft Wanting to make use of CM3s new UTF-16 feature I have tried to use greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is beta in the unicode table. However I soon had to notice that outputing widechars is not supported by Trestle which still seems to be based on X11R4. Some analysis of the problem has shown that TextVBT calls VBT.PaintText which does however use the CHAR type internally rather than Widechar calling PaintSub to output text instead of the X11R6 function XDrawString16. Is it true that you plan real unicode support for CM3 or is there any way to hack the trestle toolkit into allowing X11R6 functions? If yes or no how could I convert current X11R6 includes for being used with Modula-3? Nonetheless I would really welcome true native utf-16 support (as nowadays given by the iso10646-1 X core fonts like also 'fixed') because that would be the only way to make use of utf-16 for Windows ports. Otherwise I will have to consider whether I can use Modula-3 at all for my current project which is about converting the automaton simulator www.elstel.org/coan from Object Pascal into a currently supported language and publishing it as open source. Thanks a lot for your effort! Yours, Elmar Stellnberger -- 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 dabenavidesd at yahoo.es Fri Nov 29 02:41:18 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> Message-ID: <1385689278.60242.YahooMailNeo@web171905.mail.ir2.yahoo.com> Hi all: I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? http://www.ascii-codes.com/cp869.html Thanks in advance PD: I? will have time In January, if you want I can help port your app (if it doens't have too much goto's) El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner escribi?: I know that there have been controverse discussions about the right way to do unicode support. Is there any way to help Elmar Stellnberger with a quick solution? Olaf Begin forwarded message: Date: Wed, 27 Nov 2013 20:13:54 +0100 From: Elmar Stellnberger To: m3-support at elego.de Subject: UTF-16: Greek alphabet with CM3 Dear Supporters of CM3, Elegosoft ? Wanting to make use of CM3s new UTF-16 feature I have tried to use greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is beta in the unicode table. However I soon had to notice that outputing widechars is not supported by Trestle which still seems to be based on X11R4. Some analysis of the problem has shown that TextVBT calls VBT.PaintText which does however use the CHAR type internally rather than Widechar calling PaintSub to output text instead of the X11R6 function XDrawString16. Is it true that you plan real unicode support for CM3 or is there any way to hack the trestle toolkit into allowing X11R6 functions? If yes or no how could I convert current X11R6 includes for being used with Modula-3? Nonetheless I would really welcome true native utf-16 support (as nowadays given by the iso10646-1 X core fonts like also 'fixed') because that would be the only way to make use of utf-16 for Windows ports. Otherwise I will have to consider whether I can use Modula-3 at all for my current project which is about converting the automaton simulator www.elstel.org/coan from Object Pascal into a currently supported language and publishing it as open source. Thanks a lot for your effort! Yours, Elmar Stellnberger -- 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 -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Nov 29 07:44:49 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 Nov 2013 07:44:49 +0100 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 Message-ID: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> Hi Elmar Stellnberger, I've forwarded your question to the m3devel mailing list; there has only been one answer so far though (see below). Daniel is talking about using some ISO-charset variant; I'm not sure if that is an option for you. I myself would think it should not be too much work to adapt Trestle and X for Unicode support, but then I haven't had a close look at the code and surely won't have the time to do that. I'm also unsure if UTF-8 might not be the way to go, Olaf Begin forwarded message: Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) From: "Daniel Alejandro Benavides D." To: Olaf Wagner , "m3devel at elegosoft.com" Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 Hi all: I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? http://www.ascii-codes.com/cp869.html Thanks in advance PD: I? will have time In January, if you want I can help port your app (if it doens't have too much goto's) El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner escribi?: I know that there have been controverse discussions about the right way to do unicode support. Is there any way to help Elmar Stellnberger with a quick solution? Olaf Begin forwarded message: Date: Wed, 27 Nov 2013 20:13:54 +0100 From: Elmar Stellnberger To: m3-support at elego.de Subject: UTF-16: Greek alphabet with CM3 Dear Supporters of CM3, Elegosoft ? Wanting to make use of CM3s new UTF-16 feature I have tried to use greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is beta in the unicode table. However I soon had to notice that outputing widechars is not supported by Trestle which still seems to be based on X11R4. Some analysis of the problem has shown that TextVBT calls VBT.PaintText which does however use the CHAR type internally rather than Widechar calling PaintSub to output text instead of the X11R6 function XDrawString16. Is it true that you plan real unicode support for CM3 or is there any way to hack the trestle toolkit into allowing X11R6 functions? If yes or no how could I convert current X11R6 includes for being used with Modula-3? Nonetheless I would really welcome true native utf-16 support (as nowadays given by the iso10646-1 X core fonts like also 'fixed') because that would be the only way to make use of utf-16 for Windows ports. Otherwise I will have to consider whether I can use Modula-3 at all for my current project which is about converting the automaton simulator www.elstel.org/coan from Object Pascal into a currently supported language and publishing it as open source. Thanks a lot for your effort! Yours, Elmar Stellnberger -- 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 -- 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 estellnb at elstel.org Fri Nov 29 17:05:45 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 Nov 2013 16:05:45 +0000 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> Message-ID: <5298BB59.3080703@elstel.org> Am 29.11.2013 06:44, schrieb Olaf Wagner: > Hi Elmar Stellnberger, > > I've forwarded your question to the m3devel mailing list; there has only > been one answer so far though (see below). Daniel is talking about using > some ISO-charset variant; I'm not sure if that is an option for you. > > I myself would think it should not be too much work to adapt Trestle > and X for Unicode support, but then I haven't had a close look at the > code and surely won't have the time to do that. > > I'm also unsure if UTF-8 might not be the way to go, > > Olaf > > Begin forwarded message: > > Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) > From: "Daniel Alejandro Benavides D." > To: Olaf Wagner , "m3devel at elegosoft.com" > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > Hi all: > I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? > http://www.ascii-codes.com/cp869.html Unfortunately I am in need of an entire Greek alphabet because automatons that have already been created with this program should continue to work and be displayed correctly. > > > Thanks in advance > > > PD: I will have time In January, if you want I can help port your app (if it doens't have too much goto's) Great! If you could guarantee me your assistance at least for the Trestle/VBT issues in support of 16bit wide characters I would start to work on a Modula-3 port. The thing is that I will need the port for my studies and I do hardly want to take the risk in failing to hack Trestle/VBT though the thing should not be that hard to do as Olaf has already indicated. As far as I have researched things all that would need to be done is add an additional painting operation to the PaintPrivate interface; or perhaps a second one for drawing elliptical arcs rather than just using Path.CurveTo and to make these new operations be used by the respective painting primitives. Additionally I would welcome some styling of buttons and bevels that goes ahead of pure black and white X-windows. Some Qt-like or at least a Windows 3.1 like button and menu styling might not be unimportant for the acceptance of the application. Nonetheless up to now I can not verify the impact of new painting operations on ports for Windows and MacOS which I am not confident with. No, it does not have a single goto; I`d consider it well structured as it uses classes, objects, method variables and nested procedures and can easily be extended for new automatons. At the moment I am still reading into Trestle. > > > > > El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner escribi?: > > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? > > Olaf P.S.: I have already programmed a module converting between UTF-16 and UTF-8 for console usage and am ready to publish it under BSD or any non-infective license allowing to re-license under any license. I would consider it really a pity if CM3 had good internal UTF-16 support but no interface to make use of it in practice. Additionally I could upload my still existent VIM environment for hacking Modula-3 including syntax highlighting, a treeview buffer and a backtrace analyzer to http://www.elstel.org/modula3 if anyone is interested in it. Elmar From dmuysers at hotmail.com Fri Nov 29 17:52:09 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 29 Nov 2013 17:52:09 +0100 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298BB59.3080703@elstel.org> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> Message-ID: Forget Trestle/VBT and Cie. Modern GUI systems all offer platform look and feel. The easiest solution is to create an import library for IUP (http://www.tecgraf.puc-rio.br/iup/). IUP is a compact (about a 100 "C" functions), portable and platform rendered GUI library. BTW, it uses (since version 3.9) UTF-8 text. I still find that the split of the character set into chars and wides was a very bad decision. It is always stupid to follow the Microsoft trail, the most incompetent software company (IMHO) in the world. -----Original Message----- From: Elmar Stellnberger Sent: Friday, November 29, 2013 5:05 PM To: dabenavidesd at yahoo.es Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 Am 29.11.2013 06:44, schrieb Olaf Wagner: > Hi Elmar Stellnberger, > > I've forwarded your question to the m3devel mailing list; there has only > been one answer so far though (see below). Daniel is talking about using > some ISO-charset variant; I'm not sure if that is an option for you. > > I myself would think it should not be too much work to adapt Trestle > and X for Unicode support, but then I haven't had a close look at the > code and surely won't have the time to do that. > > I'm also unsure if UTF-8 might not be the way to go, > > Olaf > > Begin forwarded message: > > Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) > From: "Daniel Alejandro Benavides D." > To: Olaf Wagner , "m3devel at elegosoft.com" > > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > Hi all: > I'm retired for Modula-3 work for now, but the ASCII table had codes for > Greek alphabet are you sure you can't print that with ASCII? > http://www.ascii-codes.com/cp869.html Unfortunately I am in need of an entire Greek alphabet because automatons that have already been created with this program should continue to work and be displayed correctly. > > > Thanks in advance > > > PD: I will have time In January, if you want I can help port your app (if > it doens't have too much goto's) Great! If you could guarantee me your assistance at least for the Trestle/VBT issues in support of 16bit wide characters I would start to work on a Modula-3 port. The thing is that I will need the port for my studies and I do hardly want to take the risk in failing to hack Trestle/VBT though the thing should not be that hard to do as Olaf has already indicated. As far as I have researched things all that would need to be done is add an additional painting operation to the PaintPrivate interface; or perhaps a second one for drawing elliptical arcs rather than just using Path.CurveTo and to make these new operations be used by the respective painting primitives. Additionally I would welcome some styling of buttons and bevels that goes ahead of pure black and white X-windows. Some Qt-like or at least a Windows 3.1 like button and menu styling might not be unimportant for the acceptance of the application. Nonetheless up to now I can not verify the impact of new painting operations on ports for Windows and MacOS which I am not confident with. No, it does not have a single goto; I`d consider it well structured as it uses classes, objects, method variables and nested procedures and can easily be extended for new automatons. At the moment I am still reading into Trestle. > > > > > El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner > escribi?: > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? > > Olaf P.S.: I have already programmed a module converting between UTF-16 and UTF-8 for console usage and am ready to publish it under BSD or any non-infective license allowing to re-license under any license. I would consider it really a pity if CM3 had good internal UTF-16 support but no interface to make use of it in practice. Additionally I could upload my still existent VIM environment for hacking Modula-3 including syntax highlighting, a treeview buffer and a backtrace analyzer to http://www.elstel.org/modula3 if anyone is interested in it. Elmar From estellnb at elstel.org Fri Nov 29 18:21:57 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 Nov 2013 17:21:57 +0000 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> Message-ID: <5298CD35.10200@elstel.org> As said the difference between UTF-8 and UTF-16 should not matter as long as we just use 16bit characters and as I plan to use a 'tr' function like in qt in order to convert into the current local language which will also handle things like character encoding. As far as I can remember we had something that could convert C interfaces into Modula-3. Is that correct, Olaf? Also; wasn`t there once an attempt to also convert GTK? Nonetheless converting a light weight toolkit may be easier and sufficient for the given purpose. If any of the mentioned languages supported nested procedures and objects at the same time that would allow me to convert existing Object Pascal code without wrapper objects which I would personally like to avoid. C and C++ do not have this feature apart from a very different syntax which would make a converter basing on an LL1 parser necessary. I don`t know that much about Lua and LED. However something that compiles would be fine as well. Elmar Am 29.11.2013 16:52, schrieb dirk muysers: > Forget Trestle/VBT and Cie. Modern GUI systems all offer platform > look and feel. The easiest solution is to create an import library for > IUP (http://www.tecgraf.puc-rio.br/iup/). IUP is a compact (about > a 100 "C" functions), portable and platform rendered GUI library. > BTW, it uses (since version 3.9) UTF-8 text. I still find that the > split of the character set into chars and wides was a very bad > decision. It is always stupid to follow the Microsoft trail, the > most incompetent software company (IMHO) in the world. > > -----Original Message----- From: Elmar Stellnberger > Sent: Friday, November 29, 2013 5:05 PM > To: dabenavidesd at yahoo.es > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 > > > Am 29.11.2013 06:44, schrieb Olaf Wagner: >> Hi Elmar Stellnberger, >> >> I've forwarded your question to the m3devel mailing list; there has only >> been one answer so far though (see below). Daniel is talking about using >> some ISO-charset variant; I'm not sure if that is an option for you. >> >> I myself would think it should not be too much work to adapt Trestle >> and X for Unicode support, but then I haven't had a close look at the >> code and surely won't have the time to do that. >> >> I'm also unsure if UTF-8 might not be the way to go, >> >> Olaf >> >> Begin forwarded message: >> >> Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) >> From: "Daniel Alejandro Benavides D." >> To: Olaf Wagner , "m3devel at elegosoft.com" >> >> Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 >> >> >> Hi all: >> I'm retired for Modula-3 work for now, but the ASCII table had codes >> for Greek alphabet are you sure you can't print that with ASCII? >> http://www.ascii-codes.com/cp869.html > Unfortunately I am in need of an entire Greek alphabet because > automatons that have already been created with this program should > continue to work and be displayed correctly. > >> >> >> Thanks in advance >> >> >> PD: I will have time In January, if you want I can help port your >> app (if it doens't have too much goto's) > Great! > If you could guarantee me your assistance at least for the Trestle/VBT > issues in support of 16bit wide characters I would start to work on a > Modula-3 port. The thing is that I will need the port for my studies and > I do hardly want to take the risk in failing to hack Trestle/VBT though > the thing should not be that hard to do as Olaf has already indicated. > As far as I have researched things all that would need to be done is add > an additional painting operation to the PaintPrivate interface; or > perhaps a second one for drawing elliptical arcs rather than just using > Path.CurveTo and to make these new operations be used by the respective > painting primitives. Additionally I would welcome some styling of > buttons and bevels that goes ahead of pure black and white X-windows. > Some Qt-like or at least a Windows 3.1 like button and menu styling > might not be unimportant for the acceptance of the application. > Nonetheless up to now I can not verify the impact of new painting > operations on ports for Windows and MacOS which I am not confident with. > > No, it does not have a single goto; I`d consider it well structured as > it uses classes, objects, method variables and nested procedures and can > easily be extended for new automatons. At the moment I am still reading > into Trestle. > >> >> >> >> >> El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner >> escribi?: >> I know that there have been controverse discussions about the right >> way to do unicode support. >> >> Is there any way to help Elmar Stellnberger with a quick solution? >> >> Olaf > P.S.: I have already programmed a module converting between UTF-16 and > UTF-8 for console usage and am ready to publish it under BSD or any > non-infective license allowing to re-license under any license. I would > consider it really a pity if CM3 had good internal UTF-16 support but no > interface to make use of it in practice. > > Additionally I could upload my still existent VIM environment for > hacking Modula-3 including syntax highlighting, a treeview buffer and a > backtrace analyzer to http://www.elstel.org/modula3 if anyone is > interested in it. > > Elmar > > From dmuysers at hotmail.com Fri Nov 29 18:43:58 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 29 Nov 2013 18:43:58 +0100 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298CD35.10200@elstel.org> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> <5298CD35.10200@elstel.org> Message-ID: No need to use a tool for that. Just write a IUP.i3 file and use the <*EXTERNAL*> pragma. Also a mechanical translation will not do. One must be creative here and use some intermediate code, e.g. have look at . > As far as I can remember we had something that could convert > C interfaces into Modula-3. Is that correct, Olaf? > Also; wasn`t there once an attempt to also convert GTK? > Nonetheless converting a light weight toolkit may be easier and > sufficient for the given purpose. From lemming at henning-thielemann.de Fri Nov 29 18:55:17 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 29 Nov 2013 18:55:17 +0100 (CET) Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298CD35.10200@elstel.org> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> <5298CD35.10200@elstel.org> Message-ID: On Fri, 29 Nov 2013, Elmar Stellnberger wrote: > As far as I can remember we had something that could convert C > interfaces into Modula-3. Is that correct, Olaf? I extended SWIG with Modula-3 support. From jay.krell at cornell.edu Sat Nov 30 04:50:50 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 Nov 2013 03:50:50 +0000 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com>, <5298BB59.3080703@elstel.org>, , <5298CD35.10200@elstel.org>, Message-ID: > Wanting to make use of CM3s new UTF-16 feature Cm3 has had 16bit WIDECHAR for over 10 years now. This is plenty to support most languages. Yes, I know, these days Unicode is a I think a 20bit encoding. I don't like Trestle either, but how we convert it take widen any TEXT to WIDECHARs (16 or 32bits then truncate to 16bits and use the "16" stuff in X?) - Jay > Date: Fri, 29 Nov 2013 18:55:17 +0100 > From: lemming at henning-thielemann.de > To: estellnb at elstel.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 > > > On Fri, 29 Nov 2013, Elmar Stellnberger wrote: > > > As far as I can remember we had something that could convert C > > interfaces into Modula-3. Is that correct, Olaf? > > I extended SWIG with Modula-3 support. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Nov 30 06:35:07 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 00:35:07 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <1385689278.60242.YahooMailNeo@web171905.mail.ir2.yahoo.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <1385689278.60242.YahooMailNeo@web171905.mail.ir2.yahoo.com> Message-ID: <20131130053507.GA20380@topoi.pooq.com> On Fri, Nov 29, 2013 at 01:41:18AM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? > http://www.ascii-codes.com/cp869.html Perhaps not ASCII, but there must have been a Greek national veriant of the ISO code back when it was still an eight-bit code. Thatnwould be a matter of sspecifying the right environment variables at run time. -- hendrik From hendrik at topoi.pooq.com Sat Nov 30 06:46:55 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 00:46:55 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> Message-ID: <20131130054655.GB20380@topoi.pooq.com> On Thu, Nov 28, 2013 at 07:47:55AM +0100, Olaf Wagner wrote: > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? See http://en.wikipedia.org/wiki/ISO/IEC_8859-7 It seems there's an eight-bit code that's enough for the Greek language. So in theory all you need to do is set the right environment variables to specify a Greek character set. In practice you might have to define the geometry fot the Greek characters for Trestle. Unless it manages to use the underlying OS support for this. -- hendrik > > Olaf > > Begin forwarded message: > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > From: Elmar Stellnberger > To: m3-support at elego.de > Subject: UTF-16: Greek alphabet with CM3 > > > Dear Supporters of CM3, Elegosoft > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > beta in the unicode table. However I soon had to notice that outputing > widechars is not supported by Trestle which still seems to be based on > X11R4. Some analysis of the problem has shown that TextVBT calls > VBT.PaintText which does however use the CHAR type internally rather > than Widechar calling PaintSub to output text instead of the X11R6 > function XDrawString16. Is it true that you plan real unicode support > for CM3 or is there any way to hack the trestle toolkit into allowing > X11R6 functions? If yes or no how could I convert current X11R6 includes > for being used with Modula-3? Nonetheless I would really welcome true > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > like also 'fixed') because that would be the only way to make use of > utf-16 for Windows ports. Otherwise I will have to consider whether I > can use Modula-3 at all for my current project which is about converting > the automaton simulator www.elstel.org/coan from Object Pascal into a > currently supported language and publishing it as open source. > Thanks a lot for your effort! > > Yours, > Elmar Stellnberger > -- > 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 jay.krell at cornell.edu Sat Nov 30 09:26:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 Nov 2013 08:26:29 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131130054655.GB20380@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> Message-ID: Right, In this respect, everything probably just works and always has. Just don't try to display any two non-English languages in a GUI at once. I think we should port Trestle to use 16 bit characters always internally. Even going so far as to double the memory use of common English strings. Can anyone vouch for XDrawString16 generally being implemented and working? - Jay > Date: Sat, 30 Nov 2013 00:46:55 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > On Thu, Nov 28, 2013 at 07:47:55AM +0100, Olaf Wagner wrote: > > I know that there have been controverse discussions about the right > > way to do unicode support. > > > > Is there any way to help Elmar Stellnberger with a quick solution? > > See http://en.wikipedia.org/wiki/ISO/IEC_8859-7 > It seems there's an eight-bit code that's enough for the Greek language. > So in theory all you need to do is set the right environment variables > to specify a Greek character set. In practice you might have to define > the geometry fot the Greek characters for Trestle. Unless it manages > to use the underlying OS support for this. > > -- hendrik > > > > > > Olaf > > > > Begin forwarded message: > > > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > > From: Elmar Stellnberger > > To: m3-support at elego.de > > Subject: UTF-16: Greek alphabet with CM3 > > > > > > Dear Supporters of CM3, Elegosoft > > > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > > beta in the unicode table. However I soon had to notice that outputing > > widechars is not supported by Trestle which still seems to be based on > > X11R4. Some analysis of the problem has shown that TextVBT calls > > VBT.PaintText which does however use the CHAR type internally rather > > than Widechar calling PaintSub to output text instead of the X11R6 > > function XDrawString16. Is it true that you plan real unicode support > > for CM3 or is there any way to hack the trestle toolkit into allowing > > X11R6 functions? If yes or no how could I convert current X11R6 includes > > for being used with Modula-3? Nonetheless I would really welcome true > > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > > like also 'fixed') because that would be the only way to make use of > > utf-16 for Windows ports. Otherwise I will have to consider whether I > > can use Modula-3 at all for my current project which is about converting > > the automaton simulator www.elstel.org/coan from Object Pascal into a > > currently supported language and publishing it as open source. > > Thanks a lot for your effort! > > > > Yours, > > Elmar Stellnberger > > -- > > 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 -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 30 10:06:03 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 Nov 2013 09:06:03 +0000 Subject: [M3devel] how to represent a 16bit char? Message-ID: 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? 2) Are we really certain that redefining WIDECHAR is the way to go? Not, say, introduce a new time, CHAR32 or UCHAR32? And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? Or do people now advocate: get rid of WIDECHAR leave 8 bit CHAR with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? ?? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Nov 30 10:34:47 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Sat, 30 Nov 2013 10:34:47 +0100 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: References: Message-ID: Yes, I think UTF-8 CHAR is the way to go. Nearly all recent Un*x libraries use it by now. Only Microsoft sticks to CHAR16 nowadays. I have a UTF-8 TEXT implementation in the making and don?t have the time, these days, to complete it. It has a constant time cursor to sequentially access this encoding, support for character properties, dynamic text building and formatting, and NLS (National Language support), and will have an XML reader. Finished: TEXT implementation, and char props. Partially finished: Dynamic buffer and NLS. Unfinished so far: Formatting and XML. The software is called libunicode. As for Win32, most software use dynamic translation to CHAR16, when required, eg Component Pascal for .Net, GTK, golang etc. leaving it the craggy island it is. From: Jay K Sent: Saturday, November 30, 2013 10:06 AM To: m3devel Subject: [M3devel] how to represent a 16bit char? 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? 2) Are we really certain that redefining WIDECHAR is the way to go? Not, say, introduce a new time, CHAR32 or UCHAR32? And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? Or do people now advocate: get rid of WIDECHAR leave 8 bit CHAR with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? ?? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Nov 30 11:41:42 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 30 Nov 2013 11:41:42 +0100 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: References: Message-ID: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> Are we really sure about this Xlib interfacing? There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? -- Dragi?a Duri? dragisha at m3w.org On 30 Nov 2013, at 10:06, Jay K wrote: > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? > 2) Are we really certain that redefining WIDECHAR is the way to go? > Not, say, introduce a new time, CHAR32 or UCHAR32? > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? > > Or do people now advocate: > get rid of WIDECHAR > leave 8 bit CHAR > with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? > ?? > > Thank you, > - Jay -------------- 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 dragisha at m3w.org Sat Nov 30 11:52:22 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 30 Nov 2013 11:52:22 +0100 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> References: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> Message-ID: And yes, Cairo uses UTF-8 natively, even on Windows. On 30 Nov 2013, at 11:41, Dragi?a Duri? wrote: > Are we really sure about this Xlib interfacing? > > There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 30 Nov 2013, at 10:06, Jay K wrote: > >> 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >> 2) Are we really certain that redefining WIDECHAR is the way to go? >> Not, say, introduce a new time, CHAR32 or UCHAR32? >> And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >> >> Or do people now advocate: >> get rid of WIDECHAR >> leave 8 bit CHAR >> with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? >> ?? >> >> Thank you, >> - Jay > -------------- 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 dragisha at m3w.org Sat Nov 30 12:02:03 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 30 Nov 2013 12:02:03 +0100 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> Message-ID: <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> I think this would be a major error. Choose 16bit route when only Windows does this, and everybody else is using UTF-8 is not a logical decision. -- Dragi?a Duri? dragisha at m3w.org On 30 Nov 2013, at 09:26, Jay K wrote: > Right, In this respect, everything probably just works and always has. > Just don't try to display any two non-English languages in a GUI at once. > > I think we should port Trestle to use 16 bit characters always internally. > Even going so far as to double the memory use of common English strings. > > Can anyone vouch for XDrawString16 generally being implemented and working? > > - Jay > > > > Date: Sat, 30 Nov 2013 00:46:55 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > > On Thu, Nov 28, 2013 at 07:47:55AM +0100, Olaf Wagner wrote: > > > I know that there have been controverse discussions about the right > > > way to do unicode support. > > > > > > Is there any way to help Elmar Stellnberger with a quick solution? > > > > See http://en.wikipedia.org/wiki/ISO/IEC_8859-7 > > It seems there's an eight-bit code that's enough for the Greek language. > > So in theory all you need to do is set the right environment variables > > to specify a Greek character set. In practice you might have to define > > the geometry fot the Greek characters for Trestle. Unless it manages > > to use the underlying OS support for this. > > > > -- hendrik > > > > > > > > > > Olaf > > > > > > Begin forwarded message: > > > > > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > > > From: Elmar Stellnberger > > > To: m3-support at elego.de > > > Subject: UTF-16: Greek alphabet with CM3 > > > > > > > > > Dear Supporters of CM3, Elegosoft > > > > > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > > > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > > > beta in the unicode table. However I soon had to notice that outputing > > > widechars is not supported by Trestle which still seems to be based on > > > X11R4. Some analysis of the problem has shown that TextVBT calls > > > VBT.PaintText which does however use the CHAR type internally rather > > > than Widechar calling PaintSub to output text instead of the X11R6 > > > function XDrawString16. Is it true that you plan real unicode support > > > for CM3 or is there any way to hack the trestle toolkit into allowing > > > X11R6 functions? If yes or no how could I convert current X11R6 includes > > > for being used with Modula-3? Nonetheless I would really welcome true > > > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > > > like also 'fixed') because that would be the only way to make use of > > > utf-16 for Windows ports. Otherwise I will have to consider whether I > > > can use Modula-3 at all for my current project which is about converting > > > the automaton simulator www.elstel.org/coan from Object Pascal into a > > > currently supported language and publishing it as open source. > > > Thanks a lot for your effort! > > > > > > Yours, > > > Elmar Stellnberger > > > -- > > > 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 -------------- 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 estellnb at elstel.org Sat Nov 30 12:25:31 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 11:25:31 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> Message-ID: <5299CB2B.9090008@elstel.org> > Right, In this respect, everything probably just works and always has. > Just don't try to display any two non-English languages in a GUI at once. That was exactly the requirement: use greek and latin characters at the same time to display mathematical expressions > I think we should port Trestle to use 16 bit characters always internally. > Even going so far as to double the memory use of common English strings. No, that does not double the memory usage. I have just inserted a Text.IsWide function to let a future version of VBT.PaintText select whether it wants to use XDrawString16 or its eight bit counterpart. > Can anyone vouch for XDrawString16 generally being implemented and working? Yes it is shipped with X11R4 - Jay > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? > 2) Are we really certain that redefining WIDECHAR is the way to go? > Not, say, introduce a new time, CHAR32 or UCHAR32? > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: first you would have to upgrade the whole Trestle kit to X11R6 you would have to use the very heavy weight X11R6 XIM interface to make use of WideChar32 then you would finally have to change the internal representation of the Text type. Am 30.11.2013 11:02, schrieb Dragi?a Duri?: > I think this would be a major error. Choose 16bit route when only > Windows does this, and everybody else is using UTF-8 is not a logical > decision. I do not consent. WideChar32 will come with the additional benefit of some additionally supported languages. That is all it would be good for. If we ever upgraded to use XIM which will be a major effort as I have already tried to point out we can still consider WC32 though converting between UTF-8 and UTF-16 is no big deal (I have an implementation which I could give you.). i.e. X11R4 uses WC16 X11R6-XIM uses WC32 I do not want to speak against WC32; Nonetheless it basically depends on how much effort you are willing to invest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat Nov 30 12:34:42 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 11:34:42 +0000 Subject: [M3devel] use CM3_INSTALL_PREFIX to ship to a different target Message-ID: <5299CD52.8020207@elstel.org> As far as I have tested it cm3 -ship ignores CM3_INSTALL_PREFIX so that I can not ship to any directory different from /usr/local/cm3. I always had a different source and target compiler in the times when I was working with PM3 so that things could not get messed up easily. On desire I could compile the compiler with itself. So in a short: Is there any way to make cm3 ship to another directory than /usr/local/cm3 but still compile with /usr/local/cm3 Sorry; I haven` t found out yet how to do that. Perhaps it simply was not implemented. From estellnb at elstel.org Sat Nov 30 12:40:41 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 11:40:41 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5299CB2B.9090008@elstel.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> Message-ID: <5299CEB9.7010508@elstel.org> I do not know about the internals of Trestle but I have some knowledge of the X core protocol and thus I know that everything related to XIM is very complicated though usage of XIM rather than just XDrawString16 would enable user input of Asian languages. Elmar Am 30.11.2013 11:25, schrieb Elmar Stellnberger: > > Right, In this respect, everything probably just works and always has. > > Just don't try to display any two non-English languages in a GUI at > once. > > That was exactly the requirement: use greek and latin characters at > the same time to display mathematical expressions > > > I think we should port Trestle to use 16 bit characters always > internally. > > Even going so far as to double the memory use of common English strings. > > No, that does not double the memory usage. I have just inserted a > Text.IsWide function to let a future > version of VBT.PaintText select whether it wants to use XDrawString16 > or its eight bit counterpart. > > > Can anyone vouch for XDrawString16 generally being implemented and > working? > > Yes it is shipped with X11R4 > > - Jay > > > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I > use where WIDECHAR used to be correct? > > 2) Are we really certain that redefining WIDECHAR is the way to go? > > Not, say, introduce a new time, CHAR32 or UCHAR32? > > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type > that nobody will ever consider changing? > > upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: > first you would have to upgrade the whole Trestle kit to X11R6 > you would have to use the very heavy weight X11R6 XIM interface to > make use of WideChar32 > then you would finally have to change the internal representation of > the Text type. > > > > Am 30.11.2013 11:02, schrieb Dragi?a Duri?: >> I think this would be a major error. Choose 16bit route when only >> Windows does this, and everybody else is using UTF-8 is not a logical >> decision. > I do not consent. WideChar32 will come with the additional benefit of > some additionally supported languages. That is all it would be good for. > If we ever upgraded to use XIM which will be a major effort as I have > already tried to point out we can still consider WC32 though converting > between UTF-8 and UTF-16 is no big deal (I have an implementation > which I could give you.). > > i.e. X11R4 uses WC16 > X11R6-XIM uses WC32 > > I do not want to speak against WC32; Nonetheless > it basically depends on how much effort you are willing to invest. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat Nov 30 13:24:29 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 12:24:29 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5299CB2B.9090008@elstel.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> Message-ID: <5299D8FD.6090809@elstel.org> Actually the devil is in the details: Continuing to use 16bit characters outputting strings would be easy. However when it comes to adjust the input function there is no XKeySymToKeyCode16 function which means that you would either have to implement one on your own or the other way upgrade to X11R6, use XIM and convert from UTF-32 to UTF-16. Well there is a possibility to use XIM functions right the way as an XKeySymToKeyCode32 function would work without any input or status reflection. In order to use XOM for outputting 32 bit characters you would have to use 'font sets' on the other hand which I personally have never done. Elmar Am 30.11.2013 11:25, schrieb Elmar Stellnberger: > > Right, In this respect, everything probably just works and always has. > > Just don't try to display any two non-English languages in a GUI at > once. > > That was exactly the requirement: use greek and latin characters at > the same time to display mathematical expressions > > > I think we should port Trestle to use 16 bit characters always > internally. > > Even going so far as to double the memory use of common English strings. > > No, that does not double the memory usage. I have just inserted a > Text.IsWide function to let a future > version of VBT.PaintText select whether it wants to use XDrawString16 > or its eight bit counterpart. > > > Can anyone vouch for XDrawString16 generally being implemented and > working? > > Yes it is shipped with X11R4 > > - Jay > > > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I > use where WIDECHAR used to be correct? > > 2) Are we really certain that redefining WIDECHAR is the way to go? > > Not, say, introduce a new time, CHAR32 or UCHAR32? > > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type > that nobody will ever consider changing? > > upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: > first you would have to upgrade the whole Trestle kit to X11R6 > you would have to use the very heavy weight X11R6 XIM interface to > make use of WideChar32 > then you would finally have to change the internal representation of > the Text type. > > > > Am 30.11.2013 11:02, schrieb Dragi?a Duri?: >> I think this would be a major error. Choose 16bit route when only >> Windows does this, and everybody else is using UTF-8 is not a logical >> decision. > I do not consent. WideChar32 will come with the additional benefit of > some additionally supported languages. That is all it would be good for. > If we ever upgraded to use XIM which will be a major effort as I have > already tried to point out we can still consider WC32 though converting > between UTF-8 and UTF-16 is no big deal (I have an implementation > which I could give you.). > > i.e. X11R4 uses WC16 > X11R6-XIM uses WC32 > > I do not want to speak against WC32; Nonetheless > it basically depends on how much effort you are willing to invest. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Nov 30 17:52:44 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 Nov 2013 10:52:44 -0600 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5299D8FD.6090809@elstel.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> Message-ID: <529A17DC.3080906@lcwb.coop> Another devilish detail to be aware of: UTF-16 is _not_ the same as the current Modula-3 16-bit WIDECHAR, even when restricted to values <= 16_FFFF. Current Wr/Rd library code just writes/reads exactly 16 bits in two bytes, with whatever code point is in the WIDECHAR variable. In contrast, UTF-16 will encode code points greater than UFFFF as a pair of 16-bit code units with surrogate values in them. Then to make this work right, the surrogate values are not allowed in unencoded variables. So attempting to encode a surrogate in UTF-16 is an error, and decoding a surrogate that is not part of a proper first-surrogate/second-surrogate pair is "ill formed" and usually decodes to UFFFD. You could get by with treating these as interchangeable only be being careful to ensure there is never either a surrogate code nor a code point > UFFFF, in either input or output. Also, current Wr/Rd always write/read only in little-endian byte order, whereas there are both little- and big-endian variants of UTF-16. I have no idea which endianness of UTF-16 is used by various GUI libraries, but it would have to be little for this to work. On 11/30/2013 06:24 AM, Elmar Stellnberger wrote: > Actually the devil is in the details: > Continuing to use 16bit characters outputting strings would be easy. > However when it comes to adjust the input function there is no > XKeySymToKeyCode16 function which means that you would either > have to implement one on your own or the other way upgrade to > X11R6, use XIM and convert from UTF-32 to UTF-16. Well there is > a possibility to use XIM functions right the way as an > XKeySymToKeyCode32 function would work without any input > or status reflection. > In order to use XOM for outputting 32 bit characters you would > have to use 'font sets' on the other hand which I personally have > never done. > > Elmar > > > Am 30.11.2013 11:25, schrieb Elmar Stellnberger: >> > Right, In this respect, everything probably just works and always has. >> > Just don't try to display any two non-English languages in a GUI at once. >> >> That was exactly the requirement: use greek and latin characters at the same time to display mathematical expressions >> >> > I think we should port Trestle to use 16 bit characters always internally. >> > Even going so far as to double the memory use of common English strings. >> >> No, that does not double the memory usage. I have just inserted a Text.IsWide function to let a future >> version of VBT.PaintText select whether it wants to use XDrawString16 or its eight bit counterpart. >> >> > Can anyone vouch for XDrawString16 generally being implemented and working? >> >> Yes it is shipped with X11R4 >> >> - Jay >> >> > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >> > 2) Are we really certain that redefining WIDECHAR is the way to go? >> > Not, say, introduce a new time, CHAR32 or UCHAR32? >> > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >> >> upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: >> first you would have to upgrade the whole Trestle kit to X11R6 >> you would have to use the very heavy weight X11R6 XIM interface to make use of WideChar32 >> then you would finally have to change the internal representation of the Text type. >> >> >> >> Am 30.11.2013 11:02, schrieb Dragi?a Duri?: >>> I think this would be a major error. Choose 16bit route when only Windows does this, and everybody else is using UTF-8 is not a logical decision. >> I do not consent. WideChar32 will come with the additional benefit of some additionally supported languages. That is all it would be good for. >> If we ever upgraded to use XIM which will be a major effort as I have already tried to point out we can still consider WC32 though converting >> between UTF-8 and UTF-16 is no big deal (I have an implementation which I could give you.). >> >> i.e. X11R4 uses WC16 >> X11R6-XIM uses WC32 >> >> I do not want to speak against WC32; Nonetheless >> it basically depends on how much effort you are willing to invest. >> >> >> > From rodney_bates at lcwb.coop Sat Nov 30 18:02:30 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 Nov 2013 11:02:30 -0600 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298E46D.2020209@lcwb.coop> References: <5298E46D.2020209@lcwb.coop> Message-ID: <529A1A26.6010007@lcwb.coop> The first post of this seems to have disappeared into cyberspace. -------- Original Message -------- Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 Date: Fri, 29 Nov 2013 13:01:01 -0600 From: Rodney M. Bates To: m3devel at elegosoft.com, estellnb at elstel.org I have created a CVS branch (devel_unicode) that changes WIDECHAR to a big enough value range to handle all 16_110000 Unicode code points. I think this may be mostly orthogonal to what you need, as I am sure the Greek letters are in the BMP (first 16_10000) code points of Unicode, and thus representable by the current WIDECHAR. What might be useful to you though, in interfacing to Trestle or any other GUI system, is that it contains encoders/decoders for all of the Unicode-specified encodings (UTF-8, UTF-16-BE/LE, and UTF-32-BE/LE), as well as what I think are the older UCS2-BE/LE, and Modula-3's current ISO-Latin-1 and WIDECHAR encodings. The way these work is that WIDECHARs in memory, including within a TEXT, are fixed sized and are pure Unicode code points, preserving the way original CHAR works, especially, allowing efficient random access by character number, not byte number. But the en/decoding is done while reading/writing streams (Wr.T, Rd,t), which are, as originally, sequential, and thus suited to the variable-length encodings. Of course, you could do unusual things, for example, write with UTF-8 encoding to a pipe and decode with Ascii, thus getting the individual characters of UTF-8 into a TEXT or ARRAY OF CHAR, where you could mess with the encoded bytes in memory, rather than treating them as code points. The en/decoders are available in one-code-point-per-call forms, as well as in filters that are semantically almost identical to Wr and Rd, which work on whole streams, with a constant encoding. The latter, in front of TextWr/TextRd would probably make it easy to interface to any GUI library that uses in-memory UTF-8, etc. It also would not be hard to make these work with 16-bit WIDECHAR, with any input coded beyond UFFFF converted to the standard Unicode replacement UFFFD. It sounds like you would be unlikely to use such values. How soon do you need to start? On 11/28/2013 12:47 AM, Olaf Wagner wrote: > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? > > Olaf > > Begin forwarded message: > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > From: Elmar Stellnberger > To: m3-support at elego.de > Subject: UTF-16: Greek alphabet with CM3 > > > Dear Supporters of CM3, Elegosoft > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > beta in the unicode table. However I soon had to notice that outputing > widechars is not supported by Trestle which still seems to be based on > X11R4. Some analysis of the problem has shown that TextVBT calls > VBT.PaintText which does however use the CHAR type internally rather > than Widechar calling PaintSub to output text instead of the X11R6 > function XDrawString16. Is it true that you plan real unicode support > for CM3 or is there any way to hack the trestle toolkit into allowing > X11R6 functions? If yes or no how could I convert current X11R6 includes > for being used with Modula-3? Nonetheless I would really welcome true > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > like also 'fixed') because that would be the only way to make use of > utf-16 for Windows ports. Otherwise I will have to consider whether I > can use Modula-3 at all for my current project which is about converting > the automaton simulator www.elstel.org/coan from Object Pascal into a > currently supported language and publishing it as open source. > Thanks a lot for your effort! > > Yours, > Elmar Stellnberger > From hendrik at topoi.pooq.com Sat Nov 30 18:29:06 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 12:29:06 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529A17DC.3080906@lcwb.coop> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> Message-ID: <20131130172906.GA28372@topoi.pooq.com> On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > Another devilish detail to be aware of: UTF-16 is _not_ the same as > the current Modula-3 16-bit WIDECHAR, even when restricted to values > <= 16_FFFF. Current Wr/Rd library code just writes/reads > exactly 16 bits in two bytes, with whatever code point is in the > WIDECHAR variable. > > In contrast, UTF-16 will encode code points greater than > UFFFF as a pair of 16-bit code units with surrogate values in them. > Then to make this work right, the surrogate values are not > allowed in unencoded variables. So attempting to encode a surrogate > in UTF-16 is an error, and decoding a surrogate that is not part of a > proper first-surrogate/second-surrogate pair is "ill formed" and usually > decodes to UFFFD. > > You could get by with treating these as interchangeable only be being > careful to ensure there is never either a surrogate code nor a code > point > UFFFF, in either input or output. > > Also, current Wr/Rd always write/read only in little-endian byte order, > whereas there are both little- and big-endian variants of UTF-16. > I have no idea which endianness of UTF-16 is used by various GUI > libraries, but it would have to be little for this to work. It lools as if one might as well use UTF-8 if one is going to consider UTF-16. I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have been superseded by SCIM, I don't know the status of uim, except that it has a uim bridge. It does look as if SCIM (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended as a simple way to interface to many other input methods, such as XIM. It may be worth a look. --- hendrik From rodney_bates at lcwb.coop Sat Nov 30 20:59:47 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 Nov 2013 13:59:47 -0600 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131130172906.GA28372@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> Message-ID: <529A43B3.2090803@lcwb.coop> On 11/30/2013 11:29 AM, Hendrik Boom wrote: > On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: >> Another devilish detail to be aware of: UTF-16 is _not_ the same as >> the current Modula-3 16-bit WIDECHAR, even when restricted to values >> <= 16_FFFF. Current Wr/Rd library code just writes/reads >> exactly 16 bits in two bytes, with whatever code point is in the >> WIDECHAR variable. >> >> In contrast, UTF-16 will encode code points greater than >> UFFFF as a pair of 16-bit code units with surrogate values in them. >> Then to make this work right, the surrogate values are not >> allowed in unencoded variables. So attempting to encode a surrogate >> in UTF-16 is an error, and decoding a surrogate that is not part of a >> proper first-surrogate/second-surrogate pair is "ill formed" and usually >> decodes to UFFFD. >> >> You could get by with treating these as interchangeable only be being >> careful to ensure there is never either a surrogate code nor a code >> point > UFFFF, in either input or output. >> >> Also, current Wr/Rd always write/read only in little-endian byte order, >> whereas there are both little- and big-endian variants of UTF-16. >> I have no idea which endianness of UTF-16 is used by various GUI >> libraries, but it would have to be little for this to work. > > It lools as if one might as well use UTF-8 if one is going to consider UTF-16. Hmm. Actually, *if* one could live with the restrictions on values above, passing the same strings back and forth, with the GUI considering them UTF-16LE and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have the advantage that the M3 app code could deal naturally in characters, rather than varying numbers of fragments of characters. UTF-8 would require the latter. > > I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > been superseded by SCIM, I don't know the status of uim, except that > it has a uim bridge. > > It does look as if SCIM > (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > as a simple way to interface to many other input methods, such as XIM. > It may be worth a look. > > --- hendrik > > From rodney_bates at lcwb.coop Tue Nov 5 18:47:13 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 05 Nov 2013 11:47:13 -0600 Subject: [M3devel] How to run m3cggen? Message-ID: <52792F21.6020802@lcwb.coop> I need to rebuild m3cc after changes to m3middle/src/M3CG_Binary.i3 and m3cggen/src/Main. I can see that at a minimum, I have to recompile m3cggen first, then run it and place its output appropriately, before compiling m3cc. m3cggen comes after m3cc in pkginfo.txt, so the do-cm3-*.sh scripts can't work here. A massive recursive grep of everything for "m3cggen" doesn't appear to turn up anything in a script, makefile, or m3makefile, other than disconnected building of m3cggen itself. However, there is so much false output here, that it's a needle in a haystack. So is there any script, makefile, etc. that takes care of this, or is it all manual? Are there any other generated source files or similar steps that also need to be redone that I can't easily find? m3cg.h (The result of this process) is a CVS file, which at least hints that this is just being done manually. Slightly related, I found out the hard way that the parse.c in the gcc version you are compiling is actually, sometimes, overlaid during building, by the one in gcc/gcc/m3cg. What is the complete set of source files that, like this, are not where one would expect them to be? Is it everything in the m3cg subdirectory? Just parse.c? Some other subset? From jay.krell at cornell.edu Tue Nov 5 19:55:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Nov 2013 18:55:38 +0000 Subject: [M3devel] How to run m3cggen? In-Reply-To: <52792F21.6020802@lcwb.coop> References: <52792F21.6020802@lcwb.coop> Message-ID: Right. I hit the same problem at some point and wasn't satisfied either. I fixed it, or almost fixed it. Building it in a list of other stuff is correct, not a false hit, part of the solution. upgrade.sh and ugprade.py both handle this, almost. upgrade.sh: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/upgrade.sh?rev=1.37;content-type=text%2Fplain if [ "x${GCC_BACKEND}" = xyes ]; then # Continue with the backend, if needed. Deliberately don't ship it! # "$root/m3-sys/m3cggen/${TARGET}/m3cggen" > "$root/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" "$root/scripts/do-pkg.sh" "$@" "build" m3cc || exit 1 fi upgrade.py: https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/python/upgrade.py?rev=1.39;content-type=text%2Fplain a = Root + "/m3-sys/m3cggen/" + Target + "/m3cggen > " + Root + "/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" print(a) # os.system(a) FilterPackages([ "m3cc" ]) and DoPackage(argv_BuildShip, [ "m3cc" ]) Those two lines should be uncommented. Or, more likely, they should redirect elsewhere and do a "move if change". In the python case, "elsewhere" should be read the pipe into a variable in memory. It isn't supposed to change if there are no local edits, but streamlining it is very good to have. Maybe that is why I left it commented out. Only approx. 3 of us have changed this probably in 10 years. Tony probably doesn't use any of the scripts. I do and almost fixed it. You are #3. Can you make it so or shall I? m3cggen is "standalone" for this reason, or should be. > gcc/gcc/m3cg. > What is the complete set of source files that, like this, are not where one would > expect them to be? Is it everything in the m3cg subdirectory? Just parse.c? The list is whatever the source does. The alternative would be to have several almost identical copies and disconnected history. It is a little confusing, but the alternative isn't great either. For parse.c, and related, look in m3-sys/src/m3makefile. For example, we also sometimes have to make links for gmp/mpfr/mpc. - Jay > Date: Tue, 5 Nov 2013 11:47:13 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] How to run m3cggen? > > I need to rebuild m3cc after changes to m3middle/src/M3CG_Binary.i3 and m3cggen/src/Main. > I can see that at a minimum, I have to recompile m3cggen first, then run it and place > its output appropriately, before compiling m3cc. m3cggen comes after m3cc in pkginfo.txt, > so the do-cm3-*.sh scripts can't work here. > > A massive recursive grep of everything for "m3cggen" doesn't appear to turn up anything in > a script, makefile, or m3makefile, other than disconnected building of m3cggen itself. > However, there is so much false output here, that it's a needle in a haystack. > > So is there any script, makefile, etc. that takes care of this, or is it all manual? > Are there any other generated source files or similar steps that also need to be redone > that I can't easily find? > > m3cg.h (The result of this process) is a CVS file, which at least hints that this is > just being done manually. > > Slightly related, I found out the hard way that the parse.c in the gcc version you are > compiling is actually, sometimes, overlaid during building, by the one in gcc/gcc/m3cg. > What is the complete set of source files that, like this, are not where one would > expect them to be? Is it everything in the m3cg subdirectory? Just parse.c? > Some other subset? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Nov 10 18:48:22 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 10 Nov 2013 18:48:22 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks Message-ID: Anybody doing it? 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 Mon Nov 11 08:09:23 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 11 Nov 2013 07:09:23 +0000 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: Message-ID: I'm still hanging back on a version that supports PowerPC/Rosetta. ?:)? ?Our system is very portable.? ? Consider helloWorld. And users of pthreads (or Win32 threads). ? ?And we hope/trust Apple and co. to maintain a certain level of compatibility.? ?For example. the HPUX man pages decree that get/set/make/swapcontext may? ? not be compatible across releases. We use them, sometimes, for user threads only.? If you find there is any problem, please let us know. Anything you find is likely surmountable by a cross build. ?- Jay ________________________________ > From: dragisha at m3w.org > Date: Sun, 10 Nov 2013 18:48:22 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] AMD64_DARWIN with OSX Mavericks > > Anybody doing it? > > TIA, > -- > Dragi?a Duri? > dragisha at m3w.org From dragisha at m3w.org Wed Nov 13 10:03:15 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 10:03:15 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: Message-ID: I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common SYSTEM_LIBS = { "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" ], "LEX-YACC" : [ "-ll" ], "FLEX-BISON" : [ "-lfl" ], "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], "TCP" : [ ] % below: X11, ODBC, POSTGRES95, MOTIF } My current AMD64_DARWIN configuration continues to work. -- Dragi?a Duri? dragisha at m3w.org On 11 Nov 2013, at 08:09, Jay K wrote: > I'm still hanging back on a version that supports PowerPC/Rosetta. :) > > Our system is very portable. > Consider helloWorld. And users of pthreads (or Win32 threads). > > And we hope/trust Apple and co. to maintain a certain level of compatibility. > > For example. the HPUX man pages decree that get/set/make/swapcontext may > not be compatible across releases. We use them, sometimes, for user threads only. > > > If you find there is any problem, please let us know. > Anything you find is likely surmountable by a cross build. > > > - Jay > > ________________________________ >> From: dragisha at m3w.org >> Date: Sun, 10 Nov 2013 18:48:22 +0100 >> To: m3devel at elegosoft.com >> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >> >> Anybody doing it? >> >> 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 Wed Nov 13 10:53:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 13 Nov 2013 09:53:17 +0000 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: , Message-ID: Is that really needed? Doesn't this work? hello.c: #include int main() { return !!printf("hello\n"); } cc hello.c If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) - Jay Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks From: dragisha at m3w.org Date: Wed, 13 Nov 2013 10:03:15 +0100 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common SYSTEM_LIBS = { "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" ], "LEX-YACC" : [ "-ll" ], "FLEX-BISON" : [ "-lfl" ], "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], "TCP" : [ ]% below: X11, ODBC, POSTGRES95, MOTIF} My current AMD64_DARWIN configuration continues to work.--Dragi?a Duri?dragisha at m3w.org On 11 Nov 2013, at 08:09, Jay K wrote:I'm still hanging back on a version that supports PowerPC/Rosetta. :) Our system is very portable. Consider helloWorld. And users of pthreads (or Win32 threads). And we hope/trust Apple and co. to maintain a certain level of compatibility. For example. the HPUX man pages decree that get/set/make/swapcontext may not be compatible across releases. We use them, sometimes, for user threads only. If you find there is any problem, please let us know. Anything you find is likely surmountable by a cross build. - Jay ________________________________ From: dragisha at m3w.org Date: Sun, 10 Nov 2013 18:48:22 +0100 To: m3devel at elegosoft.com Subject: [M3devel] AMD64_DARWIN with OSX Mavericks Anybody doing it? TIA, -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Nov 13 11:08:47 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 11:08:47 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: References: , Message-ID: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 10:53, Jay K wrote: > Is that really needed? > > Doesn't this work? > > hello.c: > #include > int main() { return !!printf("hello\n"); } > > cc hello.c > > If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) > > - Jay > > > > > Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks > From: dragisha at m3w.org > Date: Wed, 13 Nov 2013 10:03:15 +0100 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common > > SYSTEM_LIBS = { > "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", > "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" > ], > "LEX-YACC" : [ "-ll" ], > "FLEX-BISON" : [ "-lfl" ], > "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, > "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], > "TCP" : [ ] > % below: X11, ODBC, POSTGRES95, MOTIF > } > > My current AMD64_DARWIN configuration continues to work. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 11 Nov 2013, at 08:09, Jay K wrote: > > I'm still hanging back on a version that supports PowerPC/Rosetta. :) > > Our system is very portable. > Consider helloWorld. And users of pthreads (or Win32 threads). > > And we hope/trust Apple and co. to maintain a certain level of compatibility. > > For example. the HPUX man pages decree that get/set/make/swapcontext may > not be compatible across releases. We use them, sometimes, for user threads only. > > > If you find there is any problem, please let us know. > Anything you find is likely surmountable by a cross build. > > > - Jay > > ________________________________ > From: dragisha at m3w.org > Date: Sun, 10 Nov 2013 18:48:22 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] AMD64_DARWIN with OSX Mavericks > > Anybody doing it? > > 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 dragisha at m3w.org Wed Nov 13 11:25:43 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 11:25:43 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> References: , <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> Message-ID: <0548803B-A685-420A-8C84-B1C365257775@m3w.org> Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. Xcode I have installed is version 4.6.x, and cm3 works as always. -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: > There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 10:53, Jay K wrote: > >> Is that really needed? >> >> Doesn't this work? >> >> hello.c: >> #include >> int main() { return !!printf("hello\n"); } >> >> cc hello.c >> >> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >> >> - Jay >> >> >> >> >> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >> From: dragisha at m3w.org >> Date: Wed, 13 Nov 2013 10:03:15 +0100 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >> >> SYSTEM_LIBS = { >> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >> ], >> "LEX-YACC" : [ "-ll" ], >> "FLEX-BISON" : [ "-lfl" ], >> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >> "TCP" : [ ] >> % below: X11, ODBC, POSTGRES95, MOTIF >> } >> >> My current AMD64_DARWIN configuration continues to work. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 11 Nov 2013, at 08:09, Jay K wrote: >> >> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >> >> Our system is very portable. >> Consider helloWorld. And users of pthreads (or Win32 threads). >> >> And we hope/trust Apple and co. to maintain a certain level of compatibility. >> >> For example. the HPUX man pages decree that get/set/make/swapcontext may >> not be compatible across releases. We use them, sometimes, for user threads only. >> >> >> If you find there is any problem, please let us know. >> Anything you find is likely surmountable by a cross build. >> >> >> - Jay >> >> ________________________________ >> From: dragisha at m3w.org >> Date: Sun, 10 Nov 2013 18:48:22 +0100 >> To: m3devel at elegosoft.com >> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >> >> Anybody doing it? >> >> 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 dragisha at m3w.org Wed Nov 13 19:27:20 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 19:27:20 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <0548803B-A685-420A-8C84-B1C365257775@m3w.org> References: , <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> Message-ID: <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> After Xcode 5.0.2 install, it works no more :) new source -> compiling Main.m3 clang: warning: argument unused during compilation: '-fPIC' Main.ms:1:9: error: unsupported directive '.stabs' .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 ^ -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote: > Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. > > Xcode I have installed is version 4.6.x, and cm3 works as always. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: > >> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 10:53, Jay K wrote: >> >>> Is that really needed? >>> >>> Doesn't this work? >>> >>> hello.c: >>> #include >>> int main() { return !!printf("hello\n"); } >>> >>> cc hello.c >>> >>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>> >>> - Jay >>> >>> >>> >>> >>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>> From: dragisha at m3w.org >>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>> CC: m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>> >>> SYSTEM_LIBS = { >>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>> ], >>> "LEX-YACC" : [ "-ll" ], >>> "FLEX-BISON" : [ "-lfl" ], >>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>> "TCP" : [ ] >>> % below: X11, ODBC, POSTGRES95, MOTIF >>> } >>> >>> My current AMD64_DARWIN configuration continues to work. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 11 Nov 2013, at 08:09, Jay K wrote: >>> >>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>> >>> Our system is very portable. >>> Consider helloWorld. And users of pthreads (or Win32 threads). >>> >>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>> >>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>> not be compatible across releases. We use them, sometimes, for user threads only. >>> >>> >>> If you find there is any problem, please let us know. >>> Anything you find is likely surmountable by a cross build. >>> >>> >>> - Jay >>> >>> ________________________________ >>> From: dragisha at m3w.org >>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>> >>> Anybody doing it? >>> >>> 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 dragisha at m3w.org Wed Nov 13 19:38:07 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 13 Nov 2013 19:38:07 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <5705AEB1-3476-44BD-BAE5-3EA14D34E6F4@gmail.com> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> <5705AEB1-3476-44BD-BAE5-3EA14D34E6F4@gmail.com> Message-ID: AFAIK, automake/autoconf is big pain? of C world. Whole build systems were devised/built, just to bypass autowhatever. I don?t see any reason to envy current C build systems. But, if you are looking for a model, then also look at Maven/Gradle of Java world. Convention over configuration paradigm (very accepted, and which looks very much like cm3 config + m3makefile ) is so far away from autowhatever as possible. -- Dragi?a Duri? dragisha at m3w.org On 13 Nov 2013, at 18:11, Jay wrote: > I do repeatedly wonder if we should be a thin layer over automake/autoconf/pkg-config/libtool. I look into them every so often. What bugs me, maybe not pkg-config, is that they seem slow and have to generate files. I want something that usually makes fast decisions for every run. Optionally recording them in a file for bootstrapping or overridability. Cm3 was ahead of its time, kinda, but those tools solve much of the same problem, with other people maintaining them and more "dynamism"/"manifestation" -- I can't think of the word, but throw together a random posixish platform and autoconf can probe it and piece it together. There is no need to record static platform definitions and local configuration details are inferred/deduced at build-time, and there is good cross build support. > -------------- 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 Thu Nov 14 04:04:34 2013 From: jay.krell at cornell.edu (Jay) Date: Wed, 13 Nov 2013 19:04:34 -0800 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> Message-ID: <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> Try the C backed? Edit the g/stabs flag in the config file? - Jay On Nov 13, 2013, at 10:27 AM, Dragi?a Duri? wrote: > After Xcode 5.0.2 install, it works no more :) > > new source -> compiling Main.m3 > clang: warning: argument unused during compilation: '-fPIC' > Main.ms:1:9: error: unsupported directive '.stabs' > .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 > ^ > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote: > >> Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. >> >> Xcode I have installed is version 4.6.x, and cm3 works as always. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: >> >>> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 13 Nov 2013, at 10:53, Jay K wrote: >>> >>>> Is that really needed? >>>> >>>> Doesn't this work? >>>> >>>> hello.c: >>>> #include >>>> int main() { return !!printf("hello\n"); } >>>> >>>> cc hello.c >>>> >>>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>>> >>>> - Jay >>>> >>>> >>>> >>>> >>>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>>> From: dragisha at m3w.org >>>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>>> CC: m3devel at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>>> >>>> SYSTEM_LIBS = { >>>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>>> ], >>>> "LEX-YACC" : [ "-ll" ], >>>> "FLEX-BISON" : [ "-lfl" ], >>>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>>> "TCP" : [ ] >>>> % below: X11, ODBC, POSTGRES95, MOTIF >>>> } >>>> >>>> My current AMD64_DARWIN configuration continues to work. >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On 11 Nov 2013, at 08:09, Jay K wrote: >>>> >>>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>>> >>>> Our system is very portable. >>>> Consider helloWorld. And users of pthreads (or Win32 threads). >>>> >>>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>>> >>>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>>> not be compatible across releases. We use them, sometimes, for user threads only. >>>> >>>> >>>> If you find there is any problem, please let us know. >>>> Anything you find is likely surmountable by a cross build. >>>> >>>> >>>> - Jay >>>> >>>> ________________________________ >>>> From: dragisha at m3w.org >>>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>>> To: m3devel at elegosoft.com >>>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>>> >>>> Anybody doing it? >>>> >>>> TIA, >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Nov 14 05:30:42 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 14 Nov 2013 04:30:42 +0000 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> References: , , , , <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org>, <0548803B-A685-420A-8C84-B1C365257775@m3w.org>, <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org>, <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> Message-ID: > AFAIK, automake/autoconf is big pain. of C world. > Whole build systems were devised/built, just to bypass autowhatever. Yes but my research suggests nobody has matched it, in particular for cross builds and in particular autoconf's ability to work with brand new systems, as long as they can be composed from preexisting variables -- which are probed for. But I don't like layers and layers of generated files, Bourne shell, and m4. C and C++ aren't so bad. They do have positive and negatives. Lack of a good module system is one of their negatives. And therefore build speed and incremental builds. cm3 resembles the ideal user interface of automake, but without generating files. Where I most want autoX/libtool/pkg-config is to determine how to run the C compiler/assembler/linker for given packages. I think pkg-config addresses one of our weakest point. The point in the config files that list "ODBC" or "POSTGRES" and such. That part has never seemed great, not even with cminstall. The problem with cminstall is that packages can be installed and uninstalled in any order. I kinda think we could support it within cm3, easily enough, in one of a few ways: meta-syntax in the config file to indicate we should run pkg-config --libs and add that to the link command or we could try it unconditionally or we could find the .pc files ourselves, conditionally or unconditionally. see http://linux.die.net/man/1/pkg-config Someday maybe we'll generate .h files to interfacing with Modula-3, and then we could create .pc files also.. libtool I also want, because we duplicate a lot of it. Better to punt to another project. Though the wide availability of gcc combined with convergence to not that many OSes makes it not too difficult to do it yourself, which is what we do... - Jay From: jay.krell at cornell.edu Date: Wed, 13 Nov 2013 19:04:34 -0800 To: dragisha at m3w.org CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks Try the C backed? Edit the g/stabs flag in the config file? - Jay On Nov 13, 2013, at 10:27 AM, Dragi?a Duri? wrote: After Xcode 5.0.2 install, it works no more :) new source -> compiling Main.m3clang: warning: argument unused during compilation: '-fPIC'Main.ms:1:9: error: unsupported directive '.stabs' .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 ^ --Dragi?a Duri?dragisha at m3w.org On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote:Site is https://developer.apple.com/downloads, package is named "Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013" and cm3 I've used since Snow Leopard, all through Lion. works again without previous hack. Xcode I have installed is version 4.6.x, and cm3 works as always. --Dragi?a Duri?dragisha at m3w.org On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote:There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. --Dragi?a Duri?dragisha at m3w.org On 13 Nov 2013, at 10:53, Jay K wrote:Is that really needed? Doesn't this work? hello.c: #include int main() { return !!printf("hello\n"); } cc hello.c If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) - Jay Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks From: dragisha at m3w.org Date: Wed, 13 Nov 2013 10:03:15 +0100 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common SYSTEM_LIBS = { "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" ], "LEX-YACC" : [ "-ll" ], "FLEX-BISON" : [ "-lfl" ], "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], "TCP" : [ ]% below: X11, ODBC, POSTGRES95, MOTIF} My current AMD64_DARWIN configuration continues to work.--Dragi?a Duri?dragisha at m3w.org On 11 Nov 2013, at 08:09, Jay K wrote:I'm still hanging back on a version that supports PowerPC/Rosetta. :) Our system is very portable. Consider helloWorld. And users of pthreads (or Win32 threads). And we hope/trust Apple and co. to maintain a certain level of compatibility. For example. the HPUX man pages decree that get/set/make/swapcontext may not be compatible across releases. We use them, sometimes, for user threads only. If you find there is any problem, please let us know. Anything you find is likely surmountable by a cross build. - Jay ________________________________ From: dragisha at m3w.org Date: Sun, 10 Nov 2013 18:48:22 +0100 To: m3devel at elegosoft.com Subject: [M3devel] AMD64_DARWIN with OSX Mavericks Anybody doing it? TIA, -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Nov 13 18:11:22 2013 From: jay.krell at cornell.edu (Jay) Date: Wed, 13 Nov 2013 09:11:22 -0800 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <0548803B-A685-420A-8C84-B1C365257775@m3w.org> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> Message-ID: <5705AEB1-3476-44BD-BAE5-3EA14D34E6F4@gmail.com> I do repeatedly wonder if we should be a thin layer over automake/autoconf/pkg-config/libtool. I look into them every so often. What bugs me, maybe not pkg-config, is that they seem slow and have to generate files. I want something that usually makes fast decisions for every run. Optionally recording them in a file for bootstrapping or overridability. Cm3 was ahead of its time, kinda, but those tools solve much of the same problem, with other people maintaining them and more "dynamism"/"manifestation" -- I can't think of the word, but throw together a random posixish platform and autoconf can probe it and piece it together. There is no need to record static platform definitions and local configuration details are inferred/deduced at build-time, and there is good cross build support. I've considered coding up similar in M3/Python/C/C++. I do put some runtime tests in the config files. I suppose pkg-config is what we miss most, and we could read its files in cm3??? I.e. this is the part of the config files that are the most site-specific, and worse, need to change as surrounding packages are installed/uninstalled? What autoconf is "really" for, we get very far with light dependencies ("the functions are assumed all present"), light ifdefing (m3core's preemptive suspend), and light "practicality" (I.e. picking out integer types). Automake we basically have our own. Libtool I believe works through static knowledge, like us. And pkg-config, we miss out on largely. - Jay On Nov 13, 2013, at 2:25 AM, Dragi?a Duri? wrote: > Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. > > Xcode I have installed is version 4.6.x, and cm3 works as always. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: > >> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 10:53, Jay K wrote: >> >>> Is that really needed? >>> >>> Doesn't this work? >>> >>> hello.c: >>> #include >>> int main() { return !!printf("hello\n"); } >>> >>> cc hello.c >>> >>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>> >>> - Jay >>> >>> >>> >>> >>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>> From: dragisha at m3w.org >>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>> CC: m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>> >>> SYSTEM_LIBS = { >>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>> ], >>> "LEX-YACC" : [ "-ll" ], >>> "FLEX-BISON" : [ "-lfl" ], >>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>> "TCP" : [ ] >>> % below: X11, ODBC, POSTGRES95, MOTIF >>> } >>> >>> My current AMD64_DARWIN configuration continues to work. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 11 Nov 2013, at 08:09, Jay K wrote: >>> >>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>> >>> Our system is very portable. >>> Consider helloWorld. And users of pthreads (or Win32 threads). >>> >>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>> >>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>> not be compatible across releases. We use them, sometimes, for user threads only. >>> >>> >>> If you find there is any problem, please let us know. >>> Anything you find is likely surmountable by a cross build. >>> >>> >>> - Jay >>> >>> ________________________________ >>> From: dragisha at m3w.org >>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>> >>> Anybody doing it? >>> >>> TIA, >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Nov 14 12:14:34 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 14 Nov 2013 12:14:34 +0100 Subject: [M3devel] AMD64_DARWIN with OSX Mavericks In-Reply-To: <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> References: <50FBE2DA-EC4C-4F2E-A7C6-9CBBB2FAB88D@m3w.org> <0548803B-A685-420A-8C84-B1C365257775@m3w.org> <3695EA8D-594C-4649-B11F-9589D47FCBC2@m3w.org> <2F7C8AD5-DEF3-47FE-82ED-778AD53E56D2@gmail.com> Message-ID: <7F9E43C8-CF1B-422C-88B9-14B576CEDC76@m3w.org> I will, time permitting :). Right now, working recipe is - Xcode 4.6.3 downgrade, alreay mentioned command line utils installed. It works like it always had. -- Dragi?a Duri? dragisha at m3w.org On 14 Nov 2013, at 04:04, Jay wrote: > Try the C backed? > > > Edit the g/stabs flag in the config file? > > > - Jay > > On Nov 13, 2013, at 10:27 AM, Dragi?a Duri? wrote: > >> After Xcode 5.0.2 install, it works no more :) >> >> new source -> compiling Main.m3 >> clang: warning: argument unused during compilation: '-fPIC' >> Main.ms:1:9: error: unsupported directive '.stabs' >> .stabs "/Users/dragisha/m3/eratosthenes/AMD64_DARWIN/",100,0,0,Ltext0 >> ^ >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On 13 Nov 2013, at 11:25, Dragi?a Duri? wrote: >> >>> Site is https://developer.apple.com/downloads, package is named ?Command Line Tools (OS X Mavericks) for Xcode - Late October Oct 22, 2013? and cm3 I?ve used since Snow Leopard, all through Lion? works again without previous hack. >>> >>> Xcode I have installed is version 4.6.x, and cm3 works as always. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 13 Nov 2013, at 11:08, Dragi?a Duri? wrote: >>> >>>> There is probably easier solution, I am installing command line devel tools right now and then I will try to simplify this. >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On 13 Nov 2013, at 10:53, Jay K wrote: >>>> >>>>> Is that really needed? >>>>> >>>>> Doesn't this work? >>>>> >>>>> hello.c: >>>>> #include >>>>> int main() { return !!printf("hello\n"); } >>>>> >>>>> cc hello.c >>>>> >>>>> If that works, gradually expand it to reference more symbols, i.e. pthreads, the mach suspend/resume/getcontext functions (see m3-libs/m3core/src/thread/PTHREAD/ThreadApple.c or such) >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> >>>>> Subject: Re: [M3devel] AMD64_DARWIN with OSX Mavericks >>>>> From: dragisha at m3w.org >>>>> Date: Wed, 13 Nov 2013 10:03:15 +0100 >>>>> CC: m3devel at elegosoft.com >>>>> To: jay.krell at cornell.edu >>>>> >>>>> I will bootstrap new version(s) as per your instructions ASAP, but until then, this is a change I made to config/Darwin.common >>>>> >>>>> SYSTEM_LIBS = { >>>>> "LIBC" : [ "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib", >>>>> "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/system" >>>>> ], >>>>> "LEX-YACC" : [ "-ll" ], >>>>> "FLEX-BISON" : [ "-lfl" ], >>>>> "OPENGL" : [ "-Wl,-dylib_file," & LIBGL_DYLIB & ":" & LIBGL_DYLIB, >>>>> "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ], >>>>> "TCP" : [ ] >>>>> % below: X11, ODBC, POSTGRES95, MOTIF >>>>> } >>>>> >>>>> My current AMD64_DARWIN configuration continues to work. >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On 11 Nov 2013, at 08:09, Jay K wrote: >>>>> >>>>> I'm still hanging back on a version that supports PowerPC/Rosetta. :) >>>>> >>>>> Our system is very portable. >>>>> Consider helloWorld. And users of pthreads (or Win32 threads). >>>>> >>>>> And we hope/trust Apple and co. to maintain a certain level of compatibility. >>>>> >>>>> For example. the HPUX man pages decree that get/set/make/swapcontext may >>>>> not be compatible across releases. We use them, sometimes, for user threads only. >>>>> >>>>> >>>>> If you find there is any problem, please let us know. >>>>> Anything you find is likely surmountable by a cross build. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> ________________________________ >>>>> From: dragisha at m3w.org >>>>> Date: Sun, 10 Nov 2013 18:48:22 +0100 >>>>> To: m3devel at elegosoft.com >>>>> Subject: [M3devel] AMD64_DARWIN with OSX Mavericks >>>>> >>>>> Anybody doing it? >>>>> >>>>> 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 rcolebur at SCIRES.COM Sat Nov 16 17:38:08 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sat, 16 Nov 2013 16:38:08 +0000 Subject: [M3devel] pickle2 compilation error Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF924B950A@ATLEX04-SRV.SCIRES.LOCAL> I'm getting a compilation error for pickles v2 on Windows XP: unable to open file for reading: ..\src\pickle\ver2\PklFpMap.i3: ErrorCode=2: The system cannot find the file specified. I've updated from head branch, so perhaps this is due to a recent change. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Nov 16 19:17:23 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 16 Nov 2013 12:17:23 -0600 Subject: [M3devel] pickle2 compilation error In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF924B950A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924B950A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <5287B6B3.2080307@lcwb.coop> Oops, sorry, I apparently didn't get PklFpMap.[im]3 added in the head. They should be there now. On 11/16/2013 10:38 AM, Coleburn, Randy wrote: > I?m getting a compilation error for pickles v2 on Windows XP: > > unable to open file for reading: ..\src\pickle\ver2\PklFpMap.i3: ErrorCode=2: The system cannot find the file specified. > > I?ve updated from head branch, so perhaps this is due to a recent change. > > --Randy > From dragisha at m3w.org Sun Nov 17 20:49:53 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 17 Nov 2013 20:49:53 +0100 Subject: [M3devel] GC deadlock Message-ID: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack #0 0x00130416 in __kernel_vsyscall () #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 another: #0 0x00130416 in __kernel_vsyscall () #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 and others: #0 0x00130416 in __kernel_vsyscall () #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) at ../src/thread/PTHREAD/ThreadPThread.m3:1205 #4 #5 0x00130416 in __kernel_vsyscall () #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? -- 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 dragisha at m3w.org Sun Nov 17 22:45:33 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 17 Nov 2013 22:45:33 +0100 Subject: [M3devel] GC deadlock In-Reply-To: References: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> Message-ID: <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> Good. I will try same cases with more recent one ASAP. -- Dragi?a Duri? dragisha at m3w.org On 17 Nov 2013, at 21:40, Antony Hosking wrote: > I know 5.8.6 had problems. > > On Nov 17, 2013, at 2:49 PM, Dragi?a Duri? wrote: > >> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack >> >> #0 0x00130416 in __kernel_vsyscall () >> #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 >> #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 >> #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 >> #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 >> #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 >> >> another: >> #0 0x00130416 in __kernel_vsyscall () >> #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 >> #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 >> #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 >> #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 >> #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 >> #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 >> #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >> #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >> >> and others: >> #0 0x00130416 in __kernel_vsyscall () >> #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 >> #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 >> #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) >> at ../src/thread/PTHREAD/ThreadPThread.m3:1205 >> #4 >> #5 0x00130416 in __kernel_vsyscall () >> #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >> >> Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? >> >> -- >> 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 rcolebur at SCIRES.COM Wed Nov 20 00:47:28 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 19 Nov 2013 23:47:28 +0000 Subject: [M3devel] compiler build problem Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF924CBE81@ATLEX04-SRV.SCIRES.LOCAL> I'm running into a new problem. I've updated from the HEAD branch and rebuilding everything on Windows XP again. Building of the package group "front" in stage 1 goes well and I install the new cm3.exe. Then, when I try to build in stage 2 using the new cm3.exe, I get the following error when invoking cm3.exe: *** *** runtime error: *** A compile-time type is missing. *** file "..\src\Utils.m3" *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12fea0 0x6d6c76 Fail + 0x79 in ..\src\runtime\common\RTType.m3 0x12fecc 0x6d5ea3 ResolveTypeLink + 0x50 in ..\src\runtime\common\RTType.m3 0x12fef8 0x6c242b ResolveTypeLinks + 0x57 in ..\src\runtime\common\RTLinker.m3 0x12ff2c 0x6c21ab FixTypes + 0x107 in ..\src\runtime\common\RTLinker.m3 0x12ff40 0x6c1c9d AddUnitI + 0xe2 in ..\src\runtime\common\RTLinker.m3 0x12ff60 0x6c1d56 AddUnit + 0x9c in ..\src\runtime\common\RTLinker.m3 0x12ff7c 0x401038 0x12ffc0 0x70d738 RTTypeMap_M3 + 0x4d6 in ..\src\runtime\common\RTTypeMap.m3 ......... ......... ... more frames ... Any ideas on what is wrong? Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Nov 20 03:13:07 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 Nov 2013 20:13:07 -0600 Subject: [M3devel] compiler build problem In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF924CBE81@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF924CBE81@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <528C1AB3.3010009@lcwb.coop> I don't know for sure what is going on in your case, but I have several times found this error disappearing after exhaustive cm3 -realclean or do-cm3-*.sh realclean, followed by recompiling everything from scratch. I think I recall one time even vetting this and finding some package that was present in different versions in the link closure, or something similar. The declaration-granularity automatic recompilation in the compiler only pretends to work within a package. Inter-package, you are on your own to make sure everything is compiled in the right order and consistently. Sorry, I don't have any help on what order that is. But I think the order of packages in pkginfo.txt is, at least mostly, right, if you use the do-cm3-*.sh scripts. On 11/19/2013 05:47 PM, Coleburn, Randy wrote: > I?m running into a new problem. > > I?ve updated from the HEAD branch and rebuilding everything on Windows XP again. > > Building of the package group ?front? in stage 1 goes well and I install the new cm3.exe. > > Then, when I try to build in stage 2 using the new cm3.exe, I get the following error when invoking cm3.exe: > > *** > > *** runtime error: > > *** A compile-time type is missing. > > *** file "..\src\Utils.m3" > > *** > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12fea0 0x6d6c76 Fail + 0x79 in ..\src\runtime\common\RTType.m3 > > 0x12fecc 0x6d5ea3 ResolveTypeLink + 0x50 in ..\src\runtime\common\RTType.m3 > > 0x12fef8 0x6c242b ResolveTypeLinks + 0x57 in ..\src\runtime\common\RTLinker.m3 > > 0x12ff2c 0x6c21ab FixTypes + 0x107 in ..\src\runtime\common\RTLinker.m3 > > 0x12ff40 0x6c1c9d AddUnitI + 0xe2 in ..\src\runtime\common\RTLinker.m3 > > 0x12ff60 0x6c1d56 AddUnit + 0x9c in ..\src\runtime\common\RTLinker.m3 > > 0x12ff7c 0x401038 > > 0x12ffc0 0x70d738 RTTypeMap_M3 + 0x4d6 in ..\src\runtime\common\RTTypeMap.m3 > > ......... ......... ... more frames ... > > Any ideas on what is wrong? > > Thanks, > > Randy Coleburn > From rodney_bates at lcwb.coop Fri Nov 22 16:44:28 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 Nov 2013 09:44:28 -0600 Subject: [M3devel] How to compile m3cc with -O0 Message-ID: <528F7BDC.8020005@lcwb.coop> Before I track this down laboriously, does anybody know right off hand where to put the optimization flag -O0 for compiling m3cc? There are dozens of CFLAGS and similar in quake variables, make variables, environment variables, etc., getting passed all over the place. Naive replacements of "-O2" by "-O0" so far aren't getting through to the compilation. From dragisha at m3w.org Fri Nov 22 23:31:28 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 22 Nov 2013 23:31:28 +0100 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? Message-ID: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org> + ./scripts/do-pkg.sh buildship m3core libm3 tcp /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc === package m3-libs/m3core === +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling WinBase.i3 "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) -- 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 dragisha at m3w.org Fri Nov 22 23:55:23 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 22 Nov 2013 23:55:23 +0100 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org> References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org> Message-ID: <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> Yes, it was in a memo? Sorry for disruption :). On 22 Nov 2013, at 23:31, Dragi?a Duri? wrote: > + ./scripts/do-pkg.sh buildship m3core libm3 tcp > /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc > === package m3-libs/m3core === > +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling WinBase.i3 > "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) > > -- > 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 Nov 23 12:17:47 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 23 Nov 2013 11:17:47 +0000 Subject: [M3devel] How to compile m3cc with -O0 In-Reply-To: <528F7BDC.8020005@lcwb.coop> References: <528F7BDC.8020005@lcwb.coop> Message-ID: Yes? But anyone, na?ve replacement should work, as long as it a little extra thorough. :) Look in m3cc/gcc-*/Makefile*.in m3cc/gcc-*/gcc/Makefile*.in You could also do in in src/m3makefile via CFLAGS=-O0 or such. There is a reason it is tricky though, and that is because of bootstrapping. And I gather they really like libgcc to be optimized, so give it separate flags to avoid being hit by the other. We don't use libgcc so no matter. Why? Because it takes too long to build optimized? Yes, that is annoying. Because it hard to debug? Yes, that is lame. The C compilers should do better there. If you are focusing on debugging very particular code, you can also often sprinkle in volatile to defeat the optimizer. or "make foo.o", copy/paste what it runs, run it yourself edited, and then make to continue. Also a bit annoying. - Jay > Date: Fri, 22 Nov 2013 09:44:28 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] How to compile m3cc with -O0 > > Before I track this down laboriously, does anybody know right off hand where > to put the optimization flag -O0 for compiling m3cc? There are dozens of > CFLAGS and similar in quake variables, make variables, environment variables, etc., > getting passed all over the place. Naive replacements of "-O2" by "-O0" so > far aren't getting through to the compilation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 23 12:13:43 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 23 Nov 2013 11:13:43 +0000 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org>, <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> Message-ID: This is deliberate, and slightly useful, and the warnings shouldn't occur in the head, for several years now. Please upgrade more frequently. In particular: - It is useful because "much" of the interfaces are describing types, and types aren't just for function parameters, for functions that aren't available, but they are used as part of files, and you can, hypothetically, use them in your own functions (heck, you can write a Win32-on-Posix compatibility layer and provide the functions..). In particular, mklib uses these types and is fairly portable. It might have endian/alignment problems though, esp. endian. I do have a plan to get rid of mklib though...i was slow to realize it because mklib exports too much and I wanted a replacement wthout that flaw, but just matching it is adequate. The frontend/backends shall output the .def files instead of mklib. And then the usual lib/ar/link can/should make the libraries. If anyone wants to use LTCG on NT with the C backend, this is the way (or put everything in one source file via the backend, not a bad idea).. - In the past 20 years or so, there is only one widely used platform that made the mistake of having multiple calling conventions and that is NT/x86. Not NT in general, but NT/x86 specifically. I expect nobody will make this mistake again. I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake. On NT/x86, the calling convention does not bifurcate the entire target and force building everything multiple times, because you can sprinkle it around and each "type" can call each "type". This is good and bad. The other OS/processor combinations with multiple calling conventions define it as multiple ABIs with I believe no offical interop (except at the kernel level, for some of them). Therefore, callling conventions can be safely ignored on all platforms except NT/x86. Nobody will have any names to use here, overlapping the NT/x86 names or not. If the day comes where I am wrong and some target has multiple conventions, we should change the pragma to accept multiple. If the names overlap with NT/x86, we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3 and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost the same, but for one little difference that could be handled another way, they go duplicated. That pattern bugs me. - Jay From: dragisha at m3w.org Date: Fri, 22 Nov 2013 23:55:23 +0100 To: m3devel at elegosoft.com Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase? Yes, it was in a memo. Sorry for disruption :). On 22 Nov 2013, at 23:31, Dragi?a Duri? wrote:+ ./scripts/do-pkg.sh buildship m3core libm3 tcp/root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc=== package m3-libs/m3core === +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++--- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling WinBase.i3"../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI)"../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI)"../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Nov 23 18:06:00 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 Nov 2013 18:06:00 +0100 Subject: [M3devel] GC deadlock... crash this time In-Reply-To: <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> References: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> Message-ID: Ok.. Now I am at HEAD, literraly: *** *** runtime error: *** An array subscript was out of range. *** file "../src/runtime/common/RTCollector.m3", line 418 *** #32 0x003dbe44 in _m3_fault (M3_AcxOUs_arg=) from /usr/local/cm3/bin/../lib/libm3core.so.5 #33 0x003d3807 in RTCollector__Move (M3_BVudqN_self=, M3_AJWxb1_cp=) at ../src/runtime/common/RTCollector.m3:418 #34 0x003cfb86 in RTHeapMap__Walk (M3_AJWxb1_x=, M3_AJWxb1_pc=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:202 #35 0x003cf471 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:62 #36 0x003cf448 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:57 #37 0x003cf3ee in RTHeapMap__WalkRef (M3_Edk2y1_h=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:47 #38 0x003d58b6 in RTCollector__CleanBetween (M3_Edk2y1_h=, M3_Edk2y1_he=, M3_AicXUJ_clean=) at ../src/runtime/common/RTCollector.m3:1091 #39 0x003d56d7 in RTCollector__CleanPage (M3_BtgLOI_page=) at ../src/runtime/common/RTCollector.m3:1064 #40 0x003d4ed2 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 #41 0x003d476a in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 #42 0x003d444a in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 #43 0x003cd245 in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=, M3_Cwb5VA_dataAlignment=, M3_B1GO5V_thread=) at ../src/runtime/common/RTAllocator.m3:367 #44 0x003cc3cc in RTAllocator__GetTracedRef (M3_Eic7CK_def=) at ../src/runtime/common/RTAllocator.m3:202 #45 0x003cc027 in RTHooks__AllocateTracedRef (M3_AJWxb1_defn=) at ../src/runtime/common/RTAllocator.m3:115 #46 0x002fcb05 in IntRefTbl__Put (M3_C1DLtw_tbl=, M3_EN2A1V_key=, M3_EKuYlT_val=) at ../LINUXLIBC6/IntRefTbl.m3 => ../src/table/Table.mg:126 On 17 Nov 2013, at 22:45, Dragi?a Duri? wrote: > Good. I will try same cases with more recent one ASAP. > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 17 Nov 2013, at 21:40, Antony Hosking wrote: > >> I know 5.8.6 had problems. >> >> On Nov 17, 2013, at 2:49 PM, Dragi?a Duri? wrote: >> >>> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack >>> >>> #0 0x00130416 in __kernel_vsyscall () >>> #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 >>> #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 >>> #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 >>> #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 >>> #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 >>> >>> another: >>> #0 0x00130416 in __kernel_vsyscall () >>> #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 >>> #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 >>> #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 >>> #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 >>> #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 >>> #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 >>> #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >>> #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >>> >>> and others: >>> #0 0x00130416 in __kernel_vsyscall () >>> #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 >>> #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 >>> #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:1205 >>> #4 >>> #5 0x00130416 in __kernel_vsyscall () >>> #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >>> >>> Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? >>> >>> -- >>> 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 Sat Nov 23 21:33:51 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 23 Nov 2013 14:33:51 -0600 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org>, <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> Message-ID: <5291112F.5040102@lcwb.coop> On 11/23/2013 05:13 AM, Jay K wrote: > This is deliberate, and slightly useful, and the warnings shouldn't occur in the head, > for several years now. Please upgrade more frequently. > > I feel very strongly that the latest release compiler should always build the head. We have all too few Modula-3 users anyway. If we don''t have this ability, then we become an exclusive club with unreasonable barriers to outsiders. There is hardly a better way to keep the community shrinking. I know it can be a pain to maintain compatibility, but we really must do it. Until we get a new release with a compiler that won't choke on WINAPI, we need to keep different versions of the source. Actually, I thought I had removed all occurrences of this problem a few months ago. How did I miss this one? > In particular: > > > - It is useful because "much" of the interfaces are describing types, > and types aren't just for function parameters, for functions that > aren't available, but they are used as part of files, and you can, > hypothetically, use them in your own functions (heck, you can > write a Win32-on-Posix compatibility layer and provide the functions..). > > > In particular, mklib uses these types and is fairly portable. > It might have endian/alignment problems though, esp. endian. > > > I do have a plan to get rid of mklib though...i was slow to realize it > because mklib exports too much and I wanted a replacement wthout that flaw, > but just matching it is adequate. The frontend/backends shall output > the .def files instead of mklib. And then the usual lib/ar/link can/should > make the libraries. If anyone wants to use LTCG on NT with the C backend, > this is the way (or put everything in one source file via the backend, not a bad idea).. > > > - In the past 20 years or so, there is only one widely used > platform that made the mistake of having multiple calling conventions > and that is NT/x86. Not NT in general, but NT/x86 specifically. > I expect nobody will make this mistake again. > I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake. > On NT/x86, the calling convention does not bifurcate the entire target > and force building everything multiple times, because you can sprinkle it around and > each "type" can call each "type". This is good and bad. > The other OS/processor combinations with multiple calling conventions > define it as multiple ABIs with I believe no offical interop (except at the > kernel level, for some of them). > > > Therefore, callling conventions can be safely ignored on all platforms except NT/x86. > Nobody will have any names to use here, overlapping the NT/x86 names or not. > If the day comes where I am wrong and some target has multiple conventions, > we should change the pragma to accept multiple. If the names overlap with NT/x86, > we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3 > and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost > the same, but for one little difference that could be handled another way, they go duplicated. > That pattern bugs me. > > > - Jay > > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > From: dragisha at m3w.org > Date: Fri, 22 Nov 2013 23:55:23 +0100 > To: m3devel at elegosoft.com > Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase? > > Yes, it was in a memo. Sorry for disruption :). > > On 22 Nov 2013, at 23:31, Dragi?a Duri? > wrote: > > + ./scripts/do-pkg.sh buildship m3core libm3 tcp > /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc > === package m3-libs/m3core === > +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling WinBase.i3 > "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) > "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) > "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > From dragisha at m3w.org Sat Nov 23 23:30:06 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 Nov 2013 23:30:06 +0100 Subject: [M3devel] GC deadlock... crash this time In-Reply-To: <9E8E3A08-047F-45D2-BD1E-C473DC2E6E54@purdue.edu> References: <1163BA7F-067F-4414-B7BF-21A825CEFF45@m3w.org> <9ED1E702-2D0A-493B-94A3-0CA6925C69C0@m3w.org> <9E8E3A08-047F-45D2-BD1E-C473DC2E6E54@purdue.edu> Message-ID: <6EE7FE7E-A8F5-496C-8033-F761DEF87A59@m3w.org> There is UNSAFE code, few LOOPHOLEs, nothing much, and I am not loopholing anything untraced over. And yes, this is x86_32, some old dual Xeon machine. If it happens again, I will definitely try @M3paranoidgc. While here.. What are prospects of Atomic ops? TIA, dd On 23 Nov 2013, at 20:33, Antony Hosking wrote: > These issues are best diagnosed by running with @M3paranoidgc. That will perform extensive checking of heap integrity after each GC cycle. It would appear that some sort of heap corruption has occurred. Does your application have much unsafe code? Unfortunately, UNSAFE code can arbitrarily confuse the GC. > > Also, what platform is this on? x86_64 or x86_32? Looks like LINUXLIBC6 which I believe is still x86_32. > > On Nov 23, 2013, at 12:06 PM, Dragi?a Duri? wrote: > >> Ok.. Now I am at HEAD, literraly: >> >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "../src/runtime/common/RTCollector.m3", line 418 >> *** >> >> #32 0x003dbe44 in _m3_fault (M3_AcxOUs_arg=) from /usr/local/cm3/bin/../lib/libm3core.so.5 >> #33 0x003d3807 in RTCollector__Move (M3_BVudqN_self=, M3_AJWxb1_cp=) >> at ../src/runtime/common/RTCollector.m3:418 >> #34 0x003cfb86 in RTHeapMap__Walk (M3_AJWxb1_x=, M3_AJWxb1_pc=, M3_Deq2V9_v=) >> at ../src/runtime/common/RTHeapMap.m3:202 >> #35 0x003cf471 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) >> at ../src/runtime/common/RTHeapMap.m3:62 >> #36 0x003cf448 in RTHeapMap__DoWalkRef (M3_Eic7CK_t=, M3_AJWxb1_a=, M3_Deq2V9_v=) >> at ../src/runtime/common/RTHeapMap.m3:57 >> #37 0x003cf3ee in RTHeapMap__WalkRef (M3_Edk2y1_h=, M3_Deq2V9_v=) at ../src/runtime/common/RTHeapMap.m3:47 >> #38 0x003d58b6 in RTCollector__CleanBetween (M3_Edk2y1_h=, M3_Edk2y1_he=, >> M3_AicXUJ_clean=) at ../src/runtime/common/RTCollector.m3:1091 >> #39 0x003d56d7 in RTCollector__CleanPage (M3_BtgLOI_page=) at ../src/runtime/common/RTCollector.m3:1064 >> #40 0x003d4ed2 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:885 >> #41 0x003d476a in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >> #42 0x003d444a in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >> #43 0x003cd245 in RTAllocator__AllocTraced (M3_Cwb5VA_dataSize=, M3_Cwb5VA_dataAlignment=, >> M3_B1GO5V_thread=) at ../src/runtime/common/RTAllocator.m3:367 >> #44 0x003cc3cc in RTAllocator__GetTracedRef (M3_Eic7CK_def=) at ../src/runtime/common/RTAllocator.m3:202 >> #45 0x003cc027 in RTHooks__AllocateTracedRef (M3_AJWxb1_defn=) at ../src/runtime/common/RTAllocator.m3:115 >> #46 0x002fcb05 in IntRefTbl__Put (M3_C1DLtw_tbl=, M3_EN2A1V_key=, M3_EKuYlT_val=) >> at ../LINUXLIBC6/IntRefTbl.m3 => ../src/table/Table.mg:126 >> >> On 17 Nov 2013, at 22:45, Dragi?a Duri? wrote: >> >>> Good. I will try same cases with more recent one ASAP. >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On 17 Nov 2013, at 21:40, Antony Hosking wrote: >>> >>>> I know 5.8.6 had problems. >>>> >>>> On Nov 17, 2013, at 2:49 PM, Dragi?a Duri? wrote: >>>> >>>>> This is 5.8.6 codebase, so it?s maybe solved in later codebase? I have few threads, one has this on top of stack >>>>> >>>>> #0 0x00130416 in __kernel_vsyscall () >>>>> #1 0x00ca6019 in __lll_lock_wait () from /lib/libpthread.so.0 >>>>> #2 0x00ca1430 in _L_lock_677 () from /lib/libpthread.so.0 >>>>> #3 0x00ca1301 in pthread_mutex_lock () from /lib/libpthread.so.0 >>>>> #4 0x00428aa1 in ThreadPThread__pthread_mutex_lock (m=0xc6e430) at ../src/thread/PTHREAD/ThreadPThreadC.c:557 >>>>> #5 0x00427d67 in RTOS__LockHeap () at ../src/thread/PTHREAD/ThreadPThread.m3:1434 >>>>> >>>>> another: >>>>> #0 0x00130416 in __kernel_vsyscall () >>>>> #1 0x00ca6c66 in nanosleep () from /lib/libpthread.so.0 >>>>> #2 0x00428941 in ThreadPThread__Nanosleep (req=0xb6c30d88, rem=0xb6c30d90) at ../src/thread/PTHREAD/ThreadPThreadC.c:500 >>>>> #3 0x00424f02 in ThreadPThread__CommonSleep () at ../src/thread/c:551 >>>>> #4 0x00426cc9 in ThreadPThread__StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1086 >>>>> #5 0x004260c3 in RTThread__SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:812 >>>>> #6 0x00408cd6 in RTCollector__CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:746 >>>>> #7 0x00408c95 in RTCollector__CollectSome () at ../src/runtime/common/RTCollector.m3:720 >>>>> #8 0x00408748 in RTHeapRep__CollectEnough () at ../src/runtime/common/RTCollector.m3:654 >>>>> >>>>> and others: >>>>> #0 0x00130416 in __kernel_vsyscall () >>>>> #1 0x00cdeede in sigsuspend () from /lib/libc.so.6 >>>>> #2 0x0042836e in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 >>>>> #3 0x004271f6 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=, M3_AJWxb1_info=, M3_AJWxb1_context=) >>>>> at ../src/thread/PTHREAD/ThreadPThread.m3:1205 >>>>> #4 >>>>> #5 0x00130416 in __kernel_vsyscall () >>>>> #6 0x00ca3664 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >>>>> >>>>> Am I reading this correctly? Thread waiting for lock ?refuses? to be suspended? >>>>> >>>>> -- >>>>> 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 dragisha at m3w.org Sat Nov 23 23:32:39 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 23 Nov 2013 23:32:39 +0100 Subject: [M3devel] missed the memo? LINUXLIBC6 building WinBase? In-Reply-To: <5291112F.5040102@lcwb.coop> References: <8FCAA925-B00F-4721-9590-BA7F4A8000C1@m3w.org>, <92946731-26E6-4336-8746-33C89C1892AE@m3w.org> <5291112F.5040102@lcwb.coop> Message-ID: <977737CA-F2B7-4940-860D-5B56D64B658A@m3w.org> I think some interim release, of ?get on with Modula-3 fast? kind, is better idea than to slow progress. And I don?t dislike this current state. As for sommunity shrinking? Maybe some web facelift would be good idea? Anybody willing? dd On 23 Nov 2013, at 21:33, Rodney M. Bates wrote: > > > On 11/23/2013 05:13 AM, Jay K wrote: >> This is deliberate, and slightly useful, and the warnings shouldn't occur in the head, >> for several years now. Please upgrade more frequently. >> >> > > I feel very strongly that the latest release compiler should always build the head. > We have all too few Modula-3 users anyway. If we don''t have this ability, > then we become an exclusive club with unreasonable barriers to outsiders. > There is hardly a better way to keep the community shrinking. > > I know it can be a pain to maintain compatibility, but we really must do it. > Until we get a new release with a compiler that won't choke on WINAPI, we > need to keep different versions of the source. > > Actually, I thought I had removed all occurrences of this problem a few > months ago. How did I miss this one? > > >> In particular: >> >> >> - It is useful because "much" of the interfaces are describing types, >> and types aren't just for function parameters, for functions that >> aren't available, but they are used as part of files, and you can, >> hypothetically, use them in your own functions (heck, you can >> write a Win32-on-Posix compatibility layer and provide the functions..). >> >> >> In particular, mklib uses these types and is fairly portable. >> It might have endian/alignment problems though, esp. endian. >> >> >> I do have a plan to get rid of mklib though...i was slow to realize it >> because mklib exports too much and I wanted a replacement wthout that flaw, >> but just matching it is adequate. The frontend/backends shall output >> the .def files instead of mklib. And then the usual lib/ar/link can/should >> make the libraries. If anyone wants to use LTCG on NT with the C backend, >> this is the way (or put everything in one source file via the backend, not a bad idea).. >> >> >> - In the past 20 years or so, there is only one widely used >> platform that made the mistake of having multiple calling conventions >> and that is NT/x86. Not NT in general, but NT/x86 specifically. >> I expect nobody will make this mistake again. >> I'm not sure MIPSo32/MIPSn32 or ARM-mess count as the same mistake. >> On NT/x86, the calling convention does not bifurcate the entire target >> and force building everything multiple times, because you can sprinkle it around and >> each "type" can call each "type". This is good and bad. >> The other OS/processor combinations with multiple calling conventions >> define it as multiple ABIs with I believe no offical interop (except at the >> kernel level, for some of them). >> >> >> Therefore, callling conventions can be safely ignored on all platforms except NT/x86. >> Nobody will have any names to use here, overlapping the NT/x86 names or not. >> If the day comes where I am wrong and some target has multiple conventions, >> we should change the pragma to accept multiple. If the names overlap with NT/x86, >> we would put platform qualifiers on them. Never again should we have the Win32 SQL.i3 >> and Posix SQL.i3 that are the same, except for calling convention. What a waste -- almost >> the same, but for one little difference that could be handled another way, they go duplicated. >> That pattern bugs me. >> >> >> - Jay >> >> >> >> >> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > -- >> From: dragisha at m3w.org >> Date: Fri, 22 Nov 2013 23:55:23 +0100 >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] missed the memo? LINUXLIBC6 building WinBase? >> >> Yes, it was in a memo. Sorry for disruption :). >> >> On 22 Nov 2013, at 23:31, Dragi?a Duri? > wrote: >> >> + ./scripts/do-pkg.sh buildship m3core libm3 tcp >> /root/rpmbuild/BUILD/cm3/scripts/pkgmap.sh -c cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' && cm3 -ship -DROOT='/root/rpmbuild/BUILD/cm3' m3core libm3 tc >> === package m3-libs/m3core === >> +++ cm3 -build -DROOT='/root/rpmbuild/BUILD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/root/rpmbuild/BUILD/cm3' +++ >> --- building in LINUXLIBC6 --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling WinBase.i3 >> "../src/win32/WinDef.i3", line 131: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinDef.i3", line 132: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinDef.i3", line 133: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinBase.i3", line 198: warning: unrecognized pragma (ignored) (WINAPI) >> "../src/win32/WinBase.i3", line 918: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 921: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 924: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 927: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 930: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 933: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 943: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 949: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 952: unsupported language or calling convention (WINAPI) >> "../src/win32/WinBase.i3", line 955: unsupported language or calling convention (WINAPI) >> >> -- >> 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 wagner at elegosoft.com Thu Nov 28 07:47:55 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 Nov 2013 07:47:55 +0100 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 Message-ID: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> I know that there have been controverse discussions about the right way to do unicode support. Is there any way to help Elmar Stellnberger with a quick solution? Olaf Begin forwarded message: Date: Wed, 27 Nov 2013 20:13:54 +0100 From: Elmar Stellnberger To: m3-support at elego.de Subject: UTF-16: Greek alphabet with CM3 Dear Supporters of CM3, Elegosoft Wanting to make use of CM3s new UTF-16 feature I have tried to use greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is beta in the unicode table. However I soon had to notice that outputing widechars is not supported by Trestle which still seems to be based on X11R4. Some analysis of the problem has shown that TextVBT calls VBT.PaintText which does however use the CHAR type internally rather than Widechar calling PaintSub to output text instead of the X11R6 function XDrawString16. Is it true that you plan real unicode support for CM3 or is there any way to hack the trestle toolkit into allowing X11R6 functions? If yes or no how could I convert current X11R6 includes for being used with Modula-3? Nonetheless I would really welcome true native utf-16 support (as nowadays given by the iso10646-1 X core fonts like also 'fixed') because that would be the only way to make use of utf-16 for Windows ports. Otherwise I will have to consider whether I can use Modula-3 at all for my current project which is about converting the automaton simulator www.elstel.org/coan from Object Pascal into a currently supported language and publishing it as open source. Thanks a lot for your effort! Yours, Elmar Stellnberger -- 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 dabenavidesd at yahoo.es Fri Nov 29 02:41:18 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> Message-ID: <1385689278.60242.YahooMailNeo@web171905.mail.ir2.yahoo.com> Hi all: I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? http://www.ascii-codes.com/cp869.html Thanks in advance PD: I? will have time In January, if you want I can help port your app (if it doens't have too much goto's) El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner escribi?: I know that there have been controverse discussions about the right way to do unicode support. Is there any way to help Elmar Stellnberger with a quick solution? Olaf Begin forwarded message: Date: Wed, 27 Nov 2013 20:13:54 +0100 From: Elmar Stellnberger To: m3-support at elego.de Subject: UTF-16: Greek alphabet with CM3 Dear Supporters of CM3, Elegosoft ? Wanting to make use of CM3s new UTF-16 feature I have tried to use greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is beta in the unicode table. However I soon had to notice that outputing widechars is not supported by Trestle which still seems to be based on X11R4. Some analysis of the problem has shown that TextVBT calls VBT.PaintText which does however use the CHAR type internally rather than Widechar calling PaintSub to output text instead of the X11R6 function XDrawString16. Is it true that you plan real unicode support for CM3 or is there any way to hack the trestle toolkit into allowing X11R6 functions? If yes or no how could I convert current X11R6 includes for being used with Modula-3? Nonetheless I would really welcome true native utf-16 support (as nowadays given by the iso10646-1 X core fonts like also 'fixed') because that would be the only way to make use of utf-16 for Windows ports. Otherwise I will have to consider whether I can use Modula-3 at all for my current project which is about converting the automaton simulator www.elstel.org/coan from Object Pascal into a currently supported language and publishing it as open source. Thanks a lot for your effort! Yours, Elmar Stellnberger -- 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 -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Nov 29 07:44:49 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 Nov 2013 07:44:49 +0100 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 Message-ID: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> Hi Elmar Stellnberger, I've forwarded your question to the m3devel mailing list; there has only been one answer so far though (see below). Daniel is talking about using some ISO-charset variant; I'm not sure if that is an option for you. I myself would think it should not be too much work to adapt Trestle and X for Unicode support, but then I haven't had a close look at the code and surely won't have the time to do that. I'm also unsure if UTF-8 might not be the way to go, Olaf Begin forwarded message: Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) From: "Daniel Alejandro Benavides D." To: Olaf Wagner , "m3devel at elegosoft.com" Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 Hi all: I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? http://www.ascii-codes.com/cp869.html Thanks in advance PD: I? will have time In January, if you want I can help port your app (if it doens't have too much goto's) El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner escribi?: I know that there have been controverse discussions about the right way to do unicode support. Is there any way to help Elmar Stellnberger with a quick solution? Olaf Begin forwarded message: Date: Wed, 27 Nov 2013 20:13:54 +0100 From: Elmar Stellnberger To: m3-support at elego.de Subject: UTF-16: Greek alphabet with CM3 Dear Supporters of CM3, Elegosoft ? Wanting to make use of CM3s new UTF-16 feature I have tried to use greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is beta in the unicode table. However I soon had to notice that outputing widechars is not supported by Trestle which still seems to be based on X11R4. Some analysis of the problem has shown that TextVBT calls VBT.PaintText which does however use the CHAR type internally rather than Widechar calling PaintSub to output text instead of the X11R6 function XDrawString16. Is it true that you plan real unicode support for CM3 or is there any way to hack the trestle toolkit into allowing X11R6 functions? If yes or no how could I convert current X11R6 includes for being used with Modula-3? Nonetheless I would really welcome true native utf-16 support (as nowadays given by the iso10646-1 X core fonts like also 'fixed') because that would be the only way to make use of utf-16 for Windows ports. Otherwise I will have to consider whether I can use Modula-3 at all for my current project which is about converting the automaton simulator www.elstel.org/coan from Object Pascal into a currently supported language and publishing it as open source. Thanks a lot for your effort! Yours, Elmar Stellnberger -- 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 -- 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 estellnb at elstel.org Fri Nov 29 17:05:45 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 Nov 2013 16:05:45 +0000 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> Message-ID: <5298BB59.3080703@elstel.org> Am 29.11.2013 06:44, schrieb Olaf Wagner: > Hi Elmar Stellnberger, > > I've forwarded your question to the m3devel mailing list; there has only > been one answer so far though (see below). Daniel is talking about using > some ISO-charset variant; I'm not sure if that is an option for you. > > I myself would think it should not be too much work to adapt Trestle > and X for Unicode support, but then I haven't had a close look at the > code and surely won't have the time to do that. > > I'm also unsure if UTF-8 might not be the way to go, > > Olaf > > Begin forwarded message: > > Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) > From: "Daniel Alejandro Benavides D." > To: Olaf Wagner , "m3devel at elegosoft.com" > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > Hi all: > I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? > http://www.ascii-codes.com/cp869.html Unfortunately I am in need of an entire Greek alphabet because automatons that have already been created with this program should continue to work and be displayed correctly. > > > Thanks in advance > > > PD: I will have time In January, if you want I can help port your app (if it doens't have too much goto's) Great! If you could guarantee me your assistance at least for the Trestle/VBT issues in support of 16bit wide characters I would start to work on a Modula-3 port. The thing is that I will need the port for my studies and I do hardly want to take the risk in failing to hack Trestle/VBT though the thing should not be that hard to do as Olaf has already indicated. As far as I have researched things all that would need to be done is add an additional painting operation to the PaintPrivate interface; or perhaps a second one for drawing elliptical arcs rather than just using Path.CurveTo and to make these new operations be used by the respective painting primitives. Additionally I would welcome some styling of buttons and bevels that goes ahead of pure black and white X-windows. Some Qt-like or at least a Windows 3.1 like button and menu styling might not be unimportant for the acceptance of the application. Nonetheless up to now I can not verify the impact of new painting operations on ports for Windows and MacOS which I am not confident with. No, it does not have a single goto; I`d consider it well structured as it uses classes, objects, method variables and nested procedures and can easily be extended for new automatons. At the moment I am still reading into Trestle. > > > > > El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner escribi?: > > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? > > Olaf P.S.: I have already programmed a module converting between UTF-16 and UTF-8 for console usage and am ready to publish it under BSD or any non-infective license allowing to re-license under any license. I would consider it really a pity if CM3 had good internal UTF-16 support but no interface to make use of it in practice. Additionally I could upload my still existent VIM environment for hacking Modula-3 including syntax highlighting, a treeview buffer and a backtrace analyzer to http://www.elstel.org/modula3 if anyone is interested in it. Elmar From dmuysers at hotmail.com Fri Nov 29 17:52:09 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 29 Nov 2013 17:52:09 +0100 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298BB59.3080703@elstel.org> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> Message-ID: Forget Trestle/VBT and Cie. Modern GUI systems all offer platform look and feel. The easiest solution is to create an import library for IUP (http://www.tecgraf.puc-rio.br/iup/). IUP is a compact (about a 100 "C" functions), portable and platform rendered GUI library. BTW, it uses (since version 3.9) UTF-8 text. I still find that the split of the character set into chars and wides was a very bad decision. It is always stupid to follow the Microsoft trail, the most incompetent software company (IMHO) in the world. -----Original Message----- From: Elmar Stellnberger Sent: Friday, November 29, 2013 5:05 PM To: dabenavidesd at yahoo.es Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 Am 29.11.2013 06:44, schrieb Olaf Wagner: > Hi Elmar Stellnberger, > > I've forwarded your question to the m3devel mailing list; there has only > been one answer so far though (see below). Daniel is talking about using > some ISO-charset variant; I'm not sure if that is an option for you. > > I myself would think it should not be too much work to adapt Trestle > and X for Unicode support, but then I haven't had a close look at the > code and surely won't have the time to do that. > > I'm also unsure if UTF-8 might not be the way to go, > > Olaf > > Begin forwarded message: > > Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) > From: "Daniel Alejandro Benavides D." > To: Olaf Wagner , "m3devel at elegosoft.com" > > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > Hi all: > I'm retired for Modula-3 work for now, but the ASCII table had codes for > Greek alphabet are you sure you can't print that with ASCII? > http://www.ascii-codes.com/cp869.html Unfortunately I am in need of an entire Greek alphabet because automatons that have already been created with this program should continue to work and be displayed correctly. > > > Thanks in advance > > > PD: I will have time In January, if you want I can help port your app (if > it doens't have too much goto's) Great! If you could guarantee me your assistance at least for the Trestle/VBT issues in support of 16bit wide characters I would start to work on a Modula-3 port. The thing is that I will need the port for my studies and I do hardly want to take the risk in failing to hack Trestle/VBT though the thing should not be that hard to do as Olaf has already indicated. As far as I have researched things all that would need to be done is add an additional painting operation to the PaintPrivate interface; or perhaps a second one for drawing elliptical arcs rather than just using Path.CurveTo and to make these new operations be used by the respective painting primitives. Additionally I would welcome some styling of buttons and bevels that goes ahead of pure black and white X-windows. Some Qt-like or at least a Windows 3.1 like button and menu styling might not be unimportant for the acceptance of the application. Nonetheless up to now I can not verify the impact of new painting operations on ports for Windows and MacOS which I am not confident with. No, it does not have a single goto; I`d consider it well structured as it uses classes, objects, method variables and nested procedures and can easily be extended for new automatons. At the moment I am still reading into Trestle. > > > > > El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner > escribi?: > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? > > Olaf P.S.: I have already programmed a module converting between UTF-16 and UTF-8 for console usage and am ready to publish it under BSD or any non-infective license allowing to re-license under any license. I would consider it really a pity if CM3 had good internal UTF-16 support but no interface to make use of it in practice. Additionally I could upload my still existent VIM environment for hacking Modula-3 including syntax highlighting, a treeview buffer and a backtrace analyzer to http://www.elstel.org/modula3 if anyone is interested in it. Elmar From estellnb at elstel.org Fri Nov 29 18:21:57 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 Nov 2013 17:21:57 +0000 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> Message-ID: <5298CD35.10200@elstel.org> As said the difference between UTF-8 and UTF-16 should not matter as long as we just use 16bit characters and as I plan to use a 'tr' function like in qt in order to convert into the current local language which will also handle things like character encoding. As far as I can remember we had something that could convert C interfaces into Modula-3. Is that correct, Olaf? Also; wasn`t there once an attempt to also convert GTK? Nonetheless converting a light weight toolkit may be easier and sufficient for the given purpose. If any of the mentioned languages supported nested procedures and objects at the same time that would allow me to convert existing Object Pascal code without wrapper objects which I would personally like to avoid. C and C++ do not have this feature apart from a very different syntax which would make a converter basing on an LL1 parser necessary. I don`t know that much about Lua and LED. However something that compiles would be fine as well. Elmar Am 29.11.2013 16:52, schrieb dirk muysers: > Forget Trestle/VBT and Cie. Modern GUI systems all offer platform > look and feel. The easiest solution is to create an import library for > IUP (http://www.tecgraf.puc-rio.br/iup/). IUP is a compact (about > a 100 "C" functions), portable and platform rendered GUI library. > BTW, it uses (since version 3.9) UTF-8 text. I still find that the > split of the character set into chars and wides was a very bad > decision. It is always stupid to follow the Microsoft trail, the > most incompetent software company (IMHO) in the world. > > -----Original Message----- From: Elmar Stellnberger > Sent: Friday, November 29, 2013 5:05 PM > To: dabenavidesd at yahoo.es > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 > > > Am 29.11.2013 06:44, schrieb Olaf Wagner: >> Hi Elmar Stellnberger, >> >> I've forwarded your question to the m3devel mailing list; there has only >> been one answer so far though (see below). Daniel is talking about using >> some ISO-charset variant; I'm not sure if that is an option for you. >> >> I myself would think it should not be too much work to adapt Trestle >> and X for Unicode support, but then I haven't had a close look at the >> code and surely won't have the time to do that. >> >> I'm also unsure if UTF-8 might not be the way to go, >> >> Olaf >> >> Begin forwarded message: >> >> Date: Fri, 29 Nov 2013 01:41:18 +0000 (GMT) >> From: "Daniel Alejandro Benavides D." >> To: Olaf Wagner , "m3devel at elegosoft.com" >> >> Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 >> >> >> Hi all: >> I'm retired for Modula-3 work for now, but the ASCII table had codes >> for Greek alphabet are you sure you can't print that with ASCII? >> http://www.ascii-codes.com/cp869.html > Unfortunately I am in need of an entire Greek alphabet because > automatons that have already been created with this program should > continue to work and be displayed correctly. > >> >> >> Thanks in advance >> >> >> PD: I will have time In January, if you want I can help port your >> app (if it doens't have too much goto's) > Great! > If you could guarantee me your assistance at least for the Trestle/VBT > issues in support of 16bit wide characters I would start to work on a > Modula-3 port. The thing is that I will need the port for my studies and > I do hardly want to take the risk in failing to hack Trestle/VBT though > the thing should not be that hard to do as Olaf has already indicated. > As far as I have researched things all that would need to be done is add > an additional painting operation to the PaintPrivate interface; or > perhaps a second one for drawing elliptical arcs rather than just using > Path.CurveTo and to make these new operations be used by the respective > painting primitives. Additionally I would welcome some styling of > buttons and bevels that goes ahead of pure black and white X-windows. > Some Qt-like or at least a Windows 3.1 like button and menu styling > might not be unimportant for the acceptance of the application. > Nonetheless up to now I can not verify the impact of new painting > operations on ports for Windows and MacOS which I am not confident with. > > No, it does not have a single goto; I`d consider it well structured as > it uses classes, objects, method variables and nested procedures and can > easily be extended for new automatons. At the moment I am still reading > into Trestle. > >> >> >> >> >> El Jueves 28 de noviembre de 2013 1:54, Olaf Wagner >> escribi?: >> I know that there have been controverse discussions about the right >> way to do unicode support. >> >> Is there any way to help Elmar Stellnberger with a quick solution? >> >> Olaf > P.S.: I have already programmed a module converting between UTF-16 and > UTF-8 for console usage and am ready to publish it under BSD or any > non-infective license allowing to re-license under any license. I would > consider it really a pity if CM3 had good internal UTF-16 support but no > interface to make use of it in practice. > > Additionally I could upload my still existent VIM environment for > hacking Modula-3 including syntax highlighting, a treeview buffer and a > backtrace analyzer to http://www.elstel.org/modula3 if anyone is > interested in it. > > Elmar > > From dmuysers at hotmail.com Fri Nov 29 18:43:58 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 29 Nov 2013 18:43:58 +0100 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298CD35.10200@elstel.org> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> <5298CD35.10200@elstel.org> Message-ID: No need to use a tool for that. Just write a IUP.i3 file and use the <*EXTERNAL*> pragma. Also a mechanical translation will not do. One must be creative here and use some intermediate code, e.g. have look at . > As far as I can remember we had something that could convert > C interfaces into Modula-3. Is that correct, Olaf? > Also; wasn`t there once an attempt to also convert GTK? > Nonetheless converting a light weight toolkit may be easier and > sufficient for the given purpose. From lemming at henning-thielemann.de Fri Nov 29 18:55:17 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 29 Nov 2013 18:55:17 +0100 (CET) Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298CD35.10200@elstel.org> References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com> <5298BB59.3080703@elstel.org> <5298CD35.10200@elstel.org> Message-ID: On Fri, 29 Nov 2013, Elmar Stellnberger wrote: > As far as I can remember we had something that could convert C > interfaces into Modula-3. Is that correct, Olaf? I extended SWIG with Modula-3 support. From jay.krell at cornell.edu Sat Nov 30 04:50:50 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 Nov 2013 03:50:50 +0000 Subject: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131129074449.330cf8fa65ac89045063ca61@elegosoft.com>, <5298BB59.3080703@elstel.org>, , <5298CD35.10200@elstel.org>, Message-ID: > Wanting to make use of CM3s new UTF-16 feature Cm3 has had 16bit WIDECHAR for over 10 years now. This is plenty to support most languages. Yes, I know, these days Unicode is a I think a 20bit encoding. I don't like Trestle either, but how we convert it take widen any TEXT to WIDECHARs (16 or 32bits then truncate to 16bits and use the "16" stuff in X?) - Jay > Date: Fri, 29 Nov 2013 18:55:17 +0100 > From: lemming at henning-thielemann.de > To: estellnb at elstel.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: Re: Fw: UTF-16: Greek alphabet with CM3 > > > On Fri, 29 Nov 2013, Elmar Stellnberger wrote: > > > As far as I can remember we had something that could convert C > > interfaces into Modula-3. Is that correct, Olaf? > > I extended SWIG with Modula-3 support. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Nov 30 06:35:07 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 00:35:07 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <1385689278.60242.YahooMailNeo@web171905.mail.ir2.yahoo.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <1385689278.60242.YahooMailNeo@web171905.mail.ir2.yahoo.com> Message-ID: <20131130053507.GA20380@topoi.pooq.com> On Fri, Nov 29, 2013 at 01:41:18AM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > I'm retired for Modula-3 work for now, but the ASCII table had codes for Greek alphabet are you sure you can't print that with ASCII? > http://www.ascii-codes.com/cp869.html Perhaps not ASCII, but there must have been a Greek national veriant of the ISO code back when it was still an eight-bit code. Thatnwould be a matter of sspecifying the right environment variables at run time. -- hendrik From hendrik at topoi.pooq.com Sat Nov 30 06:46:55 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 00:46:55 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> Message-ID: <20131130054655.GB20380@topoi.pooq.com> On Thu, Nov 28, 2013 at 07:47:55AM +0100, Olaf Wagner wrote: > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? See http://en.wikipedia.org/wiki/ISO/IEC_8859-7 It seems there's an eight-bit code that's enough for the Greek language. So in theory all you need to do is set the right environment variables to specify a Greek character set. In practice you might have to define the geometry fot the Greek characters for Trestle. Unless it manages to use the underlying OS support for this. -- hendrik > > Olaf > > Begin forwarded message: > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > From: Elmar Stellnberger > To: m3-support at elego.de > Subject: UTF-16: Greek alphabet with CM3 > > > Dear Supporters of CM3, Elegosoft > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > beta in the unicode table. However I soon had to notice that outputing > widechars is not supported by Trestle which still seems to be based on > X11R4. Some analysis of the problem has shown that TextVBT calls > VBT.PaintText which does however use the CHAR type internally rather > than Widechar calling PaintSub to output text instead of the X11R6 > function XDrawString16. Is it true that you plan real unicode support > for CM3 or is there any way to hack the trestle toolkit into allowing > X11R6 functions? If yes or no how could I convert current X11R6 includes > for being used with Modula-3? Nonetheless I would really welcome true > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > like also 'fixed') because that would be the only way to make use of > utf-16 for Windows ports. Otherwise I will have to consider whether I > can use Modula-3 at all for my current project which is about converting > the automaton simulator www.elstel.org/coan from Object Pascal into a > currently supported language and publishing it as open source. > Thanks a lot for your effort! > > Yours, > Elmar Stellnberger > -- > 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 jay.krell at cornell.edu Sat Nov 30 09:26:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 Nov 2013 08:26:29 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131130054655.GB20380@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> Message-ID: Right, In this respect, everything probably just works and always has. Just don't try to display any two non-English languages in a GUI at once. I think we should port Trestle to use 16 bit characters always internally. Even going so far as to double the memory use of common English strings. Can anyone vouch for XDrawString16 generally being implemented and working? - Jay > Date: Sat, 30 Nov 2013 00:46:55 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > On Thu, Nov 28, 2013 at 07:47:55AM +0100, Olaf Wagner wrote: > > I know that there have been controverse discussions about the right > > way to do unicode support. > > > > Is there any way to help Elmar Stellnberger with a quick solution? > > See http://en.wikipedia.org/wiki/ISO/IEC_8859-7 > It seems there's an eight-bit code that's enough for the Greek language. > So in theory all you need to do is set the right environment variables > to specify a Greek character set. In practice you might have to define > the geometry fot the Greek characters for Trestle. Unless it manages > to use the underlying OS support for this. > > -- hendrik > > > > > > Olaf > > > > Begin forwarded message: > > > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > > From: Elmar Stellnberger > > To: m3-support at elego.de > > Subject: UTF-16: Greek alphabet with CM3 > > > > > > Dear Supporters of CM3, Elegosoft > > > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > > beta in the unicode table. However I soon had to notice that outputing > > widechars is not supported by Trestle which still seems to be based on > > X11R4. Some analysis of the problem has shown that TextVBT calls > > VBT.PaintText which does however use the CHAR type internally rather > > than Widechar calling PaintSub to output text instead of the X11R6 > > function XDrawString16. Is it true that you plan real unicode support > > for CM3 or is there any way to hack the trestle toolkit into allowing > > X11R6 functions? If yes or no how could I convert current X11R6 includes > > for being used with Modula-3? Nonetheless I would really welcome true > > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > > like also 'fixed') because that would be the only way to make use of > > utf-16 for Windows ports. Otherwise I will have to consider whether I > > can use Modula-3 at all for my current project which is about converting > > the automaton simulator www.elstel.org/coan from Object Pascal into a > > currently supported language and publishing it as open source. > > Thanks a lot for your effort! > > > > Yours, > > Elmar Stellnberger > > -- > > 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 -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Nov 30 10:06:03 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 Nov 2013 09:06:03 +0000 Subject: [M3devel] how to represent a 16bit char? Message-ID: 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? 2) Are we really certain that redefining WIDECHAR is the way to go? Not, say, introduce a new time, CHAR32 or UCHAR32? And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? Or do people now advocate: get rid of WIDECHAR leave 8 bit CHAR with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? ?? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sat Nov 30 10:34:47 2013 From: dmuysers at hotmail.com (dirk muysers) Date: Sat, 30 Nov 2013 10:34:47 +0100 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: References: Message-ID: Yes, I think UTF-8 CHAR is the way to go. Nearly all recent Un*x libraries use it by now. Only Microsoft sticks to CHAR16 nowadays. I have a UTF-8 TEXT implementation in the making and don?t have the time, these days, to complete it. It has a constant time cursor to sequentially access this encoding, support for character properties, dynamic text building and formatting, and NLS (National Language support), and will have an XML reader. Finished: TEXT implementation, and char props. Partially finished: Dynamic buffer and NLS. Unfinished so far: Formatting and XML. The software is called libunicode. As for Win32, most software use dynamic translation to CHAR16, when required, eg Component Pascal for .Net, GTK, golang etc. leaving it the craggy island it is. From: Jay K Sent: Saturday, November 30, 2013 10:06 AM To: m3devel Subject: [M3devel] how to represent a 16bit char? 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? 2) Are we really certain that redefining WIDECHAR is the way to go? Not, say, introduce a new time, CHAR32 or UCHAR32? And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? Or do people now advocate: get rid of WIDECHAR leave 8 bit CHAR with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? ?? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Nov 30 11:41:42 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 30 Nov 2013 11:41:42 +0100 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: References: Message-ID: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> Are we really sure about this Xlib interfacing? There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? -- Dragi?a Duri? dragisha at m3w.org On 30 Nov 2013, at 10:06, Jay K wrote: > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? > 2) Are we really certain that redefining WIDECHAR is the way to go? > Not, say, introduce a new time, CHAR32 or UCHAR32? > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? > > Or do people now advocate: > get rid of WIDECHAR > leave 8 bit CHAR > with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? > ?? > > Thank you, > - Jay -------------- 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 dragisha at m3w.org Sat Nov 30 11:52:22 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 30 Nov 2013 11:52:22 +0100 Subject: [M3devel] how to represent a 16bit char? In-Reply-To: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> References: <1FC4FC40-AE87-4190-8ADE-C3CD32932CB6@m3w.org> Message-ID: And yes, Cairo uses UTF-8 natively, even on Windows. On 30 Nov 2013, at 11:41, Dragi?a Duri? wrote: > Are we really sure about this Xlib interfacing? > > There are several very-low-level and very-portable libraries right now. Why don?t we use Cairo? > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On 30 Nov 2013, at 10:06, Jay K wrote: > >> 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >> 2) Are we really certain that redefining WIDECHAR is the way to go? >> Not, say, introduce a new time, CHAR32 or UCHAR32? >> And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >> >> Or do people now advocate: >> get rid of WIDECHAR >> leave 8 bit CHAR >> with a new understanding that it is UTF-8 encoded, and force lots conversion back and forth? >> ?? >> >> Thank you, >> - Jay > -------------- 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 dragisha at m3w.org Sat Nov 30 12:02:03 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 30 Nov 2013 12:02:03 +0100 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> Message-ID: <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> I think this would be a major error. Choose 16bit route when only Windows does this, and everybody else is using UTF-8 is not a logical decision. -- Dragi?a Duri? dragisha at m3w.org On 30 Nov 2013, at 09:26, Jay K wrote: > Right, In this respect, everything probably just works and always has. > Just don't try to display any two non-English languages in a GUI at once. > > I think we should port Trestle to use 16 bit characters always internally. > Even going so far as to double the memory use of common English strings. > > Can anyone vouch for XDrawString16 generally being implemented and working? > > - Jay > > > > Date: Sat, 30 Nov 2013 00:46:55 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 > > > > On Thu, Nov 28, 2013 at 07:47:55AM +0100, Olaf Wagner wrote: > > > I know that there have been controverse discussions about the right > > > way to do unicode support. > > > > > > Is there any way to help Elmar Stellnberger with a quick solution? > > > > See http://en.wikipedia.org/wiki/ISO/IEC_8859-7 > > It seems there's an eight-bit code that's enough for the Greek language. > > So in theory all you need to do is set the right environment variables > > to specify a Greek character set. In practice you might have to define > > the geometry fot the Greek characters for Trestle. Unless it manages > > to use the underlying OS support for this. > > > > -- hendrik > > > > > > > > > > Olaf > > > > > > Begin forwarded message: > > > > > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > > > From: Elmar Stellnberger > > > To: m3-support at elego.de > > > Subject: UTF-16: Greek alphabet with CM3 > > > > > > > > > Dear Supporters of CM3, Elegosoft > > > > > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > > > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > > > beta in the unicode table. However I soon had to notice that outputing > > > widechars is not supported by Trestle which still seems to be based on > > > X11R4. Some analysis of the problem has shown that TextVBT calls > > > VBT.PaintText which does however use the CHAR type internally rather > > > than Widechar calling PaintSub to output text instead of the X11R6 > > > function XDrawString16. Is it true that you plan real unicode support > > > for CM3 or is there any way to hack the trestle toolkit into allowing > > > X11R6 functions? If yes or no how could I convert current X11R6 includes > > > for being used with Modula-3? Nonetheless I would really welcome true > > > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > > > like also 'fixed') because that would be the only way to make use of > > > utf-16 for Windows ports. Otherwise I will have to consider whether I > > > can use Modula-3 at all for my current project which is about converting > > > the automaton simulator www.elstel.org/coan from Object Pascal into a > > > currently supported language and publishing it as open source. > > > Thanks a lot for your effort! > > > > > > Yours, > > > Elmar Stellnberger > > > -- > > > 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 -------------- 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 estellnb at elstel.org Sat Nov 30 12:25:31 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 11:25:31 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> Message-ID: <5299CB2B.9090008@elstel.org> > Right, In this respect, everything probably just works and always has. > Just don't try to display any two non-English languages in a GUI at once. That was exactly the requirement: use greek and latin characters at the same time to display mathematical expressions > I think we should port Trestle to use 16 bit characters always internally. > Even going so far as to double the memory use of common English strings. No, that does not double the memory usage. I have just inserted a Text.IsWide function to let a future version of VBT.PaintText select whether it wants to use XDrawString16 or its eight bit counterpart. > Can anyone vouch for XDrawString16 generally being implemented and working? Yes it is shipped with X11R4 - Jay > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? > 2) Are we really certain that redefining WIDECHAR is the way to go? > Not, say, introduce a new time, CHAR32 or UCHAR32? > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: first you would have to upgrade the whole Trestle kit to X11R6 you would have to use the very heavy weight X11R6 XIM interface to make use of WideChar32 then you would finally have to change the internal representation of the Text type. Am 30.11.2013 11:02, schrieb Dragi?a Duri?: > I think this would be a major error. Choose 16bit route when only > Windows does this, and everybody else is using UTF-8 is not a logical > decision. I do not consent. WideChar32 will come with the additional benefit of some additionally supported languages. That is all it would be good for. If we ever upgraded to use XIM which will be a major effort as I have already tried to point out we can still consider WC32 though converting between UTF-8 and UTF-16 is no big deal (I have an implementation which I could give you.). i.e. X11R4 uses WC16 X11R6-XIM uses WC32 I do not want to speak against WC32; Nonetheless it basically depends on how much effort you are willing to invest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat Nov 30 12:34:42 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 11:34:42 +0000 Subject: [M3devel] use CM3_INSTALL_PREFIX to ship to a different target Message-ID: <5299CD52.8020207@elstel.org> As far as I have tested it cm3 -ship ignores CM3_INSTALL_PREFIX so that I can not ship to any directory different from /usr/local/cm3. I always had a different source and target compiler in the times when I was working with PM3 so that things could not get messed up easily. On desire I could compile the compiler with itself. So in a short: Is there any way to make cm3 ship to another directory than /usr/local/cm3 but still compile with /usr/local/cm3 Sorry; I haven` t found out yet how to do that. Perhaps it simply was not implemented. From estellnb at elstel.org Sat Nov 30 12:40:41 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 11:40:41 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5299CB2B.9090008@elstel.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> Message-ID: <5299CEB9.7010508@elstel.org> I do not know about the internals of Trestle but I have some knowledge of the X core protocol and thus I know that everything related to XIM is very complicated though usage of XIM rather than just XDrawString16 would enable user input of Asian languages. Elmar Am 30.11.2013 11:25, schrieb Elmar Stellnberger: > > Right, In this respect, everything probably just works and always has. > > Just don't try to display any two non-English languages in a GUI at > once. > > That was exactly the requirement: use greek and latin characters at > the same time to display mathematical expressions > > > I think we should port Trestle to use 16 bit characters always > internally. > > Even going so far as to double the memory use of common English strings. > > No, that does not double the memory usage. I have just inserted a > Text.IsWide function to let a future > version of VBT.PaintText select whether it wants to use XDrawString16 > or its eight bit counterpart. > > > Can anyone vouch for XDrawString16 generally being implemented and > working? > > Yes it is shipped with X11R4 > > - Jay > > > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I > use where WIDECHAR used to be correct? > > 2) Are we really certain that redefining WIDECHAR is the way to go? > > Not, say, introduce a new time, CHAR32 or UCHAR32? > > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type > that nobody will ever consider changing? > > upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: > first you would have to upgrade the whole Trestle kit to X11R6 > you would have to use the very heavy weight X11R6 XIM interface to > make use of WideChar32 > then you would finally have to change the internal representation of > the Text type. > > > > Am 30.11.2013 11:02, schrieb Dragi?a Duri?: >> I think this would be a major error. Choose 16bit route when only >> Windows does this, and everybody else is using UTF-8 is not a logical >> decision. > I do not consent. WideChar32 will come with the additional benefit of > some additionally supported languages. That is all it would be good for. > If we ever upgraded to use XIM which will be a major effort as I have > already tried to point out we can still consider WC32 though converting > between UTF-8 and UTF-16 is no big deal (I have an implementation > which I could give you.). > > i.e. X11R4 uses WC16 > X11R6-XIM uses WC32 > > I do not want to speak against WC32; Nonetheless > it basically depends on how much effort you are willing to invest. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat Nov 30 13:24:29 2013 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 Nov 2013 12:24:29 +0000 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5299CB2B.9090008@elstel.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> Message-ID: <5299D8FD.6090809@elstel.org> Actually the devil is in the details: Continuing to use 16bit characters outputting strings would be easy. However when it comes to adjust the input function there is no XKeySymToKeyCode16 function which means that you would either have to implement one on your own or the other way upgrade to X11R6, use XIM and convert from UTF-32 to UTF-16. Well there is a possibility to use XIM functions right the way as an XKeySymToKeyCode32 function would work without any input or status reflection. In order to use XOM for outputting 32 bit characters you would have to use 'font sets' on the other hand which I personally have never done. Elmar Am 30.11.2013 11:25, schrieb Elmar Stellnberger: > > Right, In this respect, everything probably just works and always has. > > Just don't try to display any two non-English languages in a GUI at > once. > > That was exactly the requirement: use greek and latin characters at > the same time to display mathematical expressions > > > I think we should port Trestle to use 16 bit characters always > internally. > > Even going so far as to double the memory use of common English strings. > > No, that does not double the memory usage. I have just inserted a > Text.IsWide function to let a future > version of VBT.PaintText select whether it wants to use XDrawString16 > or its eight bit counterpart. > > > Can anyone vouch for XDrawString16 generally being implemented and > working? > > Yes it is shipped with X11R4 > > - Jay > > > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I > use where WIDECHAR used to be correct? > > 2) Are we really certain that redefining WIDECHAR is the way to go? > > Not, say, introduce a new time, CHAR32 or UCHAR32? > > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type > that nobody will ever consider changing? > > upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: > first you would have to upgrade the whole Trestle kit to X11R6 > you would have to use the very heavy weight X11R6 XIM interface to > make use of WideChar32 > then you would finally have to change the internal representation of > the Text type. > > > > Am 30.11.2013 11:02, schrieb Dragi?a Duri?: >> I think this would be a major error. Choose 16bit route when only >> Windows does this, and everybody else is using UTF-8 is not a logical >> decision. > I do not consent. WideChar32 will come with the additional benefit of > some additionally supported languages. That is all it would be good for. > If we ever upgraded to use XIM which will be a major effort as I have > already tried to point out we can still consider WC32 though converting > between UTF-8 and UTF-16 is no big deal (I have an implementation > which I could give you.). > > i.e. X11R4 uses WC16 > X11R6-XIM uses WC32 > > I do not want to speak against WC32; Nonetheless > it basically depends on how much effort you are willing to invest. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Nov 30 17:52:44 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 Nov 2013 10:52:44 -0600 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5299D8FD.6090809@elstel.org> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com>, <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> Message-ID: <529A17DC.3080906@lcwb.coop> Another devilish detail to be aware of: UTF-16 is _not_ the same as the current Modula-3 16-bit WIDECHAR, even when restricted to values <= 16_FFFF. Current Wr/Rd library code just writes/reads exactly 16 bits in two bytes, with whatever code point is in the WIDECHAR variable. In contrast, UTF-16 will encode code points greater than UFFFF as a pair of 16-bit code units with surrogate values in them. Then to make this work right, the surrogate values are not allowed in unencoded variables. So attempting to encode a surrogate in UTF-16 is an error, and decoding a surrogate that is not part of a proper first-surrogate/second-surrogate pair is "ill formed" and usually decodes to UFFFD. You could get by with treating these as interchangeable only be being careful to ensure there is never either a surrogate code nor a code point > UFFFF, in either input or output. Also, current Wr/Rd always write/read only in little-endian byte order, whereas there are both little- and big-endian variants of UTF-16. I have no idea which endianness of UTF-16 is used by various GUI libraries, but it would have to be little for this to work. On 11/30/2013 06:24 AM, Elmar Stellnberger wrote: > Actually the devil is in the details: > Continuing to use 16bit characters outputting strings would be easy. > However when it comes to adjust the input function there is no > XKeySymToKeyCode16 function which means that you would either > have to implement one on your own or the other way upgrade to > X11R6, use XIM and convert from UTF-32 to UTF-16. Well there is > a possibility to use XIM functions right the way as an > XKeySymToKeyCode32 function would work without any input > or status reflection. > In order to use XOM for outputting 32 bit characters you would > have to use 'font sets' on the other hand which I personally have > never done. > > Elmar > > > Am 30.11.2013 11:25, schrieb Elmar Stellnberger: >> > Right, In this respect, everything probably just works and always has. >> > Just don't try to display any two non-English languages in a GUI at once. >> >> That was exactly the requirement: use greek and latin characters at the same time to display mathematical expressions >> >> > I think we should port Trestle to use 16 bit characters always internally. >> > Even going so far as to double the memory use of common English strings. >> >> No, that does not double the memory usage. I have just inserted a Text.IsWide function to let a future >> version of VBT.PaintText select whether it wants to use XDrawString16 or its eight bit counterpart. >> >> > Can anyone vouch for XDrawString16 generally being implemented and working? >> >> Yes it is shipped with X11R4 >> >> - Jay >> >> > 1) Ok for purposes of interfacing with Win32 and Xlib, what should I use where WIDECHAR used to be correct? >> > 2) Are we really certain that redefining WIDECHAR is the way to go? >> > Not, say, introduce a new time, CHAR32 or UCHAR32? >> > And maybe add an explicit alias CHAR16 or UCHAR16 to provide a type that nobody will ever consider changing? >> >> upgrading to WideChar32 would AFAIK be a major effort, not a simple fix: >> first you would have to upgrade the whole Trestle kit to X11R6 >> you would have to use the very heavy weight X11R6 XIM interface to make use of WideChar32 >> then you would finally have to change the internal representation of the Text type. >> >> >> >> Am 30.11.2013 11:02, schrieb Dragi?a Duri?: >>> I think this would be a major error. Choose 16bit route when only Windows does this, and everybody else is using UTF-8 is not a logical decision. >> I do not consent. WideChar32 will come with the additional benefit of some additionally supported languages. That is all it would be good for. >> If we ever upgraded to use XIM which will be a major effort as I have already tried to point out we can still consider WC32 though converting >> between UTF-8 and UTF-16 is no big deal (I have an implementation which I could give you.). >> >> i.e. X11R4 uses WC16 >> X11R6-XIM uses WC32 >> >> I do not want to speak against WC32; Nonetheless >> it basically depends on how much effort you are willing to invest. >> >> >> > From rodney_bates at lcwb.coop Sat Nov 30 18:02:30 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 Nov 2013 11:02:30 -0600 Subject: [M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <5298E46D.2020209@lcwb.coop> References: <5298E46D.2020209@lcwb.coop> Message-ID: <529A1A26.6010007@lcwb.coop> The first post of this seems to have disappeared into cyberspace. -------- Original Message -------- Subject: Re: [M3devel] Fw: UTF-16: Greek alphabet with CM3 Date: Fri, 29 Nov 2013 13:01:01 -0600 From: Rodney M. Bates To: m3devel at elegosoft.com, estellnb at elstel.org I have created a CVS branch (devel_unicode) that changes WIDECHAR to a big enough value range to handle all 16_110000 Unicode code points. I think this may be mostly orthogonal to what you need, as I am sure the Greek letters are in the BMP (first 16_10000) code points of Unicode, and thus representable by the current WIDECHAR. What might be useful to you though, in interfacing to Trestle or any other GUI system, is that it contains encoders/decoders for all of the Unicode-specified encodings (UTF-8, UTF-16-BE/LE, and UTF-32-BE/LE), as well as what I think are the older UCS2-BE/LE, and Modula-3's current ISO-Latin-1 and WIDECHAR encodings. The way these work is that WIDECHARs in memory, including within a TEXT, are fixed sized and are pure Unicode code points, preserving the way original CHAR works, especially, allowing efficient random access by character number, not byte number. But the en/decoding is done while reading/writing streams (Wr.T, Rd,t), which are, as originally, sequential, and thus suited to the variable-length encodings. Of course, you could do unusual things, for example, write with UTF-8 encoding to a pipe and decode with Ascii, thus getting the individual characters of UTF-8 into a TEXT or ARRAY OF CHAR, where you could mess with the encoded bytes in memory, rather than treating them as code points. The en/decoders are available in one-code-point-per-call forms, as well as in filters that are semantically almost identical to Wr and Rd, which work on whole streams, with a constant encoding. The latter, in front of TextWr/TextRd would probably make it easy to interface to any GUI library that uses in-memory UTF-8, etc. It also would not be hard to make these work with 16-bit WIDECHAR, with any input coded beyond UFFFF converted to the standard Unicode replacement UFFFD. It sounds like you would be unlikely to use such values. How soon do you need to start? On 11/28/2013 12:47 AM, Olaf Wagner wrote: > I know that there have been controverse discussions about the right > way to do unicode support. > > Is there any way to help Elmar Stellnberger with a quick solution? > > Olaf > > Begin forwarded message: > > Date: Wed, 27 Nov 2013 20:13:54 +0100 > From: Elmar Stellnberger > To: m3-support at elego.de > Subject: UTF-16: Greek alphabet with CM3 > > > Dear Supporters of CM3, Elegosoft > > Wanting to make use of CM3s new UTF-16 feature I have tried to use > greek letters by VAL(945+code,WIDECHAR) where 945 is alpha and 946 is > beta in the unicode table. However I soon had to notice that outputing > widechars is not supported by Trestle which still seems to be based on > X11R4. Some analysis of the problem has shown that TextVBT calls > VBT.PaintText which does however use the CHAR type internally rather > than Widechar calling PaintSub to output text instead of the X11R6 > function XDrawString16. Is it true that you plan real unicode support > for CM3 or is there any way to hack the trestle toolkit into allowing > X11R6 functions? If yes or no how could I convert current X11R6 includes > for being used with Modula-3? Nonetheless I would really welcome true > native utf-16 support (as nowadays given by the iso10646-1 X core fonts > like also 'fixed') because that would be the only way to make use of > utf-16 for Windows ports. Otherwise I will have to consider whether I > can use Modula-3 at all for my current project which is about converting > the automaton simulator www.elstel.org/coan from Object Pascal into a > currently supported language and publishing it as open source. > Thanks a lot for your effort! > > Yours, > Elmar Stellnberger > From hendrik at topoi.pooq.com Sat Nov 30 18:29:06 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 Nov 2013 12:29:06 -0500 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <529A17DC.3080906@lcwb.coop> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> Message-ID: <20131130172906.GA28372@topoi.pooq.com> On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: > Another devilish detail to be aware of: UTF-16 is _not_ the same as > the current Modula-3 16-bit WIDECHAR, even when restricted to values > <= 16_FFFF. Current Wr/Rd library code just writes/reads > exactly 16 bits in two bytes, with whatever code point is in the > WIDECHAR variable. > > In contrast, UTF-16 will encode code points greater than > UFFFF as a pair of 16-bit code units with surrogate values in them. > Then to make this work right, the surrogate values are not > allowed in unencoded variables. So attempting to encode a surrogate > in UTF-16 is an error, and decoding a surrogate that is not part of a > proper first-surrogate/second-surrogate pair is "ill formed" and usually > decodes to UFFFD. > > You could get by with treating these as interchangeable only be being > careful to ensure there is never either a surrogate code nor a code > point > UFFFF, in either input or output. > > Also, current Wr/Rd always write/read only in little-endian byte order, > whereas there are both little- and big-endian variants of UTF-16. > I have no idea which endianness of UTF-16 is used by various GUI > libraries, but it would have to be little for this to work. It lools as if one might as well use UTF-8 if one is going to consider UTF-16. I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have been superseded by SCIM, I don't know the status of uim, except that it has a uim bridge. It does look as if SCIM (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended as a simple way to interface to many other input methods, such as XIM. It may be worth a look. --- hendrik From rodney_bates at lcwb.coop Sat Nov 30 20:59:47 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 Nov 2013 13:59:47 -0600 Subject: [M3devel] Fw: UTF-16: Greek alphabet with CM3 In-Reply-To: <20131130172906.GA28372@topoi.pooq.com> References: <20131128074755.6ee24b3012340c4eb54940c0@elegosoft.com> <20131130054655.GB20380@topoi.pooq.com> <8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org> <5299CB2B.9090008@elstel.org> <5299D8FD.6090809@elstel.org> <529A17DC.3080906@lcwb.coop> <20131130172906.GA28372@topoi.pooq.com> Message-ID: <529A43B3.2090803@lcwb.coop> On 11/30/2013 11:29 AM, Hendrik Boom wrote: > On Sat, Nov 30, 2013 at 10:52:44AM -0600, Rodney M. Bates wrote: >> Another devilish detail to be aware of: UTF-16 is _not_ the same as >> the current Modula-3 16-bit WIDECHAR, even when restricted to values >> <= 16_FFFF. Current Wr/Rd library code just writes/reads >> exactly 16 bits in two bytes, with whatever code point is in the >> WIDECHAR variable. >> >> In contrast, UTF-16 will encode code points greater than >> UFFFF as a pair of 16-bit code units with surrogate values in them. >> Then to make this work right, the surrogate values are not >> allowed in unencoded variables. So attempting to encode a surrogate >> in UTF-16 is an error, and decoding a surrogate that is not part of a >> proper first-surrogate/second-surrogate pair is "ill formed" and usually >> decodes to UFFFD. >> >> You could get by with treating these as interchangeable only be being >> careful to ensure there is never either a surrogate code nor a code >> point > UFFFF, in either input or output. >> >> Also, current Wr/Rd always write/read only in little-endian byte order, >> whereas there are both little- and big-endian variants of UTF-16. >> I have no idea which endianness of UTF-16 is used by various GUI >> libraries, but it would have to be little for this to work. > > It lools as if one might as well use UTF-8 if one is going to consider UTF-16. Hmm. Actually, *if* one could live with the restrictions on values above, passing the same strings back and forth, with the GUI considering them UTF-16LE and the Modula-3 app code considering them cm3's 16_bit WIDECHAR, would have the advantage that the M3 app code could deal naturally in characters, rather than varying numbers of fragments of characters. UTF-8 would require the latter. > > I looked up XIM on Wikipedia (http://en.wikipedia.org/wiki/X_Input_Method). > and it referred to newer systems, SCIM, uim, and IIMF. IIMF ppears to have > been superseded by SCIM, I don't know the status of uim, except that > it has a uim bridge. > > It does look as if SCIM > (http://en.wikipedia.org/wiki/Smart_Common_Input_Method) is intended > as a simple way to interface to many other input methods, such as XIM. > It may be worth a look. > > --- hendrik > >