[M3devel] Fwd: Output from "cron" command

Thu Dec 18 00:38:06 CET 2008

Think about the difference between safe and UNSAFE in Modula-3.

On 18 Dec 2008, at 10:13, Jay wrote:

> ps: similar question:
>
> What does "low level" mean?
>
> hand.c and dtoa.c seem low level to me.
>   I know, they are excused because they are rare and in m3core.
>
> FilePosixC.c does not.
>   The stuff I did for stat, somewhat.
>
> The garbage collector does.
> But I can't define it, other than, uselessly "dealing with bits is  
> low level", but
> int is_even(int a) { return !(a & 1); } doesn't seem very "low  
> level", just slightly, and is very "portable".
>
> I was given a book about "complexity" as a gift.
> It makes a point that "complex" and "simple" are hard to define.
> Many things that seem the one, also seem the other.
>
> I have to say, I have whittled down unix/*.i3 a bunch, for all the  
> "new" platforms, and I look at what is left, and I am inclined to  
> keep "attacking" it, keep making it "smaller", like the bitflags in  
> Ustat.i3.
>
> I am inclined to write something like this:
>
> Ustat.i3:
>
> TYPE StatFlags = RECORD
>   X, R, W: INTEGER; (* maybe u_short *)
> END;
>
> PROCEDURE GetStatFlags(VAR StatFlags);
>
> UstatC.c
>
> typedef struct { long /* maybe u_short */ X, R, W; } StatFlags_t;
> const static StatFlags_t StatsFlags = { X, R, W };
> void GetStatFlags(StatFlags_t* Result) { *Result = StatFlags };
>
> Any module using any of the flags, would retrieve them in  
> initialization.
> A bit inefficient.
> Portable.
> Cuts out many repeated lines.
>
> The C could would need a bit of #ifdefing, to handle platforms that  
> don't have some of the flags, to make them 0.
>
> Again, very portable.
> Cuts out repetition.
> Is a little slower.
> I know it also might not work, like if there are switch statements  
> or code needing actual constant constants.
>
>
>  - Jay
>
>
>
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] Fwd: Output from "cron" command
> Date: Wed, 17 Dec 2008 22:52:14 +0000
>
> 1) I totally don't mind the emails. I can ignore them for a day or  
> so easily. :)
>
>
> 2) C code in m3core or elsewhere. This is a philisophical question I  
> couldn't decide, interested in discussing some.
> Originally I put "FilePosixC.c" in m3core, and called it from libm3.  
> But I think that's..not great.
>
>
> 3) "portable"
> You throw this word around with emphasis a lot.
> Portable Modula-3 code.
> The lie of portable C code.
> What do you mean?
>
>
> There are many ways to write portable and non-portable Modula-3 and  
> C code.
> For example there were Modula-3 regression tests printing the size  
> of an integer.
>   Portable to lots of systems, but not all.
>
> I can write Modula-3 code or C code dependent or independent of  
> sizeof(int) or long or void*.
> It's quite easy to do either way, in either language.
> I don't think that proves anything.
>
>
> Likewise, in both Modula-3 and C, I can easily directly call Posix  
> open, or Win32 CreateFile.
> They are both actually very portable, but less portable than calling  
> libraries that wrap them.
> What I mean is, Posix open is implemented on tons of systems, but  
> not all.
> Win32 CreateFile is also implemented on tons of systems, but not all.
> It depends partly how you quantify systems.
> Win32 Create 1) is implemented on over a billion actual machines.
> open is actually in msvcrt.dll also, but let's ignore it for this  
> discussion.
> I've read that the "Unix workstation" market is only like in the  
> single digit millions, either sold per year or sold ever.
> I realize those billion PCs that run Windows, can also run *BSD and  
> Linux, making this all gray.
>
> Now, another way to quantify this though, that I find "impressive",  
> is that Win32 CreateFile at least historically was implemented on  
> PowerPC, MIPS, Alpha, and currently x86, IA64, AMD64. Not bad.
> (Basically, NT has been ported among the most of any /commercial  
> closed source/ OS.)
>
> But again, I don't think this proves anything.
> I can pretty equally easily write portable or non-portable C or  
> Modula, "at the library level".
>
> One angle you might argue, is that Modula-3 has a "built in"  
> portability layer/library.
> It is, in a sense, easier to not call CreateFile or open in Modula-3  
> than it is in C.
> If that is what you mean, ok.
>
> HOWEVER, if you look at the Modula-3 system, the portability layer,  
> you know, it is forked in terms of Posix and Win32. If you limit  
> yourself to the Posix part of it, well, then, you can use Posix.
> I realize Posix systems are not all equal, they are all supersets of  
> Posix, with some overlap in their supersetting.
> That's why my checkin worked on some systems but not others.
>
> Also, with respect to I/O, if use just stdio -- very portable.
> Threading -- finally, soon, multi threading will be very portable in  
> C++, at least to the implementations still being maintained.
> As well, there is OpenMP.
>
> Another angle actually you can play here is quality of compiler.
> I did some experimentation with a range of compilers I had..I guess  
> I was using C++ at the time.
> Some older compilers really stunk. Like, with CFront, you couldn't  
> have more than one return.
> Therefore, code like:
>   int even(int a)
>   {
>     if (a & 1)
>       return 0;
>     return 1;
>   }
>
> /could/ be deemed not portable.
>
> Modula-3 wins here by virtue of there being only one implementation.
> Cheating I think.
>
> See also Python and Perl.
> Well, ok, Modula-3 wins here by virtue of having a good small  
> language spec.
> You know..Perl is speced as the language implemented by  
> perl.exe....so big and gnarly and impossible to predict..impossible  
> to write down...C++ is fairly well speced, but only through  
> mountains of paper and endless discussion and clarifications....
>
>
>  - Jay
>
>
>
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Thu, 18 Dec 2008 09:27:36 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: Output from "cron" command
>
>
>
> No, broken briefly then fixed quickly is OK -- that's what  
> regressions are for.  But on the other hand, testing before checkin  
> is probably nicer to the rest of the world.  That way you don't get  
> whinging e-mails from me complaining that the Tinderbox regressions  
> broke.  I suppose it depends which pain you prefer: my e-mails or  
> testing comprehensively.  ;-)
>
> I would hope that these sorts of system-dependent changes are  
> minimized by keeping as much code in *portable* Modula-3 as  
> possible.  To my mind, nothing outside of m3core should need to  
> escape to C.
>
> On 18 Dec 2008, at 09:24, Jay wrote:
>
> (critical typo -- you can provide a time for it to power back on.)
> I'm loathe to leave all my machines on and burn the electricity..
> I don't trust them to have good power management, lower power when  
> idle.
> I should automate something here though, see if I can run Tinderbox,  
> and see if I can get cron to power on/off.
> Every time I have looked at the Tinderbox it seemed too difficult to  
> run.
>
> On the other hand, I don't know if the status quo is so bad.
> You tell me it's broken. I understand that is not ideal, and I  
> should fix it fairly asap, but is it terrible every so often?
> I do tend to at least build multiple platforms, even if not  
> "all"..so not every checkin breaks anything/everything.
>
> I figure LINUXLIBC6 is the most popular, and I can always test that  
> on birch.
>
>  - Jay
>
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] Fwd: Output from "cron" command
> Date: Thu, 18 Dec 2008 09:12:52 +1100
>
>
> My machine is in a machine room at Purdue, on all the time.
>
> On 18 Dec 2008, at 08:37, Jay wrote:
>
> I keep most of my machines powered off most of the time.
>
> Do you have automation that both runs a daily Tinderbox, and turns  
> the machine on/off?
> My SGI machine at least has a nice feature where you can software  
> power it off, and provide a time that it should power down. I  
> haven't automated, but it seems ideal for daily Tinderboxes.
>
>  - Jay
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Thu, 18 Dec 2008 07:10:05 +1100
> CC: m3devel at elegosoft.com
> Subject: [M3devel] Fwd: Output from "cron" command
>
>
> Jay,
>
> I am still getting a compile error on whatever changes you made...
>
> -- Tony
>
> Begin forwarded message:
>
> From: Tony Hosking <hosking at cs.purdue.edu>
> Date: 18 December 2008 00:04:32 GMT+11:00
> To: hosking at cs.purdue.edu
> Subject: Output from "cron" command
>
> Your "cron" job on niagara.cs.purdue.edu
> $HOME/cm3/scripts/regression/cron.sh
>
> produced the following output:
>
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2008-12-17-11-30-04
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara release-build"
>
> creating log file /tmp/build-cm3-20081217-063006-fOaGeh/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2008.12.17 06:30:07 -- checkout in progress.
> [start checkout 2008.12.17 06:30:11]
> cd /tmp/build-cm3-20081217-063006-fOaGeh/build
> cvs return value: 0
> [end checkout 2008.12.17 06:49:43]
> CHECKOUT_RETURN = 0
> --
> 2008.12.17 06:49:45 -- compile in progress.
> [start compile 2008.12.17 06:49:45]
> compile return value: 0
> [end compile 2008.12.17 06:55:03]
> COMPILE_RETURN = 1
> *** COMPILE FAILED
> removing build tree /tmp/build-cm3-20081217-063006-fOaGeh ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
>
> TESTHOSTNAME=niagara
> WS=/homes/hosking/work/cm3-ws/niagara-2008-12-17-11-57-02
> LASTREL=5.4.0
> INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0
> INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-ok
> INSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-ok
> INSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/current
> CM3_OSTYPE=POSIX
> CM3_TARGET=SOLgnu
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> CM3CVSSERVER=birch.elegosoft.com
> CM3CVSROOT=birch.elegosoft.com:/usr/cvs
> BINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgz
> BINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgz
> testing ssh birch.elegosoft.com..
> ssh birch.elegosoft.com ok
> Building cm3.
> Tinderbox Tree:   "cm3"
> Buildname:        "SOLgnu SunOS 5.10 niagara lastok-build"
>
> creating log file /tmp/build-cm3-20081217-065704-RGaGCn/log.txt
>
> ---
>
> checkout, compile and test of cm3 ...
> 2008.12.17 06:57:04 -- checkout in progress.
> [start checkout 2008.12.17 06:57:06]
> cd /tmp/build-cm3-20081217-065704-RGaGCn/build
> cvs return value: 0
> [end checkout 2008.12.17 07:16:18]
> CHECKOUT_RETURN = 0
> --
> 2008.12.17 07:16:21 -- compile in progress.
> [start compile 2008.12.17 07:16:21]
> compile return value: 0
> [end compile 2008.12.17 08:01:31]
> COMPILE_RETURN = 0
> 2008.12.17 08:01:38 -- tests in progress.
> [start run-tests 2008.12.17 08:01:38]
> cd /tmp/build-cm3-20081217-065704-RGaGCn/build
> [end run-tests 2008.12.17 08:01:38]
> TESTS_RETURN = 0
> 2008.12.17 08:01:38 -- checkout, compile and test run done.
>
> ---
>
> removing build tree /tmp/build-cm3-20081217-065704-RGaGCn ...
> cleaning CM3 workspaces...
> /homes/hosking/work/cm3-ws/niagara-*
>
> cleaning regression test log files...
> /homes/hosking/tmp/cm3/niagara/cm3-rlog-*
>
> cleaning m3test log files...
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stdout
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr
>
> /homes/hosking/tmp/cm3/niagara/m3tests-*.stderr.extract
>
> cleaning snapshot files...
> /homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgz
>
> cleaning package reports...
> /tmp/cm3-pkg-report-SOLgnu-*.html
>
> done.
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20081218/34f70575/attachment-0002.html>