Re: Exit before second main with -funittest

[Ali Çehreli via Digitalmars-d-learn]

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 
> - GnuCOBOL FAQ 

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


Ali

Re: Exit before second main with -funittest

[Brian TIffin via Digitalmars-d-learn]

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 
- GnuCOBOL FAQ 

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


Have good.

Re: Exit before second main with -funittest

[Ali Çehreli via Digitalmars-d-learn]

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

Re: Exit before second main with -funittest

[Brian Tiffin via Digitalmars-d-learn]

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.

Re: Exit before second main with -funittest

[Bastiaan Veelo via Digitalmars-d-learn]

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.

Re: Exit before second main with -funittest

[Ali Çehreli via Digitalmars-d-learn]

On 7/29/21 9:22 PM, 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

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


Ali

Re: Exit before second main with -funittest

[Brian Tiffin via Digitalmars-d-learn]

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.

Re: Exit before second main with -funittest

[Mathias LANG via Digitalmars-d-learn]

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

Re: Exit before second main with -funittest

[Ali Çehreli via Digitalmars-d-learn]

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

Re: Exit before second main with -funittest

[jfondren via Digitalmars-d-learn]

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 {
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, , 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 = 
}
}

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

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