From dragisha at m3w.org Sun Jun 1 09:07:00 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Jun 2014 09:07:00 +0200 Subject: [M3devel] Git synchronized to CVS@May30 In-Reply-To: References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org> Message-ID: <6E6D5980-F37A-4FB9-83FF-7FB27F06BFEE@m3w.org> Darko and Henning added. I don?t know if github?s jaykrell is our Jay? dd On 31 May 2014, at 23:01, Dragi?a Duri? wrote: > I have added Rodney and Anthony for now. And I am waiting for few other people to give me exact data. And everybody else to give me any data :) > > What I need is short form show on github, to be sure it is you I am adding. Thanks in advance! > > dd > > On 31 May 2014, at 21:56, Dragi?a Duri? wrote: > >> https://github.com/dragisha/cm3 >> >> Please let me have your usernames on github. >> >> I am continuing now through Jenkins setup. I hope to have few platforms happily building from tomorrow on. >> >> dd >> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dragisha at m3w.org Sun Jun 1 12:17:54 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Jun 2014 12:17:54 +0200 Subject: [M3devel] Git synchronized to CVS@May30 In-Reply-To: References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org> Message-ID: Of course all will be preserved. Current priority is what is alive and being changed right now. hudson-config I will use while setting Jenkins up, to learn from previous experience. And other repos will be preserved one by one. Especially pm3. dd On 01 Jun 2014, at 11:42, Kai Henningsen wrote: > On Sat, May 31, 2014 at 9:56 PM, Dragi?a Duri? wrote: >> https://github.com/dragisha/cm3 > > I see you have > > modula3.elegosoft.com:/usr/cvs/cm3/ > > However, what about > > modula3.elegosoft.com:/usr/cvs/hudson-config/ > modula3.elegosoft.com:/usr/cvs/m3-misc/ > modula3.elegosoft.com:/usr/cvs/m3-misc-new/ > modula3.elegosoft.com:/usr/cvs/pm3/ > modula3.elegosoft.com:/usr/cvs/testing/ > > ? At least some of those seem as though they should be preserved, too. > Especially pm3. > > -- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCM/CS/IT d s+: a++ C++ UL++++ P+++ L+++ E--- W++@ N@ !o !K w(++) O-@ > M-@ V-- PS++@ PE- Y+ PGP+@ t- 5 X- !tv b++>+++ D--- G e+ h-- !r y? > ------END GEEK CODE BLOCK------ -------------- 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 Sun Jun 1 12:20:49 2014 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Jun 2014 10:20:49 +0000 Subject: [M3devel] Starting out with CM3 In-Reply-To: <5389E887.5050405@gmail.com> References: <53893F74.1040608@gmail.com>,<5389E887.5050405@gmail.com> Message-ID: > MinGW I got this working years ago, but it isn't in active use. Things are structured now such that bit-rot is fairly slow, so it could still work. Someone besides me should document the cross/bootstrap steps, that granted, I advocate and use: First you will want a working install on any system. Then you will: cd scripts/python boot1.py I386_MINGW if this works, you'll have a .tar.gz or .zip there. Extract it on target system, cd into it, make. That gives you cm3. Make sure it runs and prints "can't find config" or similar. Put it somewhere, on $PATH, e.g. /cm3/bin, and then boot2.sh. You could try these old builds: http://opencm3.net/uploaded-archives/index.html http://opencm3.net/uploaded-archives/cm3-min-NT386MINGNU-d5.7.1.tar.gz etc. There is also I386_CYGWIN. And I386_INTERIX which is noticeably faster due to fast fork. NT386GNU and NT386MINGNU are old names for I386_CYGWIN and I386_MINGW. - Jay > Date: Sat, 31 May 2014 22:34:47 +0800 > From: bruce.axtens at gmail.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Starting out with CM3 > > Oh and while I'm at it, seeing as I have a recent MinGW here, how do I > build for MinGW? > > Bruce. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.axtens at gmail.com Sun Jun 1 14:13:20 2014 From: bruce.axtens at gmail.com (Bruce M. Axtens) Date: Sun, 01 Jun 2014 20:13:20 +0800 Subject: [M3devel] Git synchronized to CVS@May30 In-Reply-To: References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>

Message-ID: <538B18E0.5000200@gmail.com> I'm at if raw recruits get rights. Kind regards, Bruce. From dragisha at m3w.org Sun Jun 1 17:43:36 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Jun 2014 17:43:36 +0200 Subject: [M3devel] Git synchronized to CVS@May30 In-Reply-To: References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org> Message-ID: <80235D34-DFE6-4C95-A075-B59D966B59E7@m3w.org> https://github.com/dragisha/pm3 For emergencies :) On 01 Jun 2014, at 11:42, Kai Henningsen wrote: > On Sat, May 31, 2014 at 9:56 PM, Dragi?a Duri? wrote: >> https://github.com/dragisha/cm3 > > I see you have > > modula3.elegosoft.com:/usr/cvs/cm3/ > > However, what about > > modula3.elegosoft.com:/usr/cvs/hudson-config/ > modula3.elegosoft.com:/usr/cvs/m3-misc/ > modula3.elegosoft.com:/usr/cvs/m3-misc-new/ > modula3.elegosoft.com:/usr/cvs/pm3/ > modula3.elegosoft.com:/usr/cvs/testing/ > > ? At least some of those seem as though they should be preserved, too. > Especially pm3. > > -- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCM/CS/IT d s+: a++ C++ UL++++ P+++ L+++ E--- W++@ N@ !o !K w(++) O-@ > M-@ V-- PS++@ PE- Y+ PGP+@ t- 5 X- !tv b++>+++ D--- G e+ h-- !r y? > ------END GEEK CODE BLOCK------ -------------- 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 Sun Jun 1 22:53:06 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 01 Jun 2014 15:53:06 -0500 Subject: [M3devel] Fwd: Re: build problems with libunicode In-Reply-To: <5388DFA6.1060406@lcwb.coop> References: <5388DFA6.1060406@lcwb.coop> Message-ID: <538B92B2.5040302@lcwb.coop> Resend, after ~~48 hours -------- Original Message -------- Subject: Re: [M3devel] build problems with libunicode Date: Fri, 30 May 2014 14:44:38 -0500 From: Rodney M. Bates Reply-To: rodney.m.bates at acm.org To: m3devel at elegosoft.com Try with the change to m3-libs/libunicode/src/m3makefile that I just checked in. It just skips building altogether, if not configured for full Unicode WIDECHAR. On 05/29/2014 08:38 PM, Coleburn, Randy wrote: > Jay / Rodney: > > Well I didn?t ?pick? anything, but it appears that since I chose to rebuild everything based on *pkginfo.txt* that is why *libunicode* is now trying to build on my Windows box. > > I have several options: > > 1.Using my build scripts, I could choose to exclude libunicode (I have an option for that). > > 2.We could modify the cm3.cfg and m3makefile as Jay suggests to prevent libunicode from trying to build unless Unicode_WIDECHAR is defined and TRUE. > > 3.Etc. > > For the short term, I think I?ll try #1. > > Then, I?ll think about some mods for #2 and commit them if they test out. That way, the Unicode_WIDECHAR could be used to turn this feature on and off as Rodney suggested. > > For the *elego\prjm* package, I?m not sure whether it is supposed to be buildable on Windows. If not, I can just exclude it, or we can modify the m3makefile to prevent it from building on Windows. Obviously, I never used this package before. > > Thanks for your help! > > Thanks, > > Randy > > *From:*jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of *Jay K > *Sent:* Thursday, May 29, 2014 9:12 PM > *To:* Coleburn, Randy; m3devel > *Subject:* EXT:RE: [M3devel] build problems with libunicode > > I guess Unicode_WIDECHAR = TRUE is what you picked, so: > > if not defined("Unicode_WIDECHAR") > Unicode_WIDECHAR = FALSE > end > in cm3cfg.common and libunicode/src/m3makefile > > and then if Unicode_WIDECHAR around the rest of libunicode/src/m3makefile? > > > I would have likely used a function returning byte size. > > > > - Jay > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > From: jay.krell at cornell.edu > To: rcolebur at scires.com ; m3devel at elegosoft.com > Subject: RE: [M3devel] build problems with libunicode > Date: Fri, 30 May 2014 00:07:11 +0000 > > Can https://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libunicode/src/m3makefile > > > do something to filter itself out from building with a compiler that won't work? > > Can you add a builtin quake function > WideCharByteSize() or some other name > > that returns 2 or 4, and in cm3cfg.common, if it isn't already defined (builtin), define one that returns 2? > and then, in libunicode/src/m3makefile, do the same thing, define a function that returns 2 if it isn't already defined? > > > > - Jay > >> From: rcolebur at SCIRES.COM >> To:m3devel at elegosoft.com >> Date: Thu, 29 May 2014 21:37:59 +0000 >> Subject: Re: [M3devel] build problems with libunicode >> >> Rodney: >> >> I looked thru the various cm3.cfg files (and the ones that get included) and I don't anywhere see a line with "Unicode_WIDECHAR" in it. >> >> So, not sure why libunicode is trying to build on Windows (NT386). >> >> --Randy Coleburn >> >> -----Original Message----- >> From: Coleburn, Randy >> Sent: Thursday, May 29, 2014 4:55 PM >> To:m3devel at elegosoft.com >> Subject: Re: [M3devel] build problems with libunicode >> >> Rodney: >> >> Thanks very much for your response. >> >> As far as I know, I've not changed the default configuration of my compiler, so based on your statement, I don't see why libunicode should be trying to build. >> >> I'll take a look at your release notes. >> >> Thanks, >> Randy Coleburn >> >> -----Original Message----- >> From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] >> Sent: Thursday, May 29, 2014 11:27 AM >> To:m3devel at elegosoft.com >> Subject: EXT:Re: [M3devel] build problems with libunicode >> >> >> >> On 05/29/2014 12:40 AM, Coleburn, Randy wrote: >> > I've been rebuilding everything from the HEAD branch on Windows XP (32-bit). >> > >> > The m3-libs\libunicode package fails to build (see errors below). >> > >> > I haven't taken time yet to look at the source code, but wanted to go ahead and post these results to the group in case someone knows of a quick fix. >> > >> > The problem module is: UnsafeUniCodec.m3 >> > >> > Thanks, >> > >> > Randy Coleburn >> > >> >> I am responsible for libunicode. >> >> 1. libunicode won't and is not designed to build unless the compiler is >> configured to make WIDECHAR have full unicode range, which, by default, >> it is not. >> >> 2. The simplest way to thus configure the compiler is to add the line >> Unicode_WIDECHAR="TRUE" to cm3.cfg, in /usr/local/cm3/bin, then rebuild >> everything, starting with m3core. >> >> You can bootstrap all of this using the release compiler, see cm3/scripts/README-build-unicode >> >> I put libunicode in a separate package for that reason, and left the compiler configured by default for the existing 16-bit range of WIDECHAR, so there would be no perturbation to anybody's code unless you take some action. >> >> We can change the default if there is consensus to do so. Most code should not be affected, but some lower-level things will be. There is lots of info on this subject, including what you get from it and what kinds of code might be affected in: >> >> cm3/README-unicode-summary >> cm3/README-unicode >> cm3/scripts/README-build-unicode >> >> Rodney Bates >>rodney.m.bates at acm.org > -- Rodney Bates rodney.m.bates at acm.org From estellnb at elstel.org Mon Jun 2 08:29:18 2014 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 2 Jun 2014 08:29:18 +0200 Subject: [M3devel] build problems with libunicode In-Reply-To: <5388B44B.2000602@lcwb.coop> References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL> <538751AD.8080206@lcwb.coop> <5388B44B.2000602@lcwb.coop> Message-ID: <03759842-50EA-4798-92B7-89F542D8E124@elstel.org> > > > But do gtk and qt actually treat all characters as 16-bit fixed-size code points, or do they > actually use UTF16, with the 16-bit value being a code unit, not a code point? In the > latter case, using UniWr and UniRd to do the encoding/decoding would be a much cleaner > option. > Qt and Gtk should be able to handle true UTF-16 including surrogate pairs so that finally making an UniRd and UniWr from such a 16bit type would be the way to go. As far as I have researched Gtk has some UCS-4 conversion functions by its own. Qt has a QString::fromUcs4( const unit* unicode, int size=-1) function as well, so that we could even do the conversion in some client library. There is also a QVector QString::toUcs4() const which you can apply a .data() upon to get an in memory array of UCS-4 characters. Elmar Stellnberger -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Mon Jun 2 08:40:04 2014 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 2 Jun 2014 08:40:04 +0200 Subject: [M3devel] build problems with libunicode In-Reply-To: <03759842-50EA-4798-92B7-89F542D8E124@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL> <538751AD.8080206@lcwb.coop> <5388B44B.2000602@lcwb.coop> <03759842-50EA-4798-92B7-89F542D8E124@elstel.org> Message-ID: The only target system that does not support such a conversion on its own would be Xorg/Trestle. You would need to convert to utf-16 and then byte swap for little endian machines as the XChar2b is defined as a struct with the hi byte first. Am 02.06.2014 um 08:29 schrieb Elmar Stellnberger: >> >> >> But do gtk and qt actually treat all characters as 16-bit fixed-size code points, or do they >> actually use UTF16, with the 16-bit value being a code unit, not a code point? In the >> latter case, using UniWr and UniRd to do the encoding/decoding would be a much cleaner >> option. >> > > Qt and Gtk should be able to handle true UTF-16 including surrogate pairs so that > finally making an UniRd and UniWr from such a 16bit type would be the way to go. > As far as I have researched Gtk has some UCS-4 conversion functions by its own. > Qt has a QString::fromUcs4( const unit* unicode, int size=-1) function as well, so > that we could even do the conversion in some client library. There is also a > QVector QString::toUcs4() const which you can apply a .data() upon to get > an in memory array of UCS-4 characters. > > Elmar Stellnberger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Mon Jun 2 08:34:40 2014 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 2 Jun 2014 08:34:40 +0200 Subject: [M3devel] build problems with libunicode In-Reply-To: <20140531105003.c365f974ec13b9f47b5fda34@elegosoft.com> References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL> <20140531105003.c365f974ec13b9f47b5fda34@elegosoft.com> Message-ID: Am 31.05.2014 um 10:50 schrieb Olaf Wagner: > On Fri, 30 May 2014 01:38:01 +0000 > "Coleburn, Randy" wrote: > >> Jay / Rodney: >> >> For the elego\prjm package, I'm not sure whether it is supposed to be buildable on Windows. If not, I can just exclude it, or we can modify the m3makefile to prevent it from building on Windows. Obviously, I never used this package before. > > All the packages from Elego used to build on Windows, Linux, BSD > and Solaris platforms. However, I don't think anything depends > on this that you will need so you should be safe to exclude > all the stuff in the elego directory. > > Olaf > -- Nonetheless I would highly appreciate some UCS-4 support in the upcoming release if we still have time for that. If it just does not build under Windows there may be a viable way to fix it. From estellnb at elstel.org Mon Jun 2 09:07:46 2014 From: estellnb at elstel.org (Elmar Stellnberger) Date: Mon, 2 Jun 2014 09:07:46 +0200 Subject: [M3devel] build problems with libunicode In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL> <538751AD.8080206@lcwb.coop> <5388B44B.2000602@lcwb.coop> <03759842-50EA-4798-92B7-89F542D8E124@elstel.org> Message-ID: <35A933B1-3E6C-4233-890F-2D37A38DF3B9@elstel.org> > The only target system that does not support such a conversion on its own would be > Xorg/Trestle. You would need to convert to utf-16 and then byte swap for little endian > machines as the XChar2b is defined as a struct with the hi byte first. > However the XChar2b of X11 can only handle 16bit code units with up to 65536 chars so that a more simple direct conversion would be appropriate in this case. I guess we could even skip utf-16 support and simply take libunicode as is by fixing its compilation errors though utf-16 is is widely in use by Qt, Gtk, Java and C# and proper support for it will improve interoperability. From rodney_bates at lcwb.coop Tue Jun 3 02:34:32 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 02 Jun 2014 19:34:32 -0500 Subject: [M3devel] build problems with libunicode In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A8F6D@ATLEX04-SRV.SCIRES.LOCAL> <20140531105003.c365f974ec13b9f47b5fda34@elegosoft.com> Message-ID: <538D1818.8010208@lcwb.coop> On 06/02/2014 01:34 AM, Elmar Stellnberger wrote: > > Am 31.05.2014 um 10:50 schrieb Olaf Wagner: > >> On Fri, 30 May 2014 01:38:01 +0000 >> "Coleburn, Randy" wrote: >> >>> Jay / Rodney: >>> >>> For the elego\prjm package, I'm not sure whether it is supposed to be buildable on Windows. If not, I can just exclude it, or we can modify the m3makefile to prevent it from building on Windows. Obviously, I never used this package before. >> >> All the packages from Elego used to build on Windows, Linux, BSD >> and Solaris platforms. However, I don't think anything depends >> on this that you will need so you should be safe to exclude >> all the stuff in the elego directory. >> >> Olaf >> -- > > Nonetheless I would highly appreciate some UCS-4 support in the upcoming release > if we still have time for that. Hmm, how different is UCS4 from UTF32? The UCS and Unicode standards are coordinated and often agree on such things. UTF32, in big-endian, little-endian, and host-endian are already in libunicode. If they differ, adding a new encoding would not be hard at this point. If it just does not build under Windows there may be a > viable way to fix it. >-- I don't expect the build problem to have anything to do with Windows/Posix. It only requires that the compiler make WIDECHAR big enough for Unicode. I don't have many targets to actually test on, but it is coded to work on Cartesian product: [32-bit,64-bit target] X [big-endian,little-endian target] X [big-endian, little-endian streams]. I don't expect other target characteristics to matter. Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue Jun 3 02:52:50 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 02 Jun 2014 19:52:50 -0500 Subject: [M3devel] build problems with libunicode In-Reply-To: <35A933B1-3E6C-4233-890F-2D37A38DF3B9@elstel.org> References: <0BB8FA59C2932741A3A2941A8B9D8BFF926A6EDC@ATLEX04-SRV.SCIRES.LOCAL> <538751AD.8080206@lcwb.coop> <5388B44B.2000602@lcwb.coop> <03759842-50EA-4798-92B7-89F542D8E124@elstel.org> <35A933B1-3E6C-4233-890F-2D37A38DF3B9@elstel.org> Message-ID: <538D1C62.2090108@lcwb.coop> On 06/02/2014 02:07 AM, Elmar Stellnberger wrote: > >> The only target system that does not support such a conversion on its own would be >> Xorg/Trestle. You would need to convert to utf-16 and then byte swap for little endian >> machines as the XChar2b is defined as a struct with the hi byte first. >> > > However the XChar2b of X11 can only handle 16bit code units with up to 65536 chars > so that a more simple direct conversion would be appropriate in this case. If X11's XChar2b is really a code unit, and sometimes two of them can represent a code point, then UniEncoding.Encoding.UTF16BE in libunicode will take care of this. If XChar2b is a code point, and only code points up to 65535 can be handled, then UniEncoding.Encoding.UCS2BE will do it. Unless, in X11, the surrogate codes of Unicode are real printing characters and not surrogates, in which case, libunicode would need a new encoding, like CM3WC, except big endian. > I guess we > could even skip utf-16 support and simply take libunicode as is by fixing its compilation > errors though utf-16 is is widely in use by Qt, Gtk, Java and C# and proper support for it > will improve interoperability. > > If you set up the compiler to support Unicode, there is full support of utf-16 in libunicode, as is. -- Rodney Bates rodney.m.bates at acm.org From rcolebur at SCIRES.COM Tue Jun 3 03:35:52 2014 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 3 Jun 2014 01:35:52 +0000 Subject: [M3devel] Starting out with CM3 Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF926AFA99@ATLEX04-SRV.SCIRES.LOCAL> Bruce: I just read your posts about building CM3 on Windows. I wrote some instructions on this a while back. Let me find them and send to you. I know that Jay has some python scripts for doing all this, but I've never been successful using them on Windows, so I wrote scripts for the native Windows command shell. You should probably try Jay's python first, but you also are welcome to use my scripts. BTW, you will need to install Microsoft Visual C++ so that you have a linker and some LIBs and DLLs that are needed. The good news is that you can use the FREE Visual C++ Express edition so you don't have to shell out any money for it. I'm swamped right now, but will try to locate this for you soon. Thanks, Randy Coleburn -----Original Message----- From: Bruce M. Axtens [mailto:bruce.axtens at gmail.com] Sent: Saturday, May 31, 2014 10:34 AM To: m3devel Subject: EXT:[M3devel] Starting out with CM3 G'day everyone I've slurped down the full CVS tree. How do I build for Windows 7 ... from scratch? Is there a readme/faq for this somewhere? Kind regards, Bruce. From rodney_bates at lcwb.coop Wed Jun 4 20:14:09 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 04 Jun 2014 13:14:09 -0500 Subject: [M3devel] CVS to GIT migration -- shutdown of elego's CVS services for M3 In-Reply-To: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com> References: <20140531113852.22c6713299119e2be29bffcf@elegosoft.com> Message-ID: <538F61F1.7000802@lcwb.coop> Thank you very much, Olaf for your support of Modula-3 these many years, both through hands-on work and by providing essential hosting. How long ago was it that you stepped in for Montreal Poly? I don't even remember. We all greatly appreciate it. Hopefully, this dramatically superior programming language can survive and maybe gain some of the recognition and usage it deserves and play the role it is capable of, in addressing the ever increasing vitalness yet vulnerability of computer systems in this era. On 05/31/2014 04:38 AM, Olaf Wagner wrote: > Hello all, > > with the possibility of the CM3 project being hosted on Github, > where it can be continued safely and with much more and better > hardware resources than elego could ever provide, elego will > stop providing the legacy CVS service for the source code as > soon as possible. This does not mean that we will stop all of > our support, and we certainly won't remove access to the sources > before easy access to them at another provider is established. > But we would like to urge all the developers to help with the > migration and ensure that the use and development of Modula-3 > will continue as seamlessly as possible. > > The WWW service can stay online some time longer, though > I think all the stuff available there should be reviewed > and moved to a Wiki with easy access for all the developers. > > 13 months ago I set up this Wiki page at the M3 Trac > instance to allocate all the things that I thought should > be done and considered, but nobody else has contributed > to that, so that has probably not been the right approach: > > https://cm3-bugs.elegosoft.com/cm3/wiki/CvsToGitMigration > > However, I think a clean migration to git should be no > big problem, and it should also improve the visibility > and ease of use of the assets, so it will be all for the > best of the project. > > Some personal notes: > > After the huge amount of time I spent in preparing, testing > and bundling the last release of CM3 several years ago, > I was not able to sustain any noticable contribution to > the M3 development. Both private and business matters > claimed so much attention that I was not able to provide > the necessary time to even keep all the infrastructure > -- WWW, scripts, CI etc. -- in proper and usable shape. > And I'm afraid that this won't change soon, so there is > no hope for much contribution from my side for the > foreseeable future. > > I would dearly like to see the use of Modula-3 spread and > the project prosper and thrive and I'll try to support > this as much as I can. Embarrassing desasters like > heartbleed could easily have been prevented by the use > of Modula-3 or the application of the sound principles > and techniques that are its base. I still believe that > using a safe language for large projects should be a > inevitable decision from an engineering point of view, > but keeping the users and developers of M3 in a kind of > enclave won't help in the large run. > > So please see my decision to discontinue the repository > support as a friendly push to start moving in the right > direction. > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu Jun 5 00:39:30 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 04 Jun 2014 17:39:30 -0500 Subject: [M3devel] Heartbleed, initialization, and Modula-3 Message-ID: <538FA022.2060501@lcwb.coop> Olaf's recent mention of safe languages and Heartbleed prompted me to look into the specifics of the bug, particularly to see what Modula-3 might have done to prevent it. According to the descriptions I found, a recent protocol extension (called "heartbeat") allows one machine (call it the client) to ask another (call it the server) to echo a verbatim copy of an arbitrary character string, I suppose to check whether the server is alive and responding. The request message contains two redundant string lengths, one part of the string itself (in a way not described in the descriptions I saw, but it doesn't matter) and one prepended at the beginning, so the server can allocate a buffer prior to storing the string. The two were probably presumed to be equal, but nothing forces this. How good a protocol design this is could be debated. The real bug is in the server-side implementation, which uses the requested buffer size rather than the sent string length as the length of the string to echo. So an attacker can give an over-large buffer size and a short string. The string gets stored in the first few bytes of the buffer, while the rest are uninitialized. The attacker gets back a lot of left-over bytes from whatever the buffer was used for previously. It would then have to figure out what it actually got and how to exploit it, but the data is at least there. Modula-3, as it is would likely not have prevented this. The language requires only that all newly allocated variables come into existence with some bit pattern that is a legal value of the type. For many types, this would require a compiler-generated runtime initialization, which would have overlaid the leftover sensitive data. But for a type whose value set covers all bit patterns of the machine-level representation, the language rule is satisfied with no initialization. Coded in Modula-3, the buffer would almost surely been typed as an array of CHAR or array of some other discrete type whose range exactly uses a byte, thus requiring no compiler-generated initialization and leaving the sensitive data intact. I have long been ambivalent about this language rule. I see the argument for it. It is the minimum runtime penalty that ensures the abstract type system of the language behaves as expected. But it also allows some things to happen that, although not type-safety bugs, are nevertheless undefined behaviour, even if explainable in the abstract data system of the language. Defined initialization of everything would have prevented the Heartbleed bug from compromising sensitive data. It would also make uninitialized (by explicit source code) bugs deterministic and repeatable, which is a huge advantage. The cost would be small constant-time execution speed losses, greatly diluted by other things. This would allow us to claim publically that modern Modula-3 would have prevented the Heartbleed bug from compromising anything. We could also implement this without stating it in the language, but I think that might be something of the worst of both worlds, since one could not fully rely on it's staying that way. What does everyone think? P.S.: It's pretty easy to define the values and pretty easy to implement. -- Rodney Bates rodney.m.bates at acm.org From hendrik at topoi.pooq.com Thu Jun 5 03:03:49 2014 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 4 Jun 2014 21:03:49 -0400 Subject: [M3devel] Heartbleed, initialization, and Modula-3 In-Reply-To: <538FA022.2060501@lcwb.coop> References: <538FA022.2060501@lcwb.coop> Message-ID: <20140605005753.GA27124@topoi.pooq.com> On Wed, Jun 04, 2014 at 05:39:30PM -0500, Rodney M. Bates wrote: > Olaf's recent mention of safe languages and Heartbleed prompted me to > look into the specifics of the bug, particularly to see what Modula-3 > might have done to prevent it. > > According to the descriptions I found, a recent protocol extension > (called "heartbeat") allows one machine (call it the client) to ask > another (call it the server) to echo a verbatim copy of an arbitrary > character string, I suppose to check whether the server is alive and > responding. > > The request message contains two redundant string lengths, one part of > the string itself (in a way not described in the descriptions I saw, > but it doesn't matter) and one prepended at the beginning, so the > server can allocate a buffer prior to storing the string. The two > were probably presumed to be equal, but nothing forces this. How good > a protocol design this is could be debated. > > The real bug is in the server-side implementation, which uses the > requested buffer size rather than the sent string length as the length > of the string to echo. So an attacker can give an over-large buffer > size and a short string. The string gets stored in the first few > bytes of the buffer, while the rest are uninitialized. The attacker > gets back a lot of left-over bytes from whatever the buffer was used > for previously. It would then have to figure out what it actually got > and how to exploit it, but the data is at least there. > > Modula-3, as it is would likely not have prevented this. The language > requires only that all newly allocated variables come into existence > with some bit pattern that is a legal value of the type. For many > types, this would require a compiler-generated runtime initialization, > which would have overlaid the leftover sensitive data. But for a type > whose value set covers all bit patterns of the machine-level > representation, the language rule is satisfied with no initialization. > > Coded in Modula-3, the buffer would almost surely been typed as an > array of CHAR or array of some other discrete type whose range exactly > uses a byte, thus requiring no compiler-generated initialization and > leaving the sensitive data intact. > > I have long been ambivalent about this language rule. I see the > argument for it. It is the minimum runtime penalty that ensures the > abstract type system of the language behaves as expected. But it also > allows some things to happen that, although not type-safety bugs, are > nevertheless undefined behaviour, even if explainable in the abstract > data system of the language. > > Defined initialization of everything would have prevented the > Heartbleed bug from compromising sensitive data. It would also make > uninitialized (by explicit source code) bugs deterministic and > repeatable, which is a huge advantage. The cost would be small > constant-time execution speed losses, greatly diluted by other things. constant-time? only if they are only ever executed once each. > > This would allow us to claim publically that modern Modula-3 would > have prevented the Heartbleed bug from compromising anything. > > We could also implement this without stating it in the language, but I > think that might be something of the worst of both worlds, since one > could not fully rely on it's staying that way. > > What does everyone think? > > P.S.: It's pretty easy to define the values and pretty easy to > implement. And pretty slow if the first thing you do with that storage is to initialize it yourself. I'd be in favour of such an initialization as a compile-time option it the values were values that are not likely to be welcome in normal use, so that the programmer's missed initialiations are likely to show up. for example, a NaN for floating point. But in production I'd really like the option of turning this off if performance is critical. And even if it's on, I'd like the optimiser, if any, to remove these default initialisations if it can determine that the default initializations are dead. (that said, I hardly ever turn checking options off in practice.) -- hendrik > > -- > Rodney Bates > rodney.m.bates at acm.org From schlepptop at henning-thielemann.de Thu Jun 5 10:51:01 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Thu, 05 Jun 2014 10:51:01 +0200 Subject: [M3devel] Heartbleed, initialization, and Modula-3 In-Reply-To: <538FA022.2060501@lcwb.coop> References: <538FA022.2060501@lcwb.coop> Message-ID: <53902F75.1040201@henning-thielemann.de> Am 05.06.2014 00:39, schrieb Rodney M. Bates: > Olaf's recent mention of safe languages and Heartbleed prompted me to > look into the specifics of the bug, particularly to see what Modula-3 > might have done to prevent it. My general experience is that a language is only as safe as the programmer wants to. You can add as many safety belts as you like, a careless programmer will always find a way to remove them. I consider the value of safe languages the other way round: A careful programmer can get a lot of security support from a safe language. The programmer of the heartbleed bug was criticized for rating performance higher than security and other things. There would have been ways to prevent that bug even in C. From dragisha at m3w.org Thu Jun 5 11:18:21 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 5 Jun 2014 11:18:21 +0200 Subject: [M3devel] Heartbleed, initialization, and Modula-3 In-Reply-To: <53902F75.1040201@henning-thielemann.de> References: <538FA022.2060501@lcwb.coop> <53902F75.1040201@henning-thielemann.de> Message-ID: <623A43CF-07B5-46EA-8E1B-727D922FAF62@m3w.org> In my experience, big strength of Modula-3, safety-wise, is easy isolation of unsafe code. I like to separate single unsafe method to separate source file, implementing same interface in two or more source files, with only one of them unsafe. This drastically eases code review, and code review is another important step which failed in this Heartbleed case. C is unsafe at scale of 100%. What are we exactly reviewing when we review C code safety? Decision to use it in first place? dd On 05 Jun 2014, at 10:51, Henning Thielemann wrote: > Am 05.06.2014 00:39, schrieb Rodney M. Bates: > >> Olaf's recent mention of safe languages and Heartbleed prompted me to >> look into the specifics of the bug, particularly to see what Modula-3 >> might have done to prevent it. > > My general experience is that a language is only as safe as the programmer wants to. You can add as many safety belts as you like, a careless programmer will always find a way to remove them. I consider the value of safe languages the other way round: A careful programmer can get a lot of security support from a safe language. > > The programmer of the heartbleed bug was criticized for rating performance higher than security and other things. There would have been ways to prevent that bug even in C. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rodney_bates at lcwb.coop Fri Jun 6 16:26:18 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Jun 2014 09:26:18 -0500 Subject: [M3devel] Heartbleed, initialization, and Modula-3 In-Reply-To: <20140605005753.GA27124@topoi.pooq.com> References: <538FA022.2060501@lcwb.coop> <20140605005753.GA27124@topoi.pooq.com> Message-ID: <5391CF8A.2070804@lcwb.coop> On 06/04/2014 08:03 PM, Hendrik Boom wrote: > On Wed, Jun 04, 2014 at 05:39:30PM -0500, Rodney M. Bates wrote: >> Olaf's recent mention of safe languages and Heartbleed prompted me to >> look into the specifics of the bug, particularly to see what Modula-3 >> might have done to prevent it. >> >> According to the descriptions I found, a recent protocol extension >> (called "heartbeat") allows one machine (call it the client) to ask >> another (call it the server) to echo a verbatim copy of an arbitrary >> character string, I suppose to check whether the server is alive and >> responding. >> >> The request message contains two redundant string lengths, one part of >> the string itself (in a way not described in the descriptions I saw, >> but it doesn't matter) and one prepended at the beginning, so the >> server can allocate a buffer prior to storing the string. The two >> were probably presumed to be equal, but nothing forces this. How good >> a protocol design this is could be debated. >> >> The real bug is in the server-side implementation, which uses the >> requested buffer size rather than the sent string length as the length >> of the string to echo. So an attacker can give an over-large buffer >> size and a short string. The string gets stored in the first few >> bytes of the buffer, while the rest are uninitialized. The attacker >> gets back a lot of left-over bytes from whatever the buffer was used >> for previously. It would then have to figure out what it actually got >> and how to exploit it, but the data is at least there. >> >> Modula-3, as it is would likely not have prevented this. The language >> requires only that all newly allocated variables come into existence >> with some bit pattern that is a legal value of the type. For many >> types, this would require a compiler-generated runtime initialization, >> which would have overlaid the leftover sensitive data. But for a type >> whose value set covers all bit patterns of the machine-level >> representation, the language rule is satisfied with no initialization. >> >> Coded in Modula-3, the buffer would almost surely been typed as an >> array of CHAR or array of some other discrete type whose range exactly >> uses a byte, thus requiring no compiler-generated initialization and >> leaving the sensitive data intact. >> >> I have long been ambivalent about this language rule. I see the >> argument for it. It is the minimum runtime penalty that ensures the >> abstract type system of the language behaves as expected. But it also >> allows some things to happen that, although not type-safety bugs, are >> nevertheless undefined behaviour, even if explainable in the abstract >> data system of the language. >> >> Defined initialization of everything would have prevented the >> Heartbleed bug from compromising sensitive data. It would also make >> uninitialized (by explicit source code) bugs deterministic and >> repeatable, which is a huge advantage. The cost would be small >> constant-time execution speed losses, greatly diluted by other things. > > constant-time? only if they are only ever executed once each. > >> >> This would allow us to claim publically that modern Modula-3 would >> have prevented the Heartbleed bug from compromising anything. >> >> We could also implement this without stating it in the language, but I >> think that might be something of the worst of both worlds, since one >> could not fully rely on it's staying that way. >> >> What does everyone think? >> >> P.S.: It's pretty easy to define the values and pretty easy to >> implement. > > And pretty slow if the first thing you do with that storage is to > initialize it yourself. > I'd be in favour of such an initialization as a compile-time option it > the values were values that are not likely to be welcome in normal use, > so that the programmer's missed initialiations are likely to show > up. for example, a NaN for floating point. Hmm, defining it in the language for floating piont is harder than had occurred to me. A NaN is obviously right, but not all floating point representations have NaNs, and the language needs not to require them. Actually, it would be sufficient for the original example if variables were just initialized, not necessarily to anything in particular, as long as it didn't depend on anything happening at runtime. > But in production I'd really like the option of turning this off if > performance is critical. > And even if it's on, I'd like the optimiser, if any, to remove these > default initialisations if it can determine that the default > initializations are dead. Yes, I would take it for granted that well-known and already implemented optimizations would do this. > > (that said, I hardly ever turn checking options off in practice.) > > -- hendrik >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri Jun 6 16:28:37 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Jun 2014 09:28:37 -0500 Subject: [M3devel] Heartbleed, initialization, and Modula-3 In-Reply-To: References: <538FA022.2060501@lcwb.coop> Message-ID: <5391D015.3070604@lcwb.coop> On 06/05/2014 03:06 AM, Antony Hosking wrote: > I note that a heap-allocated string will be zeroed in the current implementation (AFAIR). > > Sent from my iPad So we can probably claim today that Modula-3, as implemented, would have prevented heartbleed from disclosing sensitive data. The offending buffer would almost surely been heap-allocated. > >> On Jun 5, 2014, at 12:39 AM, "Rodney M. Bates" wrote: >> >> Olaf's recent mention of safe languages and Heartbleed prompted me to >> look into the specifics of the bug, particularly to see what Modula-3 >> might have done to prevent it. >> >> According to the descriptions I found, a recent protocol extension >> (called "heartbeat") allows one machine (call it the client) to ask >> another (call it the server) to echo a verbatim copy of an arbitrary >> character string, I suppose to check whether the server is alive and >> responding. >> >> The request message contains two redundant string lengths, one part of >> the string itself (in a way not described in the descriptions I saw, >> but it doesn't matter) and one prepended at the beginning, so the >> server can allocate a buffer prior to storing the string. The two >> were probably presumed to be equal, but nothing forces this. How good >> a protocol design this is could be debated. >> >> The real bug is in the server-side implementation, which uses the >> requested buffer size rather than the sent string length as the length >> of the string to echo. So an attacker can give an over-large buffer >> size and a short string. The string gets stored in the first few >> bytes of the buffer, while the rest are uninitialized. The attacker >> gets back a lot of left-over bytes from whatever the buffer was used >> for previously. It would then have to figure out what it actually got >> and how to exploit it, but the data is at least there. >> >> Modula-3, as it is would likely not have prevented this. The language >> requires only that all newly allocated variables come into existence >> with some bit pattern that is a legal value of the type. For many >> types, this would require a compiler-generated runtime initialization, >> which would have overlaid the leftover sensitive data. But for a type >> whose value set covers all bit patterns of the machine-level >> representation, the language rule is satisfied with no initialization. >> >> Coded in Modula-3, the buffer would almost surely been typed as an >> array of CHAR or array of some other discrete type whose range exactly >> uses a byte, thus requiring no compiler-generated initialization and >> leaving the sensitive data intact. >> >> I have long been ambivalent about this language rule. I see the >> argument for it. It is the minimum runtime penalty that ensures the >> abstract type system of the language behaves as expected. But it also >> allows some things to happen that, although not type-safety bugs, are >> nevertheless undefined behaviour, even if explainable in the abstract >> data system of the language. >> >> Defined initialization of everything would have prevented the >> Heartbleed bug from compromising sensitive data. It would also make >> uninitialized (by explicit source code) bugs deterministic and >> repeatable, which is a huge advantage. The cost would be small >> constant-time execution speed losses, greatly diluted by other things. >> >> This would allow us to claim publically that modern Modula-3 would >> have prevented the Heartbleed bug from compromising anything. >> >> We could also implement this without stating it in the language, but I >> think that might be something of the worst of both worlds, since one >> could not fully rely on it's staying that way. >> >> What does everyone think? >> >> P.S.: It's pretty easy to define the values and pretty easy to >> implement. >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri Jun 6 16:47:15 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 06 Jun 2014 09:47:15 -0500 Subject: [M3devel] Heartbleed, initialization, and Modula-3 In-Reply-To: <53902F75.1040201@henning-thielemann.de> References: <538FA022.2060501@lcwb.coop> <53902F75.1040201@henning-thielemann.de> Message-ID: <5391D473.1050907@lcwb.coop> On 06/05/2014 03:51 AM, Henning Thielemann wrote: > Am 05.06.2014 00:39, schrieb Rodney M. Bates: > >> Olaf's recent mention of safe languages and Heartbleed prompted me to >> look into the specifics of the bug, particularly to see what Modula-3 >> might have done to prevent it. > > My general experience is that a language is only as safe as the programmer wants to. You can add as many safety belts as you like, a careless programmer will always find a way to remove them. I consider the value of safe languages the other way round: A careful programmer can get a lot of security support from a safe language. > Well, I agree. I have always felt that it was impractical for a language to try to thwart a programmer determined to undermine its safety features. It's mainly to help the programmer who values and wants the help. > The programmer of the heartbleed bug was criticized for rating performance higher than security and other things. There would have been ways to prevent that bug even in C. > > And yet, the biggest problem, IMO, is the sheer volume of things one must be careful about. I consider myself extremely careful, yet I continue to make bugs. Over the decades, my bug rate per LOC has slowly but steadily declined. But that has meant I can take on bigger bodies of code, so the bug rate per hour of my time has probably pretty much held up. Prior to the last 3 or so years, I kept logs of every bug, classified and periodically tabulated them. One thing I found is the distribution has steadily been skewing more toward simple oversights that I knew perfectly well better than, leaving the subtle algorithmic bugs less frequent. I consider this good news, because it is exactly the huge volume of trivial little things that a language can help with, leaving more of my limited attention to those it cannot. The situation tilts even more in favor of safe languages when doing maintenance. Here, the information about what needs to be checked-on is just so widely distributed over so much code. In practice, it's hardly possible to dig it all out, though I certainly give it a good try. A safe language helps immensely. -- Rodney Bates rodney.m.bates at acm.org From hendrik at topoi.pooq.com Fri Jun 6 23:36:06 2014 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 6 Jun 2014 17:36:06 -0400 Subject: [M3devel] Heartbleed, initialization, and Modula-3 In-Reply-To: <5391D473.1050907@lcwb.coop> References: <538FA022.2060501@lcwb.coop> <53902F75.1040201@henning-thielemann.de> <5391D473.1050907@lcwb.coop> Message-ID: <20140606213606.GB2400@topoi.pooq.com> On Fri, Jun 06, 2014 at 09:47:15AM -0500, Rodney M. Bates wrote: > > > On 06/05/2014 03:51 AM, Henning Thielemann wrote: > > Prior to the last 3 or so years, I kept logs of every bug, classified and > periodically tabulated them. One thing I found is the distribution has > steadily been skewing more toward simple oversights that I knew perfectly > well better than, leaving the subtle algorithmic bugs less frequent. I > consider this good news, because it is exactly the huge volume of trivial > little things that a language can help with, leaving more of my limited > attention to those it cannot. > > The situation tilts even more in favor of safe languages when doing maintenance. > Here, the information about what needs to be checked-on is just so widely distributed > over so much code. In practice, it's hardly possible to dig it all out, though > I certainly give it a good try. A safe language helps immensely. Yes. I found a bug log to be quite interesting. In the early 70's I kept a bug log while writing an Algol 68 compiler. I found that almost all my bugs could have been caught by the compiler at compile time if I had written it *in* Algol 68. Sometime later I had the opportunity to use a commercially written Algol 68 on the CDC Cyber, and found that my bugs *were* caught at comile time. Algol 68 and Modula 3 are the only languages in which I have written substantial blocks of code (500 lines or more) that ran correctly first time. I suspect that OCaml is another such language. I think that all programming lnguage designers should keep bug logs, and let the results influnce their language designs in an iterative desiign process. -- hendrik From rodney_bates at lcwb.coop Mon Jun 23 04:03:57 2014 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 22 Jun 2014 21:03:57 -0500 Subject: [M3devel] cvs->git propagation? Message-ID: <53A78B0D.1030600@lcwb.coop> I had somehow gotten the impression that commits to the cvs elegosoft repository are being automatically propagated to the githup repo. But it doesn't seem to be happening, after a few days. I couldn't find a post on this subject. Did I misunderstand? Is it going the other direction? Am I just not patient enough? -- Rodney Bates rodney.m.bates at acm.org From dragisha at m3w.org Mon Jun 23 08:17:23 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 23 Jun 2014 08:17:23 +0200 Subject: [M3devel] cvs->git propagation? In-Reply-To: <53A78B0D.1030600@lcwb.coop> References: <53A78B0D.1030600@lcwb.coop> Message-ID: <7438F686-33C9-4C82-8A3B-03DA2B32C1BA@m3w.org> It is not automatic, I hope it will work as advertised (incrementally) once I start process on my box. Later this week, when I get time for this work. On 23 Jun 2014, at 04:03, Rodney M. Bates wrote: > I had somehow gotten the impression that commits to the cvs elegosoft repository > are being automatically propagated to the githup repo. But it doesn't seem to > be happening, after a few days. I couldn't find a post on this subject. > > Did I misunderstand? Is it going the other direction? Am I just not patient > enough? > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- 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 Jun 1 09:07:00 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Jun 2014 09:07:00 +0200 Subject: [M3devel] Git synchronized to CVS@May30 In-Reply-To: References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org> Message-ID: <6E6D5980-F37A-4FB9-83FF-7FB27F06BFEE@m3w.org> Darko and Henning added. I don?t know if github?s jaykrell is our Jay? dd On 31 May 2014, at 23:01, Dragi?a Duri? wrote: > I have added Rodney and Anthony for now. And I am waiting for few other people to give me exact data. And everybody else to give me any data :) > > What I need is short form show on github, to be sure it is you I am adding. Thanks in advance! > > dd > > On 31 May 2014, at 21:56, Dragi?a Duri? wrote: > >> https://github.com/dragisha/cm3 >> >> Please let me have your usernames on github. >> >> I am continuing now through Jenkins setup. I hope to have few platforms happily building from tomorrow on. >> >> dd >> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dragisha at m3w.org Sun Jun 1 12:17:54 2014 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 1 Jun 2014 12:17:54 +0200 Subject: [M3devel] Git synchronized to CVS@May30 In-Reply-To: References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org> Message-ID: Of course all will be preserved. Current priority is what is alive and being changed right now. hudson-config I will use while setting Jenkins up, to learn from previous experience. And other repos will be preserved one by one. Especially pm3. dd On 01 Jun 2014, at 11:42, Kai Henningsen wrote: > On Sat, May 31, 2014 at 9:56 PM, Dragi?a Duri? wrote: >> https://github.com/dragisha/cm3 > > I see you have > > modula3.elegosoft.com:/usr/cvs/cm3/ > > However, what about > > modula3.elegosoft.com:/usr/cvs/hudson-config/ > modula3.elegosoft.com:/usr/cvs/m3-misc/ > modula3.elegosoft.com:/usr/cvs/m3-misc-new/ > modula3.elegosoft.com:/usr/cvs/pm3/ > modula3.elegosoft.com:/usr/cvs/testing/ > > ? At least some of those seem as though they should be preserved, too. > Especially pm3. > > -- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCM/CS/IT d s+: a++ C++ UL++++ P+++ L+++ E--- W++@ N@ !o !K w(++) O-@ > M-@ V-- PS++@ PE- Y+ PGP+@ t- 5 X- !tv b++>+++ D--- G e+ h-- !r y? > ------END GEEK CODE BLOCK------ -------------- 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 Sun Jun 1 12:20:49 2014 From: jay.krell at cornell.edu (Jay K) Date: Sun, 1 Jun 2014 10:20:49 +0000 Subject: [M3devel] Starting out with CM3 In-Reply-To: <5389E887.5050405@gmail.com> References: <53893F74.1040608@gmail.com>,<5389E887.5050405@gmail.com> Message-ID: > MinGW I got this working years ago, but it isn't in active use. Things are structured now such that bit-rot is fairly slow, so it could still work. Someone besides me should document the cross/bootstrap steps, that granted, I advocate and use: First you will want a working install on any system. Then you will: cd scripts/python boot1.py I386_MINGW if this works, you'll have a .tar.gz or .zip there. Extract it on target system, cd into it, make. That gives you cm3. Make sure it runs and prints "can't find config" or similar. Put it somewhere, on $PATH, e.g. /cm3/bin, and then boot2.sh. You could try these old builds: http://opencm3.net/uploaded-archives/index.html http://opencm3.net/uploaded-archives/cm3-min-NT386MINGNU-d5.7.1.tar.gz etc. There is also I386_CYGWIN. And I386_INTERIX which is noticeably faster due to fast fork. NT386GNU and NT386MINGNU are old names for I386_CYGWIN and I386_MINGW. - Jay > Date: Sat, 31 May 2014 22:34:47 +0800 > From: bruce.axtens at gmail.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Starting out with CM3 > > Oh and while I'm at it, seeing as I have a recent MinGW here, how do I > build for MinGW? > > Bruce. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.axtens at gmail.com Sun Jun 1 14:13:20 2014 From: bruce.axtens at gmail.com (Bruce M. Axtens) Date: Sun, 01 Jun 2014 20:13:20 +0800 Subject: [M3devel] Git synchronized to CVS@May30 In-Reply-To: References: <5FF92F6E-F252-4A56-B5C2-5C9436509762@m3w.org>