[M3devel] Build Automation

[Rodney M. Bates]

On 08/25/2013 05:00 AM, Dirk Muysers wrote:
> I am not missing anything in quake. I just thought it was worth a look.
> If I would redo M3 (and I am too old for that), I would write a single
> byte-code producing compiler. So, no compelling need for quake
> or any other build tool. Plus a platform-dependent runtime and jitter
> (using e.g. libjit). Would make the whole thing much simpler.
> The biggest mistake IMHO was CM's new text modelthat obliges to
> code two branches for nearly any text-related job. I would have kept
> the pm3 text model but encoded in UTF-8. There is nearly no runtime
> penalty as one accesses text almost always sequentially. Tell me a
> single case where one needs random access to individual characters.

I have lots of them.

> I tried to do that, but TEXT is used in every nock and corner of the
> libraries. Also, surprisingly, it is significantly more difficult to revert
> from the cm3 to the pm3 model than CM's passage to the alternate
> model. You have to touch almost every module in the system. It took
> me half a day to grep through the libraries with Text, Text8, Text16,
> TextLiteral etc. And restarting from pm3 sacrifices the indeniable
> improvements of the cm3 compiler, disregarding its text model.
> That wide-character blunder was first introduced by Microsoft (does
> that surprise anybody?) when they thought that Unicode would never
> go beyond 16 bits. Sun followed the trail with Java and so did CM
> with M3. S. Ballmer's resignation (thanks the gods) comes to late to
> reverse the trend. Newer text models (e.g. Go) all acknowledge the
> mistake and use UTF-8.

In the devel_unicode branch, there is now a mostly-working system
that provides low-level support of full Unicode.  It's lower-level
than what (according to my admittedly sketchy impression) you (Dirk)
are working on.  The simplified description is, all it does is change
WIDECHAR to hold all of Unicode.  Arrays of WIDECHAR, etc, and TEXT
just fall out of this.  Specifically, ORD(LAST(WIDECHAR))=16_10FFFF.
(But, as an implementation detail, BITSIZE(WIDECHAR)=32).

Actually, there's another part.  New library code provides streams
almost like Rd and Wr that do encoding/decoding in nine (I think)
different encodings, many of them variable-length, including UTF-8
and all the other Unicode encodings.

When Modula-3 had only CHAR, we had two different abstractions:
Text and streams (Rd, Wr).  Slightly oversimplified, Text is inherently
designed for random access.  (Yeah, I know this took a hit with CM3, but
it's still feasible.) Streams are inherently sequential.  In the branch,
these two abstractions get full Unicode support while preserving their
original characteristics.

I feel _very_ strongly that it is wrong to axe the possiblity of random
access in Text.  Yes, a lot of usage is sequential, but not all, and
Text is a very easy-to-use, purely functional abstraction that often
is just so much easier than ARRAY OF (WIDE)CHAR, for many other purposes
in addition to random access.  I personally probably use Text.GetChar (and
Text.Sub) more often in non-sequential patterns than sequential.

If you are adventurous, you could probably start trying it out now.  I am
still working on testing/development on pickle and netobj compatability
between programs compiled with different WIDECHAR sizes, plus various
loose ends.  Also, I have to come up with a definitive procedure for
bootstrapping it.

> I am currently working at a Unicode-friendly library that uses UTF-8
> text side-by-side with the existing cm3 TEXT.
>
> *From:* Jay K <mailto:jay.krell at cornell.edu>
> *Sent:* Sunday, August 25, 2013 9:31 AM
> *To:* Dragiša Durić <mailto:dragisha at m3w.org> ; Dirk Muysers <mailto:dmuysers at hotmail.com>
> *Cc:* m3devel <mailto:m3devel at elegosoft.com>
> *Subject:* RE: [M3devel] Build Automation
>
> For what we use it for, Quake is hard to beat.
>
> What are you missing in Quake?
>
> It falls down only slightly:
>     - not as much parallelism as it could have
>     - it is an obscure system, like Modula-3
>     - it is perhaps fairly Modula-3 specific; but it is extensible and we do have C/C++ in their, presumably one could add Java/C# support reasonably easily..
>     - doesn't offer building multiple programs/modules in one invocation -- directory traversal; we layer thin scripts over it
>      - the name -- I assume it meant quick make
>
> it wins:
>    - integrated with the compiler (this can be viewed as bad too)
>    - declarative (or at least appears so, it is actually clever and imperative, but it is a great facsimile)
>    - presumably efficient -- they actually compile it down to a bytecode internally and execute that!
>   - presumably efficient -- underlying native code Modula-3 implementation..if this means anything any longer, so much is written in JavaScript, C#, Java, theoretical efficiencies all over the place and yet most things seem ok
>
>
>   - Jay
>
>
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 --
> From: dragisha at m3w.org
> Date: Fri, 23 Aug 2013 22:03:16 +0200
> To: dmuysers at hotmail.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Build Automation
>
> Gradle is better maven, better ant, better Ivy, etc. It is from/for Java world.
>
> It integrates other Java ecosystem build tools and extends them. It is written in Groovy, and lots of its "virtue" derives from this fact.
>
> To be useable for us, it probably first needs to integrate quake. Not an easy task, without clear benefits.
>
> --
> Dragiša Durić
> dragisha at m3w.org <mailto:dragisha at m3w.org>
>
>
>
> On Aug 20, 2013, at 7:23 PM, Dirk Muysers wrote:
>
>     Is Gradle <http://www.gradle.org/> a better quake?
>
>