<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
The system works fairly well, but also could use some obvious improvement.<br><br><br>What do people want to work on that I am in the way of?<br>If you do actually work on the same file as I do, you can still merge.<br>Source control is not mutual exclusion.<br>Granted, CVS doesn't help nearly as much as other source control systems.<br>Perforce is the best I have used, by far, among just a few.<br><br><br>Some of the possible future directions moot others.<br>For example, enabling/fixing the typinfo in the gcc backend would be nice, but<br>replacing it with LLVM and/or C++ and/or integrated backends moots that.<br><br><br>Ditto for using the gcc exception handling infrastructure.<br><br><br><br>Anything anyone is interested in doing, please speak up, and/or send diffs, and/or commit changes.<br> Please don't be offended or discouraged if changes are backed out, if they don't work for some people.<br> If there is target-dependence, consider some way to enable/disable based on target, and only<br> enabling what you can test, waiting for others to test/enable others.<br><br><br>I agree we have too little contribution from too few people, but not clear why.<br>There are possibilities other than blaming me.<br>The system has its interesting characteristics asis, but competition from other languages and libraries are probably more the cause (be careful not to confuse them!): C, C++, Qt, Java, GWT, C#, Perl, Python, Ruby, Tcl, Bash, "HTML", PHP, JavaScript, wxWindows, LUA, etc.<br>It is indeed unusual to have a system with optional safety and native code generation (vs. interpreter or JIT).<br>Just optional safety is rare, and present mainly only C#. I can't think of another language with optional safety and native code generation (granted, I can only name two languages with optional safety: Modula-3 and C#).<br>Having a proper module system is also great, as it makes compilation very fast, on NT386 (similar to Java and C#).<br><br><br> - Jay<br><br>> From: rcolebur@SCIRES.COM<br>> To: m3devel@elegosoft.com<br>> Date: Thu, 30 Dec 2010 17:29:50 -0500<br>> Subject: Re: [M3devel] CM3 status<br>> <br>> Olaf et al:<br>> <br>> I think I share the concern you've voiced.<br>> <br>> My observation from the M3COMMIT log emails is that Jay seems to be the most prolific these days with changes, but I find it impossible to keep track of what problem he is trying to solve. Indeed, it seems he is working on multiple issues at the same time, but it is difficult from the posts to differentiate which issue goes with which posting, and this problem is compounded by the fact that my M3COMMIT/M3DEVEL e-mails don't always seem to be received in chronological order.<br>> <br>> Thus, it is extremely difficult to know how to channel the limited time I have available into helping cooperate to solve a particular problem.<br>> <br>> Maybe it would be a good idea when each person posts something to M3COMMIT or M3DEVEL that they tag it up front with a comment or reference to the problem the post is addressing.<br>> <br>> Another idea, and perhaps your TRAC system supports it, is to assign certain problems to specific individuals who work the problem and report back their solution approach for some type of concurrence before going off on a tangent to solve. This might cut down on some of the subsequent backtracking and reverting changes. It would also allow others to offer constructive comments on the solution approach, even if they don't have time to actually implement the solution. [In reading the posts, I'm seeing many places where work is done, then later someone disagrees with it, and wants the changes reverted.]<br>> <br>> Even if one person is assigned as the lead for a particular problem, perhaps others could join in on helping solve it, coordinating their effort thru the lead person.<br>> <br>> I really do want to help as much as I can, and we definitely need to grow the development support base, so anything we can do to foster teamwork and an up-to-date awareness of the major problem areas and proposed solution paths would be helpful I think.<br>> <br>> I certainly don't want to squash anyone's individual efforts, but right now I don't think we're maximizing our use of the team concept.<br>> <br>> Regards,<br>> Randy Coleburn<br>> <br>> -----Original Message-----<br>> From: Olaf Wagner [mailto:wagner@elegosoft.com] <br>> Sent: Thursday, December 30, 2010 6:23 AM<br>> To: m3devel@elegosoft.com<br>> Subject: [M3devel] CM3 status<br>> <br>> Hi all,<br>> <br>> after reading a couple of Modula-3 mails again after some time of<br>> 'abstinence' I'm a little bit confused about the state of the code<br>> and the direction of development. I see that several different failures<br>> and ideas are discussed, but don't seem to get resolved; none of them<br>> is documented in our Trac instance as far as I know. Some things I<br>> remember offhand:<br>> <br>> o at least 2 different compiler/assembler problems on Darwin/Snow Leopard<br>> o current gcc not working on Solaris (?!)<br>> o stack walker code abandoned<br>> o possibly unsafe OS calls in new C code (this may be a wrong deduction<br>> from my side)<br>> o GUI input not working for BadBricks and other games (only on Darwin?)<br>> o no clean way for exception handling with current gcc<br>> o still alignment issues<br>> <br>> I'm concerned that things get tried out, don't work properly for all<br>> our target platforms, but are left then and not cleaned up and something<br>> else gets tried. I'm not sure this is correct, it is just me feeling<br>> unwell after reading all those mails.<br>> <br>> Hudson and Tinderbox status seem to be mostly OK though, but I haven't<br>> checked in detail (FreeBSD failing was a disk failure on my system<br>> recently). But the tests don't cover all the things we should check.<br>> <br>> I think it would be good to have an overview of the projects/work that<br>> is in progress or pending and its status. For example, we've imported<br>> a new gcc version, but that doesn't seem to work well on all targets,<br>> or does it? If not, how are we going to address this? Use older versions<br>> on some platforms? Can I read up on that somewhere?<br>> <br>> I'd like to suggest to simply use our Trac WiKi to document the ongoing<br>> work (everybody can get write access to that on request) and to record<br>> all errors, failures and major tasks there as issues. This should help<br>> everybody to participate and make me much more relaxed if I consider<br>> the M3 emails (if anybody should care about my personal discomfort<br>> at all :-)<br>> <br>> Just for reference: the trac instance can be found at<br>> https://projects.elego.de/cm3<br>> <br>> Several of the committers should already have access, and using<br>> the WiKi and the issue tracker should not be much more work than<br>> writing emails. But the information will be easier to access then.<br>> <br>> I hope to have offended nobody by this; I just wanted to make a suggestion<br>> how to improve collaboration and discussion.<br>> <br>> Olaf<br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <br> </body>
</html>