www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Exit before second main with -funittest

reply Brian Tiffin <btiffin gnu.org> writes:
Is this good, bad or indifferent (a right left choice, first one 
doesn't matter)?

```d
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
Jul 29 2021
next sibling parent jfondren <julian.fondren gmail.com> writes:
On Friday, 30 July 2021 at 01:01:02 UTC, Brian Tiffin wrote:

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


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:

```d
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 {

}

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;

}
```
Jul 29 2021
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
Almost all of my programs are in the following pattern:

import std.stdio;

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

   try {
     // Dispatch to the actual "main" function
     doIt(args);

   } catch (Exception exc) {
     // Note .msg because we don't want to print stack trace
     stderr.writefln!"ERROR: %s"(exc.msg);

   } catch (Error err) {
     // Note NO .msg because we DO want to print stack trace
     stderr.writefln!"ERROR: %s"(err);
   }
}

// This is the actual "main"
void doIt(string[] args) {
   // ...
}

Ali
Jul 29 2021
parent reply Mathias LANG <geod24 gmail.com> writes:
On Friday, 30 July 2021 at 03:45:21 UTC, Ali Çehreli wrote:

 Almost all of my programs are in the following pattern:

 ```D
 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
Jul 29 2021
next sibling parent reply Brian Tiffin <btiffin gnu.org> writes:
On Friday, 30 July 2021 at 04:22:12 UTC, Mathias LANG wrote:

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

 Almost all of my programs are in the following pattern:

 ```D
 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


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.
Jul 29 2021
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 30 July 2021 at 05:51:41 UTC, Brian Tiffin wrote:

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


 **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.


I enjoyed reading all of that.

-- Bastiaan.
Jul 30 2021
parent reply Brian Tiffin <btiffin gnu.org> writes:
On Friday, 30 July 2021 at 08:26:47 UTC, Bastiaan Veelo wrote:

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

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


 **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.


 I enjoyed reading all of that.

 -- Bastiaan.


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.
Jul 30 2021
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 7/30/21 3:08 PM, Brian Tiffin wrote:


 Don't take to C++, never have, even while watching
 cfront and Walter having the first** brain to craft a native compiler.


[...]


 ** I'm not sure Walter was first first, or close first, or...


He wrote the first C++ compiler. (cfront was a C++-to-C transpiler.) I 
hope I am relaying correctly: Walter claims that without his compiler 
that made C++ accessible to the public, C++ might have remained in 
research organizations.

Ali
Jul 30 2021
parent reply Brian TIffin <btiffin gnu.org> writes:
On Friday, 30 July 2021 at 22:51:00 UTC, Ali Çehreli wrote:

 On 7/30/21 3:08 PM, Brian Tiffin wrote:


 Don't take to C++, never have, even while watching
 cfront and Walter having the first** brain to craft a native


 compiler.

 [...]


 ** I'm not sure Walter was first first, or close first, or...


 He wrote the first C++ compiler. (cfront was a C++-to-C 
 transpiler.) I hope I am relaying correctly: Walter claims that 
 without his compiler that made C++ accessible to the public, 
 C++ might have remained in research organizations.

 Ali


Thanks, Ali.

Yeah, early C++ was C, watched it evolve. Programming in Forth, 
C, Icon during those years.  Found, find, C++ too hot for most to 
handle, so why?

And yes, I'd agree that Walter's native C++ compiler was the big 
ticket item, in C++ evolution.

And a deeper thanks, Ali, for the book.

Just in case you ever want to try Unicon programming, or need to 
glue to some COBOL data, I put these on offer, umm, meaning free.

- Unicon Programming <https://unicon.sourceforge.io/up/>
- GnuCOBOL FAQ <https://gnucobol.sourceforge.io/faq/index.html>

Hoping those might let me return the favour for your D book. Nice 
work. ;-)

Have good.
Jul 30 2021
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 7/30/21 7:48 PM, Brian TIffin wrote:


 Found, find, C++ too hot for most to handle, so why?


I rubbed shoulders with C++ people who would argue to the effect of "C++ 
was not meant to be for everyone."


 And a deeper thanks, Ali, for the book.


You're welcome. I am very happy when it is helpful.


 Just in case you ever want to try Unicon programming, or need to glue to
 some COBOL data, I put these on offer, umm, meaning free.

 - Unicon Programming <https://unicon.sourceforge.io/up/>
 - GnuCOBOL FAQ <https://gnucobol.sourceforge.io/faq/index.html>


I've just browsed them. Impressive work; both the content and the 
technology covered. :)

Ali
Jul 31 2021
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 7/29/21 9:22 PM, Mathias LANG wrote:


 On Friday, 30 July 2021 at 03:45:21 UTC, Ali =C3=87ehreli wrote:

 Almost all of my programs are in the following pattern:

 ```D
 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


No, I wasn't aware. Thanks! Part of the reason must be because these=20
programs started with 2.084. :)

Ali
Jul 29 2021