[M3devel] Fwd: Output from "cron" command

Jay jay.krell at cornell.edu
Thu Dec 18 00:13:12 CET 2008


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.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] Fwd: Output from "cron" commandDate: 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.eduTo: jay.krell at cornell.eduDate: Thu, 18 Dec 2008 09:27:36 +1100CC: m3devel at elegosoft.comSubject: 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.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] Fwd: Output from "cron" commandDate: 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.eduTo: jay.krell at cornell.eduDate: Thu, 18 Dec 2008 07:10:05 +1100CC: m3devel at elegosoft.comSubject: [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.shproduced the following output:TESTHOSTNAME=niagaraWS=/homes/hosking/work/cm3-ws/niagara-2008-12-17-11-30-04LASTREL=5.4.0INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-okINSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-okINSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/currentCM3_OSTYPE=POSIXCM3_TARGET=SOLgnuBINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgzCM3CVSSERVER=birch.elegosoft.comCM3CVSROOT=birch.elegosoft.com:/usr/cvsBINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgzBINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgztesting ssh birch.elegosoft.com..ssh birch.elegosoft.com okBuilding 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/buildcvs 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 FAILEDremoving 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.extractcleaning snapshot files.../homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgzcleaning package reports.../tmp/cm3-pkg-report-SOLgnu-*.htmlTESTHOSTNAME=niagaraWS=/homes/hosking/work/cm3-ws/niagara-2008-12-17-11-57-02LASTREL=5.4.0INSTROOT_REL=/homes/hosking/work/cm3-inst/niagara/rel-5.4.0INSTROOT_POK=/homes/hosking/work/cm3-inst/niagara/prev-okINSTROOT_LOK=/homes/hosking/work/cm3-inst/niagara/last-okINSTROOT_CUR=/homes/hosking/work/cm3-inst/niagara/currentCM3_OSTYPE=POSIXCM3_TARGET=SOLgnuBINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgzCM3CVSSERVER=birch.elegosoft.comCM3CVSROOT=birch.elegosoft.com:/usr/cvsBINDISTMIN_NAME=cm3-min-POSIX-SOLgnu-5.4.0.tgzBINDISTMIN=/homes/hosking/work/cm3-min-POSIX-SOLgnu-5.4.0.tgztesting ssh birch.elegosoft.com..ssh birch.elegosoft.com okBuilding 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/buildcvs 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 = 02008.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 = 02008.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.extractcleaning snapshot files.../homes/hosking/tmp/cm3/niagara/cm3-min-POSIX-SOLgnu-*-*.tgzcleaning package reports.../tmp/cm3-pkg-report-SOLgnu-*.htmldone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20081217/ffabe3b6/attachment-0002.html>


More information about the M3devel mailing list