From mika at async.caltech.edu Fri Feb 1 11:08:49 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 01 Feb 2013 02:08:49 -0800 Subject: [M3devel] Information about record/object field name. In-Reply-To: <510A95E6.4000308@lcwb.coop> References: <510A95E6.4000308@lcwb.coop> Message-ID: <20130201100849.D91041A207D@async.async.caltech.edu> Of course field-order independent serialization won't actually work in Modula-3 unless you know what you are doing. (You will need to know more than just the field name, in particular.) Consider the following: TYPE T = OBJECT f : F; END; U = T OBJECT f : F; END; VAR u : U; with these declarations, the object "u" has two fields of the same type F called f. A reference to u of type U, e.g., VAR p : U := u; will see the second field and VAR q : T := u; will see the first field. You can also switch fields by using NARROW. In any case there will be two fields of the same name. This is not some accident of the language or a mistake or even bad coding practice. It was deliberately done this way for the sake of modularity. Mika "Rodney M. Bates" writes: >This question raises several others in my mind. > >Since you mention a serializer, do I correctly presume you want >the field names of a record/object type that exists in the same >program doing the reading? > >Are you familiar with the existing compiler-generated type information, >in RTTypeMap.i3 and RTTipeMap.i3, and accessible at runtime using RT0.i3 >and other things in m3-libs/m3core/src/runtime/common/*, and produced by >the compiler in, e.g., m3-sys/m3front/src/misc/TipeDesc.i3? > >Unfortunately, neither of these kinds of runtime type information has >field names, only a lists of field types in order. For a serializer, >runtime type information would be a far more convenient source, since >it would not require having either source files or separate derived files (.M3WEB). >Adding the field names here would probably not be a big coding change, >but a change in runtime data structure would no doubt be a big bootstrapping >and upgrading operation, for all concerned. > >Field names are also available in the generated debug information. But >even though this might be a more convenient location to get it from, >decoding it this way would be a nightmare. It's a specialized derivative >of stabs, with lots of Modula-3-specific stuff mangled and encoded inside >the string fields of stabs records. gdb has gobs of code to read in >general stabs and m3gdb has gobs more to further decode it, all in c. >Moreover, there are quite a few differences in what is produced by >various compilers, depending on the version of the M3 front end, the >version of the gcc-derived code generator or the other code generators, >and the target. > >The idea of field-order independent serializing at first seemed pointless >to me. I think the intent must be to allow a serialized object to be >deserialized into a different program as a different type, with different >field orders. Is this the intent? what are the rules about how different >a type can be and still be used in this way? Is it cross-language too? > >The existing Modula-3 serializer (m3-libs/libm3/src/pickle/ver2/Pickle2.i3 etc.) >requires that there be type in the deserializing program that is an exact >(structural) match to the type in the serializing program, according to the >language's rules of type equality. Pickle enforces this by looking for equality >of a 64-bit "signature" that is a hash on a type structure, with the >assumption collisions will not occur. > >Perhaps you have read enough of the runtime, compiler, and serializer >to know all this already. > >Tell us more about the json serializer. > >On 01/28/2013 11:30 AM, Alexey Veselovsky wrote: >> Hello. >> >> It is possible to retrieve field names for given Record or Object type? >> >> I need it for json serializer. >> >> Also this information useful for creating field-order independent serializer. >> >> Thanks, Alexey. From michael.anderson at elego.de Fri Feb 1 14:22:02 2013 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 01 Feb 2013 14:22:02 +0100 Subject: [M3devel] Can't acces to cvs repo. In-Reply-To: References: Message-ID: <510BC17A.3050701@elego.de> On 1/31/13 4:14 PM, Alexey Veselovsky wrote: > Subj. > > Login timeout: > > # cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > Logging in to :pserver:anonymous at modula3.elegosoft.com:2401/usr/cvs > > CVS password: > > cvs [login aborted]: connect to modula3.elegosoft.com > (46.4.219.187):2401 failed: Connection > timed out > > Thanks, Alexey. Hello Alexy, The cvs pserver port was blocked by our firewall, sorry about that. I've opened the port and the pserver is up and running. Please feel free to contact or me directly at if you have any problems. Best Regards, Michael -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Feb 1 18:31:38 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 01 Feb 2013 11:31:38 -0600 Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: References: Message-ID: <510BFBFA.8060208@lcwb.coop> On 01/30/2013 02:24 AM, Jay K wrote: > I commited a fix. But two questions: > > 1) why not just stat, instead of open, fstat, close? > > 2) a lighter weight way to fix this than I did? > In particular: > a) VAR m := NEW(MUTEX); > can we at least say VAR m: MUTEX instead? I tried. It crashed. I would expect this to crash because m would be default initialized to NIL, which when dereferenced, would show up as a segfault, in any M3 implementation I have experience with. Actually, the language only says it has to be initialized to a bit pattern that represents some member of the type. But for or any reference type, the only sensible choice for a compiler to make would be NIL. Perhaps we should change the language to say this explicitly? I am very confident it wouldn't undermine either any existing code or compiler, and might save some grief in the future. > > b) some notion of a "once"? a lock that will only be successfully entered once, for one-time initialization, all other attempts to enter wait for the first enterer to leave, and the it is never entered again. pthreads has this. Win32 since Vista has it (I'd still provide something compatible to pre-Vista, but it can be done easily enough. > They are faster and perhaps smaller than other kinds of locks. > I shouldn't be hard to wrap these with an interface. Lots of people have agonized over the performance hit every time of "has it been done once". > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 30 Jan 2013 07:40:02 +0000 > Subject: [M3devel] awful race condition in libm3/FilePosix.m3? > > FilePosix.m3: > > > I'm not 100% sure, but looks really bad. > I suspect it will close arbitrary files out from other threads. > Notice there is absolutely no mutual exclusion. > An arbitrary number of threads will run here, mostly succeeding, but not necessarily. > > VAR > null_done := FALSE; > null_stat: Ustat.struct_stat; > null_fd: INTEGER; > > > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = > VAR result: INTEGER; > BEGIN > IF NOT null_done THEN > null_fd := Unix.open(M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); > IF null_fd < 0 THEN > null_done := TRUE; > RETURN FALSE > ELSE > result := Ustat.fstat(null_fd, ADR(null_stat)); > EVAL Unix.close(null_fd); > IF result # 0 THEN > null_fd := -1 > END > END; > null_done := TRUE; > END; > RETURN null_fd >= 0 AND statbuf.st_rdev = null_stat.st_rdev > END IsDevNull; > > > - Jay From dmuysers at hotmail.com Fri Feb 1 19:04:02 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Fri, 1 Feb 2013 19:04:02 +0100 Subject: [M3devel] DLLs Message-ID: Using the standard cm3 tools there is no official way to build a library as a DLL. Hence, out of curiosity, the following question: Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 1 21:16:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 1 Feb 2013 20:16:29 +0000 Subject: [M3devel] DLLs In-Reply-To: References: Message-ID: Dirk, From my memory, you have it backwards. .dlls are built by default for any "library".You can suppress .dll building with build_standalone(). It works like this, it is a bit unusual, but kind of nice: f or every "library", we build a static library and a .dll/.so "programs" default to linking to .dlls if present, else static libraries - Jay From: dmuysers at hotmail.com To: m3devel at elegosoft.com Date: Fri, 1 Feb 2013 19:04:02 +0100 Subject: [M3devel] DLLs Using the standard cm3 tools there is no official way to build a library as a DLL. Hence, out of curiosity, the following question: Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Feb 2 07:16:18 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 01 Feb 2013 22:16:18 -0800 Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: <510BFBFA.8060208@lcwb.coop> References: <510BFBFA.8060208@lcwb.coop> Message-ID: <20130202061618.46C6E1A207D@async.async.caltech.edu> "Rodney M. Bates" writes: ... >I would expect this to crash because m would be default initialized to NIL, >which when dereferenced, would show up as a segfault, in any M3 implementation >I have experience with. > >Actually, the language only says it has to be initialized to a bit >pattern that represents some member of the type. But for or any reference >type, the only sensible choice for a compiler to make would be NIL. > >Perhaps we should change the language to say this explicitly? I am >very confident it wouldn't undermine either any existing code or compiler, >and might save some grief in the future. ... The only problem with this proposal is that to me, as a human, VAR m : MUTEX := NIL; ... today means something different from VAR m : MUTEX; notwithstanding the fact that the compiler may implement them the same way. Mika From darko at darko.org Sat Feb 2 09:19:44 2013 From: darko at darko.org (Darko) Date: Sat, 2 Feb 2013 00:19:44 -0800 Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: <20130202061618.46C6E1A207D@async.async.caltech.edu> References: <510BFBFA.8060208@lcwb.coop> <20130202061618.46C6E1A207D@async.async.caltech.edu> Message-ID: <9FF533CE-7B33-4A62-ABD8-13A29B9E1F38@darko.org> I agree with Mika's use of style, but it isn't really affected by the proposed change. I've always thought the notion that the compiler would ever initialize a reference to a value other than Nil unconvincing. The exception would be TEXT references. Then there might be others in the future. The argument for keeping the definition as it is is that it's simple. On Feb 1, 2013, at 10:16 PM, mika at async.caltech.edu wrote: > "Rodney M. Bates" writes: > ... >> I would expect this to crash because m would be default initialized to NIL, >> which when dereferenced, would show up as a segfault, in any M3 implementation >> I have experience with. >> >> Actually, the language only says it has to be initialized to a bit >> pattern that represents some member of the type. But for or any reference >> type, the only sensible choice for a compiler to make would be NIL. >> >> Perhaps we should change the language to say this explicitly? I am >> very confident it wouldn't undermine either any existing code or compiler, >> and might save some grief in the future. > ... > > The only problem with this proposal is that to me, as a human, > > VAR m : MUTEX := NIL; > > ... > > today means something different from > > VAR m : MUTEX; > > notwithstanding the fact that the compiler may implement them the same way. > > Mika > From dabenavidesd at yahoo.es Sat Feb 2 15:29:43 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Feb 2013 14:29:43 +0000 (GMT) Subject: [M3devel] DLLs In-Reply-To: Message-ID: <1359815383.71359.YahooMailClassic@web133104.mail.ir2.yahoo.com> Hi all: indeed you can convert it backwards program called m3-sys/dll2lib I guess if translation process is backwards executed it can do your process, without a problem as long as any type information is lost during normal execution Thanks in advance --- El vie, 1/2/13, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] DLLs Para: "Dirk Muysers" , "m3devel" Fecha: viernes, 1 de febrero, 2013 15:16 Dirk, From my memory,?you have it backwards. .dlls are built?by default for any "library".You can suppress .dll building with build_standalone().?It works like this, it is a bit unusual, but kind of nice:?f or every "library", we build a static library and a .dll/.so?"programs" default to linking to .dlls if present, else static libraries ???- Jay ?From: dmuysers at hotmail.com To: m3devel at elegosoft.com Date: Fri, 1 Feb 2013 19:04:02 +0100 Subject: [M3devel] DLLs Using the standard cm3 tools there is no official way to build a library as a DLL. Hence, out of curiosity, the following question: Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Feb 2 15:38:54 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Feb 2013 14:38:54 +0000 (GMT) Subject: [M3devel] Can't acces to cvs repo. In-Reply-To: <510BC17A.3050701@elego.de> Message-ID: <1359815934.45082.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi all: I think Elego cvs web client is still down or something at: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/ Maybe the security system works but not at that layer level ( hum, maybe this causes cvsup trouble as well?), but upper one, or your link is broken Thanks in advance --- El vie, 1/2/13, Michael Anderson escribi?: De: Michael Anderson Asunto: Re: [M3devel] Can't acces to cvs repo. Para: m3devel at elegosoft.com Fecha: viernes, 1 de febrero, 2013 08:22 On 1/31/13 4:14 PM, Alexey Veselovsky wrote: Subj. Login timeout: # cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login Logging in to :pserver:anonymous at modula3.elegosoft.com:2401/usr/cvs CVS password:? cvs [login aborted]: connect to modula3.elegosoft.com(46.4.219.187):2401 failed: Connection timed out Thanks, Alexey. Hello Alexy, The cvs pserver port was blocked by our firewall, sorry about that. I've opened the port and the pserver is up and running. Please feel free to contact or me directly at if you have any problems. Best Regards, Michael -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Feb 2 21:55:30 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Feb 2013 20:55:30 +0000 (GMT) Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: <9FF533CE-7B33-4A62-ABD8-13A29B9E1F38@darko.org> Message-ID: <1359838530.51873.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi all: you can still use simulated I/O error using a faulty memory component address to some extent, for instance a VAX9000 would immediately shutdown the memory to processor circuit, and kill process using it if possible. If a HW error is scanned and detected prior completion of the program the value is? detected by the test scanner and thus avoid the instruction completion or refusing to run the program (silently or verbosely). Alpha had a similar feature but in execution time. Sorry i don't thing I remember that well details. In a different processor there might be aleatory error in CPU but it won't stop the process already running which is UNSAFE, that's where you might want to use some NIL constant, but in general you cannot "simulate" that error only with that system trap as said because you can prevent the error or ignore it? in a safe way (obviously not with other processors misleading errors). Thanks in advance --- El s?b, 2/2/13, Darko escribi?: De: Darko Asunto: Re: [M3devel] awful race condition in libm3/FilePosix.m3? Para: mika at async.caltech.edu CC: m3devel at elegosoft.com Fecha: s?bado, 2 de febrero, 2013 03:19 I agree with Mika's use of style, but it isn't really affected by the proposed change. I've always thought the notion that the compiler would ever initialize a reference to a value other than Nil unconvincing. The exception would be TEXT references. Then there might be others in the future. The argument for keeping the definition as it is is that it's simple. On Feb 1, 2013, at 10:16 PM, mika at async.caltech.edu wrote: > "Rodney M. Bates" writes: > ... >> I would expect this to crash because m would be default initialized to NIL, >> which when dereferenced, would show up as a segfault, in any M3 implementation >> I have experience with. >> >> Actually, the language only says it has to be initialized to a bit >> pattern that represents some member of the type.? But for or any reference >> type, the only sensible choice for a compiler to make would be NIL. >> >> Perhaps we should change the language to say this explicitly?? I am >> very confident it wouldn't undermine either any existing code or compiler, >> and might save some grief in the future. > ... > > The only problem with this proposal is that to me, as a human, > > VAR m : MUTEX := NIL; > > ... > > today means something different from > > VAR m : MUTEX; > > notwithstanding the fact that the compiler may implement them the same way. > >? ???Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 4 08:14:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 4 Feb 2013 07:14:56 +0000 Subject: [M3devel] Socket error hacks for Ultrix and OSF? Message-ID: We have: WITH errno = GetError() DO IF errno = EINVAL THEN (* hack to try to get real errno, hidden due to NBIO bug in connect *) RefetchError (t.fd); ELSIF errno = EBADF THEN (* we'll try the same for EBADF, which we've seen on Alpha *) RefetchError (t.fd); END; END; PROCEDURE RefetchError(fd: INTEGER) = (* Awful hack to retrieve a meaningful error from a TCP accept socket. Only works on Ultrix and OSF. Leaves result in GetError(). *) VAR optbuf: int := 0; optlen: socklen_t := BYTESIZE(optbuf); BEGIN IF SocketPosix_IsUltrixOrOSF.Value THEN EVAL getsockopt (fd, IPPROTO_TCP, TCP_NODELAY, ADR(optbuf), ADR(optlen)); END; END RefetchError; does anyone know or believe this is useful code? Does anyone object to removing it? I don't believe we'll ever run on Ultrix. OSF/Tru64 is of very marginal interest. Posix doesn't bless this code. It seems ok without this -- it is a subtle matter of precisely which error is raised. Portable code can't depend on the supposedly better Ultrix/OSF behavior, unless they are substandard and return EINVAL/EBADF when other systems return something more specific. If I could find this workaround in any half way recently maintained C or C++ (Perl? Python?) I'd feel a lot better. I guess I'll look. More generally I'd like to see the essentially 4 socket libraries we have (libm3/posix, libm3/win32, m3-comm/win32, m3-comm/posix) merged into one portable C file, and support IPv6... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Mon Feb 4 12:27:55 2013 From: wagner at elego.de (Olaf Wagner) Date: Mon, 4 Feb 2013 12:27:55 +0100 Subject: [M3devel] Compiler upgrade broken in Hudson CI Message-ID: <20130204122755.f9b56cdb.wagner@elego.de> I only just came around to have a look at the recent Hudson CI runs for the cm3 compiler build. It seems that the upgrade path implemented in scripts/upgrade.sh is broken now: http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console What has changed in the dependencies? How to fix upgrade.sh? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Feb 4 13:16:02 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2013 23:16:02 +1100 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <20130204122755.f9b56cdb.wagner@elego.de> References: <20130204122755.f9b56cdb.wagner@elego.de> Message-ID: <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> Jay? Sent from my iPad On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > I only just came around to have a look at the recent Hudson CI runs for > the cm3 compiler build. It seems that the upgrade path implemented in > scripts/upgrade.sh is broken now: > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > What has changed in the dependencies? > How to fix upgrade.sh? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 4 22:09:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 4 Feb 2013 21:09:57 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> References: <20130204122755.f9b56cdb.wagner@elego.de>, <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> Message-ID: I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 4 Feb 2013 23:16:02 +1100 > To: wagner at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > Jay? > > Sent from my iPad > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > I only just came around to have a look at the recent Hudson CI runs for > > the cm3 compiler build. It seems that the upgrade path implemented in > > scripts/upgrade.sh is broken now: > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > What has changed in the dependencies? > > How to fix upgrade.sh? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 4 22:46:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 4 Feb 2013 21:46:05 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, Message-ID: ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; wagner at elego.de Date: Mon, 4 Feb 2013 21:09:57 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 4 Feb 2013 23:16:02 +1100 > To: wagner at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > Jay? > > Sent from my iPad > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > I only just came around to have a look at the recent Hudson CI runs for > > the cm3 compiler build. It seems that the upgrade path implemented in > > scripts/upgrade.sh is broken now: > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > What has changed in the dependencies? > > How to fix upgrade.sh? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Feb 5 07:51:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 06:51:15 +0000 Subject: [M3devel] socket options? Message-ID: Realize that the socket API is almost identical on Win32 and Posix. And the Modula-3 libraries are therefore almost identical -- unfortunately duplicated.. SocketPosix.m3: PROCEDURE InitStream (fd: CARDINAL) RAISES {OSError.E} = (* We assume that the runtime ignores SIGPIPE signals *) VAR one : int := 1; linger := struct_linger{1, 1}; BEGIN EVAL setsockopt(fd, SOL_SOCKET, SO_LINGER, ADR(linger), BYTESIZE(linger)); EVAL setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, ADR(one), BYTESIZE(one)); MakeNonBlocking (fd); END InitStream; PROCEDURE MakeNonBlocking (fd: INTEGER) RAISES {OSError.E} = VAR old_mode := fcntl (fd, F_GETFL, 0); new_mode := Word.Or (old_mode, M3_NONBLOCK); BEGIN IF fcntl (fd, F_SETFL, new_mode) = -1 THEN IOError (Unexpected); END; END MakeNonBlocking; SocketWin32.m3 PROCEDURE InitSock (sock: SOCKET) = (* We assume that the runtime ignores SIGPIPE signals *) VAR one: int := 1; linger := struct_linger{0, 0}; BEGIN EVAL setsockopt (sock, SOL_SOCKET, SO_LINGER, ADR(linger), BYTESIZE(linger)); (**** WinSock documentation warns that this may cause problems ****) EVAL setsockopt (sock, IPPROTO_TCP, TCP_NODELAY, ADR(one), BYTESIZE(one)); END InitSock; The meaning of struct_linger is the SAME on Posix and Win32. The fact that Modula-3 passes "opposite" parameters is clearly broken. so, obvious questions: Do we need either setsockopt? Clearly if we use SO_LINGER, we should use the same parameters. TCP_NODELAY seems to be generally discouraged. But it seems to usually have a real meaning, and removing it here would break things? In particular, it, like, turns off buffering. It means if you do write with just one byte, it will be sent immediately. If that is the "last" byte for a "while", ok. If you are making a series of small writes, it pays very much to coalesce them into fewer larger writes, at the cost of delaying the earlier writes. Here is an example of implicity discouraging it: http://smalltalk.gnu.org/project/issue/119 "The tcp delay, aka. nagles algorithm has it's applications and disabling it should be done only in special applications (eg. where low-latency for is required) IMO. " Doing this unconditionally for all sockets seems wrong. On the other hand: http://en.wikipedia.org/wiki/Nagle%27s_algorithm paraphrasing part of it: As long as the application does not issue small writes, it is ok. At least this part we do the same for Posix and Win32. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Tue Feb 5 09:11:40 2013 From: wagner at elego.de (Olaf Wagner) Date: Tue, 5 Feb 2013 09:11:40 +0100 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de> <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> Message-ID: <20130205091140.ff4fd78c.wagner@elego.de> On Mon, 4 Feb 2013 21:46:05 +0000 Jay K wrote: > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay Yes, please fix it. I'd like to keep up at least two platforms with the old backend. Olaf > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elego.de > Date: Mon, 4 Feb 2013 21:09:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > To: wagner at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > Jay? > > > > Sent from my iPad > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > scripts/upgrade.sh is broken now: > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > What has changed in the dependencies? > > > How to fix upgrade.sh? > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -- 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 Tue Feb 5 09:28:00 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <20130205091140.ff4fd78c.wagner@elego.de> References: <20130204122755.f9b56cdb.wagner@elego.de>, <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , <20130205091140.ff4fd78c.wagner@elego.de> Message-ID: I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 10:49:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , , , , <20130205091140.ff4fd78c.wagner@elego.de>, Message-ID: Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 11:02:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 10:02:26 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, ,,<79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, ,,, ,,, , , <20130205091140.ff4fd78c.wagner@elego.de>, , , Message-ID: The errors also predate the C mode, slightly. I've seen this, like when the target is wrong, or maybe when there is a change in the cm3cg format. I don't remember if the upgrade process is automated enough for that, cm3cg format changes. There hadn't been an attempted build in months for some reason, since August. I'm also curious to trigger Solaris/opencsw builds. I don't remember my Hudson password. Olaf, can you reset it and send it to me privately, please? Thank you. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 11:11:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 10:11:02 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , , , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , , , , , , , , , , <20130205091140.ff4fd78c.wagner@elego.de>, , , , Message-ID: Here, back in October I changed the m3cg format slightly: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/M3CG_Binary.i3.diff?r1=1.6;r2=1.7;f=u Upgrade should always incrementally build cm3cg. It is developers' responsibility to mistrust the incrementality slightly and edit m3-sys/m3cc/src/clean_marker.txt to trigger a clean build if needed..though the incrementality is all very good in my experience. But wait, maybe I messed up. Hm... Easily fixed though. Let me dig more..maybe not tonight.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Subject: RE: [M3devel] Compiler upgrade broken in Hudson CI Date: Tue, 5 Feb 2013 10:02:26 +0000 The errors also predate the C mode, slightly. I've seen this, like when the target is wrong, or maybe when there is a change in the cm3cg format. I don't remember if the upgrade process is automated enough for that, cm3cg format changes. There hadn't been an attempted build in months for some reason, since August. I'm also curious to trigger Solaris/opencsw builds. I don't remember my Hudson password. Olaf, can you reset it and send it to me privately, please? Thank you. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 11:15:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 10:15:12 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , , , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , , , , , , , , , , <20130205091140.ff4fd78c.wagner@elego.de>, , , , , Message-ID: err..maybe that was only comments... From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Subject: RE: [M3devel] Compiler upgrade broken in Hudson CI Date: Tue, 5 Feb 2013 10:11:02 +0000 Here, back in October I changed the m3cg format slightly: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/M3CG_Binary.i3.diff?r1=1.6;r2=1.7;f=u Upgrade should always incrementally build cm3cg. It is developers' responsibility to mistrust the incrementality slightly and edit m3-sys/m3cc/src/clean_marker.txt to trigger a clean build if needed..though the incrementality is all very good in my experience. But wait, maybe I messed up. Hm... Easily fixed though. Let me dig more..maybe not tonight.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Subject: RE: [M3devel] Compiler upgrade broken in Hudson CI Date: Tue, 5 Feb 2013 10:02:26 +0000 The errors also predate the C mode, slightly. I've seen this, like when the target is wrong, or maybe when there is a change in the cm3cg format. I don't remember if the upgrade process is automated enough for that, cm3cg format changes. There hadn't been an attempted build in months for some reason, since August. I'm also curious to trigger Solaris/opencsw builds. I don't remember my Hudson password. Olaf, can you reset it and send it to me privately, please? Thank you. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 20:05:25 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 19:05:25 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: <20130205190330.AC4175DEB20@birch.elegosoft.com> References: <20130205190330.AC4175DEB20@birch.elegosoft.com> Message-ID: Quake's "fs_rmrec" doesn't work where exec("rm -rf") does. Maybe a matter of deleting links instead of their target? Maybe I fixed it a long time ago? - Jay > Date: Tue, 5 Feb 2013 20:03:30 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/02/05 20:03:30 > > Modified files: > cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile > > Log message: > http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/94/consoleFull > rm -rf ../AMD64_LINUX/gmp > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", line 414: quake runtime error: cannot remove recursively ../AMD64_LINUX/gmp: error traversing directory ../AMD64_LINUX/gmp/mpn > > so try this.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Feb 5 20:46:35 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 5 Feb 2013 19:46:35 +0000 Subject: [M3devel] new release Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> I am in process of getting a new computer to replace my old office computer. I've installed the new Visual Studio 2012 Express and want to rebuild my CM3 source tree. It's been a long time since a new CM3 release was made. I note that Jay has done a lot of work and I'm not sure exactly what is the state of the main branch in the CM3 repository. Would folks advise I stick with the last official release, or update to the current main branch before rebuilding everything? The target machine is running Windows 7 Enterprise edition. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 5 22:13:58 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Feb 2013 08:13:58 +1100 Subject: [M3devel] new release In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> The last official release contains known bugs. Best I think to go with the head of the repository. Sent from my iPhone On 06/02/2013, at 6:46 AM, "Coleburn, Randy" wrote: > I am in process of getting a new computer to replace my old office computer. > I?ve installed the new Visual Studio 2012 Express and want to rebuild my CM3 source tree. > It?s been a long time since a new CM3 release was made. > I note that Jay has done a lot of work and I?m not sure exactly what is the state of the main branch in the CM3 repository. > Would folks advise I stick with the last official release, or update to the current main branch before rebuilding everything? > The target machine is running Windows 7 Enterprise edition. > Thanks, > Randy Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Feb 6 03:14:08 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 6 Feb 2013 02:14:08 +0000 (GMT) Subject: [M3devel] Socket error hacks for Ultrix and OSF? Message-ID: <1360116848.82928.YahooMailClassic@web133102.mail.ir2.yahoo.com> Hi all: Jay I deliberately want to quote you this text for your better understanding [1] (I hope it to be so): "... Software Security Explained The concepts behind secure software are often simple but rarely considered by most programmers in the design and implementation of their programs. The following are prime tenets in writing secure software: Give your software the least privileges it needs. Check all return codes religiously. ..." http://books.google.com.co/books?id=uGiOR1mrxggC&dq=inauthor%3A%22Jeff+Schmidt%22&q=%22software+security%22#search_anchor And specifically for ther matter of "assumptions" and pointer initialization: http://www.drdobbs.com/security/safe-programming-with-modula-3/184408858 note that if you guarantee "assumptions" or " absence of unchecked run-time errors" you can argue that still you export the interface as safe. in SPwM3 [2] p.45 "... 2.5.7 Safety ... An interface is 'intrinsically safe' if there is no way to produce an unchecked runtime error by using the interface in a safe module. ..." Now if you say, the VAX9000 or Alpha had probably errors more than any other computer in the era, it could mean that the VAX9000 or Alpha had runtime unchecked errors (probably by that much as any other but let's read this $1.4.5 Safety paragraph) : SPwM3 p. 7 "... ?1.4.5 Safety ?... Unfortunately, it is generally impossible to program the lowest levels of a system with complete safety. Neither the compiler nor the runtime system can check the validity of a bus address for an I/O controller, nor can they limit the ensuing havoc if it is invalid. This presents the language designer with a dilemma. Of he holds out for safety, then low level code will have to be programmed in another language. But if he adopts unsafe features his safety guarantee becomes void everywhere ..." Now, in every definition of safety of a language there must be the unchecked runtime errors (errors than can occur without isolation guarantee), you must define them explicitly as a subset of all untrapped errors. I think one of them is the mentioned above, if we could agree on this errors by platform we can say our language implementation is safe in this proportions due machine restrictions. In case of VAX9000 architecture segments were defined for separated testing of multichip Modules, you could argue you can still work in a isolated machine and guarantee each piece of Hardware satisfies certain properties, so you could think in a top-down fashion how would you build and test your machine for errors that are HW failures and in some cases avoid running the program in those conditions by using fault tolerance. There was a VAXft9000 and Alpha's versions of itself, of course this costs lot more to work in that way, so in general you can't do that as SPwM3 says, but if you want we can do it. Thanks in advance [1] J. Schmidt, Microsoft Windows 2000 security handbook. Que, 2000. [2] C. G. Nelson, Systems programming with Modula-3. Prentice Hall, 1991. --- El lun, 4/2/13, Jay K escribi?: De: Jay K Asunto: [M3devel] Socket error hacks for Ultrix and OSF? Para: "m3devel" Fecha: lunes, 4 de febrero, 2013 02:14 We have: ????? WITH errno = GetError() DO ??????? IF errno = EINVAL THEN ????????? (* hack to try to get real errno, hidden due to NBIO bug in connect *) ????????? RefetchError (t.fd); ??????? ELSIF errno = EBADF THEN ????????? (* we'll try the same for EBADF, which we've seen on Alpha *) ????????? RefetchError (t.fd); ??????? END; ????? END; PROCEDURE RefetchError(fd: INTEGER) = (* Awful hack to retrieve a meaningful error from a TCP accept ?? socket.? Only works on Ultrix and OSF.? Leaves result ?? in GetError().? *) ? VAR optbuf: int := 0;?? optlen: socklen_t := BYTESIZE(optbuf); ? BEGIN ??? IF SocketPosix_IsUltrixOrOSF.Value THEN ????? EVAL getsockopt (fd, IPPROTO_TCP, TCP_NODELAY, ?????????????????????? ADR(optbuf), ADR(optlen)); ??? END; ? END RefetchError; does anyone know or believe this is useful code? Does anyone object to removing it? I don't believe we'll ever run on Ultrix. OSF/Tru64 is of very marginal interest. Posix doesn't bless this code. It seems ok without this -- it is a subtle matter of precisely which error is raised. Portable code can't depend on the supposedly better Ultrix/OSF behavior, unless they are substandard and return EINVAL/EBADF when other systems return something more specific. If I could find this workaround in any half way recently maintained C or C++ (Perl? Python?) I'd feel a lot better. I guess I'll look. More generally I'd like to see the essentially 4 socket libraries we have (libm3/posix, libm3/win32, m3-comm/win32, m3-comm/posix) merged into one portable C file, and support IPv6... ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 07:44:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 06:44:26 +0000 Subject: [M3devel] LONGINT to INTEGER conversion with last release Message-ID: http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/257/console "../src/M3C.m3", line 275: VAL: first argument must be an INTEGER This error dates to the previous release.The current tree lets the first parameter be a LONGINT.You can doVAL(1L, INTEGER) to convert, I think with range check, a LONGINT to an INTEGER. How do I do that with the last release though? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 08:26:04 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:26:04 +0000 Subject: [M3devel] LONGINT to INTEGER conversion with last release In-Reply-To: References: Message-ID: nevermind, I rewrote the code in C. From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 6 Feb 2013 06:44:26 +0000 Subject: [M3devel] LONGINT to INTEGER conversion with last release http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/257/console "../src/M3C.m3", line 275: VAL: first argument must be an INTEGER This error dates to the previous release.The current tree lets the first parameter be a LONGINT.You can doVAL(1L, INTEGER) to convert, I think with range check, a LONGINT to an INTEGER. How do I do that with the last release though? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 08:30:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:30:17 +0000 Subject: [M3devel] hudson_build_system.sh In-Reply-To: <20130206071829.1256B5DEB30@birch.elegosoft.com> References: <20130206071829.1256B5DEB30@birch.elegosoft.com> Message-ID: Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. It looks like the current quake/config only does that for cross builds. It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. - Jay > Date: Wed, 6 Feb 2013 08:18:28 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 13/02/06 08:18:28 > > Modified files: > cm3/scripts/regression/: hudson_build_system.sh > > Log message: > that was not what this script is supposed to do... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 08:45:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:45:56 +0000 Subject: [M3devel] dependencies on recent releases Message-ID: m3back uses LONGINT -- carefully though, it should work with 5.8.6 and not require changes since then (it didn't at first, til today) C code in m3back uses m3core.hC code in m3middle uses m3core.hThe C code in m3back can be removed when we update further, to a frontend that has slightly better support for LONGINT (a change that Tony commited long ago) So you need a "recent" release now to build the system.Recent is over 2 years ago though I believe. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 6 08:48:19 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 08:48:19 +0100 Subject: [M3devel] hudson_build_system.sh In-Reply-To: References: <20130206071829.1256B5DEB30@birch.elegosoft.com> Message-ID: <20130206084819.2c807588060601a69c2de841@elegosoft.com> On Wed, 6 Feb 2013 07:30:17 +0000 Jay K wrote: > Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. The old compiler release wasn't able to build the new sources; and in defs.sh, there are other functions for building from the old release. > The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. I don't think it was necessary here. They simply don't get used. > It looks like the current quake/config only does that for cross builds. > > It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. I'll see if I find time to do some more refactoring, but changing the regression setup is sometimes very subtle and likely to introduce errors. We'd need so many updates -- new VC, Hudson --> Jenkins, WWW, ... Right now I'd just like to get the wheels going again. Olaf > - Jay > > > > Date: Wed, 6 Feb 2013 08:18:28 +0000 > > To: m3commit at elegosoft.com > > From: wagner at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: wagner at birch. 13/02/06 08:18:28 > > > > Modified files: > > cm3/scripts/regression/: hudson_build_system.sh > > > > Log message: > > that was not what this script is supposed to do... > > > -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Feb 6 08:50:00 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 08:50:00 +0100 Subject: [M3devel] Now Hudson fails on AMD64_FREEBSD Message-ID: <20130206085000.f64dc4c94ab8e18a745b6c02@elegosoft.com> http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_FREEBSD/662/console === package m3-sys/m3back === +++ cm3 -build -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' +++ ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' ../src/M3CC.c: In function 'M3CC__UInt64ToText': ../src/M3CC.c:14: warning: return makes pointer from integer without a cast ../src/M3CC.c: At top level: ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input compile_c => 1 C compiler failed compiling: ../src/M3CC.c ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' ../src/M3CC.c: In function 'M3CC__UInt64ToText': ../src/M3CC.c:14: warning: return makes pointer from integer without a cast ../src/M3CC.c: At top level: ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input compile_c => 1 C compiler failed compiling: ../src/M3CC.c This seems to be the new C backend producing wrong assembler code. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 6 08:52:13 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:52:13 +0000 Subject: [M3devel] hudson_build_system.sh In-Reply-To: <20130206084819.2c807588060601a69c2de841@elegosoft.com> References: <20130206071829.1256B5DEB30@birch.elegosoft.com>, , <20130206084819.2c807588060601a69c2de841@elegosoft.com> Message-ID: > The old compiler release wasn't able to build the new sources I think I fixed that. I reduced my use of LONGINT by passing it off to C.There was a later change Tony made, after the initial LONGINT support, that let you use VAL to convert between more types. I was depending on that. I think I am no longer. > hudson jobs for m3cc -- just merge the jobs and use the incrementality and > the clean_marker.txt feature I put I understand, but I think this might be pretty easy.It might already be done..I'll poke around and try to do it fairly soon.We just have to make sure the CVS polling for "the one" task includes everything, doesn't exclude m3cc.The m3cc tasks aren't needed -- but can just be left disabled. The "later" tasks, pkg build, test, those can still be separate..until/unless I understand them.. :) - Jay > Date: Wed, 6 Feb 2013 08:48:19 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: hudson_build_system.sh > > On Wed, 6 Feb 2013 07:30:17 +0000 > Jay K wrote: > > > Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. > > The old compiler release wasn't able to build the new sources; and in defs.sh, there are other functions for building from the old release. > > > The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. > > I don't think it was necessary here. They simply don't get used. > > > It looks like the current quake/config only does that for cross builds. > > > > It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. > > I'll see if I find time to do some more refactoring, but changing the regression setup is sometimes very subtle and likely to introduce errors. > > We'd need so many updates -- new VC, Hudson --> Jenkins, WWW, ... > > Right now I'd just like to get the wheels going again. > > Olaf > > > - Jay > > > > > > > Date: Wed, 6 Feb 2013 08:18:28 +0000 > > > To: m3commit at elegosoft.com > > > From: wagner at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: wagner at birch. 13/02/06 08:18:28 > > > > > > Modified files: > > > cm3/scripts/regression/: hudson_build_system.sh > > > > > > Log message: > > > that was not what this script is supposed to do... > > > > > > > -- > 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 Wed Feb 6 08:53:32 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:53:32 +0000 Subject: [M3devel] Now Hudson fails on AMD64_FREEBSD In-Reply-To: <20130206085000.f64dc4c94ab8e18a745b6c02@elegosoft.com> References: <20130206085000.f64dc4c94ab8e18a745b6c02@elegosoft.com> Message-ID: > This seems to be the new C backend Yes. > producing wrong assembler code. No. It is only being used on Darwin for now. I think that'll need to remain so limited, until I declare structs better, so that debugging doesn't degrade, on systems that support m3gdb. Please stand by..but don't hold breath. - Jay > Date: Wed, 6 Feb 2013 08:50:00 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Now Hudson fails on AMD64_FREEBSD > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_FREEBSD/662/console > > === package m3-sys/m3back === > +++ cm3 -build -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' +++ > ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' > ../src/M3CC.c: In function 'M3CC__UInt64ToText': > ../src/M3CC.c:14: warning: return makes pointer from integer without a cast > ../src/M3CC.c: At top level: > ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input > compile_c => 1 > C compiler failed compiling: ../src/M3CC.c > ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' > ../src/M3CC.c: In function 'M3CC__UInt64ToText': > ../src/M3CC.c:14: warning: return makes pointer from integer without a cast > ../src/M3CC.c: At top level: > ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input > compile_c => 1 > C compiler failed compiling: ../src/M3CC.c > > This seems to be the new C backend producing wrong assembler code. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 09:29:03 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 08:29:03 +0000 Subject: [M3devel] and move to gcc 4.7? Message-ID: Olaf, things working satisfactorily for you in Hudson now for AMD64_LINUX and AMD64_FREEBSD?I'd like to bump m3cc/src/m3makefile up to 4.7 for AMD64_LINUX, FREEBSD. Or anything we have going decently in Hudson.Even though, granted, I'd like to remove that backend sooner rather than later anyway..AMD64_LINUX was at 4.7 but I backed it down to 4.5 today out of paranoia. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 6 09:30:28 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 09:30:28 +0100 Subject: [M3devel] hudson_build_system.sh In-Reply-To: References: <20130206071829.1256B5DEB30@birch.elegosoft.com> <20130206084819.2c807588060601a69c2de841@elegosoft.com> Message-ID: <20130206093028.0526f9c67e42c411f3bfbe14@elegosoft.com> On Wed, 6 Feb 2013 07:52:13 +0000 Jay K wrote: > > The old compiler release wasn't able to build the new sources > I think I fixed that. I reduced my use of LONGINT by passing it off to C.There was a later change Tony made, after the initial LONGINT support, that let you use VAL to convert between more types. I was depending on that. I think I am no longer. OK > > hudson jobs for m3cc -- just merge the jobs and use the incrementality and > the clean_marker.txt feature I put > > I understand, but I think this might be pretty easy.It might already be done..I'll poke around and try to do it fairly soon.We just have to make sure the CVS polling for "the one" task includes everything, doesn't exclude m3cc.The m3cc tasks aren't needed -- but can just be left disabled. > > The "later" tasks, pkg build, test, those can still be separate..until/unless I understand them.. :) Great. I'd just prefer doing such work in separate jobs/scripts; i.e. create a new Hudson job for it which executes a new build script. And keeping the general installation layout of current/last-ok/prev-ok might also help. Olaf > - Jay > > > > Date: Wed, 6 Feb 2013 08:48:19 +0100 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: hudson_build_system.sh > > > > On Wed, 6 Feb 2013 07:30:17 +0000 > > Jay K wrote: > > > > > Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. > > > > The old compiler release wasn't able to build the new sources; and in defs.sh, there are other functions for building from the old release. > > > > > The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. > > > > I don't think it was necessary here. They simply don't get used. > > > > > It looks like the current quake/config only does that for cross builds. > > > > > > It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. > > > > I'll see if I find time to do some more refactoring, but changing the regression setup is sometimes very subtle and likely to introduce errors. > > > > We'd need so many updates -- new VC, Hudson --> Jenkins, WWW, ... > > > > Right now I'd just like to get the wheels going again. > > > > Olaf > > > > > - Jay > > > > > > > > > > Date: Wed, 6 Feb 2013 08:18:28 +0000 > > > > To: m3commit at elegosoft.com > > > > From: wagner at elego.de > > > > Subject: [M3commit] CVS Update: cm3 > > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: wagner at birch. 13/02/06 08:18:28 > > > > > > > > Modified files: > > > > cm3/scripts/regression/: hudson_build_system.sh > > > > > > > > Log message: > > > > that was not what this script is supposed to do... > > > > > > > > > > > -- > > 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 wagner at elegosoft.com Wed Feb 6 09:34:09 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 09:34:09 +0100 Subject: [M3devel] and move to gcc 4.7? In-Reply-To: References: Message-ID: <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> On Wed, 6 Feb 2013 08:29:03 +0000 Jay K wrote: > Olaf, things working satisfactorily for you in Hudson now for AMD64_LINUX and AMD64_FREEBSD? Recent builds seem to have succeeded. > I'd like to bump m3cc/src/m3makefile up to 4.7 for AMD64_LINUX, FREEBSD. Or anything we have going decently in Hudson.Even though, granted, I'd like to remove that backend sooner rather than later anyway..AMD64_LINUX was at 4.7 but I backed it down to 4.5 today out of paranoia. Just try it. Before we remove the old backend, I'd like to have some validation of the quality and performance of the new one though, just to avoid regression. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 6 09:46:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 08:46:15 +0000 Subject: [M3devel] and move to gcc 4.7? In-Reply-To: <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> References: , <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> Message-ID: > quality and performance of the new one though, just to avoid regression. Well..the main "quality" is portability.Much is being potentially sacrificed for it. There are potential other improvements, but also potential regressions. Optimization might be better, i.e. by not using gcc, or worse, i.e. by going via C. Compiler performance is likely worse, due to the extra text production and parsing.It seems ok to me. I've been using a while. But not great. Skipping the .mc/m3cg file production helped a lot. Debugging will be better on Darwin and NT -- where currently we have no type info, I hope to add significant typing. "Ease of distribution" will take a step forward, but it isn't yet where I want it to be.You know, you just want tar xf; configure; make; make install. No need for cross builds or "unusual" prerequesites, "just" a C compiler and Bourne shell and make. Portability will increase.Maintainability will increase.We will no longer have a motivation for "chasing" newer gcc. (nor patches e.g. for OpenBSD)We will "automatically" port to "every" target. This is an exaggeration, but not by a lot.The "porting" will work will decrease. Porting work will further decrease when we have cooperative suspend. - Jay > Date: Wed, 6 Feb 2013 09:34:09 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] and move to gcc 4.7? > > On Wed, 6 Feb 2013 08:29:03 +0000 > Jay K wrote: > > > Olaf, things working satisfactorily for you in Hudson now for AMD64_LINUX and AMD64_FREEBSD? > Recent builds seem to have succeeded. > > > I'd like to bump m3cc/src/m3makefile up to 4.7 for AMD64_LINUX, FREEBSD. Or anything we have going decently in Hudson.Even though, granted, I'd like to remove that backend sooner rather than later anyway..AMD64_LINUX was at 4.7 but I backed it down to 4.5 today out of paranoia. > > Just try it. > > Before we remove the old backend, I'd like to have some validation of the > quality and performance of the new one though, just to avoid regression. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 10:00:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 09:00:33 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs Message-ID: Olaf, Dagobert, Dagobert: We haven't tried to run anything in a while. 1) SOLsun is failing to login: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs is that right? Olaf:2) Can we get SPARC64_SOLARIS and AMD64_SOLARIS?They can work on the existing machines.Maybe I need to provide an initial bootstrap or setup?Maybe I did long ago?Maybe poke in ~jkrell?Maybe just start with the existing sparc32 and x86? They should cross ok, if CM3_TARGET is set explicitly to override the default target=host. Olaf:3) I'd like to see SOLsun switched to be called SPARC32_SOLARIS."It should just work." The support has been in for a long time. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 10:28:14 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 09:28:14 +0000 Subject: [M3devel] updating exception handling implementation and backend interface?? Message-ID: The jmpbuf/alloca fix? For reference, here is most of the undo:http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/Marker.m3.diff?r1=1.9;r2=1.10;f=uor http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/Marker.m3.diff?r1=1.9;r2=1.10 I had generated code like: old:char buf[sizeof(jmpbuf)]; // frontend knows sizeof(jmpbuf) -- the portability problem to be solved TRY => setjmp(buf); new:jmpbuf* buf;extern const size_t Csetjmp__Jumpbuf_size/* = sizeof(jmp_buf)*/; *)TRY => buf = m3_alloca(sizeof(Csetjmp__Jumpbuf_size)); setjmp(buf);=> alloca for every TRY, even if TRY in a loop, not good Understanding that is a further de-optimization, how about I just do:jmpbuf* buf;TRY => buf = buf ? buf : alloca(sizeof(jmpbuf)); setjmp(buf); ? It seems easy enough? furthermore, let's think ahead to the C and maybe C++ backends? The portable slightly optimizing C backend will go back to jmpbuf, no alloca.The optimizing C++ backend will try to use native C++ exception handling.And/or the optimizing C-for-NT backend will use __try/__except/__finally. Should I start/end "buf" with some distinguished name?So some backends will remove it, in favor of whatever they do better?Should "m3_alloca" be named something more specific like "m3_alloca_for_try"?Again, so it is easier to backends to recognize and remove?i.e. one of the first optimizations the C backend should make isto #include and change these to jmpbuf. Should we invent a higher level interface?Should we do "both", make low level and high level calls to the backend?It will chose to ignore one set?But the low level calls need to be altered at least a little bit.Like the locals and the calls will have a flag or a boolean indicatingthey are "exception handling related"? Am I making sense? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Wed Feb 6 10:40:31 2013 From: wagner at elego.de (Olaf Wagner) Date: Wed, 6 Feb 2013 10:40:31 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: Message-ID: <20130206104031.c16645c8.wagner@elego.de> On Wed, 6 Feb 2013 09:00:33 +0000 Jay K wrote: > Olaf, Dagobert, > > Dagobert: We haven't tried to run anything in a while. > > 1) SOLsun is failing to login: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > is that right? The problem on that build farm always was the missing direct CVS access. There used to be that proxy server; I don't know if it's still up. > Olaf:2) Can we get SPARC64_SOLARIS and AMD64_SOLARIS?They can work on the existing machines.Maybe I need to provide an initial bootstrap or setup?Maybe I did long ago?Maybe poke in ~jkrell?Maybe just start with the existing sparc32 and x86? They should cross ok, if CM3_TARGET is set explicitly to override the default target=host. I'm not sure if there are any bootstrap packages for 64 bit; maybe you need to do the initial bootstrap manually. An initial environment needs to be setup for Hudson, see http://hudson.modula3.com:8080/view/zzz/job/boot-template/ for example. > Olaf:3) I'd like to see SOLsun switched to be called SPARC32_SOLARIS."It should just work." The support has been in for a long time. OK. If you're expecting me to do something specific, please say so explicitly; I'm still very much involved in other customer projects. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elego.de Wed Feb 6 12:15:35 2013 From: wagner at elego.de (Olaf Wagner) Date: Wed, 6 Feb 2013 12:15:35 +0100 Subject: [M3devel] and move to gcc 4.7? In-Reply-To: References: <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> Message-ID: <20130206121535.f55292b8.wagner@elego.de> On Wed, 6 Feb 2013 08:46:15 +0000 Jay K wrote: > > quality and performance of the new one though, just to avoid regression. > > Well..the main "quality" is portability.Much is being potentially sacrificed for it. > > There are potential other improvements, but also potential regressions. > > Optimization might be better, i.e. by not using gcc, or worse, i.e. by going via C. > > Compiler performance is likely worse, due to the extra text production and parsing.It seems ok to me. I've been using a while. But not great. Skipping the .mc/m3cg file production helped a lot. > > Debugging will be better on Darwin and NT -- where currently we have no type info, I hope to add significant typing. > > "Ease of distribution" will take a step forward, but it isn't yet where I want it to be.You know, you just want tar xf; configure; make; make install. No need for cross builds or "unusual" prerequesites, "just" a C compiler and Bourne shell and make. > > Portability will increase.Maintainability will increase.We will no longer have a motivation for "chasing" newer gcc. (nor patches e.g. for OpenBSD)We will "automatically" port to "every" target. This is an exaggeration, but not by a lot.The "porting" will work will decrease. Porting work will further decrease when we have cooperative suspend. Yes, I understand and appreciate all those. I was just thinking of something more pragmatical. Let's start with m3tests: Recent runs show a regression from 19 to 49 errors on AMD64_LINUX: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-AMD64_LINUX/ The same for FreeBSD 8: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-AMD64_FREEBSD/ Can you explain (and fix) those? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From cornstalk at columbus.rr.com Wed Feb 6 15:38:56 2013 From: cornstalk at columbus.rr.com (Mark Morss) Date: Wed, 06 Feb 2013 09:38:56 -0500 Subject: [M3devel] new release In-Reply-To: <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> Message-ID: <51126B00.7010301@columbus.rr.com> On 02/05/2013 04:13 PM, Tony Hosking wrote: > The last official release contains known bugs. Best I think to go with > the head of the repository. > > Sent from my iPhone > > On 06/02/2013, at 6:46 AM, "Coleburn, Randy" > wrote: > >> I am in process of getting a new computer to replace my old office >> computer. >> >> I?ve installed the new Visual Studio 2012 Express and want to rebuild >> my CM3 source tree. >> >> It?s been a long time since a new CM3 release was made. >> >> I note that Jay has done a lot of work and I?m not sure exactly what >> is the state of the main branch in the CM3 repository. >> >> Would folks advise I stick with the last official release, or update >> to the current main branch before rebuilding everything? >> >> The target machine is running Windows 7 Enterprise edition. >> >> Thanks, >> >> Randy Coleburn >> Well, that's a little bit disturbing. Would it be much trouble for someone to gin up a new release with the latest corrections in it? Not everyone wants to fool around with CVS. Best to all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 6 16:38:22 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 16:38:22 +0100 Subject: [M3devel] new release In-Reply-To: <51126B00.7010301@columbus.rr.com> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> <51126B00.7010301@columbus.rr.com> Message-ID: <20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com> On Wed, 06 Feb 2013 09:38:56 -0500 Mark Morss wrote: > On 02/05/2013 04:13 PM, Tony Hosking wrote: > > The last official release contains known bugs. Best I think to go with > > the head of the repository. > > > > Sent from my iPhone > > > > On 06/02/2013, at 6:46 AM, "Coleburn, Randy" > > wrote: > > > >> I am in process of getting a new computer to replace my old office > >> computer. > >> > >> I?ve installed the new Visual Studio 2012 Express and want to rebuild > >> my CM3 source tree. > >> > >> It?s been a long time since a new CM3 release was made. > >> > >> I note that Jay has done a lot of work and I?m not sure exactly what > >> is the state of the main branch in the CM3 repository. > >> > >> Would folks advise I stick with the last official release, or update > >> to the current main branch before rebuilding everything? > >> > >> The target machine is running Windows 7 Enterprise edition. > >> > >> Thanks, > >> > >> Randy Coleburn > >> > Well, that's a little bit disturbing. Would it be much trouble for > someone to gin up a new release with the latest corrections in it? Not > everyone wants to fool around with CVS. Well, I think we will do a new release as soon as the C backend has settled. But you can always get current snapshots of the system from the Hudson builds, at least for Linux and FreeBSD, see http://www.opencm3.net/snaps/snapshot-index.html Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Wed Feb 6 18:24:30 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 06 Feb 2013 11:24:30 -0600 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , <20130205091140.ff4fd78c.wagner@elego.de> Message-ID: <511291CE.9090100@lcwb.coop> On 02/05/2013 02:28 AM, Jay K wrote: > I will fix it, but I do desire to drop the old backend entirely. > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. And I use m3gdb all the time in my own work. Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > - Jay > From rcolebur at SCIRES.COM Thu Feb 7 00:13:37 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 6 Feb 2013 23:13:37 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! --Randy Coleburn -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Wednesday, February 06, 2013 12:25 PM To: m3devel at elegosoft.com Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI On 02/05/2013 02:28 AM, Jay K wrote: > I will fix it, but I do desire to drop the old backend entirely. > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. And I use m3gdb all the time in my own work. Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > - Jay > From dabenavidesd at yahoo.es Thu Feb 7 05:56:26 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 7 Feb 2013 04:56:26 +0000 (GMT) Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <1360212986.90708.YahooMailClassic@web133106.mail.ir2.yahoo.com> Hi all: Gcc support is becoming harder and harder to get not here precisely in gcc camp. I agree with somethings you say, like good backend debugging support, but we need really get serious about implementation alternatives, it would be wonderful to support JIT targets (read, JVM, .NET, C-like machines), and obviously they are better to be written in C substrate (we need one hardware abstraction layer). If you could just reuse m3cc to make a throw prototype of a JIT compiler for instance to C-like bytecode (in form of inline assembly of gcc) the approach of C generating backend would be lot more easier to support, because you can create binary translators with NJ machine code toolkit translators for instance to several platforms using either C or Modula-3 decoding. Kind of supporting Thanks in advance --- El mi?, 6/2/13, Coleburn, Randy escribi?: De: Coleburn, Randy Asunto: Re: [M3devel] Compiler upgrade broken in Hudson CI Para: "m3devel at elegosoft.com" Fecha: mi?rcoles, 6 de febrero, 2013 18:13 I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! --Randy Coleburn -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Wednesday, February 06, 2013 12:25 PM To: m3devel at elegosoft.com Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI On 02/05/2013 02:28 AM, Jay K wrote: > I will fix it, but I do desire to drop the old backend entirely. > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. I have put in a *huge* amount of work on m3gdb.? While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence.? Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc.? etc. A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information.? Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more.? As I recall it, only the release branch supports a working m3gdb right now. And I use m3gdb all the time in my own work. Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*.? Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > >???- Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 7 07:35:15 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 7 Feb 2013 07:35:15 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: Message-ID: <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com> On Wed, 6 Feb 2013 09:00:33 +0000 Jay K wrote: > Olaf, Dagobert, > > Dagobert: We haven't tried to run anything in a while. > > 1) SOLsun is failing to login: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > is that right? Login works now. I've started the job http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/157/console to see how far it gets. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Feb 7 08:36:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 7 Feb 2013 07:36:41 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: m3gdb: is GPL is a fork, that will never be merged that isn't being updated is big that doesn't support some platforms e.g. Darwin, HP-UX cm3cg has some but not all of those characteristics Meanwhile, debugging on NT and Darwin is limited to line numbersand integers and floats. No useful view of structs or globalsis available. And as I understand..can anyone agree/disagree?.. gets itsdata from the backend via a total backdoor hack, that is very difficultto duplicate. E.g. including with llvm, including if we generatedtypeful gcc trees like any normal backend would do.I speculate, maybe it will be possible to output some assemblyfiles on the side with just the stabs directives. I'm hoping that: gdb on Darwin will improve drastically via the C backend; it hasn't yet windbg and Visual Studio ditto gdb on platforms that support m3gdb will come close to m3gdb,but parity might not be achievable. Our target support continues to lag. DragonflyBSD? OpenBSD w/o maintaining patches (mainline gcc doesn't support OpenBSD, but I386_ELF is all fairly much the same, so the patches are small) ARM_NT? {PPC,MIPS,ARM,SH,I386}_CE? ARM_DARWIN? Was mostly there already. PPC32_XBOX? AMD64_NT? This should come along fairly soon now via the C backend. Let's see how good we can get stock debuggers working with our C. Ok? - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 6 Feb 2013 23:13:37 +0000 > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! > --Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Wednesday, February 06, 2013 12:25 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > On 02/05/2013 02:28 AM, Jay K wrote: > > I will fix it, but I do desire to drop the old backend entirely. > > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > > > > > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. > > I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. > > Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. > > A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its > Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. > > And I use m3gdb all the time in my own work. > > Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Feb 8 00:31:46 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 8 Feb 2013 00:31:46 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com> References: <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com> Message-ID: <20130208003146.9bb5951f2fc35b356cf63582@elegosoft.com> On Thu, 7 Feb 2013 07:35:15 +0100 Olaf Wagner wrote: > On Wed, 6 Feb 2013 09:00:33 +0000 > Jay K wrote: > > > Olaf, Dagobert, > > > > Dagobert: We haven't tried to run anything in a while. > > > > 1) SOLsun is failing to login: > > > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > > > is that right? > > Login works now. I've started the job > http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/157/console > to see how far it gets. Status update: the three platforms currently configured for CM3 on the buildfarm work again to some degree. I had to change CVS ports from 2401 to 12401, change host names from current to dublin and move some files around. I386_SOLARIS fails in the m3cc package: http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console SOLsun on SPARC Solaris 9 fails in m3core: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console SOLsun on SPARC Solaris 10 succeeds: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/ We should fix those failures before changing things like target platform names. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Feb 8 08:36:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 8 Feb 2013 07:36:12 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <20130208003146.9bb5951f2fc35b356cf63582@elegosoft.com> References: , <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com>, <20130208003146.9bb5951f2fc35b356cf63582@elegosoft.com> Message-ID: > SOLsun on SPARC Solaris 9 fails in m3core: That is odd, I added fprintf for maybe more information > I386_SOLARIS fails in the m3cc package: Oops, sorry, not surprising, so I downgraded to 4.5 for all Solaris platforms.Otherwise I have to port forward the patches to gcc to avoid depending on gcc extensions. Or we can build gcc with gcc instead of Solaris cc. - Jay > Date: Fri, 8 Feb 2013 00:31:46 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > > On Thu, 7 Feb 2013 07:35:15 +0100 > Olaf Wagner wrote: > > > On Wed, 6 Feb 2013 09:00:33 +0000 > > Jay K wrote: > > > > > Olaf, Dagobert, > > > > > > Dagobert: We haven't tried to run anything in a while. > > > > > > 1) SOLsun is failing to login: > > > > > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > > > > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > > > > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > > > > > is that right? > > > > Login works now. I've started the job > > http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/157/console > > to see how far it gets. > > Status update: the three platforms currently configured for CM3 on the buildfarm > work again to some degree. I had to change CVS ports from 2401 to 12401, > change host names from current to dublin and move some files around. > > I386_SOLARIS fails in the m3cc package: > http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console > > SOLsun on SPARC Solaris 9 fails in m3core: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console > > SOLsun on SPARC Solaris 10 succeeds: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/ > > We should fix those failures before changing things like target platform names. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Feb 8 09:28:11 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 8 Feb 2013 09:28:11 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: Message-ID: <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org> Hi, sorry for answering late. Am 06.02.2013 um 10:00 schrieb Jay K : > Olaf, Dagobert, > > > Dagobert: We haven't tried to run anything in a while. > > > 1) SOLsun is failing to login: > > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664 > Building remotely on opencsw_current10s > [cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC" > cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refused > FATAL: CVS failed. exit code=1 > Finished: FAILURE > > > The Hudson job is configured to use: > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > > is that right? We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it if you need it. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Feb 8 10:44:41 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 8 Feb 2013 10:44:41 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org> References: <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org> Message-ID: <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com> On Fri, 8 Feb 2013 09:28:11 +0100 Dagobert Michelsen wrote: > We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it > if you need it. But it seems to work with Port 12401 instead of 2401, so no need to change anything right now. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Fri Feb 8 16:42:22 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 08 Feb 2013 09:42:22 -0600 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <51151CDE.1070207@lcwb.coop> On 02/07/2013 01:36 AM, Jay K wrote: > m3gdb: > is GPL > is a fork, that will never be merged > that isn't being updated > is big > that doesn't support some platforms e.g. Darwin, HP-UX Yes. But what it does, works, now. Nothing else exists now that comes close. Actually, it has been merged into at least 5 versions of gdb, counting the original modification. I have done three, and in each, I have moved towards reducing the entanglement with existing gdb code, so merging gets easier, though still no picnic. It's been updated many times, though not recently. Most of the pure updates have been enhancements. Most of the regressions have been caused by back end changes, not problems inside m3gdb. That said, as often as possible, I have worked around these inside m3gdb, by adding yet another back end version to the set it can dynamically adapt to, rather than fixing the back end. Kludgier, yes. But it's more robust, and compatible. It already copes with quite a range of back ends. > > cm3cg has some but not all of those characteristics > Ditto. > > Meanwhile, debugging on NT and Darwin is limited to line numbers > and integers and floats. No useful view of structs or globals > is available. Perhaps. But what it does, works on LINUXLIBC6 and AMD64_LINUX, now. Have you tried m3gdb on NT and Darwin using the working (debug-info-wise) gcc backend (4.5, as I recall), or only the one wherein you disabled the Modula-3 debug output (4.6, as I recall)? In the latter case, it, of course, doesn't work anywhere. I think you will find stuff like calls, procedure variables, etc., that involve the calling convention, will need target-dependent work in m3gdb. That's the way it went when adding AMD64_LINUX. But I would expect more than you describe to work on a new target, without modifications. > And as I understand..can anyone agree/disagree?.. gets its > data from the backend via a total backdoor hack, that is very difficult > to duplicate. Yes, it's a backdoor hack. But it works, now. E.g. including with llvm, In the long run, llvm plus dwarf (which llvm appears to already have good support for) is the clear way to get something non-hackish. But that will require major debugger work to support, in addition, of course, to an llvm-derived back end itself. I am sure this approach would be much easier than getting dwarf info out of either cm3cg, or gcc compiling C source. including if we generated > typeful gcc trees like any normal backend would do. > I speculate, maybe it will be possible to output some assembly > files on the side with just the stabs directives. > This could probably work, but it's just a superficially different information path for an equivalent backdoor hack. Right now, cm3cg pretty much just serves as a conduit for stabs info that is generated by the code parse.c. From there, it ends up, with little or no change, interspersed in the rest of the cm3cg-generated assembly code. But I expect this would be the only reasonable way to get any Modula-3-literate debug info past C source code. > > > I'm hoping that: > gdb on Darwin will improve drastically via the C backend; it hasn't yet > windbg and Visual Studio ditto > > gdb on platforms that support m3gdb will come close to m3gdb, > but parity might not be achievable. You will not achieve anything close to parity without a debugger that has a lot of Modula-3-specific code inside. Have you read cm3/doc/help/m3gdb/m3gdb-onepage.html? Consider it the definition of parity. > > > Our target support continues to lag. > DragonflyBSD? > OpenBSD w/o maintaining patches (mainline gcc doesn't support OpenBSD, but I386_ELF is all fairly much the same, so the patches are small) > ARM_NT? > {PPC,MIPS,ARM,SH,I386}_CE? > ARM_DARWIN? Was mostly there already. > PPC32_XBOX? > AMD64_NT? This should come along fairly soon now via the C backend. > > > Let's see how good we can get stock debuggers working with our C. Ok? > Do whatever you can and want to. But don't torpedo what is now working, until you can replace it with something that achieves parity. Until then, don't break, disable, or remove it from CVS head. Keep it an easy-to-choose and findably-documented option. If you make changes that could possibly undermine it, make a branch, until they are well-tested. > > - Jay > > > > From: rcolebur at SCIRES.COM > > To: m3devel at elegosoft.com > > Date: Wed, 6 Feb 2013 23:13:37 +0000 > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! > > --Randy Coleburn > > > > -----Original Message----- > > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > > Sent: Wednesday, February 06, 2013 12:25 PM > > To: m3devel at elegosoft.com > > Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > On 02/05/2013 02:28 AM, Jay K wrote: > > > I will fix it, but I do desire to drop the old backend entirely. > > > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > > > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > > > > > > > > > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. > > > > I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. > > > > Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. > > > > A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its > > Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. > > > > And I use m3gdb all the time in my own work. > > > > Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > > > > > > > > > - Jay > > > From jay.krell at cornell.edu Wed Feb 13 11:20:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 13 Feb 2013 10:20:51 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com> References: , <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org>, <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com> Message-ID: > I386_SOLARIS fails in the m3cc package: http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console > This looks ok now. >> http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/166/consoleFull > SOLsun on SPARC Solaris 9 fails in m3core: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console I changed this to print more, but it doesn't. I'm guessing it is the previous m3core failing? Use a new minimum distribution? I'll work on it.. Thanks, - Jay > Date: Fri, 8 Feb 2013 10:44:41 +0100 > From: wagner at elegosoft.com > To: dam at opencsw.org > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > > On Fri, 8 Feb 2013 09:28:11 +0100 > Dagobert Michelsen wrote: > > > We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it > > if you need it. > > But it seems to work with Port 12401 instead of 2401, so no need to > change anything right now. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 17 08:59:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 07:59:26 +0000 Subject: [M3devel] sparc64 problem Message-ID: This looks familiar..but I don't remember what I did about it, and don't see a fix in the tree already... new source -> compiling Matrix4.m3 m3front ../src/Matrix4.m3 -w1 /Users/jay/dev2/cm3/m3-sys/m3cc/AMD64_DARWIN-SPARC64_SOLARIS/cm3cg -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Matrix4.mc -o Matrix4.ms ../src/Matrix4.m3: In function 'Matrix4__TransformUnitCube': ../src/Matrix4.m3:317:0: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:6212 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: Matrix4.mc INTERFACE Point3; TYPE T = RECORD x,y,z : REAL; END; INTERFACE Matrix4; IMPORT Point3; PROCEDURE TransformUnitCube (p, a, b, c : Point3.T) : T; This is probably because we declare that records have size, but no fields. i.e. yet another thing bad about the current cm3cg backend.. I can try with 4.2 or 4.3 or 4.5 or 4.6, but I expect they are the same here.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 17 08:59:06 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 17 Feb 2013 08:59:06 +0100 Subject: [M3devel] DLLs In-Reply-To: References: Message-ID: <927C5FEC-CD7F-4787-B61C-E8C9DFEAF817@m3w.org> Also from memory, I second this? I was/am using .DLL's in a manner compatible with Linux/OSX (using right API calls, of course). No special anything anywhere. -- Divided by a common language Dragi?a Duri? dragisha at m3w.org On Feb 1, 2013, at 9:16 PM, Jay K wrote: > Dirk, From my memory, you have it backwards. .dlls are built by default for any "library". > You can suppress .dll building with build_standalone(). > > It works like this, it is a bit unusual, but kind of nice: > f or every "library", we build a static library and a .dll/.so > "programs" default to linking to .dlls if present, else static libraries > > > - Jay > > From: dmuysers at hotmail.com > To: m3devel at elegosoft.com > Date: Fri, 1 Feb 2013 19:04:02 +0100 > Subject: [M3devel] DLLs > > Using the standard cm3 tools there is no official way to build a library as a DLL. > Hence, out of curiosity, the following question: > Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Feb 17 22:02:51 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 17 Feb 2013 15:02:51 -0600 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: <20130217205228.0C60B5DEA8F@birch.elegosoft.com> References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com> Message-ID: <5121457B.6060703@lcwb.coop> What is happening here? Every time I commit these two files, cvs inserts a few opening comment delimiters without matching closing ones. It does this to my local copy, in addition to, as nearly as I can ascertain, the checked-in copy. On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/02/17 21:52:28 > > Modified files: > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > Log message: > > > From jay.krell at cornell.edu Mon Feb 18 00:22:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: <5121457B.6060703@lcwb.coop> References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, <5121457B.6060703@lcwb.coop> Message-ID: It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. - Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 18 00:25:21 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2013 00:25:21 +0100 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: <5121457B.6060703@lcwb.coop> References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com> <5121457B.6060703@lcwb.coop> Message-ID: <20130218002521.8b7e518a87cf1b2694f74df7@elegosoft.com> On Sun, 17 Feb 2013 15:02:51 -0600 "Rodney M. Bates" wrote: > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: I assume CVS replaces the magic $Id$ and $Log$ keywords. You could try to remove them, they only will make version control more difficult. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 18 00:23:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 23:23:38 +0000 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , <5121457B.6060703@lcwb.coop>, Message-ID: ps: can we not add more GPL stuff? Can use a BSD license? Thanks, - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. - Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 18 00:41:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 23:41:57 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: , , <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org>, , <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com>, Message-ID: >> SOLsun on SPARC Solaris 9 fails in m3core: >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console > I changed this to print more, but it doesn't. > I'm guessing it is the previous m3core failing? > Use a new minimum distribution? I'll work on it.. It took me a while. How about this: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-SOLsun-d5.9.0-Solaris5.8-20130217.tar.lzma ? Built on 5.8 -- should work on that and newer.. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dam at opencsw.org Date: Wed, 13 Feb 2013 10:20:51 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > I386_SOLARIS fails in the m3cc package: http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console > This looks ok now. >> http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/166/consoleFull > SOLsun on SPARC Solaris 9 fails in m3core: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console I changed this to print more, but it doesn't. I'm guessing it is the previous m3core failing? Use a new minimum distribution? I'll work on it.. Thanks, - Jay > Date: Fri, 8 Feb 2013 10:44:41 +0100 > From: wagner at elegosoft.com > To: dam at opencsw.org > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > > On Fri, 8 Feb 2013 09:28:11 +0100 > Dagobert Michelsen wrote: > > > We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it > > if you need it. > > But it seems to work with Port 12401 instead of 2401, so no need to > change anything right now. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 18 00:52:33 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2013 10:52:33 +1100 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , <5121457B.6060703@lcwb.coop>, Message-ID: GPL # BSD. We should minimize GPL stuff where we are unable to eliminate. On Feb 18, 2013, at 10:23 AM, Jay K wrote: > ps: can we not add more GPL stuff? Can use a BSD license? > > Thanks, > - Jay > > > From: jay.krell at cornell.edu > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Sun, 17 Feb 2013 23:22:33 +0000 > Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > It's related to those dollar sign thingies. We could just remove them entirely. > I found a form that doesn't break, though not clear I'm getting the intended content. > > - Jay > > > > Date: Sun, 17 Feb 2013 15:02:51 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > > > What is happening here? Every time I commit these two files, cvs inserts > > a few opening comment delimiters without matching closing ones. It does > > this to my local copy, in addition to, as nearly as I can ascertain, the > > checked-in copy. > > > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > > CVSROOT: /usr/cvs > > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > > > Modified files: > > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > > > Log message: > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 18 01:18:18 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 18 Feb 2013 00:18:18 +0000 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , , <5121457B.6060703@lcwb.coop>, , , , Message-ID: Agreed. There's been some GPL additions recently. From: hosking at cs.purdue.edu Date: Mon, 18 Feb 2013 10:52:33 +1100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 GPL # BSD. We should minimize GPL stuff where we are unable to eliminate. On Feb 18, 2013, at 10:23 AM, Jay K wrote:ps: can we not add more GPL stuff? Can use a BSD license? Thanks, - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. - Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Feb 18 02:59:53 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 18 Feb 2013 01:59:53 +0000 (GMT) Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> Hi all: core RT is different fundamentally of that proposition, e.g: http://modula3.elegosoft.com/cm3/doc/help/gen_html/m3core/src/runtime/common/RTHooks.m3.html#0TOP0 Please, we should keep improving this instead of not allowing changes or removing it without notice. Thanks in advance --- El dom, 17/2/13, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 Para: "Tony" CC: "m3devel" Fecha: domingo, 17 de febrero, 2013 19:18 Agreed. There's been some GPL additions recently. From: hosking at cs.purdue.edu Date: Mon, 18 Feb 2013 10:52:33 +1100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 GPL # BSD. We should minimize GPL stuff where we are unable to eliminate. On Feb 18, 2013, at 10:23 AM, Jay K wrote: ps: can we not add more GPL stuff? Can use a BSD license? Thanks, ?- Jay From:?jay.krell at cornell.edu To:?rodney_bates at lcwb.coop;?m3devel at elegosoft.com Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. ?- Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From:?rodney_bates at lcwb.coop > To:?m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 >? > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. >? > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > >? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 18 15:46:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 18 Feb 2013 08:46:40 -0600 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , <5121457B.6060703@lcwb.coop>, Message-ID: <51223ED0.8010502@lcwb.coop> Please elaborate on what you want to do and why. On 02/17/2013 05:52 PM, Tony Hosking wrote: > GPL # BSD. > > We should minimize GPL stuff where we are unable to eliminate. > > On Feb 18, 2013, at 10:23 AM, Jay K > wrote: > >> ps: can we not add more GPL stuff? Can use a BSD license? >> >> Thanks, >> - Jay >> >> >> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --- >> From:jay.krell at cornell.edu >> To:rodney_bates at lcwb.coop ;m3devel at elegosoft.com >> Date: Sun, 17 Feb 2013 23:22:33 +0000 >> Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 >> >> It's related to those dollar sign thingies. We could just remove them entirely. >> I found a form that doesn't break, though not clear I'm getting the intended content. >> >> - Jay >> >> >> > Date: Sun, 17 Feb 2013 15:02:51 -0600 >> > From:rodney_bates at lcwb.coop >> > To:m3devel at elegosoft.com >> > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 >> > >> > What is happening here? Every time I commit these two files, cvs inserts >> > a few opening comment delimiters without matching closing ones. It does >> > this to my local copy, in addition to, as nearly as I can ascertain, the >> > checked-in copy. >> > >> > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: >> > > CVSROOT: /usr/cvs >> > > Changes by: rodney at birch. 13/02/17 21:52:28 >> > > >> > > Modified files: >> > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 >> > > >> > > Log message: >> > > >> > > >> > > >> > > From cornstalk at columbus.rr.com Fri Feb 22 17:25:50 2013 From: cornstalk at columbus.rr.com (Mark Morss) Date: Fri, 22 Feb 2013 11:25:50 -0500 Subject: [M3devel] Mysql interface? In-Reply-To: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> References: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> Message-ID: <51279C0E.1000807@columbus.rr.com> Do I correctly suppose that there is no functioning mysql interface for Modula-3? The db module appears to contain only a place-holder for mysql. I googled on this and could not discover an answer. Best to all. From mika at async.caltech.edu Fri Feb 22 17:40:07 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 22 Feb 2013 08:40:07 -0800 Subject: [M3devel] Mysql interface? In-Reply-To: <51279C0E.1000807@columbus.rr.com> References: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> <51279C0E.1000807@columbus.rr.com> Message-ID: <20130222164007.353A51A2095@async.async.caltech.edu> The PostgreSQL interface works quite well, though. Mika Mark Morss writes: > >Do I correctly suppose that there is no functioning mysql interface for >Modula-3? The db module appears to contain only a place-holder for mysql. > >I googled on this and could not discover an answer. > >Best to all. From darko at darko.org Fri Feb 22 19:43:49 2013 From: darko at darko.org (Darko) Date: Fri, 22 Feb 2013 10:43:49 -0800 Subject: [M3devel] Mysql interface? In-Reply-To: <51279C0E.1000807@columbus.rr.com> References: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> <51279C0E.1000807@columbus.rr.com> Message-ID: <899E88D3-6134-45B1-9D3E-1F6F3C177C22@darko.org> These should work, but are not thoroughly tested nor complete. -------------- next part -------------- A non-text attachment was scrubbed... Name: MySQL.i3 Type: application/octet-stream Size: 26193 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MySQLConn.i3 Type: application/octet-stream Size: 11189 bytes Desc: not available URL: -------------- next part -------------- On Feb 22, 2013, at 8:25 AM, Mark Morss wrote: > > Do I correctly suppose that there is no functioning mysql interface for Modula-3? The db module appears to contain only a place-holder for mysql. > > I googled on this and could not discover an answer. > > Best to all. From peter.mckinna at gmail.com Sat Feb 23 00:06:31 2013 From: peter.mckinna at gmail.com (=?utf-8?B?cGV0ZXIubWNraW5uYUBnbWFpbC5jb20=?=) Date: Sat, 23 Feb 2013 10:06:31 +1100 Subject: [M3devel] =?utf-8?q?Mysql_interface=3F?= Message-ID: <5127f9f7.a3c5440a.262b.1ec2@mx.google.com> There is one but you have to get CVS access . Hasn't been a release for some time . Peter Sent from my HTC ----- Reply message ----- From: mika at async.caltech.edu To: "Mark Morss" Cc: Subject: [M3devel] Mysql interface? Date: Sat, Feb 23, 2013 3:40 am The PostgreSQL interface works quite well, though. Mika Mark Morss writes: > >Do I correctly suppose that there is no functioning mysql interface for >Modula-3? The db module appears to contain only a place-holder for mysql. > >I googled on this and could not discover an answer. > >Best to all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 24 09:10:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 24 Feb 2013 08:10:56 +0000 Subject: [M3devel] language question -- locals uninitialized or zero? Message-ID: PROCEDURE F1() VAR a, b := 1; c: INTEGER; t: TEXT; r: TRACED REF... u: UNTRACED REF... BEGIN END F1; Is a defined? To 1 or 0? Is c defined? 0? t? NIL? r? NIL? u? NIL? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 24 09:13:44 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 24 Feb 2013 08:13:44 +0000 Subject: [M3devel] feature request -- variables w/o indentation Message-ID: I would really really really like to be able to declare variables or constants, VAR, WITH, CONST, and NOT have to give up horizontal space to do so. I do like to initialize variables at point of declaration. But these are contradictory. I've been writing more Modula-3, and this among the aspects of it that bothers me the most.. C++ has always had this feature. It is considered so conservative, that even C9x has it. Can Modula-3 be fixed? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Feb 24 09:28:49 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 24 Feb 2013 09:28:49 +0100 (CET) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: References: Message-ID: On Sun, 24 Feb 2013, Jay K wrote: > PROCEDURE F1() > VAR a, b := 1; > ??? c: INTEGER; > ??? t: TEXT; > ??? r: TRACED REF... > ??? u: UNTRACED REF... > BEGIN > END F1; > > > > Is a defined? To 1 or 0? 1 " VAR v_1, ..., v_n: T := E is shorthand for: VAR v_1: T := E; ...; VAR v_n: T := E " http://www.cs.purdue.edu/homes/hosking/m3/reference/variables.html > Is c defined? 0? > t? NIL? > r? NIL? > u? NIL? "If E is omitted, the initial value is an arbitrary value of type T. If both are present, E must be assignable to T." From lemming at henning-thielemann.de Sun Feb 24 10:16:36 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 24 Feb 2013 10:16:36 +0100 (CET) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: <4634A989-48D7-4132-8560-8A47E0A127AE@gmail.com> References: <4634A989-48D7-4132-8560-8A47E0A127AE@gmail.com> Message-ID: On Sun, 24 Feb 2013, Antony Hosking wrote: > On 24/02/2013, at 7:28 PM, Henning Thielemann wrote: > >> "If E is omitted, the initial value is an arbitrary value of type T. If both are present, E must be assignable to T." > > ie, NIL It could also point to a real object, e.g. to the object it pointed to the last time when the variable was used, right? From hendrik at topoi.pooq.com Sun Feb 24 10:11:57 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 24 Feb 2013 04:11:57 -0500 Subject: [M3devel] feature request -- variables w/o indentation In-Reply-To: References: Message-ID: <20130224091157.GA30268@topoi.pooq.com> On Sun, Feb 24, 2013 at 08:13:44AM +0000, Jay K wrote: > I would really really really like to be able to declare variables or constants, VAR, WITH, CONST, and NOT have to give up horizontal space to do so. > > > I do like to initialize variables at point of declaration. > > > But these are contradictory. *I*'d like to declare variables at the point of initialization. -- hendrik From lemming at henning-thielemann.de Sun Feb 24 10:22:08 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: References: <4634A989-48D7-4132-8560-8A47E0A127AE@gmail.com> Message-ID: On Sun, 24 Feb 2013, Antony Hosking wrote: > I suppose it could, but that would be a space leak.The current implementation sets it to NIL. I believe that the question was, whether he can rely on the pointer being NIL, and I think he cannot. From dabenavidesd at yahoo.es Sun Feb 24 17:51:05 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 24 Feb 2013 16:51:05 +0000 (GMT) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: Message-ID: <1361724665.61570.YahooMailClassic@web133102.mail.ir2.yahoo.com> Hi all: if you run such a program and violate safety abstraction of uninitialized programs, you could run the program safely, but being honest means, you run the program and bypass its initialization and get the same results (which is still under first amendment argument, that is violate safety abstractions or RT). Let's suppose you run the program on different runtime environment with different initialization values the fact is you can get different results, which makes your program implementation dependent. This is UNSAFE. Thus if you don't have RT environment to choose from, you don't have any tool to verify that your program is safe and ignoring a safety abstraction is a violation always, because *******RT assumptions must always be truth**********. DEC ALPHA allowed to detect use of unitialized variables on RT, which is still better than a debugger for my own semantic model. in VAX you could get RT exception handling which is more safe, if you will to allow such program behavior in RT, but not unsafely ignoring it like you are trying to do it. Thanks in advance ? --- El dom, 24/2/13, Jay K escribi?: De: Jay K Asunto: [M3devel] language question -- locals uninitialized or zero? Para: "m3devel" Fecha: domingo, 24 de febrero, 2013 03:10 PROCEDURE F1() VAR a, b := 1; ??? c: INTEGER; ??? t: TEXT; ??? r: TRACED REF... ??? u: UNTRACED REF... BEGIN END F1; Is a defined? To 1 or 0? Is c defined? 0? t? NIL? r? NIL? u? NIL? ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 25 18:08:12 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Mon, 25 Feb 2013 09:08:12 -0800 Subject: [M3devel] language question -- locals uninitialized or zero? Message-ID: <20130225090812.FB03F54D@m0005299.ppops.net> -Rodney Bates --- lemming at henning-thielemann.de wrote: From: Henning Thielemann To: Antony Hosking Cc: m3devel Subject: Re: [M3devel] language question -- locals uninitialized or zero? Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) On Sun, 24 Feb 2013, Antony Hosking wrote: > I suppose it could, but that would be a space leak.The current implementation sets it to NIL. I believe that the question was, whether he can rely on the pointer being NIL, and I think he cannot. Yes, he cannot, strictly by the language rules. Somewhat pragmatically, it seems a real stretch to imagine why an implementer would choose anything other than NIL, for any reference type. Even more pragmatically, I am quite sure we have no variant of the compiler that uses anything other than NIL. But to have code that is guaranteed to survive any future new implementation, give it an explicit :=NIL. From mika at async.caltech.edu Mon Feb 25 23:31:20 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 25 Feb 2013 14:31:20 -0800 Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: References: Message-ID: <20130225223121.07C871A2097@async.async.caltech.edu> a and b are 1; nothing else is defined. Jay K writes: >--_b18999f1-d159-4d1d-a35d-bebf3bc4b207_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >PROCEDURE F1() >VAR a=2C b :=3D 1=3B > c: INTEGER=3B > t: TEXT=3B > r: TRACED REF... > u: UNTRACED REF... >BEGIN >END F1=3B > > > >Is a defined? To 1 or 0? >Is c defined? 0? >t? NIL? >r? NIL? >u? NIL? > > > > - Jay > > = > >--_b18999f1-d159-4d1d-a35d-bebf3bc4b207_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >
PROCEDURE F1()
VAR a=2C b := >=3D 1=3B
 =3B =3B =3B c: INTEGER=3B
 =3B =3B = >=3B t: TEXT=3B
 =3B =3B =3B r: TRACED REF...
 =3B&nbs= >p=3B =3B u: UNTRACED REF...
BEGIN
END F1=3B



Is a d= >efined? To 1 or 0?
Is c defined? 0?
t? NIL?
r? NIL?
u? NIL?
= >


 =3B- Jay

>= > >--_b18999f1-d159-4d1d-a35d-bebf3bc4b207_-- From hosking at cs.purdue.edu Tue Feb 26 01:51:39 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2013 11:51:39 +1100 Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: <20130225090812.FB03F54D@m0005299.ppops.net> References: <20130225090812.FB03F54D@m0005299.ppops.net> Message-ID: <3039283A-1CE7-4E4B-BD21-88BD3149A9A4@cs.purdue.edu> Indeed, the explicit NIL will indicate to the reader that the intent is that the variable have the value NIL. It will be no less efficient (since otherwise the compiler must initialize it implicitly). Moreover, it documents intent. On the other hand, where the programmer really does *not* care about the initial value (perhaps because of subsequent assignment before read) I would claim that initializing to NIL only clutters the code and obscures intent. Of course, there is the other alternative, such as for Java which statically prohibits uninitialized variables (either there is an initializing expression or the variable has a subsequent initializing assignment). The result is much the same. In any case, the point is that Modula-3 is *safe* in that no variable can ever have undefined mis-typed state, unlike C, where variables can have arbitrary undefined state. On Feb 26, 2013, at 4:08 AM, "Rodney Bates" wrote: Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 > > > -Rodney Bates > > --- lemming at henning-thielemann.de wrote: > > From: Henning Thielemann > To: Antony Hosking > Cc: m3devel > Subject: Re: [M3devel] language question -- locals uninitialized or zero? > Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) > > > On Sun, 24 Feb 2013, Antony Hosking wrote: > >> I suppose it could, but that would be a space leak.The current implementation sets it to NIL. > > I believe that the question was, whether he can rely on the pointer being > NIL, and I think he cannot. > > Yes, he cannot, strictly by the language rules. Somewhat pragmatically, it seems > a real stretch to imagine why an implementer would choose anything other than NIL, > for any reference type. Even more pragmatically, I am quite sure we have no variant > of the compiler that uses anything other than NIL. But to have code that is guaranteed > to survive any future new implementation, give it an explicit :=NIL. > > From dabenavidesd at yahoo.es Tue Feb 26 03:00:44 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 26 Feb 2013 02:00:44 +0000 (GMT) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: <20130225090812.FB03F54D@m0005299.ppops.net> Message-ID: <1361844044.4515.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi all: semantically the error is are in the program, not in the operating system (untrapped vs trapped error), all untrapped errors must be stopped before making any modification of the runtime system (not in the operating system abstraction). You can run in a untrapped error, but ignore it silently with automatic initialization like you are trying, doesn't help, your program is ill behaved and must be rejected in a checked runtime error. If you run it and don't report the error until it dereferences NIL you are probably making bad things before that (like in initialization code, for instance: MODULE Main; IMPORT SIO; VAR ?a,b,c: BOOLEAN := b=c ; BEGIN ?SIO.PutBool(a); ?SIO.PutBool(b); ?SIO.PutBool(c); END Main. ) in an uninitialized or zeroed program since you can not predict b and c will be at time of evaluation in a initialization. It doesn't solve the problem being pragmatical. Now, if you want to allow ignoring that isn't very well behaved IMHO. In fact, that's UNSAFE. For instance the above example prints TRUETRUEFALSE, in old LINUXLIBC6 makes sense? No, and making nasty assumptions and ignoring errors won't help. The program is simple and wrong. Thanks in advance --- El lun, 25/2/13, Rodney Bates escribi?: De: Rodney Bates Asunto: Re: [M3devel] language question -- locals uninitialized or zero? Para: m3devel at elegosoft.com Fecha: lunes, 25 de febrero, 2013 12:08 -Rodney Bates --- lemming at henning-thielemann.de wrote: From: Henning Thielemann To: Antony Hosking Cc: m3devel Subject: Re: [M3devel] language question -- locals uninitialized or zero? Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) On Sun, 24 Feb 2013, Antony Hosking wrote: > I suppose it could, but that would be a space leak.The current implementation sets it to NIL. I believe that the question was, whether he can rely on the pointer being NIL, and I think he cannot. Yes, he cannot, strictly by the language rules.? Somewhat pragmatically, it seems a real stretch to imagine why an implementer would choose anything other than NIL, for any reference type.? Even more pragmatically, I am quite sure we have no variant of the compiler that uses anything other than NIL.? But to have code that is guaranteed to survive any future new implementation, give it an explicit :=NIL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Feb 1 11:08:49 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 01 Feb 2013 02:08:49 -0800 Subject: [M3devel] Information about record/object field name. In-Reply-To: <510A95E6.4000308@lcwb.coop> References: <510A95E6.4000308@lcwb.coop> Message-ID: <20130201100849.D91041A207D@async.async.caltech.edu> Of course field-order independent serialization won't actually work in Modula-3 unless you know what you are doing. (You will need to know more than just the field name, in particular.) Consider the following: TYPE T = OBJECT f : F; END; U = T OBJECT f : F; END; VAR u : U; with these declarations, the object "u" has two fields of the same type F called f. A reference to u of type U, e.g., VAR p : U := u; will see the second field and VAR q : T := u; will see the first field. You can also switch fields by using NARROW. In any case there will be two fields of the same name. This is not some accident of the language or a mistake or even bad coding practice. It was deliberately done this way for the sake of modularity. Mika "Rodney M. Bates" writes: >This question raises several others in my mind. > >Since you mention a serializer, do I correctly presume you want >the field names of a record/object type that exists in the same >program doing the reading? > >Are you familiar with the existing compiler-generated type information, >in RTTypeMap.i3 and RTTipeMap.i3, and accessible at runtime using RT0.i3 >and other things in m3-libs/m3core/src/runtime/common/*, and produced by >the compiler in, e.g., m3-sys/m3front/src/misc/TipeDesc.i3? > >Unfortunately, neither of these kinds of runtime type information has >field names, only a lists of field types in order. For a serializer, >runtime type information would be a far more convenient source, since >it would not require having either source files or separate derived files (.M3WEB). >Adding the field names here would probably not be a big coding change, >but a change in runtime data structure would no doubt be a big bootstrapping >and upgrading operation, for all concerned. > >Field names are also available in the generated debug information. But >even though this might be a more convenient location to get it from, >decoding it this way would be a nightmare. It's a specialized derivative >of stabs, with lots of Modula-3-specific stuff mangled and encoded inside >the string fields of stabs records. gdb has gobs of code to read in >general stabs and m3gdb has gobs more to further decode it, all in c. >Moreover, there are quite a few differences in what is produced by >various compilers, depending on the version of the M3 front end, the >version of the gcc-derived code generator or the other code generators, >and the target. > >The idea of field-order independent serializing at first seemed pointless >to me. I think the intent must be to allow a serialized object to be >deserialized into a different program as a different type, with different >field orders. Is this the intent? what are the rules about how different >a type can be and still be used in this way? Is it cross-language too? > >The existing Modula-3 serializer (m3-libs/libm3/src/pickle/ver2/Pickle2.i3 etc.) >requires that there be type in the deserializing program that is an exact >(structural) match to the type in the serializing program, according to the >language's rules of type equality. Pickle enforces this by looking for equality >of a 64-bit "signature" that is a hash on a type structure, with the >assumption collisions will not occur. > >Perhaps you have read enough of the runtime, compiler, and serializer >to know all this already. > >Tell us more about the json serializer. > >On 01/28/2013 11:30 AM, Alexey Veselovsky wrote: >> Hello. >> >> It is possible to retrieve field names for given Record or Object type? >> >> I need it for json serializer. >> >> Also this information useful for creating field-order independent serializer. >> >> Thanks, Alexey. From michael.anderson at elego.de Fri Feb 1 14:22:02 2013 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 01 Feb 2013 14:22:02 +0100 Subject: [M3devel] Can't acces to cvs repo. In-Reply-To: References: Message-ID: <510BC17A.3050701@elego.de> On 1/31/13 4:14 PM, Alexey Veselovsky wrote: > Subj. > > Login timeout: > > # cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > Logging in to :pserver:anonymous at modula3.elegosoft.com:2401/usr/cvs > > CVS password: > > cvs [login aborted]: connect to modula3.elegosoft.com > (46.4.219.187):2401 failed: Connection > timed out > > Thanks, Alexey. Hello Alexy, The cvs pserver port was blocked by our firewall, sorry about that. I've opened the port and the pserver is up and running. Please feel free to contact or me directly at if you have any problems. Best Regards, Michael -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Feb 1 18:31:38 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 01 Feb 2013 11:31:38 -0600 Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: References: Message-ID: <510BFBFA.8060208@lcwb.coop> On 01/30/2013 02:24 AM, Jay K wrote: > I commited a fix. But two questions: > > 1) why not just stat, instead of open, fstat, close? > > 2) a lighter weight way to fix this than I did? > In particular: > a) VAR m := NEW(MUTEX); > can we at least say VAR m: MUTEX instead? I tried. It crashed. I would expect this to crash because m would be default initialized to NIL, which when dereferenced, would show up as a segfault, in any M3 implementation I have experience with. Actually, the language only says it has to be initialized to a bit pattern that represents some member of the type. But for or any reference type, the only sensible choice for a compiler to make would be NIL. Perhaps we should change the language to say this explicitly? I am very confident it wouldn't undermine either any existing code or compiler, and might save some grief in the future. > > b) some notion of a "once"? a lock that will only be successfully entered once, for one-time initialization, all other attempts to enter wait for the first enterer to leave, and the it is never entered again. pthreads has this. Win32 since Vista has it (I'd still provide something compatible to pre-Vista, but it can be done easily enough. > They are faster and perhaps smaller than other kinds of locks. > I shouldn't be hard to wrap these with an interface. Lots of people have agonized over the performance hit every time of "has it been done once". > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 30 Jan 2013 07:40:02 +0000 > Subject: [M3devel] awful race condition in libm3/FilePosix.m3? > > FilePosix.m3: > > > I'm not 100% sure, but looks really bad. > I suspect it will close arbitrary files out from other threads. > Notice there is absolutely no mutual exclusion. > An arbitrary number of threads will run here, mostly succeeding, but not necessarily. > > VAR > null_done := FALSE; > null_stat: Ustat.struct_stat; > null_fd: INTEGER; > > > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = > VAR result: INTEGER; > BEGIN > IF NOT null_done THEN > null_fd := Unix.open(M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); > IF null_fd < 0 THEN > null_done := TRUE; > RETURN FALSE > ELSE > result := Ustat.fstat(null_fd, ADR(null_stat)); > EVAL Unix.close(null_fd); > IF result # 0 THEN > null_fd := -1 > END > END; > null_done := TRUE; > END; > RETURN null_fd >= 0 AND statbuf.st_rdev = null_stat.st_rdev > END IsDevNull; > > > - Jay From dmuysers at hotmail.com Fri Feb 1 19:04:02 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Fri, 1 Feb 2013 19:04:02 +0100 Subject: [M3devel] DLLs Message-ID: Using the standard cm3 tools there is no official way to build a library as a DLL. Hence, out of curiosity, the following question: Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 1 21:16:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 1 Feb 2013 20:16:29 +0000 Subject: [M3devel] DLLs In-Reply-To: References: Message-ID: Dirk, From my memory, you have it backwards. .dlls are built by default for any "library".You can suppress .dll building with build_standalone(). It works like this, it is a bit unusual, but kind of nice: f or every "library", we build a static library and a .dll/.so "programs" default to linking to .dlls if present, else static libraries - Jay From: dmuysers at hotmail.com To: m3devel at elegosoft.com Date: Fri, 1 Feb 2013 19:04:02 +0100 Subject: [M3devel] DLLs Using the standard cm3 tools there is no official way to build a library as a DLL. Hence, out of curiosity, the following question: Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Feb 2 07:16:18 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 01 Feb 2013 22:16:18 -0800 Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: <510BFBFA.8060208@lcwb.coop> References: <510BFBFA.8060208@lcwb.coop> Message-ID: <20130202061618.46C6E1A207D@async.async.caltech.edu> "Rodney M. Bates" writes: ... >I would expect this to crash because m would be default initialized to NIL, >which when dereferenced, would show up as a segfault, in any M3 implementation >I have experience with. > >Actually, the language only says it has to be initialized to a bit >pattern that represents some member of the type. But for or any reference >type, the only sensible choice for a compiler to make would be NIL. > >Perhaps we should change the language to say this explicitly? I am >very confident it wouldn't undermine either any existing code or compiler, >and might save some grief in the future. ... The only problem with this proposal is that to me, as a human, VAR m : MUTEX := NIL; ... today means something different from VAR m : MUTEX; notwithstanding the fact that the compiler may implement them the same way. Mika From darko at darko.org Sat Feb 2 09:19:44 2013 From: darko at darko.org (Darko) Date: Sat, 2 Feb 2013 00:19:44 -0800 Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: <20130202061618.46C6E1A207D@async.async.caltech.edu> References: <510BFBFA.8060208@lcwb.coop> <20130202061618.46C6E1A207D@async.async.caltech.edu> Message-ID: <9FF533CE-7B33-4A62-ABD8-13A29B9E1F38@darko.org> I agree with Mika's use of style, but it isn't really affected by the proposed change. I've always thought the notion that the compiler would ever initialize a reference to a value other than Nil unconvincing. The exception would be TEXT references. Then there might be others in the future. The argument for keeping the definition as it is is that it's simple. On Feb 1, 2013, at 10:16 PM, mika at async.caltech.edu wrote: > "Rodney M. Bates" writes: > ... >> I would expect this to crash because m would be default initialized to NIL, >> which when dereferenced, would show up as a segfault, in any M3 implementation >> I have experience with. >> >> Actually, the language only says it has to be initialized to a bit >> pattern that represents some member of the type. But for or any reference >> type, the only sensible choice for a compiler to make would be NIL. >> >> Perhaps we should change the language to say this explicitly? I am >> very confident it wouldn't undermine either any existing code or compiler, >> and might save some grief in the future. > ... > > The only problem with this proposal is that to me, as a human, > > VAR m : MUTEX := NIL; > > ... > > today means something different from > > VAR m : MUTEX; > > notwithstanding the fact that the compiler may implement them the same way. > > Mika > From dabenavidesd at yahoo.es Sat Feb 2 15:29:43 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Feb 2013 14:29:43 +0000 (GMT) Subject: [M3devel] DLLs In-Reply-To: Message-ID: <1359815383.71359.YahooMailClassic@web133104.mail.ir2.yahoo.com> Hi all: indeed you can convert it backwards program called m3-sys/dll2lib I guess if translation process is backwards executed it can do your process, without a problem as long as any type information is lost during normal execution Thanks in advance --- El vie, 1/2/13, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] DLLs Para: "Dirk Muysers" , "m3devel" Fecha: viernes, 1 de febrero, 2013 15:16 Dirk, From my memory,?you have it backwards. .dlls are built?by default for any "library".You can suppress .dll building with build_standalone().?It works like this, it is a bit unusual, but kind of nice:?f or every "library", we build a static library and a .dll/.so?"programs" default to linking to .dlls if present, else static libraries ???- Jay ?From: dmuysers at hotmail.com To: m3devel at elegosoft.com Date: Fri, 1 Feb 2013 19:04:02 +0100 Subject: [M3devel] DLLs Using the standard cm3 tools there is no official way to build a library as a DLL. Hence, out of curiosity, the following question: Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Feb 2 15:38:54 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Feb 2013 14:38:54 +0000 (GMT) Subject: [M3devel] Can't acces to cvs repo. In-Reply-To: <510BC17A.3050701@elego.de> Message-ID: <1359815934.45082.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi all: I think Elego cvs web client is still down or something at: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/ Maybe the security system works but not at that layer level ( hum, maybe this causes cvsup trouble as well?), but upper one, or your link is broken Thanks in advance --- El vie, 1/2/13, Michael Anderson escribi?: De: Michael Anderson Asunto: Re: [M3devel] Can't acces to cvs repo. Para: m3devel at elegosoft.com Fecha: viernes, 1 de febrero, 2013 08:22 On 1/31/13 4:14 PM, Alexey Veselovsky wrote: Subj. Login timeout: # cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login Logging in to :pserver:anonymous at modula3.elegosoft.com:2401/usr/cvs CVS password:? cvs [login aborted]: connect to modula3.elegosoft.com(46.4.219.187):2401 failed: Connection timed out Thanks, Alexey. Hello Alexy, The cvs pserver port was blocked by our firewall, sorry about that. I've opened the port and the pserver is up and running. Please feel free to contact or me directly at if you have any problems. Best Regards, Michael -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Feb 2 21:55:30 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Feb 2013 20:55:30 +0000 (GMT) Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: <9FF533CE-7B33-4A62-ABD8-13A29B9E1F38@darko.org> Message-ID: <1359838530.51873.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi all: you can still use simulated I/O error using a faulty memory component address to some extent, for instance a VAX9000 would immediately shutdown the memory to processor circuit, and kill process using it if possible. If a HW error is scanned and detected prior completion of the program the value is? detected by the test scanner and thus avoid the instruction completion or refusing to run the program (silently or verbosely). Alpha had a similar feature but in execution time. Sorry i don't thing I remember that well details. In a different processor there might be aleatory error in CPU but it won't stop the process already running which is UNSAFE, that's where you might want to use some NIL constant, but in general you cannot "simulate" that error only with that system trap as said because you can prevent the error or ignore it? in a safe way (obviously not with other processors misleading errors). Thanks in advance --- El s?b, 2/2/13, Darko escribi?: De: Darko Asunto: Re: [M3devel] awful race condition in libm3/FilePosix.m3? Para: mika at async.caltech.edu CC: m3devel at elegosoft.com Fecha: s?bado, 2 de febrero, 2013 03:19 I agree with Mika's use of style, but it isn't really affected by the proposed change. I've always thought the notion that the compiler would ever initialize a reference to a value other than Nil unconvincing. The exception would be TEXT references. Then there might be others in the future. The argument for keeping the definition as it is is that it's simple. On Feb 1, 2013, at 10:16 PM, mika at async.caltech.edu wrote: > "Rodney M. Bates" writes: > ... >> I would expect this to crash because m would be default initialized to NIL, >> which when dereferenced, would show up as a segfault, in any M3 implementation >> I have experience with. >> >> Actually, the language only says it has to be initialized to a bit >> pattern that represents some member of the type.? But for or any reference >> type, the only sensible choice for a compiler to make would be NIL. >> >> Perhaps we should change the language to say this explicitly?? I am >> very confident it wouldn't undermine either any existing code or compiler, >> and might save some grief in the future. > ... > > The only problem with this proposal is that to me, as a human, > > VAR m : MUTEX := NIL; > > ... > > today means something different from > > VAR m : MUTEX; > > notwithstanding the fact that the compiler may implement them the same way. > >? ???Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 4 08:14:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 4 Feb 2013 07:14:56 +0000 Subject: [M3devel] Socket error hacks for Ultrix and OSF? Message-ID: We have: WITH errno = GetError() DO IF errno = EINVAL THEN (* hack to try to get real errno, hidden due to NBIO bug in connect *) RefetchError (t.fd); ELSIF errno = EBADF THEN (* we'll try the same for EBADF, which we've seen on Alpha *) RefetchError (t.fd); END; END; PROCEDURE RefetchError(fd: INTEGER) = (* Awful hack to retrieve a meaningful error from a TCP accept socket. Only works on Ultrix and OSF. Leaves result in GetError(). *) VAR optbuf: int := 0; optlen: socklen_t := BYTESIZE(optbuf); BEGIN IF SocketPosix_IsUltrixOrOSF.Value THEN EVAL getsockopt (fd, IPPROTO_TCP, TCP_NODELAY, ADR(optbuf), ADR(optlen)); END; END RefetchError; does anyone know or believe this is useful code? Does anyone object to removing it? I don't believe we'll ever run on Ultrix. OSF/Tru64 is of very marginal interest. Posix doesn't bless this code. It seems ok without this -- it is a subtle matter of precisely which error is raised. Portable code can't depend on the supposedly better Ultrix/OSF behavior, unless they are substandard and return EINVAL/EBADF when other systems return something more specific. If I could find this workaround in any half way recently maintained C or C++ (Perl? Python?) I'd feel a lot better. I guess I'll look. More generally I'd like to see the essentially 4 socket libraries we have (libm3/posix, libm3/win32, m3-comm/win32, m3-comm/posix) merged into one portable C file, and support IPv6... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Mon Feb 4 12:27:55 2013 From: wagner at elego.de (Olaf Wagner) Date: Mon, 4 Feb 2013 12:27:55 +0100 Subject: [M3devel] Compiler upgrade broken in Hudson CI Message-ID: <20130204122755.f9b56cdb.wagner@elego.de> I only just came around to have a look at the recent Hudson CI runs for the cm3 compiler build. It seems that the upgrade path implemented in scripts/upgrade.sh is broken now: http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console What has changed in the dependencies? How to fix upgrade.sh? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Feb 4 13:16:02 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2013 23:16:02 +1100 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <20130204122755.f9b56cdb.wagner@elego.de> References: <20130204122755.f9b56cdb.wagner@elego.de> Message-ID: <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> Jay? Sent from my iPad On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > I only just came around to have a look at the recent Hudson CI runs for > the cm3 compiler build. It seems that the upgrade path implemented in > scripts/upgrade.sh is broken now: > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > What has changed in the dependencies? > How to fix upgrade.sh? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 4 22:09:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 4 Feb 2013 21:09:57 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> References: <20130204122755.f9b56cdb.wagner@elego.de>, <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> Message-ID: I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 4 Feb 2013 23:16:02 +1100 > To: wagner at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > Jay? > > Sent from my iPad > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > I only just came around to have a look at the recent Hudson CI runs for > > the cm3 compiler build. It seems that the upgrade path implemented in > > scripts/upgrade.sh is broken now: > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > What has changed in the dependencies? > > How to fix upgrade.sh? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 4 22:46:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 4 Feb 2013 21:46:05 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, Message-ID: ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; wagner at elego.de Date: Mon, 4 Feb 2013 21:09:57 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 4 Feb 2013 23:16:02 +1100 > To: wagner at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > Jay? > > Sent from my iPad > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > I only just came around to have a look at the recent Hudson CI runs for > > the cm3 compiler build. It seems that the upgrade path implemented in > > scripts/upgrade.sh is broken now: > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > What has changed in the dependencies? > > How to fix upgrade.sh? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Feb 5 07:51:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 06:51:15 +0000 Subject: [M3devel] socket options? Message-ID: Realize that the socket API is almost identical on Win32 and Posix. And the Modula-3 libraries are therefore almost identical -- unfortunately duplicated.. SocketPosix.m3: PROCEDURE InitStream (fd: CARDINAL) RAISES {OSError.E} = (* We assume that the runtime ignores SIGPIPE signals *) VAR one : int := 1; linger := struct_linger{1, 1}; BEGIN EVAL setsockopt(fd, SOL_SOCKET, SO_LINGER, ADR(linger), BYTESIZE(linger)); EVAL setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, ADR(one), BYTESIZE(one)); MakeNonBlocking (fd); END InitStream; PROCEDURE MakeNonBlocking (fd: INTEGER) RAISES {OSError.E} = VAR old_mode := fcntl (fd, F_GETFL, 0); new_mode := Word.Or (old_mode, M3_NONBLOCK); BEGIN IF fcntl (fd, F_SETFL, new_mode) = -1 THEN IOError (Unexpected); END; END MakeNonBlocking; SocketWin32.m3 PROCEDURE InitSock (sock: SOCKET) = (* We assume that the runtime ignores SIGPIPE signals *) VAR one: int := 1; linger := struct_linger{0, 0}; BEGIN EVAL setsockopt (sock, SOL_SOCKET, SO_LINGER, ADR(linger), BYTESIZE(linger)); (**** WinSock documentation warns that this may cause problems ****) EVAL setsockopt (sock, IPPROTO_TCP, TCP_NODELAY, ADR(one), BYTESIZE(one)); END InitSock; The meaning of struct_linger is the SAME on Posix and Win32. The fact that Modula-3 passes "opposite" parameters is clearly broken. so, obvious questions: Do we need either setsockopt? Clearly if we use SO_LINGER, we should use the same parameters. TCP_NODELAY seems to be generally discouraged. But it seems to usually have a real meaning, and removing it here would break things? In particular, it, like, turns off buffering. It means if you do write with just one byte, it will be sent immediately. If that is the "last" byte for a "while", ok. If you are making a series of small writes, it pays very much to coalesce them into fewer larger writes, at the cost of delaying the earlier writes. Here is an example of implicity discouraging it: http://smalltalk.gnu.org/project/issue/119 "The tcp delay, aka. nagles algorithm has it's applications and disabling it should be done only in special applications (eg. where low-latency for is required) IMO. " Doing this unconditionally for all sockets seems wrong. On the other hand: http://en.wikipedia.org/wiki/Nagle%27s_algorithm paraphrasing part of it: As long as the application does not issue small writes, it is ok. At least this part we do the same for Posix and Win32. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Tue Feb 5 09:11:40 2013 From: wagner at elego.de (Olaf Wagner) Date: Tue, 5 Feb 2013 09:11:40 +0100 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de> <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> Message-ID: <20130205091140.ff4fd78c.wagner@elego.de> On Mon, 4 Feb 2013 21:46:05 +0000 Jay K wrote: > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay Yes, please fix it. I'd like to keep up at least two platforms with the old backend. Olaf > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elego.de > Date: Mon, 4 Feb 2013 21:09:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > To: wagner at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > Jay? > > > > Sent from my iPad > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > scripts/upgrade.sh is broken now: > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > What has changed in the dependencies? > > > How to fix upgrade.sh? > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -- 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 Tue Feb 5 09:28:00 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <20130205091140.ff4fd78c.wagner@elego.de> References: <20130204122755.f9b56cdb.wagner@elego.de>, <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , <20130205091140.ff4fd78c.wagner@elego.de> Message-ID: I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 10:49:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , , , , <20130205091140.ff4fd78c.wagner@elego.de>, Message-ID: Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 11:02:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 10:02:26 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, ,,<79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, ,,, ,,, , , <20130205091140.ff4fd78c.wagner@elego.de>, , , Message-ID: The errors also predate the C mode, slightly. I've seen this, like when the target is wrong, or maybe when there is a change in the cm3cg format. I don't remember if the upgrade process is automated enough for that, cm3cg format changes. There hadn't been an attempted build in months for some reason, since August. I'm also curious to trigger Solaris/opencsw builds. I don't remember my Hudson password. Olaf, can you reset it and send it to me privately, please? Thank you. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 11:11:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 10:11:02 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , , , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , , , , , , , , , , <20130205091140.ff4fd78c.wagner@elego.de>, , , , Message-ID: Here, back in October I changed the m3cg format slightly: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/M3CG_Binary.i3.diff?r1=1.6;r2=1.7;f=u Upgrade should always incrementally build cm3cg. It is developers' responsibility to mistrust the incrementality slightly and edit m3-sys/m3cc/src/clean_marker.txt to trigger a clean build if needed..though the incrementality is all very good in my experience. But wait, maybe I messed up. Hm... Easily fixed though. Let me dig more..maybe not tonight.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Subject: RE: [M3devel] Compiler upgrade broken in Hudson CI Date: Tue, 5 Feb 2013 10:02:26 +0000 The errors also predate the C mode, slightly. I've seen this, like when the target is wrong, or maybe when there is a change in the cm3cg format. I don't remember if the upgrade process is automated enough for that, cm3cg format changes. There hadn't been an attempted build in months for some reason, since August. I'm also curious to trigger Solaris/opencsw builds. I don't remember my Hudson password. Olaf, can you reset it and send it to me privately, please? Thank you. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 11:15:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 10:15:12 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , , , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , , , , , , , , , , <20130205091140.ff4fd78c.wagner@elego.de>, , , , , Message-ID: err..maybe that was only comments... From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Subject: RE: [M3devel] Compiler upgrade broken in Hudson CI Date: Tue, 5 Feb 2013 10:11:02 +0000 Here, back in October I changed the m3cg format slightly: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/M3CG_Binary.i3.diff?r1=1.6;r2=1.7;f=u Upgrade should always incrementally build cm3cg. It is developers' responsibility to mistrust the incrementality slightly and edit m3-sys/m3cc/src/clean_marker.txt to trigger a clean build if needed..though the incrementality is all very good in my experience. But wait, maybe I messed up. Hm... Easily fixed though. Let me dig more..maybe not tonight.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Subject: RE: [M3devel] Compiler upgrade broken in Hudson CI Date: Tue, 5 Feb 2013 10:02:26 +0000 The errors also predate the C mode, slightly. I've seen this, like when the target is wrong, or maybe when there is a change in the cm3cg format. I don't remember if the upgrade process is automated enough for that, cm3cg format changes. There hadn't been an attempted build in months for some reason, since August. I'm also curious to trigger Solaris/opencsw builds. I don't remember my Hudson password. Olaf, can you reset it and send it to me privately, please? Thank you. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 20:05:25 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 19:05:25 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: <20130205190330.AC4175DEB20@birch.elegosoft.com> References: <20130205190330.AC4175DEB20@birch.elegosoft.com> Message-ID: Quake's "fs_rmrec" doesn't work where exec("rm -rf") does. Maybe a matter of deleting links instead of their target? Maybe I fixed it a long time ago? - Jay > Date: Tue, 5 Feb 2013 20:03:30 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/02/05 20:03:30 > > Modified files: > cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile > > Log message: > http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/94/consoleFull > rm -rf ../AMD64_LINUX/gmp > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", line 414: quake runtime error: cannot remove recursively ../AMD64_LINUX/gmp: error traversing directory ../AMD64_LINUX/gmp/mpn > > so try this.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Feb 5 20:46:35 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 5 Feb 2013 19:46:35 +0000 Subject: [M3devel] new release Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> I am in process of getting a new computer to replace my old office computer. I've installed the new Visual Studio 2012 Express and want to rebuild my CM3 source tree. It's been a long time since a new CM3 release was made. I note that Jay has done a lot of work and I'm not sure exactly what is the state of the main branch in the CM3 repository. Would folks advise I stick with the last official release, or update to the current main branch before rebuilding everything? The target machine is running Windows 7 Enterprise edition. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 5 22:13:58 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Feb 2013 08:13:58 +1100 Subject: [M3devel] new release In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> The last official release contains known bugs. Best I think to go with the head of the repository. Sent from my iPhone On 06/02/2013, at 6:46 AM, "Coleburn, Randy" wrote: > I am in process of getting a new computer to replace my old office computer. > I?ve installed the new Visual Studio 2012 Express and want to rebuild my CM3 source tree. > It?s been a long time since a new CM3 release was made. > I note that Jay has done a lot of work and I?m not sure exactly what is the state of the main branch in the CM3 repository. > Would folks advise I stick with the last official release, or update to the current main branch before rebuilding everything? > The target machine is running Windows 7 Enterprise edition. > Thanks, > Randy Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Feb 6 03:14:08 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 6 Feb 2013 02:14:08 +0000 (GMT) Subject: [M3devel] Socket error hacks for Ultrix and OSF? Message-ID: <1360116848.82928.YahooMailClassic@web133102.mail.ir2.yahoo.com> Hi all: Jay I deliberately want to quote you this text for your better understanding [1] (I hope it to be so): "... Software Security Explained The concepts behind secure software are often simple but rarely considered by most programmers in the design and implementation of their programs. The following are prime tenets in writing secure software: Give your software the least privileges it needs. Check all return codes religiously. ..." http://books.google.com.co/books?id=uGiOR1mrxggC&dq=inauthor%3A%22Jeff+Schmidt%22&q=%22software+security%22#search_anchor And specifically for ther matter of "assumptions" and pointer initialization: http://www.drdobbs.com/security/safe-programming-with-modula-3/184408858 note that if you guarantee "assumptions" or " absence of unchecked run-time errors" you can argue that still you export the interface as safe. in SPwM3 [2] p.45 "... 2.5.7 Safety ... An interface is 'intrinsically safe' if there is no way to produce an unchecked runtime error by using the interface in a safe module. ..." Now if you say, the VAX9000 or Alpha had probably errors more than any other computer in the era, it could mean that the VAX9000 or Alpha had runtime unchecked errors (probably by that much as any other but let's read this $1.4.5 Safety paragraph) : SPwM3 p. 7 "... ?1.4.5 Safety ?... Unfortunately, it is generally impossible to program the lowest levels of a system with complete safety. Neither the compiler nor the runtime system can check the validity of a bus address for an I/O controller, nor can they limit the ensuing havoc if it is invalid. This presents the language designer with a dilemma. Of he holds out for safety, then low level code will have to be programmed in another language. But if he adopts unsafe features his safety guarantee becomes void everywhere ..." Now, in every definition of safety of a language there must be the unchecked runtime errors (errors than can occur without isolation guarantee), you must define them explicitly as a subset of all untrapped errors. I think one of them is the mentioned above, if we could agree on this errors by platform we can say our language implementation is safe in this proportions due machine restrictions. In case of VAX9000 architecture segments were defined for separated testing of multichip Modules, you could argue you can still work in a isolated machine and guarantee each piece of Hardware satisfies certain properties, so you could think in a top-down fashion how would you build and test your machine for errors that are HW failures and in some cases avoid running the program in those conditions by using fault tolerance. There was a VAXft9000 and Alpha's versions of itself, of course this costs lot more to work in that way, so in general you can't do that as SPwM3 says, but if you want we can do it. Thanks in advance [1] J. Schmidt, Microsoft Windows 2000 security handbook. Que, 2000. [2] C. G. Nelson, Systems programming with Modula-3. Prentice Hall, 1991. --- El lun, 4/2/13, Jay K escribi?: De: Jay K Asunto: [M3devel] Socket error hacks for Ultrix and OSF? Para: "m3devel" Fecha: lunes, 4 de febrero, 2013 02:14 We have: ????? WITH errno = GetError() DO ??????? IF errno = EINVAL THEN ????????? (* hack to try to get real errno, hidden due to NBIO bug in connect *) ????????? RefetchError (t.fd); ??????? ELSIF errno = EBADF THEN ????????? (* we'll try the same for EBADF, which we've seen on Alpha *) ????????? RefetchError (t.fd); ??????? END; ????? END; PROCEDURE RefetchError(fd: INTEGER) = (* Awful hack to retrieve a meaningful error from a TCP accept ?? socket.? Only works on Ultrix and OSF.? Leaves result ?? in GetError().? *) ? VAR optbuf: int := 0;?? optlen: socklen_t := BYTESIZE(optbuf); ? BEGIN ??? IF SocketPosix_IsUltrixOrOSF.Value THEN ????? EVAL getsockopt (fd, IPPROTO_TCP, TCP_NODELAY, ?????????????????????? ADR(optbuf), ADR(optlen)); ??? END; ? END RefetchError; does anyone know or believe this is useful code? Does anyone object to removing it? I don't believe we'll ever run on Ultrix. OSF/Tru64 is of very marginal interest. Posix doesn't bless this code. It seems ok without this -- it is a subtle matter of precisely which error is raised. Portable code can't depend on the supposedly better Ultrix/OSF behavior, unless they are substandard and return EINVAL/EBADF when other systems return something more specific. If I could find this workaround in any half way recently maintained C or C++ (Perl? Python?) I'd feel a lot better. I guess I'll look. More generally I'd like to see the essentially 4 socket libraries we have (libm3/posix, libm3/win32, m3-comm/win32, m3-comm/posix) merged into one portable C file, and support IPv6... ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 07:44:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 06:44:26 +0000 Subject: [M3devel] LONGINT to INTEGER conversion with last release Message-ID: http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/257/console "../src/M3C.m3", line 275: VAL: first argument must be an INTEGER This error dates to the previous release.The current tree lets the first parameter be a LONGINT.You can doVAL(1L, INTEGER) to convert, I think with range check, a LONGINT to an INTEGER. How do I do that with the last release though? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 08:26:04 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:26:04 +0000 Subject: [M3devel] LONGINT to INTEGER conversion with last release In-Reply-To: References: Message-ID: nevermind, I rewrote the code in C. From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 6 Feb 2013 06:44:26 +0000 Subject: [M3devel] LONGINT to INTEGER conversion with last release http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/257/console "../src/M3C.m3", line 275: VAL: first argument must be an INTEGER This error dates to the previous release.The current tree lets the first parameter be a LONGINT.You can doVAL(1L, INTEGER) to convert, I think with range check, a LONGINT to an INTEGER. How do I do that with the last release though? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 08:30:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:30:17 +0000 Subject: [M3devel] hudson_build_system.sh In-Reply-To: <20130206071829.1256B5DEB30@birch.elegosoft.com> References: <20130206071829.1256B5DEB30@birch.elegosoft.com> Message-ID: Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. It looks like the current quake/config only does that for cross builds. It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. - Jay > Date: Wed, 6 Feb 2013 08:18:28 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 13/02/06 08:18:28 > > Modified files: > cm3/scripts/regression/: hudson_build_system.sh > > Log message: > that was not what this script is supposed to do... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 08:45:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:45:56 +0000 Subject: [M3devel] dependencies on recent releases Message-ID: m3back uses LONGINT -- carefully though, it should work with 5.8.6 and not require changes since then (it didn't at first, til today) C code in m3back uses m3core.hC code in m3middle uses m3core.hThe C code in m3back can be removed when we update further, to a frontend that has slightly better support for LONGINT (a change that Tony commited long ago) So you need a "recent" release now to build the system.Recent is over 2 years ago though I believe. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 6 08:48:19 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 08:48:19 +0100 Subject: [M3devel] hudson_build_system.sh In-Reply-To: References: <20130206071829.1256B5DEB30@birch.elegosoft.com> Message-ID: <20130206084819.2c807588060601a69c2de841@elegosoft.com> On Wed, 6 Feb 2013 07:30:17 +0000 Jay K wrote: > Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. The old compiler release wasn't able to build the new sources; and in defs.sh, there are other functions for building from the old release. > The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. I don't think it was necessary here. They simply don't get used. > It looks like the current quake/config only does that for cross builds. > > It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. I'll see if I find time to do some more refactoring, but changing the regression setup is sometimes very subtle and likely to introduce errors. We'd need so many updates -- new VC, Hudson --> Jenkins, WWW, ... Right now I'd just like to get the wheels going again. Olaf > - Jay > > > > Date: Wed, 6 Feb 2013 08:18:28 +0000 > > To: m3commit at elegosoft.com > > From: wagner at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: wagner at birch. 13/02/06 08:18:28 > > > > Modified files: > > cm3/scripts/regression/: hudson_build_system.sh > > > > Log message: > > that was not what this script is supposed to do... > > > -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Feb 6 08:50:00 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 08:50:00 +0100 Subject: [M3devel] Now Hudson fails on AMD64_FREEBSD Message-ID: <20130206085000.f64dc4c94ab8e18a745b6c02@elegosoft.com> http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_FREEBSD/662/console === package m3-sys/m3back === +++ cm3 -build -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' +++ ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' ../src/M3CC.c: In function 'M3CC__UInt64ToText': ../src/M3CC.c:14: warning: return makes pointer from integer without a cast ../src/M3CC.c: At top level: ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input compile_c => 1 C compiler failed compiling: ../src/M3CC.c ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' ../src/M3CC.c: In function 'M3CC__UInt64ToText': ../src/M3CC.c:14: warning: return makes pointer from integer without a cast ../src/M3CC.c: At top level: ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input compile_c => 1 C compiler failed compiling: ../src/M3CC.c This seems to be the new C backend producing wrong assembler code. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 6 08:52:13 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:52:13 +0000 Subject: [M3devel] hudson_build_system.sh In-Reply-To: <20130206084819.2c807588060601a69c2de841@elegosoft.com> References: <20130206071829.1256B5DEB30@birch.elegosoft.com>, , <20130206084819.2c807588060601a69c2de841@elegosoft.com> Message-ID: > The old compiler release wasn't able to build the new sources I think I fixed that. I reduced my use of LONGINT by passing it off to C.There was a later change Tony made, after the initial LONGINT support, that let you use VAL to convert between more types. I was depending on that. I think I am no longer. > hudson jobs for m3cc -- just merge the jobs and use the incrementality and > the clean_marker.txt feature I put I understand, but I think this might be pretty easy.It might already be done..I'll poke around and try to do it fairly soon.We just have to make sure the CVS polling for "the one" task includes everything, doesn't exclude m3cc.The m3cc tasks aren't needed -- but can just be left disabled. The "later" tasks, pkg build, test, those can still be separate..until/unless I understand them.. :) - Jay > Date: Wed, 6 Feb 2013 08:48:19 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: hudson_build_system.sh > > On Wed, 6 Feb 2013 07:30:17 +0000 > Jay K wrote: > > > Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. > > The old compiler release wasn't able to build the new sources; and in defs.sh, there are other functions for building from the old release. > > > The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. > > I don't think it was necessary here. They simply don't get used. > > > It looks like the current quake/config only does that for cross builds. > > > > It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. > > I'll see if I find time to do some more refactoring, but changing the regression setup is sometimes very subtle and likely to introduce errors. > > We'd need so many updates -- new VC, Hudson --> Jenkins, WWW, ... > > Right now I'd just like to get the wheels going again. > > Olaf > > > - Jay > > > > > > > Date: Wed, 6 Feb 2013 08:18:28 +0000 > > > To: m3commit at elegosoft.com > > > From: wagner at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: wagner at birch. 13/02/06 08:18:28 > > > > > > Modified files: > > > cm3/scripts/regression/: hudson_build_system.sh > > > > > > Log message: > > > that was not what this script is supposed to do... > > > > > > > -- > 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 Wed Feb 6 08:53:32 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:53:32 +0000 Subject: [M3devel] Now Hudson fails on AMD64_FREEBSD In-Reply-To: <20130206085000.f64dc4c94ab8e18a745b6c02@elegosoft.com> References: <20130206085000.f64dc4c94ab8e18a745b6c02@elegosoft.com> Message-ID: > This seems to be the new C backend Yes. > producing wrong assembler code. No. It is only being used on Darwin for now. I think that'll need to remain so limited, until I declare structs better, so that debugging doesn't degrade, on systems that support m3gdb. Please stand by..but don't hold breath. - Jay > Date: Wed, 6 Feb 2013 08:50:00 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Now Hudson fails on AMD64_FREEBSD > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_FREEBSD/662/console > > === package m3-sys/m3back === > +++ cm3 -build -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' +++ > ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' > ../src/M3CC.c: In function 'M3CC__UInt64ToText': > ../src/M3CC.c:14: warning: return makes pointer from integer without a cast > ../src/M3CC.c: At top level: > ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input > compile_c => 1 > C compiler failed compiling: ../src/M3CC.c > ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' > ../src/M3CC.c: In function 'M3CC__UInt64ToText': > ../src/M3CC.c:14: warning: return makes pointer from integer without a cast > ../src/M3CC.c: At top level: > ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input > compile_c => 1 > C compiler failed compiling: ../src/M3CC.c > > This seems to be the new C backend producing wrong assembler code. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 09:29:03 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 08:29:03 +0000 Subject: [M3devel] and move to gcc 4.7? Message-ID: Olaf, things working satisfactorily for you in Hudson now for AMD64_LINUX and AMD64_FREEBSD?I'd like to bump m3cc/src/m3makefile up to 4.7 for AMD64_LINUX, FREEBSD. Or anything we have going decently in Hudson.Even though, granted, I'd like to remove that backend sooner rather than later anyway..AMD64_LINUX was at 4.7 but I backed it down to 4.5 today out of paranoia. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 6 09:30:28 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 09:30:28 +0100 Subject: [M3devel] hudson_build_system.sh In-Reply-To: References: <20130206071829.1256B5DEB30@birch.elegosoft.com> <20130206084819.2c807588060601a69c2de841@elegosoft.com> Message-ID: <20130206093028.0526f9c67e42c411f3bfbe14@elegosoft.com> On Wed, 6 Feb 2013 07:52:13 +0000 Jay K wrote: > > The old compiler release wasn't able to build the new sources > I think I fixed that. I reduced my use of LONGINT by passing it off to C.There was a later change Tony made, after the initial LONGINT support, that let you use VAL to convert between more types. I was depending on that. I think I am no longer. OK > > hudson jobs for m3cc -- just merge the jobs and use the incrementality and > the clean_marker.txt feature I put > > I understand, but I think this might be pretty easy.It might already be done..I'll poke around and try to do it fairly soon.We just have to make sure the CVS polling for "the one" task includes everything, doesn't exclude m3cc.The m3cc tasks aren't needed -- but can just be left disabled. > > The "later" tasks, pkg build, test, those can still be separate..until/unless I understand them.. :) Great. I'd just prefer doing such work in separate jobs/scripts; i.e. create a new Hudson job for it which executes a new build script. And keeping the general installation layout of current/last-ok/prev-ok might also help. Olaf > - Jay > > > > Date: Wed, 6 Feb 2013 08:48:19 +0100 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: hudson_build_system.sh > > > > On Wed, 6 Feb 2013 07:30:17 +0000 > > Jay K wrote: > > > > > Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. > > > > The old compiler release wasn't able to build the new sources; and in defs.sh, there are other functions for building from the old release. > > > > > The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. > > > > I don't think it was necessary here. They simply don't get used. > > > > > It looks like the current quake/config only does that for cross builds. > > > > > > It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. > > > > I'll see if I find time to do some more refactoring, but changing the regression setup is sometimes very subtle and likely to introduce errors. > > > > We'd need so many updates -- new VC, Hudson --> Jenkins, WWW, ... > > > > Right now I'd just like to get the wheels going again. > > > > Olaf > > > > > - Jay > > > > > > > > > > Date: Wed, 6 Feb 2013 08:18:28 +0000 > > > > To: m3commit at elegosoft.com > > > > From: wagner at elego.de > > > > Subject: [M3commit] CVS Update: cm3 > > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: wagner at birch. 13/02/06 08:18:28 > > > > > > > > Modified files: > > > > cm3/scripts/regression/: hudson_build_system.sh > > > > > > > > Log message: > > > > that was not what this script is supposed to do... > > > > > > > > > > > -- > > 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 wagner at elegosoft.com Wed Feb 6 09:34:09 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 09:34:09 +0100 Subject: [M3devel] and move to gcc 4.7? In-Reply-To: References: Message-ID: <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> On Wed, 6 Feb 2013 08:29:03 +0000 Jay K wrote: > Olaf, things working satisfactorily for you in Hudson now for AMD64_LINUX and AMD64_FREEBSD? Recent builds seem to have succeeded. > I'd like to bump m3cc/src/m3makefile up to 4.7 for AMD64_LINUX, FREEBSD. Or anything we have going decently in Hudson.Even though, granted, I'd like to remove that backend sooner rather than later anyway..AMD64_LINUX was at 4.7 but I backed it down to 4.5 today out of paranoia. Just try it. Before we remove the old backend, I'd like to have some validation of the quality and performance of the new one though, just to avoid regression. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 6 09:46:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 08:46:15 +0000 Subject: [M3devel] and move to gcc 4.7? In-Reply-To: <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> References: , <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> Message-ID: > quality and performance of the new one though, just to avoid regression. Well..the main "quality" is portability.Much is being potentially sacrificed for it. There are potential other improvements, but also potential regressions. Optimization might be better, i.e. by not using gcc, or worse, i.e. by going via C. Compiler performance is likely worse, due to the extra text production and parsing.It seems ok to me. I've been using a while. But not great. Skipping the .mc/m3cg file production helped a lot. Debugging will be better on Darwin and NT -- where currently we have no type info, I hope to add significant typing. "Ease of distribution" will take a step forward, but it isn't yet where I want it to be.You know, you just want tar xf; configure; make; make install. No need for cross builds or "unusual" prerequesites, "just" a C compiler and Bourne shell and make. Portability will increase.Maintainability will increase.We will no longer have a motivation for "chasing" newer gcc. (nor patches e.g. for OpenBSD)We will "automatically" port to "every" target. This is an exaggeration, but not by a lot.The "porting" will work will decrease. Porting work will further decrease when we have cooperative suspend. - Jay > Date: Wed, 6 Feb 2013 09:34:09 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] and move to gcc 4.7? > > On Wed, 6 Feb 2013 08:29:03 +0000 > Jay K wrote: > > > Olaf, things working satisfactorily for you in Hudson now for AMD64_LINUX and AMD64_FREEBSD? > Recent builds seem to have succeeded. > > > I'd like to bump m3cc/src/m3makefile up to 4.7 for AMD64_LINUX, FREEBSD. Or anything we have going decently in Hudson.Even though, granted, I'd like to remove that backend sooner rather than later anyway..AMD64_LINUX was at 4.7 but I backed it down to 4.5 today out of paranoia. > > Just try it. > > Before we remove the old backend, I'd like to have some validation of the > quality and performance of the new one though, just to avoid regression. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 10:00:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 09:00:33 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs Message-ID: Olaf, Dagobert, Dagobert: We haven't tried to run anything in a while. 1) SOLsun is failing to login: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs is that right? Olaf:2) Can we get SPARC64_SOLARIS and AMD64_SOLARIS?They can work on the existing machines.Maybe I need to provide an initial bootstrap or setup?Maybe I did long ago?Maybe poke in ~jkrell?Maybe just start with the existing sparc32 and x86? They should cross ok, if CM3_TARGET is set explicitly to override the default target=host. Olaf:3) I'd like to see SOLsun switched to be called SPARC32_SOLARIS."It should just work." The support has been in for a long time. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 10:28:14 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 09:28:14 +0000 Subject: [M3devel] updating exception handling implementation and backend interface?? Message-ID: The jmpbuf/alloca fix? For reference, here is most of the undo:http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/Marker.m3.diff?r1=1.9;r2=1.10;f=uor http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/Marker.m3.diff?r1=1.9;r2=1.10 I had generated code like: old:char buf[sizeof(jmpbuf)]; // frontend knows sizeof(jmpbuf) -- the portability problem to be solved TRY => setjmp(buf); new:jmpbuf* buf;extern const size_t Csetjmp__Jumpbuf_size/* = sizeof(jmp_buf)*/; *)TRY => buf = m3_alloca(sizeof(Csetjmp__Jumpbuf_size)); setjmp(buf);=> alloca for every TRY, even if TRY in a loop, not good Understanding that is a further de-optimization, how about I just do:jmpbuf* buf;TRY => buf = buf ? buf : alloca(sizeof(jmpbuf)); setjmp(buf); ? It seems easy enough? furthermore, let's think ahead to the C and maybe C++ backends? The portable slightly optimizing C backend will go back to jmpbuf, no alloca.The optimizing C++ backend will try to use native C++ exception handling.And/or the optimizing C-for-NT backend will use __try/__except/__finally. Should I start/end "buf" with some distinguished name?So some backends will remove it, in favor of whatever they do better?Should "m3_alloca" be named something more specific like "m3_alloca_for_try"?Again, so it is easier to backends to recognize and remove?i.e. one of the first optimizations the C backend should make isto #include and change these to jmpbuf. Should we invent a higher level interface?Should we do "both", make low level and high level calls to the backend?It will chose to ignore one set?But the low level calls need to be altered at least a little bit.Like the locals and the calls will have a flag or a boolean indicatingthey are "exception handling related"? Am I making sense? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Wed Feb 6 10:40:31 2013 From: wagner at elego.de (Olaf Wagner) Date: Wed, 6 Feb 2013 10:40:31 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: Message-ID: <20130206104031.c16645c8.wagner@elego.de> On Wed, 6 Feb 2013 09:00:33 +0000 Jay K wrote: > Olaf, Dagobert, > > Dagobert: We haven't tried to run anything in a while. > > 1) SOLsun is failing to login: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > is that right? The problem on that build farm always was the missing direct CVS access. There used to be that proxy server; I don't know if it's still up. > Olaf:2) Can we get SPARC64_SOLARIS and AMD64_SOLARIS?They can work on the existing machines.Maybe I need to provide an initial bootstrap or setup?Maybe I did long ago?Maybe poke in ~jkrell?Maybe just start with the existing sparc32 and x86? They should cross ok, if CM3_TARGET is set explicitly to override the default target=host. I'm not sure if there are any bootstrap packages for 64 bit; maybe you need to do the initial bootstrap manually. An initial environment needs to be setup for Hudson, see http://hudson.modula3.com:8080/view/zzz/job/boot-template/ for example. > Olaf:3) I'd like to see SOLsun switched to be called SPARC32_SOLARIS."It should just work." The support has been in for a long time. OK. If you're expecting me to do something specific, please say so explicitly; I'm still very much involved in other customer projects. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elego.de Wed Feb 6 12:15:35 2013 From: wagner at elego.de (Olaf Wagner) Date: Wed, 6 Feb 2013 12:15:35 +0100 Subject: [M3devel] and move to gcc 4.7? In-Reply-To: References: <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> Message-ID: <20130206121535.f55292b8.wagner@elego.de> On Wed, 6 Feb 2013 08:46:15 +0000 Jay K wrote: > > quality and performance of the new one though, just to avoid regression. > > Well..the main "quality" is portability.Much is being potentially sacrificed for it. > > There are potential other improvements, but also potential regressions. > > Optimization might be better, i.e. by not using gcc, or worse, i.e. by going via C. > > Compiler performance is likely worse, due to the extra text production and parsing.It seems ok to me. I've been using a while. But not great. Skipping the .mc/m3cg file production helped a lot. > > Debugging will be better on Darwin and NT -- where currently we have no type info, I hope to add significant typing. > > "Ease of distribution" will take a step forward, but it isn't yet where I want it to be.You know, you just want tar xf; configure; make; make install. No need for cross builds or "unusual" prerequesites, "just" a C compiler and Bourne shell and make. > > Portability will increase.Maintainability will increase.We will no longer have a motivation for "chasing" newer gcc. (nor patches e.g. for OpenBSD)We will "automatically" port to "every" target. This is an exaggeration, but not by a lot.The "porting" will work will decrease. Porting work will further decrease when we have cooperative suspend. Yes, I understand and appreciate all those. I was just thinking of something more pragmatical. Let's start with m3tests: Recent runs show a regression from 19 to 49 errors on AMD64_LINUX: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-AMD64_LINUX/ The same for FreeBSD 8: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-AMD64_FREEBSD/ Can you explain (and fix) those? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From cornstalk at columbus.rr.com Wed Feb 6 15:38:56 2013 From: cornstalk at columbus.rr.com (Mark Morss) Date: Wed, 06 Feb 2013 09:38:56 -0500 Subject: [M3devel] new release In-Reply-To: <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> Message-ID: <51126B00.7010301@columbus.rr.com> On 02/05/2013 04:13 PM, Tony Hosking wrote: > The last official release contains known bugs. Best I think to go with > the head of the repository. > > Sent from my iPhone > > On 06/02/2013, at 6:46 AM, "Coleburn, Randy" > wrote: > >> I am in process of getting a new computer to replace my old office >> computer. >> >> I?ve installed the new Visual Studio 2012 Express and want to rebuild >> my CM3 source tree. >> >> It?s been a long time since a new CM3 release was made. >> >> I note that Jay has done a lot of work and I?m not sure exactly what >> is the state of the main branch in the CM3 repository. >> >> Would folks advise I stick with the last official release, or update >> to the current main branch before rebuilding everything? >> >> The target machine is running Windows 7 Enterprise edition. >> >> Thanks, >> >> Randy Coleburn >> Well, that's a little bit disturbing. Would it be much trouble for someone to gin up a new release with the latest corrections in it? Not everyone wants to fool around with CVS. Best to all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 6 16:38:22 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 16:38:22 +0100 Subject: [M3devel] new release In-Reply-To: <51126B00.7010301@columbus.rr.com> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> <51126B00.7010301@columbus.rr.com> Message-ID: <20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com> On Wed, 06 Feb 2013 09:38:56 -0500 Mark Morss wrote: > On 02/05/2013 04:13 PM, Tony Hosking wrote: > > The last official release contains known bugs. Best I think to go with > > the head of the repository. > > > > Sent from my iPhone > > > > On 06/02/2013, at 6:46 AM, "Coleburn, Randy" > > wrote: > > > >> I am in process of getting a new computer to replace my old office > >> computer. > >> > >> I?ve installed the new Visual Studio 2012 Express and want to rebuild > >> my CM3 source tree. > >> > >> It?s been a long time since a new CM3 release was made. > >> > >> I note that Jay has done a lot of work and I?m not sure exactly what > >> is the state of the main branch in the CM3 repository. > >> > >> Would folks advise I stick with the last official release, or update > >> to the current main branch before rebuilding everything? > >> > >> The target machine is running Windows 7 Enterprise edition. > >> > >> Thanks, > >> > >> Randy Coleburn > >> > Well, that's a little bit disturbing. Would it be much trouble for > someone to gin up a new release with the latest corrections in it? Not > everyone wants to fool around with CVS. Well, I think we will do a new release as soon as the C backend has settled. But you can always get current snapshots of the system from the Hudson builds, at least for Linux and FreeBSD, see http://www.opencm3.net/snaps/snapshot-index.html Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Wed Feb 6 18:24:30 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 06 Feb 2013 11:24:30 -0600 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , <20130205091140.ff4fd78c.wagner@elego.de> Message-ID: <511291CE.9090100@lcwb.coop> On 02/05/2013 02:28 AM, Jay K wrote: > I will fix it, but I do desire to drop the old backend entirely. > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. And I use m3gdb all the time in my own work. Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > - Jay > From rcolebur at SCIRES.COM Thu Feb 7 00:13:37 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 6 Feb 2013 23:13:37 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! --Randy Coleburn -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Wednesday, February 06, 2013 12:25 PM To: m3devel at elegosoft.com Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI On 02/05/2013 02:28 AM, Jay K wrote: > I will fix it, but I do desire to drop the old backend entirely. > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. And I use m3gdb all the time in my own work. Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > - Jay > From dabenavidesd at yahoo.es Thu Feb 7 05:56:26 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 7 Feb 2013 04:56:26 +0000 (GMT) Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <1360212986.90708.YahooMailClassic@web133106.mail.ir2.yahoo.com> Hi all: Gcc support is becoming harder and harder to get not here precisely in gcc camp. I agree with somethings you say, like good backend debugging support, but we need really get serious about implementation alternatives, it would be wonderful to support JIT targets (read, JVM, .NET, C-like machines), and obviously they are better to be written in C substrate (we need one hardware abstraction layer). If you could just reuse m3cc to make a throw prototype of a JIT compiler for instance to C-like bytecode (in form of inline assembly of gcc) the approach of C generating backend would be lot more easier to support, because you can create binary translators with NJ machine code toolkit translators for instance to several platforms using either C or Modula-3 decoding. Kind of supporting Thanks in advance --- El mi?, 6/2/13, Coleburn, Randy escribi?: De: Coleburn, Randy Asunto: Re: [M3devel] Compiler upgrade broken in Hudson CI Para: "m3devel at elegosoft.com" Fecha: mi?rcoles, 6 de febrero, 2013 18:13 I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! --Randy Coleburn -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Wednesday, February 06, 2013 12:25 PM To: m3devel at elegosoft.com Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI On 02/05/2013 02:28 AM, Jay K wrote: > I will fix it, but I do desire to drop the old backend entirely. > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. I have put in a *huge* amount of work on m3gdb.? While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence.? Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc.? etc. A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information.? Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more.? As I recall it, only the release branch supports a working m3gdb right now. And I use m3gdb all the time in my own work. Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*.? Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > >???- Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 7 07:35:15 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 7 Feb 2013 07:35:15 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: Message-ID: <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com> On Wed, 6 Feb 2013 09:00:33 +0000 Jay K wrote: > Olaf, Dagobert, > > Dagobert: We haven't tried to run anything in a while. > > 1) SOLsun is failing to login: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > is that right? Login works now. I've started the job http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/157/console to see how far it gets. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Feb 7 08:36:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 7 Feb 2013 07:36:41 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: m3gdb: is GPL is a fork, that will never be merged that isn't being updated is big that doesn't support some platforms e.g. Darwin, HP-UX cm3cg has some but not all of those characteristics Meanwhile, debugging on NT and Darwin is limited to line numbersand integers and floats. No useful view of structs or globalsis available. And as I understand..can anyone agree/disagree?.. gets itsdata from the backend via a total backdoor hack, that is very difficultto duplicate. E.g. including with llvm, including if we generatedtypeful gcc trees like any normal backend would do.I speculate, maybe it will be possible to output some assemblyfiles on the side with just the stabs directives. I'm hoping that: gdb on Darwin will improve drastically via the C backend; it hasn't yet windbg and Visual Studio ditto gdb on platforms that support m3gdb will come close to m3gdb,but parity might not be achievable. Our target support continues to lag. DragonflyBSD? OpenBSD w/o maintaining patches (mainline gcc doesn't support OpenBSD, but I386_ELF is all fairly much the same, so the patches are small) ARM_NT? {PPC,MIPS,ARM,SH,I386}_CE? ARM_DARWIN? Was mostly there already. PPC32_XBOX? AMD64_NT? This should come along fairly soon now via the C backend. Let's see how good we can get stock debuggers working with our C. Ok? - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 6 Feb 2013 23:13:37 +0000 > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! > --Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Wednesday, February 06, 2013 12:25 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > On 02/05/2013 02:28 AM, Jay K wrote: > > I will fix it, but I do desire to drop the old backend entirely. > > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > > > > > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. > > I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. > > Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. > > A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its > Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. > > And I use m3gdb all the time in my own work. > > Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Feb 8 00:31:46 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 8 Feb 2013 00:31:46 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com> References: <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com> Message-ID: <20130208003146.9bb5951f2fc35b356cf63582@elegosoft.com> On Thu, 7 Feb 2013 07:35:15 +0100 Olaf Wagner wrote: > On Wed, 6 Feb 2013 09:00:33 +0000 > Jay K wrote: > > > Olaf, Dagobert, > > > > Dagobert: We haven't tried to run anything in a while. > > > > 1) SOLsun is failing to login: > > > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > > > is that right? > > Login works now. I've started the job > http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/157/console > to see how far it gets. Status update: the three platforms currently configured for CM3 on the buildfarm work again to some degree. I had to change CVS ports from 2401 to 12401, change host names from current to dublin and move some files around. I386_SOLARIS fails in the m3cc package: http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console SOLsun on SPARC Solaris 9 fails in m3core: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console SOLsun on SPARC Solaris 10 succeeds: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/ We should fix those failures before changing things like target platform names. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Feb 8 08:36:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 8 Feb 2013 07:36:12 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <20130208003146.9bb5951f2fc35b356cf63582@elegosoft.com> References: , <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com>, <20130208003146.9bb5951f2fc35b356cf63582@elegosoft.com> Message-ID: > SOLsun on SPARC Solaris 9 fails in m3core: That is odd, I added fprintf for maybe more information > I386_SOLARIS fails in the m3cc package: Oops, sorry, not surprising, so I downgraded to 4.5 for all Solaris platforms.Otherwise I have to port forward the patches to gcc to avoid depending on gcc extensions. Or we can build gcc with gcc instead of Solaris cc. - Jay > Date: Fri, 8 Feb 2013 00:31:46 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > > On Thu, 7 Feb 2013 07:35:15 +0100 > Olaf Wagner wrote: > > > On Wed, 6 Feb 2013 09:00:33 +0000 > > Jay K wrote: > > > > > Olaf, Dagobert, > > > > > > Dagobert: We haven't tried to run anything in a while. > > > > > > 1) SOLsun is failing to login: > > > > > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > > > > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > > > > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > > > > > is that right? > > > > Login works now. I've started the job > > http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/157/console > > to see how far it gets. > > Status update: the three platforms currently configured for CM3 on the buildfarm > work again to some degree. I had to change CVS ports from 2401 to 12401, > change host names from current to dublin and move some files around. > > I386_SOLARIS fails in the m3cc package: > http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console > > SOLsun on SPARC Solaris 9 fails in m3core: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console > > SOLsun on SPARC Solaris 10 succeeds: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/ > > We should fix those failures before changing things like target platform names. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Feb 8 09:28:11 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 8 Feb 2013 09:28:11 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: Message-ID: <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org> Hi, sorry for answering late. Am 06.02.2013 um 10:00 schrieb Jay K : > Olaf, Dagobert, > > > Dagobert: We haven't tried to run anything in a while. > > > 1) SOLsun is failing to login: > > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664 > Building remotely on opencsw_current10s > [cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC" > cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refused > FATAL: CVS failed. exit code=1 > Finished: FAILURE > > > The Hudson job is configured to use: > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > > is that right? We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it if you need it. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Feb 8 10:44:41 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 8 Feb 2013 10:44:41 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org> References: <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org> Message-ID: <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com> On Fri, 8 Feb 2013 09:28:11 +0100 Dagobert Michelsen wrote: > We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it > if you need it. But it seems to work with Port 12401 instead of 2401, so no need to change anything right now. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Fri Feb 8 16:42:22 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 08 Feb 2013 09:42:22 -0600 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <51151CDE.1070207@lcwb.coop> On 02/07/2013 01:36 AM, Jay K wrote: > m3gdb: > is GPL > is a fork, that will never be merged > that isn't being updated > is big > that doesn't support some platforms e.g. Darwin, HP-UX Yes. But what it does, works, now. Nothing else exists now that comes close. Actually, it has been merged into at least 5 versions of gdb, counting the original modification. I have done three, and in each, I have moved towards reducing the entanglement with existing gdb code, so merging gets easier, though still no picnic. It's been updated many times, though not recently. Most of the pure updates have been enhancements. Most of the regressions have been caused by back end changes, not problems inside m3gdb. That said, as often as possible, I have worked around these inside m3gdb, by adding yet another back end version to the set it can dynamically adapt to, rather than fixing the back end. Kludgier, yes. But it's more robust, and compatible. It already copes with quite a range of back ends. > > cm3cg has some but not all of those characteristics > Ditto. > > Meanwhile, debugging on NT and Darwin is limited to line numbers > and integers and floats. No useful view of structs or globals > is available. Perhaps. But what it does, works on LINUXLIBC6 and AMD64_LINUX, now. Have you tried m3gdb on NT and Darwin using the working (debug-info-wise) gcc backend (4.5, as I recall), or only the one wherein you disabled the Modula-3 debug output (4.6, as I recall)? In the latter case, it, of course, doesn't work anywhere. I think you will find stuff like calls, procedure variables, etc., that involve the calling convention, will need target-dependent work in m3gdb. That's the way it went when adding AMD64_LINUX. But I would expect more than you describe to work on a new target, without modifications. > And as I understand..can anyone agree/disagree?.. gets its > data from the backend via a total backdoor hack, that is very difficult > to duplicate. Yes, it's a backdoor hack. But it works, now. E.g. including with llvm, In the long run, llvm plus dwarf (which llvm appears to already have good support for) is the clear way to get something non-hackish. But that will require major debugger work to support, in addition, of course, to an llvm-derived back end itself. I am sure this approach would be much easier than getting dwarf info out of either cm3cg, or gcc compiling C source. including if we generated > typeful gcc trees like any normal backend would do. > I speculate, maybe it will be possible to output some assembly > files on the side with just the stabs directives. > This could probably work, but it's just a superficially different information path for an equivalent backdoor hack. Right now, cm3cg pretty much just serves as a conduit for stabs info that is generated by the code parse.c. From there, it ends up, with little or no change, interspersed in the rest of the cm3cg-generated assembly code. But I expect this would be the only reasonable way to get any Modula-3-literate debug info past C source code. > > > I'm hoping that: > gdb on Darwin will improve drastically via the C backend; it hasn't yet > windbg and Visual Studio ditto > > gdb on platforms that support m3gdb will come close to m3gdb, > but parity might not be achievable. You will not achieve anything close to parity without a debugger that has a lot of Modula-3-specific code inside. Have you read cm3/doc/help/m3gdb/m3gdb-onepage.html? Consider it the definition of parity. > > > Our target support continues to lag. > DragonflyBSD? > OpenBSD w/o maintaining patches (mainline gcc doesn't support OpenBSD, but I386_ELF is all fairly much the same, so the patches are small) > ARM_NT? > {PPC,MIPS,ARM,SH,I386}_CE? > ARM_DARWIN? Was mostly there already. > PPC32_XBOX? > AMD64_NT? This should come along fairly soon now via the C backend. > > > Let's see how good we can get stock debuggers working with our C. Ok? > Do whatever you can and want to. But don't torpedo what is now working, until you can replace it with something that achieves parity. Until then, don't break, disable, or remove it from CVS head. Keep it an easy-to-choose and findably-documented option. If you make changes that could possibly undermine it, make a branch, until they are well-tested. > > - Jay > > > > From: rcolebur at SCIRES.COM > > To: m3devel at elegosoft.com > > Date: Wed, 6 Feb 2013 23:13:37 +0000 > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! > > --Randy Coleburn > > > > -----Original Message----- > > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > > Sent: Wednesday, February 06, 2013 12:25 PM > > To: m3devel at elegosoft.com > > Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > On 02/05/2013 02:28 AM, Jay K wrote: > > > I will fix it, but I do desire to drop the old backend entirely. > > > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > > > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > > > > > > > > > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. > > > > I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. > > > > Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. > > > > A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its > > Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. > > > > And I use m3gdb all the time in my own work. > > > > Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > > > > > > > > > - Jay > > > From jay.krell at cornell.edu Wed Feb 13 11:20:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 13 Feb 2013 10:20:51 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com> References: , <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org>, <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com> Message-ID: > I386_SOLARIS fails in the m3cc package: http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console > This looks ok now. >> http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/166/consoleFull > SOLsun on SPARC Solaris 9 fails in m3core: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console I changed this to print more, but it doesn't. I'm guessing it is the previous m3core failing? Use a new minimum distribution? I'll work on it.. Thanks, - Jay > Date: Fri, 8 Feb 2013 10:44:41 +0100 > From: wagner at elegosoft.com > To: dam at opencsw.org > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > > On Fri, 8 Feb 2013 09:28:11 +0100 > Dagobert Michelsen wrote: > > > We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it > > if you need it. > > But it seems to work with Port 12401 instead of 2401, so no need to > change anything right now. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 17 08:59:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 07:59:26 +0000 Subject: [M3devel] sparc64 problem Message-ID: This looks familiar..but I don't remember what I did about it, and don't see a fix in the tree already... new source -> compiling Matrix4.m3 m3front ../src/Matrix4.m3 -w1 /Users/jay/dev2/cm3/m3-sys/m3cc/AMD64_DARWIN-SPARC64_SOLARIS/cm3cg -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Matrix4.mc -o Matrix4.ms ../src/Matrix4.m3: In function 'Matrix4__TransformUnitCube': ../src/Matrix4.m3:317:0: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:6212 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: Matrix4.mc INTERFACE Point3; TYPE T = RECORD x,y,z : REAL; END; INTERFACE Matrix4; IMPORT Point3; PROCEDURE TransformUnitCube (p, a, b, c : Point3.T) : T; This is probably because we declare that records have size, but no fields. i.e. yet another thing bad about the current cm3cg backend.. I can try with 4.2 or 4.3 or 4.5 or 4.6, but I expect they are the same here.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 17 08:59:06 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 17 Feb 2013 08:59:06 +0100 Subject: [M3devel] DLLs In-Reply-To: References: Message-ID: <927C5FEC-CD7F-4787-B61C-E8C9DFEAF817@m3w.org> Also from memory, I second this? I was/am using .DLL's in a manner compatible with Linux/OSX (using right API calls, of course). No special anything anywhere. -- Divided by a common language Dragi?a Duri? dragisha at m3w.org On Feb 1, 2013, at 9:16 PM, Jay K wrote: > Dirk, From my memory, you have it backwards. .dlls are built by default for any "library". > You can suppress .dll building with build_standalone(). > > It works like this, it is a bit unusual, but kind of nice: > f or every "library", we build a static library and a .dll/.so > "programs" default to linking to .dlls if present, else static libraries > > > - Jay > > From: dmuysers at hotmail.com > To: m3devel at elegosoft.com > Date: Fri, 1 Feb 2013 19:04:02 +0100 > Subject: [M3devel] DLLs > > Using the standard cm3 tools there is no official way to build a library as a DLL. > Hence, out of curiosity, the following question: > Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Feb 17 22:02:51 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 17 Feb 2013 15:02:51 -0600 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: <20130217205228.0C60B5DEA8F@birch.elegosoft.com> References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com> Message-ID: <5121457B.6060703@lcwb.coop> What is happening here? Every time I commit these two files, cvs inserts a few opening comment delimiters without matching closing ones. It does this to my local copy, in addition to, as nearly as I can ascertain, the checked-in copy. On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/02/17 21:52:28 > > Modified files: > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > Log message: > > > From jay.krell at cornell.edu Mon Feb 18 00:22:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: <5121457B.6060703@lcwb.coop> References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, <5121457B.6060703@lcwb.coop> Message-ID: It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. - Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 18 00:25:21 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2013 00:25:21 +0100 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: <5121457B.6060703@lcwb.coop> References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com> <5121457B.6060703@lcwb.coop> Message-ID: <20130218002521.8b7e518a87cf1b2694f74df7@elegosoft.com> On Sun, 17 Feb 2013 15:02:51 -0600 "Rodney M. Bates" wrote: > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: I assume CVS replaces the magic $Id$ and $Log$ keywords. You could try to remove them, they only will make version control more difficult. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 18 00:23:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 23:23:38 +0000 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , <5121457B.6060703@lcwb.coop>, Message-ID: ps: can we not add more GPL stuff? Can use a BSD license? Thanks, - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. - Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 18 00:41:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 23:41:57 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: , , <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org>, , <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com>, Message-ID: >> SOLsun on SPARC Solaris 9 fails in m3core: >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console > I changed this to print more, but it doesn't. > I'm guessing it is the previous m3core failing? > Use a new minimum distribution? I'll work on it.. It took me a while. How about this: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-SOLsun-d5.9.0-Solaris5.8-20130217.tar.lzma ? Built on 5.8 -- should work on that and newer.. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dam at opencsw.org Date: Wed, 13 Feb 2013 10:20:51 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > I386_SOLARIS fails in the m3cc package: http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console > This looks ok now. >> http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/166/consoleFull > SOLsun on SPARC Solaris 9 fails in m3core: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console I changed this to print more, but it doesn't. I'm guessing it is the previous m3core failing? Use a new minimum distribution? I'll work on it.. Thanks, - Jay > Date: Fri, 8 Feb 2013 10:44:41 +0100 > From: wagner at elegosoft.com > To: dam at opencsw.org > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > > On Fri, 8 Feb 2013 09:28:11 +0100 > Dagobert Michelsen wrote: > > > We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it > > if you need it. > > But it seems to work with Port 12401 instead of 2401, so no need to > change anything right now. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 18 00:52:33 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2013 10:52:33 +1100 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , <5121457B.6060703@lcwb.coop>, Message-ID: GPL # BSD. We should minimize GPL stuff where we are unable to eliminate. On Feb 18, 2013, at 10:23 AM, Jay K wrote: > ps: can we not add more GPL stuff? Can use a BSD license? > > Thanks, > - Jay > > > From: jay.krell at cornell.edu > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Sun, 17 Feb 2013 23:22:33 +0000 > Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > It's related to those dollar sign thingies. We could just remove them entirely. > I found a form that doesn't break, though not clear I'm getting the intended content. > > - Jay > > > > Date: Sun, 17 Feb 2013 15:02:51 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > > > What is happening here? Every time I commit these two files, cvs inserts > > a few opening comment delimiters without matching closing ones. It does > > this to my local copy, in addition to, as nearly as I can ascertain, the > > checked-in copy. > > > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > > CVSROOT: /usr/cvs > > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > > > Modified files: > > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > > > Log message: > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 18 01:18:18 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 18 Feb 2013 00:18:18 +0000 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , , <5121457B.6060703@lcwb.coop>, , , , Message-ID: Agreed. There's been some GPL additions recently. From: hosking at cs.purdue.edu Date: Mon, 18 Feb 2013 10:52:33 +1100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 GPL # BSD. We should minimize GPL stuff where we are unable to eliminate. On Feb 18, 2013, at 10:23 AM, Jay K wrote:ps: can we not add more GPL stuff? Can use a BSD license? Thanks, - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. - Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Feb 18 02:59:53 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 18 Feb 2013 01:59:53 +0000 (GMT) Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> Hi all: core RT is different fundamentally of that proposition, e.g: http://modula3.elegosoft.com/cm3/doc/help/gen_html/m3core/src/runtime/common/RTHooks.m3.html#0TOP0 Please, we should keep improving this instead of not allowing changes or removing it without notice. Thanks in advance --- El dom, 17/2/13, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 Para: "Tony" CC: "m3devel" Fecha: domingo, 17 de febrero, 2013 19:18 Agreed. There's been some GPL additions recently. From: hosking at cs.purdue.edu Date: Mon, 18 Feb 2013 10:52:33 +1100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 GPL # BSD. We should minimize GPL stuff where we are unable to eliminate. On Feb 18, 2013, at 10:23 AM, Jay K wrote: ps: can we not add more GPL stuff? Can use a BSD license? Thanks, ?- Jay From:?jay.krell at cornell.edu To:?rodney_bates at lcwb.coop;?m3devel at elegosoft.com Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. ?- Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From:?rodney_bates at lcwb.coop > To:?m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 >? > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. >? > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > >? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 18 15:46:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 18 Feb 2013 08:46:40 -0600 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , <5121457B.6060703@lcwb.coop>, Message-ID: <51223ED0.8010502@lcwb.coop> Please elaborate on what you want to do and why. On 02/17/2013 05:52 PM, Tony Hosking wrote: > GPL # BSD. > > We should minimize GPL stuff where we are unable to eliminate. > > On Feb 18, 2013, at 10:23 AM, Jay K > wrote: > >> ps: can we not add more GPL stuff? Can use a BSD license? >> >> Thanks, >> - Jay >> >> >> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --- >> From:jay.krell at cornell.edu >> To:rodney_bates at lcwb.coop ;m3devel at elegosoft.com >> Date: Sun, 17 Feb 2013 23:22:33 +0000 >> Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 >> >> It's related to those dollar sign thingies. We could just remove them entirely. >> I found a form that doesn't break, though not clear I'm getting the intended content. >> >> - Jay >> >> >> > Date: Sun, 17 Feb 2013 15:02:51 -0600 >> > From:rodney_bates at lcwb.coop >> > To:m3devel at elegosoft.com >> > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 >> > >> > What is happening here? Every time I commit these two files, cvs inserts >> > a few opening comment delimiters without matching closing ones. It does >> > this to my local copy, in addition to, as nearly as I can ascertain, the >> > checked-in copy. >> > >> > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: >> > > CVSROOT: /usr/cvs >> > > Changes by: rodney at birch. 13/02/17 21:52:28 >> > > >> > > Modified files: >> > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 >> > > >> > > Log message: >> > > >> > > >> > > >> > > From cornstalk at columbus.rr.com Fri Feb 22 17:25:50 2013 From: cornstalk at columbus.rr.com (Mark Morss) Date: Fri, 22 Feb 2013 11:25:50 -0500 Subject: [M3devel] Mysql interface? In-Reply-To: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> References: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> Message-ID: <51279C0E.1000807@columbus.rr.com> Do I correctly suppose that there is no functioning mysql interface for Modula-3? The db module appears to contain only a place-holder for mysql. I googled on this and could not discover an answer. Best to all. From mika at async.caltech.edu Fri Feb 22 17:40:07 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 22 Feb 2013 08:40:07 -0800 Subject: [M3devel] Mysql interface? In-Reply-To: <51279C0E.1000807@columbus.rr.com> References: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> <51279C0E.1000807@columbus.rr.com> Message-ID: <20130222164007.353A51A2095@async.async.caltech.edu> The PostgreSQL interface works quite well, though. Mika Mark Morss writes: > >Do I correctly suppose that there is no functioning mysql interface for >Modula-3? The db module appears to contain only a place-holder for mysql. > >I googled on this and could not discover an answer. > >Best to all. From darko at darko.org Fri Feb 22 19:43:49 2013 From: darko at darko.org (Darko) Date: Fri, 22 Feb 2013 10:43:49 -0800 Subject: [M3devel] Mysql interface? In-Reply-To: <51279C0E.1000807@columbus.rr.com> References: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> <51279C0E.1000807@columbus.rr.com> Message-ID: <899E88D3-6134-45B1-9D3E-1F6F3C177C22@darko.org> These should work, but are not thoroughly tested nor complete. -------------- next part -------------- A non-text attachment was scrubbed... Name: MySQL.i3 Type: application/octet-stream Size: 26193 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MySQLConn.i3 Type: application/octet-stream Size: 11189 bytes Desc: not available URL: -------------- next part -------------- On Feb 22, 2013, at 8:25 AM, Mark Morss wrote: > > Do I correctly suppose that there is no functioning mysql interface for Modula-3? The db module appears to contain only a place-holder for mysql. > > I googled on this and could not discover an answer. > > Best to all. From peter.mckinna at gmail.com Sat Feb 23 00:06:31 2013 From: peter.mckinna at gmail.com (=?utf-8?B?cGV0ZXIubWNraW5uYUBnbWFpbC5jb20=?=) Date: Sat, 23 Feb 2013 10:06:31 +1100 Subject: [M3devel] =?utf-8?q?Mysql_interface=3F?= Message-ID: <5127f9f7.a3c5440a.262b.1ec2@mx.google.com> There is one but you have to get CVS access . Hasn't been a release for some time . Peter Sent from my HTC ----- Reply message ----- From: mika at async.caltech.edu To: "Mark Morss" Cc: Subject: [M3devel] Mysql interface? Date: Sat, Feb 23, 2013 3:40 am The PostgreSQL interface works quite well, though. Mika Mark Morss writes: > >Do I correctly suppose that there is no functioning mysql interface for >Modula-3? The db module appears to contain only a place-holder for mysql. > >I googled on this and could not discover an answer. > >Best to all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 24 09:10:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 24 Feb 2013 08:10:56 +0000 Subject: [M3devel] language question -- locals uninitialized or zero? Message-ID: PROCEDURE F1() VAR a, b := 1; c: INTEGER; t: TEXT; r: TRACED REF... u: UNTRACED REF... BEGIN END F1; Is a defined? To 1 or 0? Is c defined? 0? t? NIL? r? NIL? u? NIL? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 24 09:13:44 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 24 Feb 2013 08:13:44 +0000 Subject: [M3devel] feature request -- variables w/o indentation Message-ID: I would really really really like to be able to declare variables or constants, VAR, WITH, CONST, and NOT have to give up horizontal space to do so. I do like to initialize variables at point of declaration. But these are contradictory. I've been writing more Modula-3, and this among the aspects of it that bothers me the most.. C++ has always had this feature. It is considered so conservative, that even C9x has it. Can Modula-3 be fixed? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Feb 24 09:28:49 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 24 Feb 2013 09:28:49 +0100 (CET) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: References: Message-ID: On Sun, 24 Feb 2013, Jay K wrote: > PROCEDURE F1() > VAR a, b := 1; > ??? c: INTEGER; > ??? t: TEXT; > ??? r: TRACED REF... > ??? u: UNTRACED REF... > BEGIN > END F1; > > > > Is a defined? To 1 or 0? 1 " VAR v_1, ..., v_n: T := E is shorthand for: VAR v_1: T := E; ...; VAR v_n: T := E " http://www.cs.purdue.edu/homes/hosking/m3/reference/variables.html > Is c defined? 0? > t? NIL? > r? NIL? > u? NIL? "If E is omitted, the initial value is an arbitrary value of type T. If both are present, E must be assignable to T." From lemming at henning-thielemann.de Sun Feb 24 10:16:36 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 24 Feb 2013 10:16:36 +0100 (CET) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: <4634A989-48D7-4132-8560-8A47E0A127AE@gmail.com> References: <4634A989-48D7-4132-8560-8A47E0A127AE@gmail.com> Message-ID: On Sun, 24 Feb 2013, Antony Hosking wrote: > On 24/02/2013, at 7:28 PM, Henning Thielemann wrote: > >> "If E is omitted, the initial value is an arbitrary value of type T. If both are present, E must be assignable to T." > > ie, NIL It could also point to a real object, e.g. to the object it pointed to the last time when the variable was used, right? From hendrik at topoi.pooq.com Sun Feb 24 10:11:57 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 24 Feb 2013 04:11:57 -0500 Subject: [M3devel] feature request -- variables w/o indentation In-Reply-To: References: Message-ID: <20130224091157.GA30268@topoi.pooq.com> On Sun, Feb 24, 2013 at 08:13:44AM +0000, Jay K wrote: > I would really really really like to be able to declare variables or constants, VAR, WITH, CONST, and NOT have to give up horizontal space to do so. > > > I do like to initialize variables at point of declaration. > > > But these are contradictory. *I*'d like to declare variables at the point of initialization. -- hendrik From lemming at henning-thielemann.de Sun Feb 24 10:22:08 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: References: <4634A989-48D7-4132-8560-8A47E0A127AE@gmail.com> Message-ID: On Sun, 24 Feb 2013, Antony Hosking wrote: > I suppose it could, but that would be a space leak.The current implementation sets it to NIL. I believe that the question was, whether he can rely on the pointer being NIL, and I think he cannot. From dabenavidesd at yahoo.es Sun Feb 24 17:51:05 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 24 Feb 2013 16:51:05 +0000 (GMT) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: Message-ID: <1361724665.61570.YahooMailClassic@web133102.mail.ir2.yahoo.com> Hi all: if you run such a program and violate safety abstraction of uninitialized programs, you could run the program safely, but being honest means, you run the program and bypass its initialization and get the same results (which is still under first amendment argument, that is violate safety abstractions or RT). Let's suppose you run the program on different runtime environment with different initialization values the fact is you can get different results, which makes your program implementation dependent. This is UNSAFE. Thus if you don't have RT environment to choose from, you don't have any tool to verify that your program is safe and ignoring a safety abstraction is a violation always, because *******RT assumptions must always be truth**********. DEC ALPHA allowed to detect use of unitialized variables on RT, which is still better than a debugger for my own semantic model. in VAX you could get RT exception handling which is more safe, if you will to allow such program behavior in RT, but not unsafely ignoring it like you are trying to do it. Thanks in advance ? --- El dom, 24/2/13, Jay K escribi?: De: Jay K Asunto: [M3devel] language question -- locals uninitialized or zero? Para: "m3devel" Fecha: domingo, 24 de febrero, 2013 03:10 PROCEDURE F1() VAR a, b := 1; ??? c: INTEGER; ??? t: TEXT; ??? r: TRACED REF... ??? u: UNTRACED REF... BEGIN END F1; Is a defined? To 1 or 0? Is c defined? 0? t? NIL? r? NIL? u? NIL? ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 25 18:08:12 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Mon, 25 Feb 2013 09:08:12 -0800 Subject: [M3devel] language question -- locals uninitialized or zero? Message-ID: <20130225090812.FB03F54D@m0005299.ppops.net> -Rodney Bates --- lemming at henning-thielemann.de wrote: From: Henning Thielemann To: Antony Hosking Cc: m3devel Subject: Re: [M3devel] language question -- locals uninitialized or zero? Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) On Sun, 24 Feb 2013, Antony Hosking wrote: > I suppose it could, but that would be a space leak.The current implementation sets it to NIL. I believe that the question was, whether he can rely on the pointer being NIL, and I think he cannot. Yes, he cannot, strictly by the language rules. Somewhat pragmatically, it seems a real stretch to imagine why an implementer would choose anything other than NIL, for any reference type. Even more pragmatically, I am quite sure we have no variant of the compiler that uses anything other than NIL. But to have code that is guaranteed to survive any future new implementation, give it an explicit :=NIL. From mika at async.caltech.edu Mon Feb 25 23:31:20 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 25 Feb 2013 14:31:20 -0800 Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: References: Message-ID: <20130225223121.07C871A2097@async.async.caltech.edu> a and b are 1; nothing else is defined. Jay K writes: >--_b18999f1-d159-4d1d-a35d-bebf3bc4b207_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >PROCEDURE F1() >VAR a=2C b :=3D 1=3B > c: INTEGER=3B > t: TEXT=3B > r: TRACED REF... > u: UNTRACED REF... >BEGIN >END F1=3B > > > >Is a defined? To 1 or 0? >Is c defined? 0? >t? NIL? >r? NIL? >u? NIL? > > > > - Jay > > = > >--_b18999f1-d159-4d1d-a35d-bebf3bc4b207_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >
PROCEDURE F1()
VAR a=2C b := >=3D 1=3B
 =3B =3B =3B c: INTEGER=3B
 =3B =3B = >=3B t: TEXT=3B
 =3B =3B =3B r: TRACED REF...
 =3B&nbs= >p=3B =3B u: UNTRACED REF...
BEGIN
END F1=3B



Is a d= >efined? To 1 or 0?
Is c defined? 0?
t? NIL?
r? NIL?
u? NIL?
= >


 =3B- Jay

>= > >--_b18999f1-d159-4d1d-a35d-bebf3bc4b207_-- From hosking at cs.purdue.edu Tue Feb 26 01:51:39 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2013 11:51:39 +1100 Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: <20130225090812.FB03F54D@m0005299.ppops.net> References: <20130225090812.FB03F54D@m0005299.ppops.net> Message-ID: <3039283A-1CE7-4E4B-BD21-88BD3149A9A4@cs.purdue.edu> Indeed, the explicit NIL will indicate to the reader that the intent is that the variable have the value NIL. It will be no less efficient (since otherwise the compiler must initialize it implicitly). Moreover, it documents intent. On the other hand, where the programmer really does *not* care about the initial value (perhaps because of subsequent assignment before read) I would claim that initializing to NIL only clutters the code and obscures intent. Of course, there is the other alternative, such as for Java which statically prohibits uninitialized variables (either there is an initializing expression or the variable has a subsequent initializing assignment). The result is much the same. In any case, the point is that Modula-3 is *safe* in that no variable can ever have undefined mis-typed state, unlike C, where variables can have arbitrary undefined state. On Feb 26, 2013, at 4:08 AM, "Rodney Bates" wrote: Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 > > > -Rodney Bates > > --- lemming at henning-thielemann.de wrote: > > From: Henning Thielemann > To: Antony Hosking > Cc: m3devel > Subject: Re: [M3devel] language question -- locals uninitialized or zero? > Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) > > > On Sun, 24 Feb 2013, Antony Hosking wrote: > >> I suppose it could, but that would be a space leak.The current implementation sets it to NIL. > > I believe that the question was, whether he can rely on the pointer being > NIL, and I think he cannot. > > Yes, he cannot, strictly by the language rules. Somewhat pragmatically, it seems > a real stretch to imagine why an implementer would choose anything other than NIL, > for any reference type. Even more pragmatically, I am quite sure we have no variant > of the compiler that uses anything other than NIL. But to have code that is guaranteed > to survive any future new implementation, give it an explicit :=NIL. > > From dabenavidesd at yahoo.es Tue Feb 26 03:00:44 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 26 Feb 2013 02:00:44 +0000 (GMT) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: <20130225090812.FB03F54D@m0005299.ppops.net> Message-ID: <1361844044.4515.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi all: semantically the error is are in the program, not in the operating system (untrapped vs trapped error), all untrapped errors must be stopped before making any modification of the runtime system (not in the operating system abstraction). You can run in a untrapped error, but ignore it silently with automatic initialization like you are trying, doesn't help, your program is ill behaved and must be rejected in a checked runtime error. If you run it and don't report the error until it dereferences NIL you are probably making bad things before that (like in initialization code, for instance: MODULE Main; IMPORT SIO; VAR ?a,b,c: BOOLEAN := b=c ; BEGIN ?SIO.PutBool(a); ?SIO.PutBool(b); ?SIO.PutBool(c); END Main. ) in an uninitialized or zeroed program since you can not predict b and c will be at time of evaluation in a initialization. It doesn't solve the problem being pragmatical. Now, if you want to allow ignoring that isn't very well behaved IMHO. In fact, that's UNSAFE. For instance the above example prints TRUETRUEFALSE, in old LINUXLIBC6 makes sense? No, and making nasty assumptions and ignoring errors won't help. The program is simple and wrong. Thanks in advance --- El lun, 25/2/13, Rodney Bates escribi?: De: Rodney Bates Asunto: Re: [M3devel] language question -- locals uninitialized or zero? Para: m3devel at elegosoft.com Fecha: lunes, 25 de febrero, 2013 12:08 -Rodney Bates --- lemming at henning-thielemann.de wrote: From: Henning Thielemann To: Antony Hosking Cc: m3devel Subject: Re: [M3devel] language question -- locals uninitialized or zero? Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) On Sun, 24 Feb 2013, Antony Hosking wrote: > I suppose it could, but that would be a space leak.The current implementation sets it to NIL. I believe that the question was, whether he can rely on the pointer being NIL, and I think he cannot. Yes, he cannot, strictly by the language rules.? Somewhat pragmatically, it seems a real stretch to imagine why an implementer would choose anything other than NIL, for any reference type.? Even more pragmatically, I am quite sure we have no variant of the compiler that uses anything other than NIL.? But to have code that is guaranteed to survive any future new implementation, give it an explicit :=NIL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Feb 1 11:08:49 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 01 Feb 2013 02:08:49 -0800 Subject: [M3devel] Information about record/object field name. In-Reply-To: <510A95E6.4000308@lcwb.coop> References: <510A95E6.4000308@lcwb.coop> Message-ID: <20130201100849.D91041A207D@async.async.caltech.edu> Of course field-order independent serialization won't actually work in Modula-3 unless you know what you are doing. (You will need to know more than just the field name, in particular.) Consider the following: TYPE T = OBJECT f : F; END; U = T OBJECT f : F; END; VAR u : U; with these declarations, the object "u" has two fields of the same type F called f. A reference to u of type U, e.g., VAR p : U := u; will see the second field and VAR q : T := u; will see the first field. You can also switch fields by using NARROW. In any case there will be two fields of the same name. This is not some accident of the language or a mistake or even bad coding practice. It was deliberately done this way for the sake of modularity. Mika "Rodney M. Bates" writes: >This question raises several others in my mind. > >Since you mention a serializer, do I correctly presume you want >the field names of a record/object type that exists in the same >program doing the reading? > >Are you familiar with the existing compiler-generated type information, >in RTTypeMap.i3 and RTTipeMap.i3, and accessible at runtime using RT0.i3 >and other things in m3-libs/m3core/src/runtime/common/*, and produced by >the compiler in, e.g., m3-sys/m3front/src/misc/TipeDesc.i3? > >Unfortunately, neither of these kinds of runtime type information has >field names, only a lists of field types in order. For a serializer, >runtime type information would be a far more convenient source, since >it would not require having either source files or separate derived files (.M3WEB). >Adding the field names here would probably not be a big coding change, >but a change in runtime data structure would no doubt be a big bootstrapping >and upgrading operation, for all concerned. > >Field names are also available in the generated debug information. But >even though this might be a more convenient location to get it from, >decoding it this way would be a nightmare. It's a specialized derivative >of stabs, with lots of Modula-3-specific stuff mangled and encoded inside >the string fields of stabs records. gdb has gobs of code to read in >general stabs and m3gdb has gobs more to further decode it, all in c. >Moreover, there are quite a few differences in what is produced by >various compilers, depending on the version of the M3 front end, the >version of the gcc-derived code generator or the other code generators, >and the target. > >The idea of field-order independent serializing at first seemed pointless >to me. I think the intent must be to allow a serialized object to be >deserialized into a different program as a different type, with different >field orders. Is this the intent? what are the rules about how different >a type can be and still be used in this way? Is it cross-language too? > >The existing Modula-3 serializer (m3-libs/libm3/src/pickle/ver2/Pickle2.i3 etc.) >requires that there be type in the deserializing program that is an exact >(structural) match to the type in the serializing program, according to the >language's rules of type equality. Pickle enforces this by looking for equality >of a 64-bit "signature" that is a hash on a type structure, with the >assumption collisions will not occur. > >Perhaps you have read enough of the runtime, compiler, and serializer >to know all this already. > >Tell us more about the json serializer. > >On 01/28/2013 11:30 AM, Alexey Veselovsky wrote: >> Hello. >> >> It is possible to retrieve field names for given Record or Object type? >> >> I need it for json serializer. >> >> Also this information useful for creating field-order independent serializer. >> >> Thanks, Alexey. From michael.anderson at elego.de Fri Feb 1 14:22:02 2013 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 01 Feb 2013 14:22:02 +0100 Subject: [M3devel] Can't acces to cvs repo. In-Reply-To: References: Message-ID: <510BC17A.3050701@elego.de> On 1/31/13 4:14 PM, Alexey Veselovsky wrote: > Subj. > > Login timeout: > > # cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > Logging in to :pserver:anonymous at modula3.elegosoft.com:2401/usr/cvs > > CVS password: > > cvs [login aborted]: connect to modula3.elegosoft.com > (46.4.219.187):2401 failed: Connection > timed out > > Thanks, Alexey. Hello Alexy, The cvs pserver port was blocked by our firewall, sorry about that. I've opened the port and the pserver is up and running. Please feel free to contact or me directly at if you have any problems. Best Regards, Michael -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Feb 1 18:31:38 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 01 Feb 2013 11:31:38 -0600 Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: References: Message-ID: <510BFBFA.8060208@lcwb.coop> On 01/30/2013 02:24 AM, Jay K wrote: > I commited a fix. But two questions: > > 1) why not just stat, instead of open, fstat, close? > > 2) a lighter weight way to fix this than I did? > In particular: > a) VAR m := NEW(MUTEX); > can we at least say VAR m: MUTEX instead? I tried. It crashed. I would expect this to crash because m would be default initialized to NIL, which when dereferenced, would show up as a segfault, in any M3 implementation I have experience with. Actually, the language only says it has to be initialized to a bit pattern that represents some member of the type. But for or any reference type, the only sensible choice for a compiler to make would be NIL. Perhaps we should change the language to say this explicitly? I am very confident it wouldn't undermine either any existing code or compiler, and might save some grief in the future. > > b) some notion of a "once"? a lock that will only be successfully entered once, for one-time initialization, all other attempts to enter wait for the first enterer to leave, and the it is never entered again. pthreads has this. Win32 since Vista has it (I'd still provide something compatible to pre-Vista, but it can be done easily enough. > They are faster and perhaps smaller than other kinds of locks. > I shouldn't be hard to wrap these with an interface. Lots of people have agonized over the performance hit every time of "has it been done once". > - Jay > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Wed, 30 Jan 2013 07:40:02 +0000 > Subject: [M3devel] awful race condition in libm3/FilePosix.m3? > > FilePosix.m3: > > > I'm not 100% sure, but looks really bad. > I suspect it will close arbitrary files out from other threads. > Notice there is absolutely no mutual exclusion. > An arbitrary number of threads will run here, mostly succeeding, but not necessarily. > > VAR > null_done := FALSE; > null_stat: Ustat.struct_stat; > null_fd: INTEGER; > > > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = > VAR result: INTEGER; > BEGIN > IF NOT null_done THEN > null_fd := Unix.open(M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); > IF null_fd < 0 THEN > null_done := TRUE; > RETURN FALSE > ELSE > result := Ustat.fstat(null_fd, ADR(null_stat)); > EVAL Unix.close(null_fd); > IF result # 0 THEN > null_fd := -1 > END > END; > null_done := TRUE; > END; > RETURN null_fd >= 0 AND statbuf.st_rdev = null_stat.st_rdev > END IsDevNull; > > > - Jay From dmuysers at hotmail.com Fri Feb 1 19:04:02 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Fri, 1 Feb 2013 19:04:02 +0100 Subject: [M3devel] DLLs Message-ID: Using the standard cm3 tools there is no official way to build a library as a DLL. Hence, out of curiosity, the following question: Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 1 21:16:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 1 Feb 2013 20:16:29 +0000 Subject: [M3devel] DLLs In-Reply-To: References: Message-ID: Dirk, From my memory, you have it backwards. .dlls are built by default for any "library".You can suppress .dll building with build_standalone(). It works like this, it is a bit unusual, but kind of nice: f or every "library", we build a static library and a .dll/.so "programs" default to linking to .dlls if present, else static libraries - Jay From: dmuysers at hotmail.com To: m3devel at elegosoft.com Date: Fri, 1 Feb 2013 19:04:02 +0100 Subject: [M3devel] DLLs Using the standard cm3 tools there is no official way to build a library as a DLL. Hence, out of curiosity, the following question: Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Feb 2 07:16:18 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 01 Feb 2013 22:16:18 -0800 Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: <510BFBFA.8060208@lcwb.coop> References: <510BFBFA.8060208@lcwb.coop> Message-ID: <20130202061618.46C6E1A207D@async.async.caltech.edu> "Rodney M. Bates" writes: ... >I would expect this to crash because m would be default initialized to NIL, >which when dereferenced, would show up as a segfault, in any M3 implementation >I have experience with. > >Actually, the language only says it has to be initialized to a bit >pattern that represents some member of the type. But for or any reference >type, the only sensible choice for a compiler to make would be NIL. > >Perhaps we should change the language to say this explicitly? I am >very confident it wouldn't undermine either any existing code or compiler, >and might save some grief in the future. ... The only problem with this proposal is that to me, as a human, VAR m : MUTEX := NIL; ... today means something different from VAR m : MUTEX; notwithstanding the fact that the compiler may implement them the same way. Mika From darko at darko.org Sat Feb 2 09:19:44 2013 From: darko at darko.org (Darko) Date: Sat, 2 Feb 2013 00:19:44 -0800 Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: <20130202061618.46C6E1A207D@async.async.caltech.edu> References: <510BFBFA.8060208@lcwb.coop> <20130202061618.46C6E1A207D@async.async.caltech.edu> Message-ID: <9FF533CE-7B33-4A62-ABD8-13A29B9E1F38@darko.org> I agree with Mika's use of style, but it isn't really affected by the proposed change. I've always thought the notion that the compiler would ever initialize a reference to a value other than Nil unconvincing. The exception would be TEXT references. Then there might be others in the future. The argument for keeping the definition as it is is that it's simple. On Feb 1, 2013, at 10:16 PM, mika at async.caltech.edu wrote: > "Rodney M. Bates" writes: > ... >> I would expect this to crash because m would be default initialized to NIL, >> which when dereferenced, would show up as a segfault, in any M3 implementation >> I have experience with. >> >> Actually, the language only says it has to be initialized to a bit >> pattern that represents some member of the type. But for or any reference >> type, the only sensible choice for a compiler to make would be NIL. >> >> Perhaps we should change the language to say this explicitly? I am >> very confident it wouldn't undermine either any existing code or compiler, >> and might save some grief in the future. > ... > > The only problem with this proposal is that to me, as a human, > > VAR m : MUTEX := NIL; > > ... > > today means something different from > > VAR m : MUTEX; > > notwithstanding the fact that the compiler may implement them the same way. > > Mika > From dabenavidesd at yahoo.es Sat Feb 2 15:29:43 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Feb 2013 14:29:43 +0000 (GMT) Subject: [M3devel] DLLs In-Reply-To: Message-ID: <1359815383.71359.YahooMailClassic@web133104.mail.ir2.yahoo.com> Hi all: indeed you can convert it backwards program called m3-sys/dll2lib I guess if translation process is backwards executed it can do your process, without a problem as long as any type information is lost during normal execution Thanks in advance --- El vie, 1/2/13, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] DLLs Para: "Dirk Muysers" , "m3devel" Fecha: viernes, 1 de febrero, 2013 15:16 Dirk, From my memory,?you have it backwards. .dlls are built?by default for any "library".You can suppress .dll building with build_standalone().?It works like this, it is a bit unusual, but kind of nice:?f or every "library", we build a static library and a .dll/.so?"programs" default to linking to .dlls if present, else static libraries ???- Jay ?From: dmuysers at hotmail.com To: m3devel at elegosoft.com Date: Fri, 1 Feb 2013 19:04:02 +0100 Subject: [M3devel] DLLs Using the standard cm3 tools there is no official way to build a library as a DLL. Hence, out of curiosity, the following question: Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Feb 2 15:38:54 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Feb 2013 14:38:54 +0000 (GMT) Subject: [M3devel] Can't acces to cvs repo. In-Reply-To: <510BC17A.3050701@elego.de> Message-ID: <1359815934.45082.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi all: I think Elego cvs web client is still down or something at: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/ Maybe the security system works but not at that layer level ( hum, maybe this causes cvsup trouble as well?), but upper one, or your link is broken Thanks in advance --- El vie, 1/2/13, Michael Anderson escribi?: De: Michael Anderson Asunto: Re: [M3devel] Can't acces to cvs repo. Para: m3devel at elegosoft.com Fecha: viernes, 1 de febrero, 2013 08:22 On 1/31/13 4:14 PM, Alexey Veselovsky wrote: Subj. Login timeout: # cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login Logging in to :pserver:anonymous at modula3.elegosoft.com:2401/usr/cvs CVS password:? cvs [login aborted]: connect to modula3.elegosoft.com(46.4.219.187):2401 failed: Connection timed out Thanks, Alexey. Hello Alexy, The cvs pserver port was blocked by our firewall, sorry about that. I've opened the port and the pserver is up and running. Please feel free to contact or me directly at if you have any problems. Best Regards, Michael -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Feb 2 21:55:30 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Feb 2013 20:55:30 +0000 (GMT) Subject: [M3devel] awful race condition in libm3/FilePosix.m3? In-Reply-To: <9FF533CE-7B33-4A62-ABD8-13A29B9E1F38@darko.org> Message-ID: <1359838530.51873.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi all: you can still use simulated I/O error using a faulty memory component address to some extent, for instance a VAX9000 would immediately shutdown the memory to processor circuit, and kill process using it if possible. If a HW error is scanned and detected prior completion of the program the value is? detected by the test scanner and thus avoid the instruction completion or refusing to run the program (silently or verbosely). Alpha had a similar feature but in execution time. Sorry i don't thing I remember that well details. In a different processor there might be aleatory error in CPU but it won't stop the process already running which is UNSAFE, that's where you might want to use some NIL constant, but in general you cannot "simulate" that error only with that system trap as said because you can prevent the error or ignore it? in a safe way (obviously not with other processors misleading errors). Thanks in advance --- El s?b, 2/2/13, Darko escribi?: De: Darko Asunto: Re: [M3devel] awful race condition in libm3/FilePosix.m3? Para: mika at async.caltech.edu CC: m3devel at elegosoft.com Fecha: s?bado, 2 de febrero, 2013 03:19 I agree with Mika's use of style, but it isn't really affected by the proposed change. I've always thought the notion that the compiler would ever initialize a reference to a value other than Nil unconvincing. The exception would be TEXT references. Then there might be others in the future. The argument for keeping the definition as it is is that it's simple. On Feb 1, 2013, at 10:16 PM, mika at async.caltech.edu wrote: > "Rodney M. Bates" writes: > ... >> I would expect this to crash because m would be default initialized to NIL, >> which when dereferenced, would show up as a segfault, in any M3 implementation >> I have experience with. >> >> Actually, the language only says it has to be initialized to a bit >> pattern that represents some member of the type.? But for or any reference >> type, the only sensible choice for a compiler to make would be NIL. >> >> Perhaps we should change the language to say this explicitly?? I am >> very confident it wouldn't undermine either any existing code or compiler, >> and might save some grief in the future. > ... > > The only problem with this proposal is that to me, as a human, > > VAR m : MUTEX := NIL; > > ... > > today means something different from > > VAR m : MUTEX; > > notwithstanding the fact that the compiler may implement them the same way. > >? ???Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 4 08:14:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 4 Feb 2013 07:14:56 +0000 Subject: [M3devel] Socket error hacks for Ultrix and OSF? Message-ID: We have: WITH errno = GetError() DO IF errno = EINVAL THEN (* hack to try to get real errno, hidden due to NBIO bug in connect *) RefetchError (t.fd); ELSIF errno = EBADF THEN (* we'll try the same for EBADF, which we've seen on Alpha *) RefetchError (t.fd); END; END; PROCEDURE RefetchError(fd: INTEGER) = (* Awful hack to retrieve a meaningful error from a TCP accept socket. Only works on Ultrix and OSF. Leaves result in GetError(). *) VAR optbuf: int := 0; optlen: socklen_t := BYTESIZE(optbuf); BEGIN IF SocketPosix_IsUltrixOrOSF.Value THEN EVAL getsockopt (fd, IPPROTO_TCP, TCP_NODELAY, ADR(optbuf), ADR(optlen)); END; END RefetchError; does anyone know or believe this is useful code? Does anyone object to removing it? I don't believe we'll ever run on Ultrix. OSF/Tru64 is of very marginal interest. Posix doesn't bless this code. It seems ok without this -- it is a subtle matter of precisely which error is raised. Portable code can't depend on the supposedly better Ultrix/OSF behavior, unless they are substandard and return EINVAL/EBADF when other systems return something more specific. If I could find this workaround in any half way recently maintained C or C++ (Perl? Python?) I'd feel a lot better. I guess I'll look. More generally I'd like to see the essentially 4 socket libraries we have (libm3/posix, libm3/win32, m3-comm/win32, m3-comm/posix) merged into one portable C file, and support IPv6... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Mon Feb 4 12:27:55 2013 From: wagner at elego.de (Olaf Wagner) Date: Mon, 4 Feb 2013 12:27:55 +0100 Subject: [M3devel] Compiler upgrade broken in Hudson CI Message-ID: <20130204122755.f9b56cdb.wagner@elego.de> I only just came around to have a look at the recent Hudson CI runs for the cm3 compiler build. It seems that the upgrade path implemented in scripts/upgrade.sh is broken now: http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console What has changed in the dependencies? How to fix upgrade.sh? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Feb 4 13:16:02 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2013 23:16:02 +1100 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <20130204122755.f9b56cdb.wagner@elego.de> References: <20130204122755.f9b56cdb.wagner@elego.de> Message-ID: <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> Jay? Sent from my iPad On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > I only just came around to have a look at the recent Hudson CI runs for > the cm3 compiler build. It seems that the upgrade path implemented in > scripts/upgrade.sh is broken now: > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > What has changed in the dependencies? > How to fix upgrade.sh? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 4 22:09:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 4 Feb 2013 21:09:57 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> References: <20130204122755.f9b56cdb.wagner@elego.de>, <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> Message-ID: I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 4 Feb 2013 23:16:02 +1100 > To: wagner at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > Jay? > > Sent from my iPad > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > I only just came around to have a look at the recent Hudson CI runs for > > the cm3 compiler build. It seems that the upgrade path implemented in > > scripts/upgrade.sh is broken now: > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > What has changed in the dependencies? > > How to fix upgrade.sh? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 4 22:46:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 4 Feb 2013 21:46:05 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, Message-ID: ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; wagner at elego.de Date: Mon, 4 Feb 2013 21:09:57 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 4 Feb 2013 23:16:02 +1100 > To: wagner at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > Jay? > > Sent from my iPad > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > I only just came around to have a look at the recent Hudson CI runs for > > the cm3 compiler build. It seems that the upgrade path implemented in > > scripts/upgrade.sh is broken now: > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > What has changed in the dependencies? > > How to fix upgrade.sh? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Feb 5 07:51:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 06:51:15 +0000 Subject: [M3devel] socket options? Message-ID: Realize that the socket API is almost identical on Win32 and Posix. And the Modula-3 libraries are therefore almost identical -- unfortunately duplicated.. SocketPosix.m3: PROCEDURE InitStream (fd: CARDINAL) RAISES {OSError.E} = (* We assume that the runtime ignores SIGPIPE signals *) VAR one : int := 1; linger := struct_linger{1, 1}; BEGIN EVAL setsockopt(fd, SOL_SOCKET, SO_LINGER, ADR(linger), BYTESIZE(linger)); EVAL setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, ADR(one), BYTESIZE(one)); MakeNonBlocking (fd); END InitStream; PROCEDURE MakeNonBlocking (fd: INTEGER) RAISES {OSError.E} = VAR old_mode := fcntl (fd, F_GETFL, 0); new_mode := Word.Or (old_mode, M3_NONBLOCK); BEGIN IF fcntl (fd, F_SETFL, new_mode) = -1 THEN IOError (Unexpected); END; END MakeNonBlocking; SocketWin32.m3 PROCEDURE InitSock (sock: SOCKET) = (* We assume that the runtime ignores SIGPIPE signals *) VAR one: int := 1; linger := struct_linger{0, 0}; BEGIN EVAL setsockopt (sock, SOL_SOCKET, SO_LINGER, ADR(linger), BYTESIZE(linger)); (**** WinSock documentation warns that this may cause problems ****) EVAL setsockopt (sock, IPPROTO_TCP, TCP_NODELAY, ADR(one), BYTESIZE(one)); END InitSock; The meaning of struct_linger is the SAME on Posix and Win32. The fact that Modula-3 passes "opposite" parameters is clearly broken. so, obvious questions: Do we need either setsockopt? Clearly if we use SO_LINGER, we should use the same parameters. TCP_NODELAY seems to be generally discouraged. But it seems to usually have a real meaning, and removing it here would break things? In particular, it, like, turns off buffering. It means if you do write with just one byte, it will be sent immediately. If that is the "last" byte for a "while", ok. If you are making a series of small writes, it pays very much to coalesce them into fewer larger writes, at the cost of delaying the earlier writes. Here is an example of implicity discouraging it: http://smalltalk.gnu.org/project/issue/119 "The tcp delay, aka. nagles algorithm has it's applications and disabling it should be done only in special applications (eg. where low-latency for is required) IMO. " Doing this unconditionally for all sockets seems wrong. On the other hand: http://en.wikipedia.org/wiki/Nagle%27s_algorithm paraphrasing part of it: As long as the application does not issue small writes, it is ok. At least this part we do the same for Posix and Win32. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Tue Feb 5 09:11:40 2013 From: wagner at elego.de (Olaf Wagner) Date: Tue, 5 Feb 2013 09:11:40 +0100 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de> <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu> Message-ID: <20130205091140.ff4fd78c.wagner@elego.de> On Mon, 4 Feb 2013 21:46:05 +0000 Jay K wrote: > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay Yes, please fix it. I'd like to keep up at least two platforms with the old backend. Olaf > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; wagner at elego.de > Date: Mon, 4 Feb 2013 21:09:57 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > To: wagner at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > Jay? > > > > Sent from my iPad > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > scripts/upgrade.sh is broken now: > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > What has changed in the dependencies? > > > How to fix upgrade.sh? > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -- 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 Tue Feb 5 09:28:00 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <20130205091140.ff4fd78c.wagner@elego.de> References: <20130204122755.f9b56cdb.wagner@elego.de>, <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , <20130205091140.ff4fd78c.wagner@elego.de> Message-ID: I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 10:49:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , , , , <20130205091140.ff4fd78c.wagner@elego.de>, Message-ID: Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 11:02:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 10:02:26 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, ,,<79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, ,,, ,,, , , <20130205091140.ff4fd78c.wagner@elego.de>, , , Message-ID: The errors also predate the C mode, slightly. I've seen this, like when the target is wrong, or maybe when there is a change in the cm3cg format. I don't remember if the upgrade process is automated enough for that, cm3cg format changes. There hadn't been an attempted build in months for some reason, since August. I'm also curious to trigger Solaris/opencsw builds. I don't remember my Hudson password. Olaf, can you reset it and send it to me privately, please? Thank you. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 11:11:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 10:11:02 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , , , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , , , , , , , , , , <20130205091140.ff4fd78c.wagner@elego.de>, , , , Message-ID: Here, back in October I changed the m3cg format slightly: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/M3CG_Binary.i3.diff?r1=1.6;r2=1.7;f=u Upgrade should always incrementally build cm3cg. It is developers' responsibility to mistrust the incrementality slightly and edit m3-sys/m3cc/src/clean_marker.txt to trigger a clean build if needed..though the incrementality is all very good in my experience. But wait, maybe I messed up. Hm... Easily fixed though. Let me dig more..maybe not tonight.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Subject: RE: [M3devel] Compiler upgrade broken in Hudson CI Date: Tue, 5 Feb 2013 10:02:26 +0000 The errors also predate the C mode, slightly. I've seen this, like when the target is wrong, or maybe when there is a change in the cm3cg format. I don't remember if the upgrade process is automated enough for that, cm3cg format changes. There hadn't been an attempted build in months for some reason, since August. I'm also curious to trigger Solaris/opencsw builds. I don't remember my Hudson password. Olaf, can you reset it and send it to me privately, please? Thank you. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 11:15:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 10:15:12 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, , , , <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , , , , , , , , , , <20130205091140.ff4fd78c.wagner@elego.de>, , , , , Message-ID: err..maybe that was only comments... From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Subject: RE: [M3devel] Compiler upgrade broken in Hudson CI Date: Tue, 5 Feb 2013 10:11:02 +0000 Here, back in October I changed the m3cg format slightly: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/M3CG_Binary.i3.diff?r1=1.6;r2=1.7;f=u Upgrade should always incrementally build cm3cg. It is developers' responsibility to mistrust the incrementality slightly and edit m3-sys/m3cc/src/clean_marker.txt to trigger a clean build if needed..though the incrementality is all very good in my experience. But wait, maybe I messed up. Hm... Easily fixed though. Let me dig more..maybe not tonight.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Subject: RE: [M3devel] Compiler upgrade broken in Hudson CI Date: Tue, 5 Feb 2013 10:02:26 +0000 The errors also predate the C mode, slightly. I've seen this, like when the target is wrong, or maybe when there is a change in the cm3cg format. I don't remember if the upgrade process is automated enough for that, cm3cg format changes. There hadn't been an attempted build in months for some reason, since August. I'm also curious to trigger Solaris/opencsw builds. I don't remember my Hudson password. Olaf, can you reset it and send it to me privately, please? Thank you. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 09:49:38 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI Hm, it isn't so obvious: - the code looks right - I set AMD64_DARWIN back to use cm3cg and it worked I'll try AMD64_LINUX on modula3.elegosoft.com I guess, though the code is all so target-independent... and upgrade.sh instead of upgrade.py.. - Jay From: jay.krell at cornell.edu To: wagner at elego.de; m3devel at elegosoft.com Date: Tue, 5 Feb 2013 08:28:00 +0000 Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI I will fix it, but I do desire to drop the old backend entirely. What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. - Jay > Date: Tue, 5 Feb 2013 09:11:40 +0100 > From: wagner at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > On Mon, 4 Feb 2013 21:46:05 +0000 > Jay K wrote: > > > ok, sorry, I know roughly the problem.Adding the C mode to builder I was a bit aggressive in cleaning it up, and didn't test the cm3cg path.I can either fix that, or be more conservative and mostly restore the old code. Probably fix it -- the code was kind of weird and repetitive...though the "rewrite" still kind of is too. There is a small combinatorial explosion of cases there -- 8 -- and I tried to make more algorithmic and based on each factor, and not just handle each case differently. - Jay > > Yes, please fix it. I'd like to keep up at least two platforms with the old backend. > > Olaf > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu; wagner at elego.de > > Date: Mon, 4 Feb 2013 21:09:57 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > > > I think the change I made yesterday for sockets was wrong. That's not likely a problem we'd catch in Hudson. I'll look later. > > > > - Jay > > > > > From: hosking at cs.purdue.edu > > > Date: Mon, 4 Feb 2013 23:16:02 +1100 > > > To: wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > Jay? > > > > > > Sent from my iPad > > > > > > On Feb 4, 2013, at 10:27 PM, Olaf Wagner wrote: > > > > > > > I only just came around to have a look at the recent Hudson CI runs for > > > > the cm3 compiler build. It seems that the upgrade path implemented in > > > > scripts/upgrade.sh is broken now: > > > > > > > > http://hudson.modula3.com:8080/view/AMD64_LINUX/job/cm3-current-build-AMD64_LINUX/243/console > > > > > > > > What has changed in the dependencies? > > > > How to fix upgrade.sh? > > > > > > > > Olaf > > > > -- > > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > 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 Tue Feb 5 20:05:25 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 5 Feb 2013 19:05:25 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: <20130205190330.AC4175DEB20@birch.elegosoft.com> References: <20130205190330.AC4175DEB20@birch.elegosoft.com> Message-ID: Quake's "fs_rmrec" doesn't work where exec("rm -rf") does. Maybe a matter of deleting links instead of their target? Maybe I fixed it a long time ago? - Jay > Date: Tue, 5 Feb 2013 20:03:30 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/02/05 20:03:30 > > Modified files: > cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile > > Log message: > http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/94/consoleFull > rm -rf ../AMD64_LINUX/gmp > "/usr/local/hudson/workspace/cm3-m3cc-AMD64_LINUX/cm3/m3-sys/m3cc/src/m3makefile", line 414: quake runtime error: cannot remove recursively ../AMD64_LINUX/gmp: error traversing directory ../AMD64_LINUX/gmp/mpn > > so try this.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Feb 5 20:46:35 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 5 Feb 2013 19:46:35 +0000 Subject: [M3devel] new release Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> I am in process of getting a new computer to replace my old office computer. I've installed the new Visual Studio 2012 Express and want to rebuild my CM3 source tree. It's been a long time since a new CM3 release was made. I note that Jay has done a lot of work and I'm not sure exactly what is the state of the main branch in the CM3 repository. Would folks advise I stick with the last official release, or update to the current main branch before rebuilding everything? The target machine is running Windows 7 Enterprise edition. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 5 22:13:58 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Feb 2013 08:13:58 +1100 Subject: [M3devel] new release In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> The last official release contains known bugs. Best I think to go with the head of the repository. Sent from my iPhone On 06/02/2013, at 6:46 AM, "Coleburn, Randy" wrote: > I am in process of getting a new computer to replace my old office computer. > I?ve installed the new Visual Studio 2012 Express and want to rebuild my CM3 source tree. > It?s been a long time since a new CM3 release was made. > I note that Jay has done a lot of work and I?m not sure exactly what is the state of the main branch in the CM3 repository. > Would folks advise I stick with the last official release, or update to the current main branch before rebuilding everything? > The target machine is running Windows 7 Enterprise edition. > Thanks, > Randy Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Feb 6 03:14:08 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 6 Feb 2013 02:14:08 +0000 (GMT) Subject: [M3devel] Socket error hacks for Ultrix and OSF? Message-ID: <1360116848.82928.YahooMailClassic@web133102.mail.ir2.yahoo.com> Hi all: Jay I deliberately want to quote you this text for your better understanding [1] (I hope it to be so): "... Software Security Explained The concepts behind secure software are often simple but rarely considered by most programmers in the design and implementation of their programs. The following are prime tenets in writing secure software: Give your software the least privileges it needs. Check all return codes religiously. ..." http://books.google.com.co/books?id=uGiOR1mrxggC&dq=inauthor%3A%22Jeff+Schmidt%22&q=%22software+security%22#search_anchor And specifically for ther matter of "assumptions" and pointer initialization: http://www.drdobbs.com/security/safe-programming-with-modula-3/184408858 note that if you guarantee "assumptions" or " absence of unchecked run-time errors" you can argue that still you export the interface as safe. in SPwM3 [2] p.45 "... 2.5.7 Safety ... An interface is 'intrinsically safe' if there is no way to produce an unchecked runtime error by using the interface in a safe module. ..." Now if you say, the VAX9000 or Alpha had probably errors more than any other computer in the era, it could mean that the VAX9000 or Alpha had runtime unchecked errors (probably by that much as any other but let's read this $1.4.5 Safety paragraph) : SPwM3 p. 7 "... ?1.4.5 Safety ?... Unfortunately, it is generally impossible to program the lowest levels of a system with complete safety. Neither the compiler nor the runtime system can check the validity of a bus address for an I/O controller, nor can they limit the ensuing havoc if it is invalid. This presents the language designer with a dilemma. Of he holds out for safety, then low level code will have to be programmed in another language. But if he adopts unsafe features his safety guarantee becomes void everywhere ..." Now, in every definition of safety of a language there must be the unchecked runtime errors (errors than can occur without isolation guarantee), you must define them explicitly as a subset of all untrapped errors. I think one of them is the mentioned above, if we could agree on this errors by platform we can say our language implementation is safe in this proportions due machine restrictions. In case of VAX9000 architecture segments were defined for separated testing of multichip Modules, you could argue you can still work in a isolated machine and guarantee each piece of Hardware satisfies certain properties, so you could think in a top-down fashion how would you build and test your machine for errors that are HW failures and in some cases avoid running the program in those conditions by using fault tolerance. There was a VAXft9000 and Alpha's versions of itself, of course this costs lot more to work in that way, so in general you can't do that as SPwM3 says, but if you want we can do it. Thanks in advance [1] J. Schmidt, Microsoft Windows 2000 security handbook. Que, 2000. [2] C. G. Nelson, Systems programming with Modula-3. Prentice Hall, 1991. --- El lun, 4/2/13, Jay K escribi?: De: Jay K Asunto: [M3devel] Socket error hacks for Ultrix and OSF? Para: "m3devel" Fecha: lunes, 4 de febrero, 2013 02:14 We have: ????? WITH errno = GetError() DO ??????? IF errno = EINVAL THEN ????????? (* hack to try to get real errno, hidden due to NBIO bug in connect *) ????????? RefetchError (t.fd); ??????? ELSIF errno = EBADF THEN ????????? (* we'll try the same for EBADF, which we've seen on Alpha *) ????????? RefetchError (t.fd); ??????? END; ????? END; PROCEDURE RefetchError(fd: INTEGER) = (* Awful hack to retrieve a meaningful error from a TCP accept ?? socket.? Only works on Ultrix and OSF.? Leaves result ?? in GetError().? *) ? VAR optbuf: int := 0;?? optlen: socklen_t := BYTESIZE(optbuf); ? BEGIN ??? IF SocketPosix_IsUltrixOrOSF.Value THEN ????? EVAL getsockopt (fd, IPPROTO_TCP, TCP_NODELAY, ?????????????????????? ADR(optbuf), ADR(optlen)); ??? END; ? END RefetchError; does anyone know or believe this is useful code? Does anyone object to removing it? I don't believe we'll ever run on Ultrix. OSF/Tru64 is of very marginal interest. Posix doesn't bless this code. It seems ok without this -- it is a subtle matter of precisely which error is raised. Portable code can't depend on the supposedly better Ultrix/OSF behavior, unless they are substandard and return EINVAL/EBADF when other systems return something more specific. If I could find this workaround in any half way recently maintained C or C++ (Perl? Python?) I'd feel a lot better. I guess I'll look. More generally I'd like to see the essentially 4 socket libraries we have (libm3/posix, libm3/win32, m3-comm/win32, m3-comm/posix) merged into one portable C file, and support IPv6... ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 07:44:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 06:44:26 +0000 Subject: [M3devel] LONGINT to INTEGER conversion with last release Message-ID: http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/257/console "../src/M3C.m3", line 275: VAL: first argument must be an INTEGER This error dates to the previous release.The current tree lets the first parameter be a LONGINT.You can doVAL(1L, INTEGER) to convert, I think with range check, a LONGINT to an INTEGER. How do I do that with the last release though? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 08:26:04 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:26:04 +0000 Subject: [M3devel] LONGINT to INTEGER conversion with last release In-Reply-To: References: Message-ID: nevermind, I rewrote the code in C. From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 6 Feb 2013 06:44:26 +0000 Subject: [M3devel] LONGINT to INTEGER conversion with last release http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/257/console "../src/M3C.m3", line 275: VAL: first argument must be an INTEGER This error dates to the previous release.The current tree lets the first parameter be a LONGINT.You can doVAL(1L, INTEGER) to convert, I think with range check, a LONGINT to an INTEGER. How do I do that with the last release though? Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 08:30:17 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:30:17 +0000 Subject: [M3devel] hudson_build_system.sh In-Reply-To: <20130206071829.1256B5DEB30@birch.elegosoft.com> References: <20130206071829.1256B5DEB30@birch.elegosoft.com> Message-ID: Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. It looks like the current quake/config only does that for cross builds. It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. - Jay > Date: Wed, 6 Feb 2013 08:18:28 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 13/02/06 08:18:28 > > Modified files: > cm3/scripts/regression/: hudson_build_system.sh > > Log message: > that was not what this script is supposed to do... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 08:45:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:45:56 +0000 Subject: [M3devel] dependencies on recent releases Message-ID: m3back uses LONGINT -- carefully though, it should work with 5.8.6 and not require changes since then (it didn't at first, til today) C code in m3back uses m3core.hC code in m3middle uses m3core.hThe C code in m3back can be removed when we update further, to a frontend that has slightly better support for LONGINT (a change that Tony commited long ago) So you need a "recent" release now to build the system.Recent is over 2 years ago though I believe. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 6 08:48:19 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 08:48:19 +0100 Subject: [M3devel] hudson_build_system.sh In-Reply-To: References: <20130206071829.1256B5DEB30@birch.elegosoft.com> Message-ID: <20130206084819.2c807588060601a69c2de841@elegosoft.com> On Wed, 6 Feb 2013 07:30:17 +0000 Jay K wrote: > Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. The old compiler release wasn't able to build the new sources; and in defs.sh, there are other functions for building from the old release. > The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. I don't think it was necessary here. They simply don't get used. > It looks like the current quake/config only does that for cross builds. > > It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. I'll see if I find time to do some more refactoring, but changing the regression setup is sometimes very subtle and likely to introduce errors. We'd need so many updates -- new VC, Hudson --> Jenkins, WWW, ... Right now I'd just like to get the wheels going again. Olaf > - Jay > > > > Date: Wed, 6 Feb 2013 08:18:28 +0000 > > To: m3commit at elegosoft.com > > From: wagner at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: wagner at birch. 13/02/06 08:18:28 > > > > Modified files: > > cm3/scripts/regression/: hudson_build_system.sh > > > > Log message: > > that was not what this script is supposed to do... > > > -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Feb 6 08:50:00 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 08:50:00 +0100 Subject: [M3devel] Now Hudson fails on AMD64_FREEBSD Message-ID: <20130206085000.f64dc4c94ab8e18a745b6c02@elegosoft.com> http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_FREEBSD/662/console === package m3-sys/m3back === +++ cm3 -build -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' +++ ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' ../src/M3CC.c: In function 'M3CC__UInt64ToText': ../src/M3CC.c:14: warning: return makes pointer from integer without a cast ../src/M3CC.c: At top level: ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input compile_c => 1 C compiler failed compiling: ../src/M3CC.c ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' ../src/M3CC.c: In function 'M3CC__UInt64ToText': ../src/M3CC.c:14: warning: return makes pointer from integer without a cast ../src/M3CC.c: At top level: ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input compile_c => 1 C compiler failed compiling: ../src/M3CC.c This seems to be the new C backend producing wrong assembler code. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 6 08:52:13 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:52:13 +0000 Subject: [M3devel] hudson_build_system.sh In-Reply-To: <20130206084819.2c807588060601a69c2de841@elegosoft.com> References: <20130206071829.1256B5DEB30@birch.elegosoft.com>, , <20130206084819.2c807588060601a69c2de841@elegosoft.com> Message-ID: > The old compiler release wasn't able to build the new sources I think I fixed that. I reduced my use of LONGINT by passing it off to C.There was a later change Tony made, after the initial LONGINT support, that let you use VAL to convert between more types. I was depending on that. I think I am no longer. > hudson jobs for m3cc -- just merge the jobs and use the incrementality and > the clean_marker.txt feature I put I understand, but I think this might be pretty easy.It might already be done..I'll poke around and try to do it fairly soon.We just have to make sure the CVS polling for "the one" task includes everything, doesn't exclude m3cc.The m3cc tasks aren't needed -- but can just be left disabled. The "later" tasks, pkg build, test, those can still be separate..until/unless I understand them.. :) - Jay > Date: Wed, 6 Feb 2013 08:48:19 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: hudson_build_system.sh > > On Wed, 6 Feb 2013 07:30:17 +0000 > Jay K wrote: > > > Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. > > The old compiler release wasn't able to build the new sources; and in defs.sh, there are other functions for building from the old release. > > > The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. > > I don't think it was necessary here. They simply don't get used. > > > It looks like the current quake/config only does that for cross builds. > > > > It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. > > I'll see if I find time to do some more refactoring, but changing the regression setup is sometimes very subtle and likely to introduce errors. > > We'd need so many updates -- new VC, Hudson --> Jenkins, WWW, ... > > Right now I'd just like to get the wheels going again. > > Olaf > > > - Jay > > > > > > > Date: Wed, 6 Feb 2013 08:18:28 +0000 > > > To: m3commit at elegosoft.com > > > From: wagner at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: wagner at birch. 13/02/06 08:18:28 > > > > > > Modified files: > > > cm3/scripts/regression/: hudson_build_system.sh > > > > > > Log message: > > > that was not what this script is supposed to do... > > > > > > > -- > 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 Wed Feb 6 08:53:32 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 07:53:32 +0000 Subject: [M3devel] Now Hudson fails on AMD64_FREEBSD In-Reply-To: <20130206085000.f64dc4c94ab8e18a745b6c02@elegosoft.com> References: <20130206085000.f64dc4c94ab8e18a745b6c02@elegosoft.com> Message-ID: > This seems to be the new C backend Yes. > producing wrong assembler code. No. It is only being used on Darwin for now. I think that'll need to remain so limited, until I declare structs better, so that debugging doesn't degrade, on systems that support m3gdb. Please stand by..but don't hold breath. - Jay > Date: Wed, 6 Feb 2013 08:50:00 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Now Hudson fails on AMD64_FREEBSD > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_FREEBSD/662/console > > === package m3-sys/m3back === > +++ cm3 -build -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/ad0e/home/hudson/workspace/cm3-current-build-AMD64_FREEBSD/cm3' +++ > ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' > ../src/M3CC.c: In function 'M3CC__UInt64ToText': > ../src/M3CC.c:14: warning: return makes pointer from integer without a cast > ../src/M3CC.c: At top level: > ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input > compile_c => 1 > C compiler failed compiling: ../src/M3CC.c > ../src/M3CC.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TEXT' > ../src/M3CC.c: In function 'M3CC__UInt64ToText': > ../src/M3CC.c:14: warning: return makes pointer from integer without a cast > ../src/M3CC.c: At top level: > ../src/M3CC.c:30: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input > compile_c => 1 > C compiler failed compiling: ../src/M3CC.c > > This seems to be the new C backend producing wrong assembler code. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 09:29:03 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 08:29:03 +0000 Subject: [M3devel] and move to gcc 4.7? Message-ID: Olaf, things working satisfactorily for you in Hudson now for AMD64_LINUX and AMD64_FREEBSD?I'd like to bump m3cc/src/m3makefile up to 4.7 for AMD64_LINUX, FREEBSD. Or anything we have going decently in Hudson.Even though, granted, I'd like to remove that backend sooner rather than later anyway..AMD64_LINUX was at 4.7 but I backed it down to 4.5 today out of paranoia. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 6 09:30:28 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 09:30:28 +0100 Subject: [M3devel] hudson_build_system.sh In-Reply-To: References: <20130206071829.1256B5DEB30@birch.elegosoft.com> <20130206084819.2c807588060601a69c2de841@elegosoft.com> Message-ID: <20130206093028.0526f9c67e42c411f3bfbe14@elegosoft.com> On Wed, 6 Feb 2013 07:52:13 +0000 Jay K wrote: > > The old compiler release wasn't able to build the new sources > I think I fixed that. I reduced my use of LONGINT by passing it off to C.There was a later change Tony made, after the initial LONGINT support, that let you use VAL to convert between more types. I was depending on that. I think I am no longer. OK > > hudson jobs for m3cc -- just merge the jobs and use the incrementality and > the clean_marker.txt feature I put > > I understand, but I think this might be pretty easy.It might already be done..I'll poke around and try to do it fairly soon.We just have to make sure the CVS polling for "the one" task includes everything, doesn't exclude m3cc.The m3cc tasks aren't needed -- but can just be left disabled. > > The "later" tasks, pkg build, test, those can still be separate..until/unless I understand them.. :) Great. I'd just prefer doing such work in separate jobs/scripts; i.e. create a new Hudson job for it which executes a new build script. And keeping the general installation layout of current/last-ok/prev-ok might also help. Olaf > - Jay > > > > Date: Wed, 6 Feb 2013 08:48:19 +0100 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: hudson_build_system.sh > > > > On Wed, 6 Feb 2013 07:30:17 +0000 > > Jay K wrote: > > > > > Olaf, between lastok and lastrel, I realize either can be correct.lastrel, for some definition of it, people do like to use to build the current system.There are arguments either way. > > > > The old compiler release wasn't able to build the new sources; and in defs.sh, there are other functions for building from the old release. > > > > > The deletion of cm3cg is deliberate, because I'm afraid some releases' quake/config might reachin and use it. In fact that's what I think was going wrong.I know for some time I thought that was a good idea.Since "shipping"/copying files is wasteful. > > > > I don't think it was necessary here. They simply don't get used. > > > > > It looks like the current quake/config only does that for cross builds. > > > > > > It doesn't delete "everything", just the executable. They can reasonably quickly be recreated.They should not be used here, except as built part way through this stuff.I don't believe there should be separate hudson jobs for m3cc -- just merge the jobs and use the incrementality and the clean_marker.txt feature I put in. > > > > I'll see if I find time to do some more refactoring, but changing the regression setup is sometimes very subtle and likely to introduce errors. > > > > We'd need so many updates -- new VC, Hudson --> Jenkins, WWW, ... > > > > Right now I'd just like to get the wheels going again. > > > > Olaf > > > > > - Jay > > > > > > > > > > Date: Wed, 6 Feb 2013 08:18:28 +0000 > > > > To: m3commit at elegosoft.com > > > > From: wagner at elego.de > > > > Subject: [M3commit] CVS Update: cm3 > > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: wagner at birch. 13/02/06 08:18:28 > > > > > > > > Modified files: > > > > cm3/scripts/regression/: hudson_build_system.sh > > > > > > > > Log message: > > > > that was not what this script is supposed to do... > > > > > > > > > > > -- > > 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 wagner at elegosoft.com Wed Feb 6 09:34:09 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 09:34:09 +0100 Subject: [M3devel] and move to gcc 4.7? In-Reply-To: References: Message-ID: <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> On Wed, 6 Feb 2013 08:29:03 +0000 Jay K wrote: > Olaf, things working satisfactorily for you in Hudson now for AMD64_LINUX and AMD64_FREEBSD? Recent builds seem to have succeeded. > I'd like to bump m3cc/src/m3makefile up to 4.7 for AMD64_LINUX, FREEBSD. Or anything we have going decently in Hudson.Even though, granted, I'd like to remove that backend sooner rather than later anyway..AMD64_LINUX was at 4.7 but I backed it down to 4.5 today out of paranoia. Just try it. Before we remove the old backend, I'd like to have some validation of the quality and performance of the new one though, just to avoid regression. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 6 09:46:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 08:46:15 +0000 Subject: [M3devel] and move to gcc 4.7? In-Reply-To: <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> References: , <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> Message-ID: > quality and performance of the new one though, just to avoid regression. Well..the main "quality" is portability.Much is being potentially sacrificed for it. There are potential other improvements, but also potential regressions. Optimization might be better, i.e. by not using gcc, or worse, i.e. by going via C. Compiler performance is likely worse, due to the extra text production and parsing.It seems ok to me. I've been using a while. But not great. Skipping the .mc/m3cg file production helped a lot. Debugging will be better on Darwin and NT -- where currently we have no type info, I hope to add significant typing. "Ease of distribution" will take a step forward, but it isn't yet where I want it to be.You know, you just want tar xf; configure; make; make install. No need for cross builds or "unusual" prerequesites, "just" a C compiler and Bourne shell and make. Portability will increase.Maintainability will increase.We will no longer have a motivation for "chasing" newer gcc. (nor patches e.g. for OpenBSD)We will "automatically" port to "every" target. This is an exaggeration, but not by a lot.The "porting" will work will decrease. Porting work will further decrease when we have cooperative suspend. - Jay > Date: Wed, 6 Feb 2013 09:34:09 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] and move to gcc 4.7? > > On Wed, 6 Feb 2013 08:29:03 +0000 > Jay K wrote: > > > Olaf, things working satisfactorily for you in Hudson now for AMD64_LINUX and AMD64_FREEBSD? > Recent builds seem to have succeeded. > > > I'd like to bump m3cc/src/m3makefile up to 4.7 for AMD64_LINUX, FREEBSD. Or anything we have going decently in Hudson.Even though, granted, I'd like to remove that backend sooner rather than later anyway..AMD64_LINUX was at 4.7 but I backed it down to 4.5 today out of paranoia. > > Just try it. > > Before we remove the old backend, I'd like to have some validation of the > quality and performance of the new one though, just to avoid regression. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 10:00:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 09:00:33 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs Message-ID: Olaf, Dagobert, Dagobert: We haven't tried to run anything in a while. 1) SOLsun is failing to login: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs is that right? Olaf:2) Can we get SPARC64_SOLARIS and AMD64_SOLARIS?They can work on the existing machines.Maybe I need to provide an initial bootstrap or setup?Maybe I did long ago?Maybe poke in ~jkrell?Maybe just start with the existing sparc32 and x86? They should cross ok, if CM3_TARGET is set explicitly to override the default target=host. Olaf:3) I'd like to see SOLsun switched to be called SPARC32_SOLARIS."It should just work." The support has been in for a long time. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 6 10:28:14 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Feb 2013 09:28:14 +0000 Subject: [M3devel] updating exception handling implementation and backend interface?? Message-ID: The jmpbuf/alloca fix? For reference, here is most of the undo:http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/Marker.m3.diff?r1=1.9;r2=1.10;f=uor http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/Marker.m3.diff?r1=1.9;r2=1.10 I had generated code like: old:char buf[sizeof(jmpbuf)]; // frontend knows sizeof(jmpbuf) -- the portability problem to be solved TRY => setjmp(buf); new:jmpbuf* buf;extern const size_t Csetjmp__Jumpbuf_size/* = sizeof(jmp_buf)*/; *)TRY => buf = m3_alloca(sizeof(Csetjmp__Jumpbuf_size)); setjmp(buf);=> alloca for every TRY, even if TRY in a loop, not good Understanding that is a further de-optimization, how about I just do:jmpbuf* buf;TRY => buf = buf ? buf : alloca(sizeof(jmpbuf)); setjmp(buf); ? It seems easy enough? furthermore, let's think ahead to the C and maybe C++ backends? The portable slightly optimizing C backend will go back to jmpbuf, no alloca.The optimizing C++ backend will try to use native C++ exception handling.And/or the optimizing C-for-NT backend will use __try/__except/__finally. Should I start/end "buf" with some distinguished name?So some backends will remove it, in favor of whatever they do better?Should "m3_alloca" be named something more specific like "m3_alloca_for_try"?Again, so it is easier to backends to recognize and remove?i.e. one of the first optimizations the C backend should make isto #include and change these to jmpbuf. Should we invent a higher level interface?Should we do "both", make low level and high level calls to the backend?It will chose to ignore one set?But the low level calls need to be altered at least a little bit.Like the locals and the calls will have a flag or a boolean indicatingthey are "exception handling related"? Am I making sense? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Wed Feb 6 10:40:31 2013 From: wagner at elego.de (Olaf Wagner) Date: Wed, 6 Feb 2013 10:40:31 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: Message-ID: <20130206104031.c16645c8.wagner@elego.de> On Wed, 6 Feb 2013 09:00:33 +0000 Jay K wrote: > Olaf, Dagobert, > > Dagobert: We haven't tried to run anything in a while. > > 1) SOLsun is failing to login: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > is that right? The problem on that build farm always was the missing direct CVS access. There used to be that proxy server; I don't know if it's still up. > Olaf:2) Can we get SPARC64_SOLARIS and AMD64_SOLARIS?They can work on the existing machines.Maybe I need to provide an initial bootstrap or setup?Maybe I did long ago?Maybe poke in ~jkrell?Maybe just start with the existing sparc32 and x86? They should cross ok, if CM3_TARGET is set explicitly to override the default target=host. I'm not sure if there are any bootstrap packages for 64 bit; maybe you need to do the initial bootstrap manually. An initial environment needs to be setup for Hudson, see http://hudson.modula3.com:8080/view/zzz/job/boot-template/ for example. > Olaf:3) I'd like to see SOLsun switched to be called SPARC32_SOLARIS."It should just work." The support has been in for a long time. OK. If you're expecting me to do something specific, please say so explicitly; I'm still very much involved in other customer projects. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elego.de Wed Feb 6 12:15:35 2013 From: wagner at elego.de (Olaf Wagner) Date: Wed, 6 Feb 2013 12:15:35 +0100 Subject: [M3devel] and move to gcc 4.7? In-Reply-To: References: <20130206093409.2a253eaa1af4ed16709e3904@elegosoft.com> Message-ID: <20130206121535.f55292b8.wagner@elego.de> On Wed, 6 Feb 2013 08:46:15 +0000 Jay K wrote: > > quality and performance of the new one though, just to avoid regression. > > Well..the main "quality" is portability.Much is being potentially sacrificed for it. > > There are potential other improvements, but also potential regressions. > > Optimization might be better, i.e. by not using gcc, or worse, i.e. by going via C. > > Compiler performance is likely worse, due to the extra text production and parsing.It seems ok to me. I've been using a while. But not great. Skipping the .mc/m3cg file production helped a lot. > > Debugging will be better on Darwin and NT -- where currently we have no type info, I hope to add significant typing. > > "Ease of distribution" will take a step forward, but it isn't yet where I want it to be.You know, you just want tar xf; configure; make; make install. No need for cross builds or "unusual" prerequesites, "just" a C compiler and Bourne shell and make. > > Portability will increase.Maintainability will increase.We will no longer have a motivation for "chasing" newer gcc. (nor patches e.g. for OpenBSD)We will "automatically" port to "every" target. This is an exaggeration, but not by a lot.The "porting" will work will decrease. Porting work will further decrease when we have cooperative suspend. Yes, I understand and appreciate all those. I was just thinking of something more pragmatical. Let's start with m3tests: Recent runs show a regression from 19 to 49 errors on AMD64_LINUX: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-AMD64_LINUX/ The same for FreeBSD 8: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-AMD64_FREEBSD/ Can you explain (and fix) those? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From cornstalk at columbus.rr.com Wed Feb 6 15:38:56 2013 From: cornstalk at columbus.rr.com (Mark Morss) Date: Wed, 06 Feb 2013 09:38:56 -0500 Subject: [M3devel] new release In-Reply-To: <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> Message-ID: <51126B00.7010301@columbus.rr.com> On 02/05/2013 04:13 PM, Tony Hosking wrote: > The last official release contains known bugs. Best I think to go with > the head of the repository. > > Sent from my iPhone > > On 06/02/2013, at 6:46 AM, "Coleburn, Randy" > wrote: > >> I am in process of getting a new computer to replace my old office >> computer. >> >> I?ve installed the new Visual Studio 2012 Express and want to rebuild >> my CM3 source tree. >> >> It?s been a long time since a new CM3 release was made. >> >> I note that Jay has done a lot of work and I?m not sure exactly what >> is the state of the main branch in the CM3 repository. >> >> Would folks advise I stick with the last official release, or update >> to the current main branch before rebuilding everything? >> >> The target machine is running Windows 7 Enterprise edition. >> >> Thanks, >> >> Randy Coleburn >> Well, that's a little bit disturbing. Would it be much trouble for someone to gin up a new release with the latest corrections in it? Not everyone wants to fool around with CVS. Best to all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 6 16:38:22 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 6 Feb 2013 16:38:22 +0100 Subject: [M3devel] new release In-Reply-To: <51126B00.7010301@columbus.rr.com> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> <51126B00.7010301@columbus.rr.com> Message-ID: <20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com> On Wed, 06 Feb 2013 09:38:56 -0500 Mark Morss wrote: > On 02/05/2013 04:13 PM, Tony Hosking wrote: > > The last official release contains known bugs. Best I think to go with > > the head of the repository. > > > > Sent from my iPhone > > > > On 06/02/2013, at 6:46 AM, "Coleburn, Randy" > > wrote: > > > >> I am in process of getting a new computer to replace my old office > >> computer. > >> > >> I?ve installed the new Visual Studio 2012 Express and want to rebuild > >> my CM3 source tree. > >> > >> It?s been a long time since a new CM3 release was made. > >> > >> I note that Jay has done a lot of work and I?m not sure exactly what > >> is the state of the main branch in the CM3 repository. > >> > >> Would folks advise I stick with the last official release, or update > >> to the current main branch before rebuilding everything? > >> > >> The target machine is running Windows 7 Enterprise edition. > >> > >> Thanks, > >> > >> Randy Coleburn > >> > Well, that's a little bit disturbing. Would it be much trouble for > someone to gin up a new release with the latest corrections in it? Not > everyone wants to fool around with CVS. Well, I think we will do a new release as soon as the C backend has settled. But you can always get current snapshots of the system from the Hudson builds, at least for Linux and FreeBSD, see http://www.opencm3.net/snaps/snapshot-index.html Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Wed Feb 6 18:24:30 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 06 Feb 2013 11:24:30 -0600 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <20130204122755.f9b56cdb.wagner@elego.de>, <79F7B53E-041A-453C-9B28-3E6F91A0CEEE@cs.purdue.edu>, , , <20130205091140.ff4fd78c.wagner@elego.de> Message-ID: <511291CE.9090100@lcwb.coop> On 02/05/2013 02:28 AM, Jay K wrote: > I will fix it, but I do desire to drop the old backend entirely. > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. And I use m3gdb all the time in my own work. Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > - Jay > From rcolebur at SCIRES.COM Thu Feb 7 00:13:37 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 6 Feb 2013 23:13:37 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! --Randy Coleburn -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Wednesday, February 06, 2013 12:25 PM To: m3devel at elegosoft.com Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI On 02/05/2013 02:28 AM, Jay K wrote: > I will fix it, but I do desire to drop the old backend entirely. > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. And I use m3gdb all the time in my own work. Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > - Jay > From dabenavidesd at yahoo.es Thu Feb 7 05:56:26 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 7 Feb 2013 04:56:26 +0000 (GMT) Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <1360212986.90708.YahooMailClassic@web133106.mail.ir2.yahoo.com> Hi all: Gcc support is becoming harder and harder to get not here precisely in gcc camp. I agree with somethings you say, like good backend debugging support, but we need really get serious about implementation alternatives, it would be wonderful to support JIT targets (read, JVM, .NET, C-like machines), and obviously they are better to be written in C substrate (we need one hardware abstraction layer). If you could just reuse m3cc to make a throw prototype of a JIT compiler for instance to C-like bytecode (in form of inline assembly of gcc) the approach of C generating backend would be lot more easier to support, because you can create binary translators with NJ machine code toolkit translators for instance to several platforms using either C or Modula-3 decoding. Kind of supporting Thanks in advance --- El mi?, 6/2/13, Coleburn, Randy escribi?: De: Coleburn, Randy Asunto: Re: [M3devel] Compiler upgrade broken in Hudson CI Para: "m3devel at elegosoft.com" Fecha: mi?rcoles, 6 de febrero, 2013 18:13 I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! --Randy Coleburn -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Wednesday, February 06, 2013 12:25 PM To: m3devel at elegosoft.com Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI On 02/05/2013 02:28 AM, Jay K wrote: > I will fix it, but I do desire to drop the old backend entirely. > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. I have put in a *huge* amount of work on m3gdb.? While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence.? Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc.? etc. A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information.? Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more.? As I recall it, only the release branch supports a working m3gdb right now. And I use m3gdb all the time in my own work. Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*.? Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > >???- Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 7 07:35:15 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 7 Feb 2013 07:35:15 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: Message-ID: <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com> On Wed, 6 Feb 2013 09:00:33 +0000 Jay K wrote: > Olaf, Dagobert, > > Dagobert: We haven't tried to run anything in a while. > > 1) SOLsun is failing to login: > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > is that right? Login works now. I've started the job http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/157/console to see how far it gets. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Feb 7 08:36:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 7 Feb 2013 07:36:41 +0000 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: m3gdb: is GPL is a fork, that will never be merged that isn't being updated is big that doesn't support some platforms e.g. Darwin, HP-UX cm3cg has some but not all of those characteristics Meanwhile, debugging on NT and Darwin is limited to line numbersand integers and floats. No useful view of structs or globalsis available. And as I understand..can anyone agree/disagree?.. gets itsdata from the backend via a total backdoor hack, that is very difficultto duplicate. E.g. including with llvm, including if we generatedtypeful gcc trees like any normal backend would do.I speculate, maybe it will be possible to output some assemblyfiles on the side with just the stabs directives. I'm hoping that: gdb on Darwin will improve drastically via the C backend; it hasn't yet windbg and Visual Studio ditto gdb on platforms that support m3gdb will come close to m3gdb,but parity might not be achievable. Our target support continues to lag. DragonflyBSD? OpenBSD w/o maintaining patches (mainline gcc doesn't support OpenBSD, but I386_ELF is all fairly much the same, so the patches are small) ARM_NT? {PPC,MIPS,ARM,SH,I386}_CE? ARM_DARWIN? Was mostly there already. PPC32_XBOX? AMD64_NT? This should come along fairly soon now via the C backend. Let's see how good we can get stock debuggers working with our C. Ok? - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 6 Feb 2013 23:13:37 +0000 > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! > --Randy Coleburn > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Wednesday, February 06, 2013 12:25 PM > To: m3devel at elegosoft.com > Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > On 02/05/2013 02:28 AM, Jay K wrote: > > I will fix it, but I do desire to drop the old backend entirely. > > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > > > > > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. > > I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. > > Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. > > A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its > Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. > > And I use m3gdb all the time in my own work. > > Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Feb 8 00:31:46 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 8 Feb 2013 00:31:46 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com> References: <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com> Message-ID: <20130208003146.9bb5951f2fc35b356cf63582@elegosoft.com> On Thu, 7 Feb 2013 07:35:15 +0100 Olaf Wagner wrote: > On Wed, 6 Feb 2013 09:00:33 +0000 > Jay K wrote: > > > Olaf, Dagobert, > > > > Dagobert: We haven't tried to run anything in a while. > > > > 1) SOLsun is failing to login: > > > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > > > is that right? > > Login works now. I've started the job > http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/157/console > to see how far it gets. Status update: the three platforms currently configured for CM3 on the buildfarm work again to some degree. I had to change CVS ports from 2401 to 12401, change host names from current to dublin and move some files around. I386_SOLARIS fails in the m3cc package: http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console SOLsun on SPARC Solaris 9 fails in m3core: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console SOLsun on SPARC Solaris 10 succeeds: http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/ We should fix those failures before changing things like target platform names. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Feb 8 08:36:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 8 Feb 2013 07:36:12 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <20130208003146.9bb5951f2fc35b356cf63582@elegosoft.com> References: , <20130207073515.32d3858fdce52fcf40e03767@elegosoft.com>, <20130208003146.9bb5951f2fc35b356cf63582@elegosoft.com> Message-ID: > SOLsun on SPARC Solaris 9 fails in m3core: That is odd, I added fprintf for maybe more information > I386_SOLARIS fails in the m3cc package: Oops, sorry, not surprising, so I downgraded to 4.5 for all Solaris platforms.Otherwise I have to port forward the patches to gcc to avoid depending on gcc extensions. Or we can build gcc with gcc instead of Solaris cc. - Jay > Date: Fri, 8 Feb 2013 00:31:46 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > > On Thu, 7 Feb 2013 07:35:15 +0100 > Olaf Wagner wrote: > > > On Wed, 6 Feb 2013 09:00:33 +0000 > > Jay K wrote: > > > > > Olaf, Dagobert, > > > > > > Dagobert: We haven't tried to run anything in a while. > > > > > > 1) SOLsun is failing to login: > > > > > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > > > > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664Building remotely on opencsw_current10s[cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC"cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refusedFATAL: CVS failed. exit code=1Finished: FAILURE > > > > > > The Hudson job is configured to use::pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > > > > > is that right? > > > > Login works now. I've started the job > > http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/157/console > > to see how far it gets. > > Status update: the three platforms currently configured for CM3 on the buildfarm > work again to some degree. I had to change CVS ports from 2401 to 12401, > change host names from current to dublin and move some files around. > > I386_SOLARIS fails in the m3cc package: > http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console > > SOLsun on SPARC Solaris 9 fails in m3core: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console > > SOLsun on SPARC Solaris 10 succeeds: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/ > > We should fix those failures before changing things like target platform names. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Feb 8 09:28:11 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 8 Feb 2013 09:28:11 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: Message-ID: <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org> Hi, sorry for answering late. Am 06.02.2013 um 10:00 schrieb Jay K : > Olaf, Dagobert, > > > Dagobert: We haven't tried to run anything in a while. > > > 1) SOLsun is failing to login: > > > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/544/console > > > Started by upstream project "cm3-current-build-AMD64_FREEBSD" build number 664 > Building remotely on opencsw_current10s > [cm3] $ cvs -q -z3 update -PdC -D "Wednesday, February 6, 2013 8:32:49 AM UTC" > cvs [update aborted]: connect to login.bo.opencsw.org(192.168.1.2):2401 failed: Connection refused > FATAL: CVS failed. exit code=1 > Finished: FAILURE > > > The Hudson job is configured to use: > :pserver:anonymous%modula3.elegosoft.com at login.bo.opencsw.org:2401/usr/cvs > > > is that right? We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it if you need it. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Feb 8 10:44:41 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 8 Feb 2013 10:44:41 +0100 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org> References: <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org> Message-ID: <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com> On Fri, 8 Feb 2013 09:28:11 +0100 Dagobert Michelsen wrote: > We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it > if you need it. But it seems to work with Port 12401 instead of 2401, so no need to change anything right now. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Fri Feb 8 16:42:22 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 08 Feb 2013 09:42:22 -0600 Subject: [M3devel] Compiler upgrade broken in Hudson CI In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF047F7C@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <51151CDE.1070207@lcwb.coop> On 02/07/2013 01:36 AM, Jay K wrote: > m3gdb: > is GPL > is a fork, that will never be merged > that isn't being updated > is big > that doesn't support some platforms e.g. Darwin, HP-UX Yes. But what it does, works, now. Nothing else exists now that comes close. Actually, it has been merged into at least 5 versions of gdb, counting the original modification. I have done three, and in each, I have moved towards reducing the entanglement with existing gdb code, so merging gets easier, though still no picnic. It's been updated many times, though not recently. Most of the pure updates have been enhancements. Most of the regressions have been caused by back end changes, not problems inside m3gdb. That said, as often as possible, I have worked around these inside m3gdb, by adding yet another back end version to the set it can dynamically adapt to, rather than fixing the back end. Kludgier, yes. But it's more robust, and compatible. It already copes with quite a range of back ends. > > cm3cg has some but not all of those characteristics > Ditto. > > Meanwhile, debugging on NT and Darwin is limited to line numbers > and integers and floats. No useful view of structs or globals > is available. Perhaps. But what it does, works on LINUXLIBC6 and AMD64_LINUX, now. Have you tried m3gdb on NT and Darwin using the working (debug-info-wise) gcc backend (4.5, as I recall), or only the one wherein you disabled the Modula-3 debug output (4.6, as I recall)? In the latter case, it, of course, doesn't work anywhere. I think you will find stuff like calls, procedure variables, etc., that involve the calling convention, will need target-dependent work in m3gdb. That's the way it went when adding AMD64_LINUX. But I would expect more than you describe to work on a new target, without modifications. > And as I understand..can anyone agree/disagree?.. gets its > data from the backend via a total backdoor hack, that is very difficult > to duplicate. Yes, it's a backdoor hack. But it works, now. E.g. including with llvm, In the long run, llvm plus dwarf (which llvm appears to already have good support for) is the clear way to get something non-hackish. But that will require major debugger work to support, in addition, of course, to an llvm-derived back end itself. I am sure this approach would be much easier than getting dwarf info out of either cm3cg, or gcc compiling C source. including if we generated > typeful gcc trees like any normal backend would do. > I speculate, maybe it will be possible to output some assembly > files on the side with just the stabs directives. > This could probably work, but it's just a superficially different information path for an equivalent backdoor hack. Right now, cm3cg pretty much just serves as a conduit for stabs info that is generated by the code parse.c. From there, it ends up, with little or no change, interspersed in the rest of the cm3cg-generated assembly code. But I expect this would be the only reasonable way to get any Modula-3-literate debug info past C source code. > > > I'm hoping that: > gdb on Darwin will improve drastically via the C backend; it hasn't yet > windbg and Visual Studio ditto > > gdb on platforms that support m3gdb will come close to m3gdb, > but parity might not be achievable. You will not achieve anything close to parity without a debugger that has a lot of Modula-3-specific code inside. Have you read cm3/doc/help/m3gdb/m3gdb-onepage.html? Consider it the definition of parity. > > > Our target support continues to lag. > DragonflyBSD? > OpenBSD w/o maintaining patches (mainline gcc doesn't support OpenBSD, but I386_ELF is all fairly much the same, so the patches are small) > ARM_NT? > {PPC,MIPS,ARM,SH,I386}_CE? > ARM_DARWIN? Was mostly there already. > PPC32_XBOX? > AMD64_NT? This should come along fairly soon now via the C backend. > > > Let's see how good we can get stock debuggers working with our C. Ok? > Do whatever you can and want to. But don't torpedo what is now working, until you can replace it with something that achieves parity. Until then, don't break, disable, or remove it from CVS head. Keep it an easy-to-choose and findably-documented option. If you make changes that could possibly undermine it, make a branch, until they are well-tested. > > - Jay > > > > From: rcolebur at SCIRES.COM > > To: m3devel at elegosoft.com > > Date: Wed, 6 Feb 2013 23:13:37 +0000 > > Subject: Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > I concur with Rodney, we must preserve the m3gdb capability and the backends that support it! > > --Randy Coleburn > > > > -----Original Message----- > > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > > Sent: Wednesday, February 06, 2013 12:25 PM > > To: m3devel at elegosoft.com > > Subject: EXT:Re: [M3devel] Compiler upgrade broken in Hudson CI > > > > > > > > On 02/05/2013 02:28 AM, Jay K wrote: > > > I will fix it, but I do desire to drop the old backend entirely. > > > What is mainly stopping me right now is that on platforms that support m3gdb, debugging is degraded. > > > I need to at least declare structs with fields (not to mention enums) before we can/should switch those platforms. > > > > > > > > > I am not sure what is happening here, but it is making me very nervous with talk of removing backends. > > > > I have put in a *huge* amount of work on m3gdb. While it is not even close to being a complete Modula-3 debugger (I have several tens of pages of handwritten to-do items for it), it is *far* ahead of anything else in existence. Many many things like executing procedure and method calls, accessing global and nonlocal variables, handling procedure variables, open arrays, Modula-3 syntax and operators, etc. etc. are either impossible or hopelessly tedious in any C or generic debugger. > > > > Moreover, for someone spoiled by Modula-3, it has been miserable work for having to be done in C, with its brain-dead type system, absurd identifier lookup system, half inside-out, half rightside-out type expressions, etc. etc. > > > > A small but vital part of this is work done inside the backend, to generate usable Modula-3 debug information. Even that has taken a big hit, as the old (4.5?) gcc-derived back end in the head has had its > > Modu8la-3 debug info output totally disabled, for a long time--perhaps two years or more. As I recall it, only the release branch supports a working m3gdb right now. > > > > And I use m3gdb all the time in my own work. > > > > Make all the *alternative* backends you want, but *do not sabotage the working m3gdb*. Leave the backend that supports m3gdb intact, present in the releases and head, and easily selectable to build and use, with simple and well-documented switches, until something newer supports at least all the same debug functions. > > > > > > > > > > - Jay > > > From jay.krell at cornell.edu Wed Feb 13 11:20:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 13 Feb 2013 10:20:51 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com> References: , <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org>, <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com> Message-ID: > I386_SOLARIS fails in the m3cc package: http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console > This looks ok now. >> http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/166/consoleFull > SOLsun on SPARC Solaris 9 fails in m3core: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console I changed this to print more, but it doesn't. I'm guessing it is the previous m3core failing? Use a new minimum distribution? I'll work on it.. Thanks, - Jay > Date: Fri, 8 Feb 2013 10:44:41 +0100 > From: wagner at elegosoft.com > To: dam at opencsw.org > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > > On Fri, 8 Feb 2013 09:28:11 +0100 > Dagobert Michelsen wrote: > > > We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it > > if you need it. > > But it seems to work with Port 12401 instead of 2401, so no need to > change anything right now. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 17 08:59:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 07:59:26 +0000 Subject: [M3devel] sparc64 problem Message-ID: This looks familiar..but I don't remember what I did about it, and don't see a fix in the tree already... new source -> compiling Matrix4.m3 m3front ../src/Matrix4.m3 -w1 /Users/jay/dev2/cm3/m3-sys/m3cc/AMD64_DARWIN-SPARC64_SOLARIS/cm3cg -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Matrix4.mc -o Matrix4.ms ../src/Matrix4.m3: In function 'Matrix4__TransformUnitCube': ../src/Matrix4.m3:317:0: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:6212 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: Matrix4.mc INTERFACE Point3; TYPE T = RECORD x,y,z : REAL; END; INTERFACE Matrix4; IMPORT Point3; PROCEDURE TransformUnitCube (p, a, b, c : Point3.T) : T; This is probably because we declare that records have size, but no fields. i.e. yet another thing bad about the current cm3cg backend.. I can try with 4.2 or 4.3 or 4.5 or 4.6, but I expect they are the same here.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 17 08:59:06 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 17 Feb 2013 08:59:06 +0100 Subject: [M3devel] DLLs In-Reply-To: References: Message-ID: <927C5FEC-CD7F-4787-B61C-E8C9DFEAF817@m3w.org> Also from memory, I second this? I was/am using .DLL's in a manner compatible with Linux/OSX (using right API calls, of course). No special anything anywhere. -- Divided by a common language Dragi?a Duri? dragisha at m3w.org On Feb 1, 2013, at 9:16 PM, Jay K wrote: > Dirk, From my memory, you have it backwards. .dlls are built by default for any "library". > You can suppress .dll building with build_standalone(). > > It works like this, it is a bit unusual, but kind of nice: > f or every "library", we build a static library and a .dll/.so > "programs" default to linking to .dlls if present, else static libraries > > > - Jay > > From: dmuysers at hotmail.com > To: m3devel at elegosoft.com > Date: Fri, 1 Feb 2013 19:04:02 +0100 > Subject: [M3devel] DLLs > > Using the standard cm3 tools there is no official way to build a library as a DLL. > Hence, out of curiosity, the following question: > Since cm3/bin contains lots of library DLLs, how were they built? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Feb 17 22:02:51 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 17 Feb 2013 15:02:51 -0600 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: <20130217205228.0C60B5DEA8F@birch.elegosoft.com> References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com> Message-ID: <5121457B.6060703@lcwb.coop> What is happening here? Every time I commit these two files, cvs inserts a few opening comment delimiters without matching closing ones. It does this to my local copy, in addition to, as nearly as I can ascertain, the checked-in copy. On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/02/17 21:52:28 > > Modified files: > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > Log message: > > > From jay.krell at cornell.edu Mon Feb 18 00:22:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: <5121457B.6060703@lcwb.coop> References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, <5121457B.6060703@lcwb.coop> Message-ID: It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. - Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 18 00:25:21 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2013 00:25:21 +0100 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: <5121457B.6060703@lcwb.coop> References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com> <5121457B.6060703@lcwb.coop> Message-ID: <20130218002521.8b7e518a87cf1b2694f74df7@elegosoft.com> On Sun, 17 Feb 2013 15:02:51 -0600 "Rodney M. Bates" wrote: > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: I assume CVS replaces the magic $Id$ and $Log$ keywords. You could try to remove them, they only will make version control more difficult. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 18 00:23:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 23:23:38 +0000 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , <5121457B.6060703@lcwb.coop>, Message-ID: ps: can we not add more GPL stuff? Can use a BSD license? Thanks, - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. - Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 18 00:41:57 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 17 Feb 2013 23:41:57 +0000 Subject: [M3devel] Hudson Modula-3 Solaris jobs In-Reply-To: References: , , <6ECDE6B1-CA66-40D9-8427-402F880B73F4@opencsw.org>, , <20130208104441.67da3940eef6f7c464cb8aa1@elegosoft.com>, Message-ID: >> SOLsun on SPARC Solaris 9 fails in m3core: >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console > I changed this to print more, but it doesn't. > I'm guessing it is the previous m3core failing? > Use a new minimum distribution? I'll work on it.. It took me a while. How about this: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-SOLsun-d5.9.0-Solaris5.8-20130217.tar.lzma ? Built on 5.8 -- should work on that and newer.. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dam at opencsw.org Date: Wed, 13 Feb 2013 10:20:51 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > I386_SOLARIS fails in the m3cc package: http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/160/console > This looks ok now. >> http://hudson.modula3.com:8080/job/cm3-current-build-I386_SOLARIS-opencsw-current10x/166/consoleFull > SOLsun on SPARC Solaris 9 fails in m3core: > http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/229/console I changed this to print more, but it doesn't. I'm guessing it is the previous m3core failing? Use a new minimum distribution? I'll work on it.. Thanks, - Jay > Date: Fri, 8 Feb 2013 10:44:41 +0100 > From: wagner at elegosoft.com > To: dam at opencsw.org > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Hudson Modula-3 Solaris jobs > > On Fri, 8 Feb 2013 09:28:11 +0100 > Dagobert Michelsen wrote: > > > We used to have cvsproxy on login, which is for some reason no longer installed. I can reinstall it > > if you need it. > > But it seems to work with Port 12401 instead of 2401, so no need to > change anything right now. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 18 00:52:33 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 18 Feb 2013 10:52:33 +1100 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , <5121457B.6060703@lcwb.coop>, Message-ID: GPL # BSD. We should minimize GPL stuff where we are unable to eliminate. On Feb 18, 2013, at 10:23 AM, Jay K wrote: > ps: can we not add more GPL stuff? Can use a BSD license? > > Thanks, > - Jay > > > From: jay.krell at cornell.edu > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Sun, 17 Feb 2013 23:22:33 +0000 > Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > It's related to those dollar sign thingies. We could just remove them entirely. > I found a form that doesn't break, though not clear I'm getting the intended content. > > - Jay > > > > Date: Sun, 17 Feb 2013 15:02:51 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > > > What is happening here? Every time I commit these two files, cvs inserts > > a few opening comment delimiters without matching closing ones. It does > > this to my local copy, in addition to, as nearly as I can ascertain, the > > checked-in copy. > > > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > > CVSROOT: /usr/cvs > > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > > > Modified files: > > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > > > Log message: > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 18 01:18:18 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 18 Feb 2013 00:18:18 +0000 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , , <5121457B.6060703@lcwb.coop>, , , , Message-ID: Agreed. There's been some GPL additions recently. From: hosking at cs.purdue.edu Date: Mon, 18 Feb 2013 10:52:33 +1100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 GPL # BSD. We should minimize GPL stuff where we are unable to eliminate. On Feb 18, 2013, at 10:23 AM, Jay K wrote:ps: can we not add more GPL stuff? Can use a BSD license? Thanks, - Jay From: jay.krell at cornell.edu To: rodney_bates at lcwb.coop; m3devel at elegosoft.com Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. - Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 > > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. > > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Feb 18 02:59:53 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 18 Feb 2013 01:59:53 +0000 (GMT) Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> Hi all: core RT is different fundamentally of that proposition, e.g: http://modula3.elegosoft.com/cm3/doc/help/gen_html/m3core/src/runtime/common/RTHooks.m3.html#0TOP0 Please, we should keep improving this instead of not allowing changes or removing it without notice. Thanks in advance --- El dom, 17/2/13, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 Para: "Tony" CC: "m3devel" Fecha: domingo, 17 de febrero, 2013 19:18 Agreed. There's been some GPL additions recently. From: hosking at cs.purdue.edu Date: Mon, 18 Feb 2013 10:52:33 +1100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 GPL # BSD. We should minimize GPL stuff where we are unable to eliminate. On Feb 18, 2013, at 10:23 AM, Jay K wrote: ps: can we not add more GPL stuff? Can use a BSD license? Thanks, ?- Jay From:?jay.krell at cornell.edu To:?rodney_bates at lcwb.coop;?m3devel at elegosoft.com Date: Sun, 17 Feb 2013 23:22:33 +0000 Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 It's related to those dollar sign thingies. We could just remove them entirely. I found a form that doesn't break, though not clear I'm getting the intended content. ?- Jay > Date: Sun, 17 Feb 2013 15:02:51 -0600 > From:?rodney_bates at lcwb.coop > To:?m3devel at elegosoft.com > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 >? > What is happening here? Every time I commit these two files, cvs inserts > a few opening comment delimiters without matching closing ones. It does > this to my local copy, in addition to, as nearly as I can ascertain, the > checked-in copy. >? > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/02/17 21:52:28 > > > > Modified files: > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 > > > > Log message: > >? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 18 15:46:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 18 Feb 2013 08:46:40 -0600 Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 In-Reply-To: References: <20130217205228.0C60B5DEA8F@birch.elegosoft.com>, , <5121457B.6060703@lcwb.coop>, Message-ID: <51223ED0.8010502@lcwb.coop> Please elaborate on what you want to do and why. On 02/17/2013 05:52 PM, Tony Hosking wrote: > GPL # BSD. > > We should minimize GPL stuff where we are unable to eliminate. > > On Feb 18, 2013, at 10:23 AM, Jay K > wrote: > >> ps: can we not add more GPL stuff? Can use a BSD license? >> >> Thanks, >> - Jay >> >> >> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --- >> From:jay.krell at cornell.edu >> To:rodney_bates at lcwb.coop ;m3devel at elegosoft.com >> Date: Sun, 17 Feb 2013 23:22:33 +0000 >> Subject: Re: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 >> >> It's related to those dollar sign thingies. We could just remove them entirely. >> I found a form that doesn't break, though not clear I'm getting the intended content. >> >> - Jay >> >> >> > Date: Sun, 17 Feb 2013 15:02:51 -0600 >> > From:rodney_bates at lcwb.coop >> > To:m3devel at elegosoft.com >> > Subject: [M3devel] cvs commit damaging code? Re: [M3commit] CVS Update: cm3 >> > >> > What is happening here? Every time I commit these two files, cvs inserts >> > a few opening comment delimiters without matching closing ones. It does >> > this to my local copy, in addition to, as nearly as I can ascertain, the >> > checked-in copy. >> > >> > On 02/17/2013 09:52 PM, Rodney M. Bates wrote: >> > > CVSROOT: /usr/cvs >> > > Changes by: rodney at birch. 13/02/17 21:52:28 >> > > >> > > Modified files: >> > > cm3/m3-libs/ordsets/ordsets/src/: Sets.i3 Sets.m3 >> > > >> > > Log message: >> > > >> > > >> > > >> > > From cornstalk at columbus.rr.com Fri Feb 22 17:25:50 2013 From: cornstalk at columbus.rr.com (Mark Morss) Date: Fri, 22 Feb 2013 11:25:50 -0500 Subject: [M3devel] Mysql interface? In-Reply-To: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> References: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> Message-ID: <51279C0E.1000807@columbus.rr.com> Do I correctly suppose that there is no functioning mysql interface for Modula-3? The db module appears to contain only a place-holder for mysql. I googled on this and could not discover an answer. Best to all. From mika at async.caltech.edu Fri Feb 22 17:40:07 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 22 Feb 2013 08:40:07 -0800 Subject: [M3devel] Mysql interface? In-Reply-To: <51279C0E.1000807@columbus.rr.com> References: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> <51279C0E.1000807@columbus.rr.com> Message-ID: <20130222164007.353A51A2095@async.async.caltech.edu> The PostgreSQL interface works quite well, though. Mika Mark Morss writes: > >Do I correctly suppose that there is no functioning mysql interface for >Modula-3? The db module appears to contain only a place-holder for mysql. > >I googled on this and could not discover an answer. > >Best to all. From darko at darko.org Fri Feb 22 19:43:49 2013 From: darko at darko.org (Darko) Date: Fri, 22 Feb 2013 10:43:49 -0800 Subject: [M3devel] Mysql interface? In-Reply-To: <51279C0E.1000807@columbus.rr.com> References: <1361152793.67479.YahooMailClassic@web133101.mail.ir2.yahoo.com> <51279C0E.1000807@columbus.rr.com> Message-ID: <899E88D3-6134-45B1-9D3E-1F6F3C177C22@darko.org> These should work, but are not thoroughly tested nor complete. -------------- next part -------------- A non-text attachment was scrubbed... Name: MySQL.i3 Type: application/octet-stream Size: 26193 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MySQLConn.i3 Type: application/octet-stream Size: 11189 bytes Desc: not available URL: -------------- next part -------------- On Feb 22, 2013, at 8:25 AM, Mark Morss wrote: > > Do I correctly suppose that there is no functioning mysql interface for Modula-3? The db module appears to contain only a place-holder for mysql. > > I googled on this and could not discover an answer. > > Best to all. From peter.mckinna at gmail.com Sat Feb 23 00:06:31 2013 From: peter.mckinna at gmail.com (=?utf-8?B?cGV0ZXIubWNraW5uYUBnbWFpbC5jb20=?=) Date: Sat, 23 Feb 2013 10:06:31 +1100 Subject: [M3devel] =?utf-8?q?Mysql_interface=3F?= Message-ID: <5127f9f7.a3c5440a.262b.1ec2@mx.google.com> There is one but you have to get CVS access . Hasn't been a release for some time . Peter Sent from my HTC ----- Reply message ----- From: mika at async.caltech.edu To: "Mark Morss" Cc: Subject: [M3devel] Mysql interface? Date: Sat, Feb 23, 2013 3:40 am The PostgreSQL interface works quite well, though. Mika Mark Morss writes: > >Do I correctly suppose that there is no functioning mysql interface for >Modula-3? The db module appears to contain only a place-holder for mysql. > >I googled on this and could not discover an answer. > >Best to all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 24 09:10:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 24 Feb 2013 08:10:56 +0000 Subject: [M3devel] language question -- locals uninitialized or zero? Message-ID: PROCEDURE F1() VAR a, b := 1; c: INTEGER; t: TEXT; r: TRACED REF... u: UNTRACED REF... BEGIN END F1; Is a defined? To 1 or 0? Is c defined? 0? t? NIL? r? NIL? u? NIL? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 24 09:13:44 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 24 Feb 2013 08:13:44 +0000 Subject: [M3devel] feature request -- variables w/o indentation Message-ID: I would really really really like to be able to declare variables or constants, VAR, WITH, CONST, and NOT have to give up horizontal space to do so. I do like to initialize variables at point of declaration. But these are contradictory. I've been writing more Modula-3, and this among the aspects of it that bothers me the most.. C++ has always had this feature. It is considered so conservative, that even C9x has it. Can Modula-3 be fixed? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Feb 24 09:28:49 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 24 Feb 2013 09:28:49 +0100 (CET) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: References: Message-ID: On Sun, 24 Feb 2013, Jay K wrote: > PROCEDURE F1() > VAR a, b := 1; > ??? c: INTEGER; > ??? t: TEXT; > ??? r: TRACED REF... > ??? u: UNTRACED REF... > BEGIN > END F1; > > > > Is a defined? To 1 or 0? 1 " VAR v_1, ..., v_n: T := E is shorthand for: VAR v_1: T := E; ...; VAR v_n: T := E " http://www.cs.purdue.edu/homes/hosking/m3/reference/variables.html > Is c defined? 0? > t? NIL? > r? NIL? > u? NIL? "If E is omitted, the initial value is an arbitrary value of type T. If both are present, E must be assignable to T." From lemming at henning-thielemann.de Sun Feb 24 10:16:36 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 24 Feb 2013 10:16:36 +0100 (CET) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: <4634A989-48D7-4132-8560-8A47E0A127AE@gmail.com> References: <4634A989-48D7-4132-8560-8A47E0A127AE@gmail.com> Message-ID: On Sun, 24 Feb 2013, Antony Hosking wrote: > On 24/02/2013, at 7:28 PM, Henning Thielemann wrote: > >> "If E is omitted, the initial value is an arbitrary value of type T. If both are present, E must be assignable to T." > > ie, NIL It could also point to a real object, e.g. to the object it pointed to the last time when the variable was used, right? From hendrik at topoi.pooq.com Sun Feb 24 10:11:57 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 24 Feb 2013 04:11:57 -0500 Subject: [M3devel] feature request -- variables w/o indentation In-Reply-To: References: Message-ID: <20130224091157.GA30268@topoi.pooq.com> On Sun, Feb 24, 2013 at 08:13:44AM +0000, Jay K wrote: > I would really really really like to be able to declare variables or constants, VAR, WITH, CONST, and NOT have to give up horizontal space to do so. > > > I do like to initialize variables at point of declaration. > > > But these are contradictory. *I*'d like to declare variables at the point of initialization. -- hendrik From lemming at henning-thielemann.de Sun Feb 24 10:22:08 2013 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: References: <4634A989-48D7-4132-8560-8A47E0A127AE@gmail.com> Message-ID: On Sun, 24 Feb 2013, Antony Hosking wrote: > I suppose it could, but that would be a space leak.The current implementation sets it to NIL. I believe that the question was, whether he can rely on the pointer being NIL, and I think he cannot. From dabenavidesd at yahoo.es Sun Feb 24 17:51:05 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 24 Feb 2013 16:51:05 +0000 (GMT) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: Message-ID: <1361724665.61570.YahooMailClassic@web133102.mail.ir2.yahoo.com> Hi all: if you run such a program and violate safety abstraction of uninitialized programs, you could run the program safely, but being honest means, you run the program and bypass its initialization and get the same results (which is still under first amendment argument, that is violate safety abstractions or RT). Let's suppose you run the program on different runtime environment with different initialization values the fact is you can get different results, which makes your program implementation dependent. This is UNSAFE. Thus if you don't have RT environment to choose from, you don't have any tool to verify that your program is safe and ignoring a safety abstraction is a violation always, because *******RT assumptions must always be truth**********. DEC ALPHA allowed to detect use of unitialized variables on RT, which is still better than a debugger for my own semantic model. in VAX you could get RT exception handling which is more safe, if you will to allow such program behavior in RT, but not unsafely ignoring it like you are trying to do it. Thanks in advance ? --- El dom, 24/2/13, Jay K escribi?: De: Jay K Asunto: [M3devel] language question -- locals uninitialized or zero? Para: "m3devel" Fecha: domingo, 24 de febrero, 2013 03:10 PROCEDURE F1() VAR a, b := 1; ??? c: INTEGER; ??? t: TEXT; ??? r: TRACED REF... ??? u: UNTRACED REF... BEGIN END F1; Is a defined? To 1 or 0? Is c defined? 0? t? NIL? r? NIL? u? NIL? ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 25 18:08:12 2013 From: rodney_bates at lcwb.coop (Rodney Bates) Date: Mon, 25 Feb 2013 09:08:12 -0800 Subject: [M3devel] language question -- locals uninitialized or zero? Message-ID: <20130225090812.FB03F54D@m0005299.ppops.net> -Rodney Bates --- lemming at henning-thielemann.de wrote: From: Henning Thielemann To: Antony Hosking Cc: m3devel Subject: Re: [M3devel] language question -- locals uninitialized or zero? Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) On Sun, 24 Feb 2013, Antony Hosking wrote: > I suppose it could, but that would be a space leak.The current implementation sets it to NIL. I believe that the question was, whether he can rely on the pointer being NIL, and I think he cannot. Yes, he cannot, strictly by the language rules. Somewhat pragmatically, it seems a real stretch to imagine why an implementer would choose anything other than NIL, for any reference type. Even more pragmatically, I am quite sure we have no variant of the compiler that uses anything other than NIL. But to have code that is guaranteed to survive any future new implementation, give it an explicit :=NIL. From mika at async.caltech.edu Mon Feb 25 23:31:20 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 25 Feb 2013 14:31:20 -0800 Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: References: Message-ID: <20130225223121.07C871A2097@async.async.caltech.edu> a and b are 1; nothing else is defined. Jay K writes: >--_b18999f1-d159-4d1d-a35d-bebf3bc4b207_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >PROCEDURE F1() >VAR a=2C b :=3D 1=3B > c: INTEGER=3B > t: TEXT=3B > r: TRACED REF... > u: UNTRACED REF... >BEGIN >END F1=3B > > > >Is a defined? To 1 or 0? >Is c defined? 0? >t? NIL? >r? NIL? >u? NIL? > > > > - Jay > > = > >--_b18999f1-d159-4d1d-a35d-bebf3bc4b207_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >
PROCEDURE F1()
VAR a=2C b := >=3D 1=3B
 =3B =3B =3B c: INTEGER=3B
 =3B =3B = >=3B t: TEXT=3B
 =3B =3B =3B r: TRACED REF...
 =3B&nbs= >p=3B =3B u: UNTRACED REF...
BEGIN
END F1=3B



Is a d= >efined? To 1 or 0?
Is c defined? 0?
t? NIL?
r? NIL?
u? NIL?
= >


 =3B- Jay

>= > >--_b18999f1-d159-4d1d-a35d-bebf3bc4b207_-- From hosking at cs.purdue.edu Tue Feb 26 01:51:39 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 26 Feb 2013 11:51:39 +1100 Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: <20130225090812.FB03F54D@m0005299.ppops.net> References: <20130225090812.FB03F54D@m0005299.ppops.net> Message-ID: <3039283A-1CE7-4E4B-BD21-88BD3149A9A4@cs.purdue.edu> Indeed, the explicit NIL will indicate to the reader that the intent is that the variable have the value NIL. It will be no less efficient (since otherwise the compiler must initialize it implicitly). Moreover, it documents intent. On the other hand, where the programmer really does *not* care about the initial value (perhaps because of subsequent assignment before read) I would claim that initializing to NIL only clutters the code and obscures intent. Of course, there is the other alternative, such as for Java which statically prohibits uninitialized variables (either there is an initializing expression or the variable has a subsequent initializing assignment). The result is much the same. In any case, the point is that Modula-3 is *safe* in that no variable can ever have undefined mis-typed state, unlike C, where variables can have arbitrary undefined state. On Feb 26, 2013, at 4:08 AM, "Rodney Bates" wrote: Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 > > > -Rodney Bates > > --- lemming at henning-thielemann.de wrote: > > From: Henning Thielemann > To: Antony Hosking > Cc: m3devel > Subject: Re: [M3devel] language question -- locals uninitialized or zero? > Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) > > > On Sun, 24 Feb 2013, Antony Hosking wrote: > >> I suppose it could, but that would be a space leak.The current implementation sets it to NIL. > > I believe that the question was, whether he can rely on the pointer being > NIL, and I think he cannot. > > Yes, he cannot, strictly by the language rules. Somewhat pragmatically, it seems > a real stretch to imagine why an implementer would choose anything other than NIL, > for any reference type. Even more pragmatically, I am quite sure we have no variant > of the compiler that uses anything other than NIL. But to have code that is guaranteed > to survive any future new implementation, give it an explicit :=NIL. > > From dabenavidesd at yahoo.es Tue Feb 26 03:00:44 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 26 Feb 2013 02:00:44 +0000 (GMT) Subject: [M3devel] language question -- locals uninitialized or zero? In-Reply-To: <20130225090812.FB03F54D@m0005299.ppops.net> Message-ID: <1361844044.4515.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi all: semantically the error is are in the program, not in the operating system (untrapped vs trapped error), all untrapped errors must be stopped before making any modification of the runtime system (not in the operating system abstraction). You can run in a untrapped error, but ignore it silently with automatic initialization like you are trying, doesn't help, your program is ill behaved and must be rejected in a checked runtime error. If you run it and don't report the error until it dereferences NIL you are probably making bad things before that (like in initialization code, for instance: MODULE Main; IMPORT SIO; VAR ?a,b,c: BOOLEAN := b=c ; BEGIN ?SIO.PutBool(a); ?SIO.PutBool(b); ?SIO.PutBool(c); END Main. ) in an uninitialized or zeroed program since you can not predict b and c will be at time of evaluation in a initialization. It doesn't solve the problem being pragmatical. Now, if you want to allow ignoring that isn't very well behaved IMHO. In fact, that's UNSAFE. For instance the above example prints TRUETRUEFALSE, in old LINUXLIBC6 makes sense? No, and making nasty assumptions and ignoring errors won't help. The program is simple and wrong. Thanks in advance --- El lun, 25/2/13, Rodney Bates escribi?: De: Rodney Bates Asunto: Re: [M3devel] language question -- locals uninitialized or zero? Para: m3devel at elegosoft.com Fecha: lunes, 25 de febrero, 2013 12:08 -Rodney Bates --- lemming at henning-thielemann.de wrote: From: Henning Thielemann To: Antony Hosking Cc: m3devel Subject: Re: [M3devel] language question -- locals uninitialized or zero? Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET) On Sun, 24 Feb 2013, Antony Hosking wrote: > I suppose it could, but that would be a space leak.The current implementation sets it to NIL. I believe that the question was, whether he can rely on the pointer being NIL, and I think he cannot. Yes, he cannot, strictly by the language rules.? Somewhat pragmatically, it seems a real stretch to imagine why an implementer would choose anything other than NIL, for any reference type.? Even more pragmatically, I am quite sure we have no variant of the compiler that uses anything other than NIL.? But to have code that is guaranteed to survive any future new implementation, give it an explicit :=NIL. -------------- next part -------------- An HTML attachment was scrubbed... URL: