Is this good, bad or indifferent (a right left choice, first one doesn't matter)?

module cpuiding;

/+ imports +/
import std.stdio: writeln;
import core.cpuid;

/++ start here +/
void main(string[] args) {
   writeln(args);

   writeln(processor());
   writeln(vendor());
}

/++ Self Test Once Only main +/
unittest {
   import core.stdc.stdlib: _Exit;
   main(["Hello, world"]);
   _Exit(1);
}

Dumb? Breaks things in weird ways? Do what you want locally, it's a preference for what you may want to do some times? I'm finding it avoids a fair amount of clutter when testing main arg handling, but too new to know if it's against the grain of intent.

Cheers

On Friday, 30 July 2021 at 01:01:02 UTC, Brian Tiffin wrote:

I think you're opening yourself up to errors where some program state persists from one run of main to another. You could think that some set of flags works fine because it tests OK, but then it doesn't work at the CLI with fresh state. This seems more appropriate for an external tester, which could also run multiple mains in parallel to save on time, etc.

But you could also have a smarter test runner instead of a magic unittest, https://dlang.org/spec/traits.html#getUnitTests has an example of replacing the built-in test runner. That could exit before main for you, or fork and run CLI tests in a separate process (even if just to avoid persistent state, with the parent just waiting for the child to finish).

Quick example of that:

module udatest;

struct testCLI {
}

unittest {
    // unrelated test
    assert(true);
}

@testCLI unittest {
    main(["exe", "world"]);
}

@testCLI unittest {
    main(["exe", "note: static int wasn't altered"]);
}

unittest {
    import std.exception : enforce;

    main(["exe"]);
    enforce(false, new Exception("dummy"));
}

@testCLI unittest {
    main(["exe", "up to main#2 now"]);
}

version (unittest) {
    bool tester() {
        import std.meta : AliasSeq, Filter;
        import std.traits : getUDAs;
        import core.sys.posix.unistd : fork;
        import core.sys.posix.sys.wait : waitpid;
        import core.sys.posix.stdlib : _Exit;
        import std.stdio;

        alias cli = AliasSeq!(__traits(getUnitTests, udatest));
        static foreach (i; 0 .. cli.length) {
            writefln!"Test %d/%d"(i + 1, cli.length);
            try {
                if (getUDAs!(cli[i], testCLI).length) {
                    if (auto child = fork) {
                        int res;
                        assert(-1 != waitpid(child, &res, 0));
                        assert(res == 0);
                    } else {
                        cli[i]();
                        stdout.flush;
                        stderr.flush;
                        _Exit(0);
                    }
                } else
                    cli[i]();
            } catch (Exception e) {
                writeln(e);
            }
        }
        return false;
    }

    shared static this() {
        import core.runtime : Runtime;

        Runtime.moduleUnitTester = &tester;
    }
}

void main(string[] args) {
    import std.stdio : writefln;

    static int n = 0;
    writefln!"main#%d called with %s"(++n, args[1 .. $]);
}

On Friday, 30 July 2021 at 03:45:21 UTC, Ali Çehreli wrote:

import std.stdio;

void main(string[] args) {
  version (unittest) {
    // Don't execute the main program when unit testing
    return;
  }
}

Are you aware that this isn't necessary since v2.090.0 ?
https://dlang.org/changelog/2.090.0.html#unittest-default

On Friday, 30 July 2021 at 04:22:12 UTC, Mathias LANG wrote:

import std.stdio;

void main(string[] args) {
  version (unittest) {
    // Don't execute the main program when unit testing
    return;
  }
}

Thanks for that. DRT- env vars look worth looking into. I'm on gdc-11.1.0, and it has been running main after tests with -funittest here.

Willing to put up with hacky for the caves I'm exploring, for now, and will aim for DRT- insider tectonics while climbing up the D ladder.

And for the interested and influencers. 58, started programming on a TRS-80, late 1970s-ish. Self taught, BASIC and Z-80 assembler. Wrote a relocatable debugger on the 8K machine, source saved and loaded using audio cassette tape. Programming languages have been my hobby since day 1. Count as an over 10,000 hour expert in Forth, C, COBOL, REBOL, Unicon. (Well, maybe not 10,000 hours each, but books and articles written). 50+ languages studied purely for interest, and when directed by management. Perl, Python, PHP, on and on. That is to set the frame of how I'm seeing and experiencing the learning curve and onboarding with D. ;-)

Onboarding is working out to be awesome. Thanks to the community and active participants. That is meant both as a fact, and a personal thanks.

Had some troubles with dmd install packages on 32bit Ubuntu at first, now working fine. dmd was generating code that abended during the init for main, and never got to main. Problem gone in the 2.097.1 package. So it's more fun with rdmd, and dub, and the reference implementation. I volunteer with GNU as a maintainer, so I lean gdc, and will probably not explore ldc that much, but that is part of fulfilling wants and desires with options left over.

Curiousities fulfilled quickly, thanks to the forums.

For the learning curve. There is an immediate sense of recognition, lasts about 3 programs beyond Hello, world. Then an initial wall of oh, these are new angles, and syntax requirements, more reading before not confused.

Then you find Ali's book and spend a few hours in information soak time, awaiting the osmosis. Over the wall, and start up the steps. Say level 3 now. Can read D source fairly quickly, but would have a tough time writing code with the various combinations of attributes in a high quality way. Unlikely to invent a code path that hasn't been explored by someone else already. Monkey see, monkey do, with some ok, let's try this thrown in.

With level 10 being the goal of enlightenment, say level 6 to qualify for a paying gig as a junior with mentor, and 8 being self reliant and trusted to give advice, perhaps on a logarithmic scale at the higher levels of getting it without needing to slowly mentally unwind the syntax and semantics, I've been about 10 to spurts of more hours in a given week or two, getting up each step (quickness of mental translation of syntax, and sense of deepness and correctness of semantic understanding. Level 3, maybe 4 now. Getting close to 100 hundreds hours of reading an twiddling. Not as fast as in the younger days, but a satisfying pace. Have not needed to program in D in anger, no deadlines or on the job stress inducing time expectations. Not yet. Looking forward to first opportunity though, and will jump. ;-)

Kudos team and contributors.

Can't really suggest that many improvements to resources needed for learning D, as a hobbyist not on a clock, being new still and low enough to not know what detail interactions might be less approachable. So far, very approachable. Not confusing, but tantalizing caves to explore and integrate into knowing about potentials, super powers, and dark corners that may need to be accounted for.

And friendly people to pester with random brain train new here questions.

Have good, make well, and thanks.

On Friday, 30 July 2021 at 05:51:41 UTC, Brian Tiffin wrote:

[... interesting account of the D experience ...]

I enjoyed reading all of that.

-- Bastiaan.

On Friday, 30 July 2021 at 08:26:47 UTC, Bastiaan Veelo wrote:

Welcome, and thanks.

Need to add something; typo, Getting close to 100 hundreds hours of reading an twiddling. Should be 100 hours of reading and twiddling. ;-)

And a detail that struck me in the night, just past.

Template function definition syntax is a really sweet and easy invention of syntax. Generic, native typing becomes a solved problem. Feels solved.

Not an expert. Don't take to C++, never have, even while watching cfront and Walter having the first** brain to craft a native compiler. I find the angle bracket source code of C++ hard to grok at speed. D, is like a soft cascade flow.

** I'm not sure Walter was first first, or close first, or... Regardless, an impressive feat. Thanks, for all the things, if you read this Walter.

Have good.