Re: Quora: Why hasn't D started to replace C++?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/01/2018 11:17 AM, H. S. Teoh wrote:

On Thu, Feb 01, 2018 at 03:47:50PM +, Russel Winder via Digitalmars-d wrote:


For me:

aptitude install ldc
aptitude install gdc
aptitude install dmd-bin
aptitude install dub

Seems to work fine, and no conflicts.

[...]

Only because the OS has a sane packaging system (and some people were
kind enough to package the compilers in nice packages). For
less-privileged OSes, the user experience could be drastically
different. ;-)



Extracting the archive and just...using the compiler inside...always 
worked fine for me on every Windows and Linux I ever tried.

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/05/2018 04:21 PM, H. S. Teoh wrote:

On Mon, Feb 05, 2018 at 09:20:16PM +, Nick Sabalausky via Digitalmars-d 
wrote:

But still, I thought we had value range propagation rules to avoid
this sort of nonsense when possible (such as the example above)?


VRP doesn't help when the code doesn't have compile-time known values,
such as in the non-reduced code my example snippet was reduced from.



Right, it wouldn't always get rid of the message, but I would think it 
should when it's known the value cannot be -128, such as the specific 
example you posted.

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/05/2018 09:30 PM, Walter Bright wrote:

On 2/5/2018 3:18 PM, Timon Gehr wrote:
The overloading rules are fine, but byte should not implicitly convert 
to char/dchar, and char should not implicitly convert to byte.


Maybe not, but casting back and forth between them is ugly.


It *should* be ugly, it's conflating numerics with partial-characters.

Which, depending on the situation, you should either A. not be doing at 
all, or B. Be really freaking explicit about the fact that "yes, I know 
I'm mixing numerics with partial-characters here and it's for this very 
good reason XYZ." This isn't the age of ASCII. I can see how it could've 
been a pain in ASCII-land, but D doesn't live there.

Re: Bye bye, fast compilation times

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/06/2018 01:11 AM, Dmitry Olshansky wrote:

On Tuesday, 6 February 2018 at 05:45:35 UTC, Steven Schveighoffer wrote:

On 2/6/18 12:35 AM, Dmitry Olshansky wrote:


That’s really bad idea - isEmail is template so the burden of 
freaking slow ctRegex
is paid on per instantiation basis. Could be horrible with separate 
compilation.


Obviously it is horrible. On my mac, it took about 2.5 seconds to 
compile this one line.


I'm not sure how to fix it though... I suppose you could make


Just use the run-time version, it’s not that much slower. But then again 
static ipRegex = regex(...) will parse and build regex at CTFE.


Maybe lazy init?



If the regex string isn't dependent on the template's params, just move 
the regex outside the template.

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/06/2018 01:22 AM, H. S. Teoh wrote:


No need to wait for the future, you can do this today:

enum toStr(alias X) = X.stringof;

enum x = 100;
pragma(msg, toStr!1);
pragma(msg, toStr!3.14159);
pragma(msg, "Hello " ~ toStr!10 ~ " world");
pragma(msg, "Hello " ~ toStr!x ~ " world");

Note, however, that this doesn't work in CTFE, only at template
expansion time.



There's an easier way that does work in CTFE:

---

import std.conv;

enum x = 100;
pragma(msg, 1.text);
pragma(msg, "Hello " ~ 10.text ~ " world");
pragma(msg, "Hello " ~ x.text ~ " world");

enum y = 2.text;
pragma(msg, y);

//pragma(msg, 3.14159.text); // Ugh, ok, floats don't work though :(

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/06/2018 05:38 PM, Luís Marques wrote:


Yeah, it's annoying. For my MSP430 work (16-bit, lots of shorts and 
bytes) I created a generic type which works around this, so you would do:


byte c = a.nx + b;

where .nx means "non-extending" and converts/wraps the (u)byte/(u)short 
in my special type. The arithmetic operations are infectious, so you 
only need to apply it to one of the operands (and you can preserve it 
across statements by using "auto" instead of "byte").


Very cool. Would love to see this as a dub package.

Re: Bye bye, fast compilation times

[Nick Sabalausky (Abscissa) via Digitalmars-d]

Yes. This has been a personal annoyance for many years. Even tried 
arguing some time back to get it fixed to no avail. Really hoping for 
better success this time.


On 02/06/2018 08:47 PM, jmh530 wrote:


Would it help to take the approach of mir, i.e. putting 
version(mir_test) before all the unittests?


That used to be a very common idiom. (And I agree with Jonathan M Davis: 
it's a STRONG sign the current design needs fixed). But newer versions 
of dub, intelligently, will only compile the files in the main project 
with -unittest, which solves the problem...*for dub users*. 
Unfortunately, this means that the idiom above has become less common 
and libraries have become less usable for anyone using a build tool 
*other* than dub. :(

Re: Bye bye, fast compilation times

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/08/2018 06:21 AM, Martin Tschierschke wrote:


Beginner question:
How to split my project, to compile the regex part separately as a lib 
and just link them?




Unfortunately that depends completely on what buildsystem you're using. 
But if you're just calling the compiler directly, then it's really easy:


> dmd -lib -of=myLib.a [all other flags your project may need] 
fileYouWantInLib.d anyOtherFileYouAlsoWant.d


> dmd myLib.a [your project's usual flags, and all the rest of your .d 
files]


If on windows, then just replace ".a" with ".lib".

Re: Somewhat OT: defining algebras in D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/08/2018 04:37 PM, Amorphorious wrote:

On Thursday, 8 February 2018 at 15:23:05 UTC, Simen Kjærås wrote:
So I was bored in a meeting and decided to implement a generic 
template for defining complex numbers, dual numbers, quaternions and 
many other possible algebras by simply defining a set of rules and the 
components on which they act:


source:

https://gist.github.com/Biotronic/833680b37d4afe774c8562fd21554c6b



Cool. Took me a while to start to understand it and still not 100% 
grokked (partly because I've never quite been able to fully grasp 
quaternion math (at least, beyond Unity3D's ultra-easy abstraction for 
it) and never heard of dual numbers before), but staring at the complex 
number example helped see how this works. It's a very cool idea!


It would be nice if you learned how to document your code. It's not 
always easy for someone on the outside to be able to pick it up and it 
ultimately means your hard work will be less used as it could be. I know 
that sometimes comments can be redundant but it can also provide a 
better understanding.




Well, that's the difference between a formal library package release vs 
sharing a working proof of concept jotted down to pass time ;)

Re: #dbugfix Issue 18068 - No file names and line numbers in stack trace

[Nick Sabalausky (Abscissa) via Digitalmars-d]

Hear, hear!

It *used* to work, but doesn't anymore. I may be wrong, but in 
Linux-land at least I think may be related to PIC. Seemed to work fine 
until I installed an updated distro that has issues with non-PIC stuff.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/08/2018 10:06 PM, Timothee Cour wrote:


/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/


That shouldn't be an issue as long as you're using /++ doc comments and 
not /** ones. If it IS a problem, I'd regard it as a bug.


(If I were in change of the world, /** and /* both would be compiler 
errors, banned from all commits, and non-nesting block comments of all 
types would be prohibited from all langauges upon pain of...well, pain. 
They are spawn of satan and should never exist.)



and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html


*That* is a compelling point: Any embedded langauge (such as URL syntax) 
where +/ is valid. That, and maybe any code examples or discussions 
which, for any reason, intentially involve an unmatched end-of-comment.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 02:54 AM, Suliman wrote:
I like D, but sometimes it's look like for me too complicated. Go have a 
lot of fans even it not simple, but primitive. But some D futures make 
it very hard to learning.


Small list by me:
1. mixins
2. inout
3. too many attributes like: @safe @system @nogc etc

Which language futures by your opinion make D harder?



Auto-decode.

Dub.

And yes, things like "inout", "auto ref" or whatever, and such, strike 
me as indicative of more fundamental design flaws. (Not "flaw" in the 
sence of "mistakes" necessarily, but "flaw" in the sence of "there must 
be a better way to design these things...")


Aside from that, I don't think features inherently make D complicated, 
but I do think there are features that are designed or implemented in 
overly-complicated ways. Or *missing* features, which by their absence 
make the langauge more complicated.


The biggest, by far, that comes to my mind is dealing with types:

- At runtime: Dealing with type infos at runtime is a mess compared to 
many other langauges (especially dynamic ones).


- At compile time: The mechanisms for dealing with type info at compile 
time seem...undesigned. It's kind of a clutter of various approaches and 
haphazard quirks, and std.traits is a testament that it's not very 
cleanly designed at the language-level.


- RT vs CT: The interfaces for dealing with types are completely 100% 
different depending whether you're working with runtime or compile-time.


Other things that come to mind:

Defining input ranges (one of my biggest pet peeves):

C# knocked it out of the park ages ago with its design for a 
stackless!!! (ie no-fibers) coroutine syntax. There's no reason the same 
approach couldn't be used in D for creating input ranges. But instead, D 
forces input ranges to be defined the same way as random-access ranges, 
which is a PITA (a necessary PITA for random-access, but unnecessary for 
mere generators like input ranges), and D provides no way around that 
without introducing the overhead of fibers. Even an old version of C# 
from ten years ago puts us to complete shame here.


And Algebraic types. Yes, we technically have them, but compared to 
something like Nemerle, D claiming to have algebraic or pattern matching 
is like C claiming to support OO: 
Umm...sorta...technically...kinda...but...uhhh...no, not really.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 03:42 AM, Kagamin wrote:


Nested comments are superficial though, 


Not if you've ever commented out a block of code.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 03:37 AM, Kagamin wrote:

/**
This is a multi-line
heredoc comment allowing
// documented unittests containing nesting comments
and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
*/



/**
This is a multi-line comment.
Be sure to check the various files at extras/foo*/package.d
And also: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
*/


Kaboom. Thank you, good night.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 03:52 AM, Kagamin wrote:
On Friday, 9 February 2018 at 08:44:31 UTC, Nick Sabalausky (Abscissa) 
wrote:

On 02/09/2018 03:42 AM, Kagamin wrote:


Nested comments are superficial though,


Not if you've ever commented out a block of code.


Comment this:


'kay:

// string sedArg="s/ +/ /";

Don't see how that's remotely as common as "*/" in a C-style-comments 
codebase or commenting out something at the sub-statement level, like a 
function argument, type modifier or sub-expression, but hey, I guess if 
you have instances of that all over most functions in your codebase, 
then, yea, I guess disabling code with /+ +/ would be pretty nasty.




Comments don't respect even lexical structure of commented code that you 
expect, version(none) does.


Uhh, you do know that IS nesting, right? And that it fails in far more 
cases than /+ +/ does? And is far less widely supported by editors? And 
that it DOES nest? And also that it nests?

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 04:23 AM, Kagamin wrote:

On Friday, 9 February 2018 at 08:57:49 UTC, Timothee Cour wrote:

version(none) { FOO } doesn't work if FOO doesn't parse.


version(none)q"EOS
   FOO
EOS";


Huh? So are you *pro-* or *anti-* heredoc?

But ok, that works, unless the code contains `EOS"`. Better change it to:

version(none)q"hey-hey-hey_dudes_I-bet-NOTHINGinMYcode-is-gonna-useTHIS
   FOO
hey-hey-hey_dudes_I-bet-NOTHINGinMYcode-is-gonna-useTHIS";

At least until I go quoting this post in my code. Crap. Guess then I 
could go back to:


version(none)q"EOS
   FOO
EOS";

Or, y'know, just cut out all the noise and just do:

/+
  FOO
+/

and be done with it.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 04:09 AM, Kagamin wrote:

On Friday, 9 February 2018 at 08:54:09 UTC, Timothee Cour wrote:

* `/* */` should never be used

Not a single reason for that
Except of course for the ones that have been pointed out. And for the 
reasons you yourself brought up in favor of version(none). Not a single 
reason aside from all of those.



* properly nested `/+ +/` indeed don't cause issues
Disproved two times in this thread. Anyway nothing properly done causes 
issues.


Being that the issues with /* */ are a superset of the issues with /+ 
+/, they clearly cause fewer issues than /* */.



* unrestricted code (eg foreign code or unfinished D code commented
out) also cause issues

Superficial

Irrational

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 04:48 AM, Kagamin wrote:
On Friday, 9 February 2018 at 09:34:01 UTC, Nick Sabalausky (Abscissa) 
wrote:
Comments don't respect even lexical structure of commented code that 
you expect, version(none) does.


Uhh, you do know that IS nesting, right?


It's not a comment though, it disables code on semantic level way above 
raw character stream level, that's why it works better, also it's often 
one liner.




You seem to keep going back and forth on whether you like nesting or 
consider it a mistake. Hard to keep up.



And is far less widely supported by editors?


If you want it be bound to a shortcut, many text editors support 
invocation of external tools or text snippet expansion.


I meant syntax highlighting. I've given up on binding the 
comment/uncomment mechanism I want to key shortcuts: Dealt with too many 
editors that have too much trouble with something that should be so 
simple, wheras just plain typing works in nearly any editor. Which is 
all the more reason I don't use version(none) to disable code.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 05:31 AM, Kagamin wrote:
On Friday, 9 February 2018 at 09:42:46 UTC, Nick Sabalausky (Abscissa) 
wrote:

Huh? So are you *pro-* or *anti-* heredoc?
I personally prefer python's triple quoted strings. Elegant, simple and 
enough for most stuff. That example only shows what D has.

version(none)q{ FOO }; is likely to work for most stuff too.


/+ +/ is likely to work for most stuff, too.

I think version(none) has solidly proven that higher-level semantic 
code-disabling, while sounds like a great idea on paper, actually 
provides no practical, non-theoretical gains other than the ability to 
nest, which /+ +/ shares (along with the ability to be used in more 
scenarios and be less verbose). In real-world use, the only thing all 
that "smart" lexical processing done by version(none) accomplishes is to 
*create* new scenarios where the compiler says "Nope, disabling that 
code like that doesn't work for me. Try again."



But ok, that works, unless the code contains `EOS"`.
The very fact that I invented that just for this thread is evidence that 
it's not a rampant issue.


Ditto to code containing +/

As for the OP however, the question isn't how frequent, but what can be 
done when it does occur. All of our trouble scenarios with disabling 
blocks of code can be dealt with fairly cleanly and easily (although 
moreso with /+ +/ than version(none) IMO). But the doccomment scenarios 
brought up aren't so simple to deal with:


/**
Be sure to check the various files at extras/foo*/package.d
and also: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
*/

Unlike the "disabling code that contains the end-of-disabled-code token" 
stuff, THIS example isn't quite so trivial to deal with in a way that's 
reasonably readable from both the generated docs and from within the 
code itself.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 08:53 AM, Seb wrote:

On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:


I'm missing too the yield return and await syntax in D every time.


What's wrong with the library solution from std.concurrency?



I can't speak for await, as I left C# for D long before it was introduced.

But as far as yield return (ie, C#'s coroutines): The problem with the 
std.concurrency version is that it introduces the overhead of fibers and 
context-switching. Sometimes that's ok (network/file i/o), sometimes 
it's not (parsing). (You *can* switch to foreach/apply to do it, but 
then you lose the ability to offer a range-based interface...unless you 
re-introduce fibers.)


But the C# version, OTOH, lacks this fiber overhead entirely: 
Internally, it works the same way as C's protothreads 
, but with far nicer syntax.



- no dedicated syntax sugar for ranges;


What do you expect here?
(also it's not entirely true - foreach already supports ranges)



For input ranges (maybe even forward ranges), a stackless corountine 
approach like C#.


But even for all-out random-access, defining them is quite boiler-plate 
heavy (by D standards anyway) and could really use some sugar. Exactly 
what that sugar would be like, I don't know, but it could definitely use 
some.



- no dedicated syntax sugar for coroutines;


What syntax sugar that can't be done by a library do you expect?



Doing it without the overhead of fibers. This requires either a C-style 
preprocesser (yuck, and note string mixins aren't sufficient here) or 
lowering. (I guess if we had AST macros, maybe we could do this lowering 
in the library, but we don't.)

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 08:51 AM, Atila Neves wrote:

On Friday, 9 February 2018 at 13:34:01 UTC, tetyys wrote:


Why do people hate dub? I think it's a great package manager and build 
tool


Great package manager? Yes.

Great build tool? No.


I used to feel the same way, but honestly, at this point, I have to 
conclude dub sucks as a package manager too just *because* it's such a 
rediculous pain to opt-out of all it's weak points, like using it as a 
build tool. Particularly if you're a library author.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 10:55 AM, Russel Winder wrote:


Of course whilst people just moan nothing changes. It strikes me as
time to actively evolve Dub or replace it.



A replacement package manager[1] has been on my pet project wish list 
for awhile, but so are a ton of other things and there's not much of me 
to go around. :(


[1] Hopefully backwards compatable with dub packages as much as 
possible, though I don't know how realistic that is given dub's enormous 
complexity.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 02:01 PM, H. S. Teoh wrote:


Currently, my vibe.d project has a subdirectory containing an empty
dummy dub project, the sole purpose of which is to declare vibe.d
dependencies so that `dub build` in that subdirectory will fetch and
build vibe.d and whatever else it may depend on, and build it into a
linkable state.  Once that's done, I leave dub aside and use SCons to
actually build and link my program with the libraries built by dub.
This resulted in an instant improvement in my build times by (at least)
half, as well as free me from needless network lookups when I'm actually
coding locally and don't *need* to be upgrading dependent libraries.



I'm kind of envious of that approach, and REALLY tempted to adopt it 
myself, but there are some unfortunate probelms with it (which are 
incidentally the exact same reasons I eventually conformed and 
begrudgingly strated using dub as my main build tool, as much as I 
dislike doing so):


1. From a compiler command-line perspective, trying to incorporate 
vibe.d in a project that isn't built with dub proved in my experience to 
be a royal pain. And then upgrading to newer versions of vibe.d had a 
tendency to break it in non-obvious ways.


2. If you want your project (especially if it's a lib) to participate in 
the the dub package repository ecosystem, you pretty much have to 
support dub as a build tool. Otherwise, anyone who DOES use dub as a 
build tool will have major trouble trying to use your lib.


So even as a package manager, dub is viral. And the unfortunate 
consequence of that is that it completely divides D package ecosystem in 
two.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 01:13 PM, Russel Winder wrote:

On Fri, 2018-02-09 at 16:10 +, Seb via Digitalmars-d wrote:



[…]

Dub is not dead, it just has limited resources.


So , if the D community want Dub to work as a build system as well as a
package manager, extend the resources by corralling the grumblers and
support them into fixing code and creating pull requests.

Whilst grumbles on the email list are not turned into evolution of Dub,
the D ecosystem does progress.


[…]




Been there, done that, put enormous work into it, a TON of arguing to 
little avail, found the code architecture difficult to work with, and 
ultimately my merged PRs barely made a dent at solving my issues. Gave 
up. I'm convinced the problems with dub are fundamental and often 
philosophical.


After my experience tring to improve dub, I'm 100% convinced what we 
need is a package manager designed from the ground up to NOT be anything 
but a package manager.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 04:58 PM, rumbu wrote:


It's not about how nice is a solution, it's about how easy is for 
someone to find out about a language feature and use it. D has a library 
solution for everything that is missing from the core language instead 
to include in the language well proven patterns.  That's why is 
complicated: one must learn about fibers, ask himself why in the world 
he must use std.concurrency to obtain a list of numbers and so on. Even 
the cluttered ((){ will scare a potential learner.




I agree with this. Though I understand why it ended, I miss the days 
when D was more open to language enhancements. Library solutions are 
often possible, and better then nothing, but by necessity they're also 
frequently sub-optimal (design-wise) as well. One of the most common 
offenders is that all that ((){ *is* visual clutter compared to other 
langauges' takes on equivalent ideas.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 04:27 PM, Jonathan M Davis wrote:


I have to agree with all of this. I've never found D as a whole to be overly
complicated. C++ wins _that_ contest hands down. And I've found languages
like Java to be overly simple (e.g. one of my professors in college said
that Java didn't become a real language until they added generics, because
that actually added some complexity to it). IMHO, any language that's really
worth using isn't going to be simple.



*nod, nod*

Any task has an inherent level of complexity. That complexity can be 
either be in the language, or in the user code. Your choice.


And then there's C++ which manages to CREATE extra needless complexity 
on both sides, thereby falsely convincing entire generations of 
programmers that langauge complexity is inherently bad. No, it's 
*unnecessary* complexity that's bad.




I originally ended up finding D, because I wanted
a language with some of the safety features that Java had but without losing
all of the power of C++. C++ had too many problems that resulted in bugs,
and Java had stripped out too many features in comparison.


*Exactly* what led me to D, too. :)

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 05:20 PM, H. S. Teoh wrote:


Sadly,
these days it seems almost every other day somebody else stumbles into a
problem to which string mixins seem to be the default answer.



Really? That's not been my perception.

From what I've seen, anything that requires the user to mixin a string, 
is pretty much automatically granted the black mark of death - no one 
will touch it.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 05:49 PM, H. S. Teoh wrote:

On Fri, Feb 09, 2018 at 05:49:31PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:


Really? That's not been my perception.

 From what I've seen, anything that requires the user to mixin a
string, is pretty much automatically granted the black mark of death -
no one will touch it.


Well no, the mixin is not exposed to the user.

But I do see it used quite a lot inside libraries, specifically Phobos.
Well, "quite a lot" is not a fair statement; perhaps I should better say
"more often than it probably should be".  While a mixin-based hack
certainly gains brownie points for cleverness, in the long term it
incurs a maintainability cost, and sometimes a hefty one.  If the mixin
is of significant length, it can be a nightmare to debug / fix / extend.
(And I say that because, yes, to my shame I've also done that in my own
code.)



Ahh, I see. I wonder if the immediate "reach for string mixins" reaction 
is larely, perhaps subconciously, due to impedance of all the asymetric 
mess that dealing with types can otherwise be?

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 05:55 PM, H. S. Teoh wrote:


When I found D, I had already been chafing for *years* under the hell
that C++ development was, but could not stand the thought of moving to
Java, because it was just (1) too verbose, and (2) not powerful enough
to express what I want. (That was in the days before Java generics...
though even with generics, I doubt I would've been convinced. It's just
... not quite "there" in terms of expressive power.)



After beginning mainly with various BASICs, I started learning about 
game development which, at the time, meant C (and "C++ as a 
C-with-classes"). So I was pretty deeply into C/C++ stockholm-syndromne 
for a good long while, just 'cause I didn't know any better.


Then a crop of new (at the time) features of C++ started perplexing me, 
but I still didn't know much better. At that point, I was in college at 
the height of the Java craze, so when I inevitably tried Java (v2), it 
was eye-opening: Ruined me on much of C++ almost instantly, and 
simultaneously ruined me on Java itself due to chafing at everything it 
deliberately couldn't do. Nearly ruined me on programming until a search 
for a happy-middle language led me to a very early D (not long after 
templates IIRC, but WELL before v1.0), and I was like "Yes! *This* is 
what I wanted!" :)


Nothing else ever lived up since. (C#, and later Nemerle, came close, 
but no proverbial cigar.)

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 06:03 PM, H. S. Teoh wrote:

On Fri, Feb 09, 2018 at 05:13:51PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:

On 02/09/2018 02:01 PM, H. S. Teoh wrote:

Currently, my vibe.d project has a subdirectory containing an empty
dummy dub project, the sole purpose of which is to declare vibe.d
dependencies so that `dub build` in that subdirectory will fetch and
build vibe.d and whatever else it may depend on, and build it into a
linkable state.  Once that's done, I leave dub aside and use SCons
to actually build and link my program with the libraries built by
dub.  This resulted in an instant improvement in my build times by
(at least) half, as well as free me from needless network lookups
when I'm actually coding locally and don't *need* to be upgrading
dependent libraries.


I'm kind of envious of that approach, and REALLY tempted to adopt it
myself, but there are some unfortunate probelms with it (which are
incidentally the exact same reasons I eventually conformed and
begrudgingly strated using dub as my main build tool, as much as I
dislike doing so):

1. From a compiler command-line perspective, trying to incorporate
vibe.d in a project that isn't built with dub proved in my experience
to be a royal pain. And then upgrading to newer versions of vibe.d had
a tendency to break it in non-obvious ways.


The biggest up-front cost is to generate that initial list of import
paths and libraries needed to get the thing to build.  It's not *hard*,
but does require parsing the last few (very long) lines of dub output
(IIRC you need -v to see it).  But since that list changes from time to
time, I'm actually tempted to write a script to parse the dub output and
generate the import/library list automatically.  Then it will become
painless to build things this way. :-D


Yea, *that's* the stuff that gave me trouble. It was also the motivation 
for my "dub describe --data=..." PR, but afterwords I felt like that 
still wasn't quite as good as I wanted, and dub's internal code just 
didn't seem designed to handle that sort of thing anyway (though maybe 
that's improved now?).



Yeah, more and more, it's giving me the impression of being a walled
garden.  You either have to buy into it wholesale, or you're left out in
the cold. :-(  It wouldn't have been such a bad proposal if said walled
garden had nice things going for it... but given dub's limitations, it
feels almost like a prison sentence.


Definitly. A big part of the problem was, at least in the early days, 
the author was very clear that it expressly wasn't intended to cover the 
needs of 100% of packages, just like 99% or whatever. On top of that, 
certain design considerations which were *intended* to avoid 
fragmentation within the dub package ecosystem had the unintended 
consequence of forcing a divide between "dub packages which have the 
luxury of playing by dub's rules" and "non-dub packages which *don't* 
have that luxury". I think that's ultimately what led to the probelms we 
have with dub, and I think solving them properly requires undoing years 
fundamental dub design was that built directly upon those early 
philosophies.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/10/2018 06:03 PM, Walter Bright wrote:


There isn't any commenting scheme that won't trip you up with certain 
characters 


That's exactly the whole point of heredocs ever existing in the first 
place, its exactly the problem they're created for.


in the comments. I don't see a compelling case for adding 
another kind of comment.




That's the same exact reason most languages don't have most of the nice 
things in D, like separators for numeric literals: Because they're not 
strictly necessary. But if D had never been willing to improve the state 
of the art by not being afraid of "not stricktly necessary" features, 
very few of us would have ever had reson to come onboard with D in the 
first place. And yes, I know D's not at that point any more. And that's 
one of my biggest dissapointments with D.


Vladimir's suggestion to use %2B instead of + seems to resolve this 
adequately.


Only for URLs. "URLs" was just one example of a language that can leas 
to trouble.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 01:54 AM, Pjotr Prins wrote:
Dub is getting some flak here. This is unsurprising because it is really 
hard to write a good package manager and build system. I use a lot of 
languages and not one has a satisfactory package manager. Mostly they 
try to do too much and get in the way or they do too little and people 
complain (I prefer the second option). And when there are 100+ 
dependencies, like with Go and Node, it just becomes impossible to say 
anything about the state of the system (security, anyone?).


Package management is mostly dependency management. This I handle with 
GNU Guix (and Nix) package managers. They are great at that.


Ugh, system-level package managers. That's the #1 reason I keep hopping 
around distros, never finding one I like:


They're all completely fucking non-standard. Every fucking distro has 
it's own damn package manager (and then there's mac and win and the 
mobiles), and on top of that, most of those system managers are almost 
completely worthless *when* you need something other then "the latest 
version" let alone multiple versions (because "newer is always better" 
is software's #1 sacred cow). Those are *exactly* the reasons why 
programming langauges have NEEDED to start rolling their own damn 
package managers, because relying on the goddamn system managers for 
libs is a complete fucking non-starter.


(Hmm, Can you tell I'm not happy with system package managers? ;) )

The langauge-based package managers just simply need to keep 
"buildsystem" OUT of the package manager's scope. That's all. THAT is 
why system-level packages can be built with whatever tool: because the 
one thing the system package managers actually do get right is NOT 
rolling their own mandatory buildsystem.


One of the things on my master list of "project's I'll probably never 
get around to" is a CLI front-end to unify all this fractured 
apt/pacman/yum crap.


This also 
leaves people to choose any old build system. Inside GNU Guix the build 
system is consistent, which is really nice. I'll write a blog some time 
this year.


What you really want is to be able to discover packages (i.e., a website 
such as Dub provides), pull them into your tree (which is just a path 
and can be handled by git submodules, though I don't like those much 
either),


Agreed.

and when you distribute: add them to Guix or Nix and provide 
those packages with build system and as binary deployments to others. 


And fracture the hell out of your user-base, forcing even Linux alone to 
be treated as 100 different fucking incompatable operating systems for 
which each package only supports one or two? Ugh, god no. Spare me. Even 
dub, for all it's shortcomings at LEAST has absolutely no trouble 
treating nearly all of Linux as ONE unified target.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 06:18 AM, Russel Winder wrote:


Clearly though there is a problem with Dub as a build system for many
of it's users – or rather people who try and reject.



The problem isn't just "dub as a buildsystem". The other equally big 
problem here is that "dub as a package manager" pretty much forces "dub 
as a buildsystem" for library authors. Yes, *officially* it doesn't, but 
realistically, yea it does. And I don't see how dub can fix in any sane 
way without a major, fundamental redesign.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 06:47 AM, rikki cattermole wrote:


Dub can do everything that you have described.


No it can't. Not if you value your time and sanity.

You are fully free to run cmake if you wish before the build. Will it 
result in binaries that are decent? Probably not for most use cases.




I *have* taken exactly that approach. It caused me literally years of 
unending greif, even single-handedly turned me away from doing much in D 
for a long while, and ultimately just proved intractable. Abandoning dub 
*entirely* is actually *easier* than trying to use it *only* as a 
package manager. But if you're putting out a D lib, you can't do that 
because people expect a lib to be part of a package system (for good 
reason).

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/10/2018 07:35 AM, Timon Gehr wrote:


TL;DR: Parametrically polymorphic functions have /runtime/ type 
parameters. inout can be interpreted as a dependent function of type 
"{type y | y.among(x, const(x), immutable(x)) } delegate(type x)" and an 
inout function can be thought of as a function that takes inout as an 
argument and produces the function as the return value. This formulation 
is more powerful than what the inout syntax can capture, and this is 
what causes problems with type safety. In particular, 'inout' does not 
support proper lexical scoping.


TS;NM: https://gist.github.com/tgehr/769ac267d76b74109a195334ddae01c3 
(Some version of this was originally intended to go to the D blog, but I 
wanted to wait until inout has an obviously type safe definition. It 
also highlights other inout issues than just type unsafety and shows how 
all of them might be fixed in principle by adding polymorphism.)


---

I'll first explain parametric polymorphism, and then what the inout 
problem is.




Ahh, thanks. I'm still not *completely* 100%, but those explanations 
definitely helped a lot. Very insightful.


Side questions:

- Does this mean that fixing the issues with inout (even if done via 
some replacement of inout) would necessarily involve some runtime 
processing in at least certain cases?


- Though I realize this may contradict the definition of "parametric 
polymorphism" as you've described (and also ignoring the matter of 
virtual functions): Would it be theoretically possible to have 
parametric polymorphism that's *implemented* entirely via compile-time 
mechanisms such as templates? Or does our template system as D has it 
already represent the fundamental limits of such an approach?


Incidentally, I've felt for a long while it would've been really nice if 
D had first-class types (for both runtime and compile time). I think a 
system like that, if done right, could have gone a long way to 
alleviating all the awkwardness and asymmetries of reflection and type 
handling in D. It's also why I can understand people coming from certain 
dynamic languages who may find our metaprogramming combersome.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 08:27 PM, Walter Bright wrote:

On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote:
That's the same exact reason most languages don't have most of the 
nice things in D, like separators for numeric literals: Because 
they're not strictly necessary. But if D had never been willing to 
improve the state of the art by not being afraid of "not stricktly 
necessary" features, very few of us would have ever had reson to come 
onboard with D in the first place. And yes, I know D's not at that 
point any more. And that's one of my biggest dissapointments with D.


D is already a very large language. There's got to be a point where some 
pruning makes for a better language. Adding more and more lightweight 
features for 0.1% use cases when we neglect heavyweight features for 30% 
use cases is not where we should be shooting our arrows.


Know what is a heavyweight problem worth our while? Having dmd be able 
to directly read C .h files, so the poor user does not have to manually 
translate them.


We've already got a huge chunk of that problem solved. The Digital Mars 
C/C++ front end is now Boost licensed. It can be used. It's already been 
converted to D! The preprocessor in it is a bit dated and a bit too 
specific to Windows - but we've got Warp now!


Replace the preprocessor in dmc++ with Warp, slice off the back end, and 
make it a module that dmd can import.


Wouldn't it be nice to support:

     import stdio.h;    // Look, Ma! C headers!

There are some intractable issues, and it may be impossible to get 100% 
to "it just works", but looking past that it might be a huge win for us.


And, let's not forget working on ref counting.


Definitely all very cool stuff, no argument here. But for smaller things 
it would still be nice to hear something closer to:


"That's a reasonable point and a would be a nice touch, and it doesn't 
impact other things. Andrei and I, naturally, can't dedicate any of our 
resources to it because we have more crutial priorities on our plates, 
but we wouldn't necessarily veto a quality implementation."


instead of:

"It's not one of the big-picture items for D therefore it doesn't belong 
in D"


Though I do realize that's not likely to happen. It's not as if I'm 
saying "hey, go do this". All I'm really saying is "I like this idea, 
I'm in favor of it, and it's worth being open to." Not much more than that.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 09:01 PM, Jonathan M Davis wrote:

On Sunday, February 11, 2018 20:30:19 Nick Sabalausky  via Digitalmars-d
wrote:

The langauge-based package managers just simply need to keep
"buildsystem" OUT of the package manager's scope. That's all. THAT is
why system-level packages can be built with whatever tool: because the
one thing the system package managers actually do get right is NOT
rolling their own mandatory buildsystem.


I'm not sure that it's entirely a bad thing that dub includes a build system
in it, since it's the ease of use of its build system that is part of why
it's so worth using. It's just that its simplicity is also part of why it
doesn't work well once you get out of the basic situation of "here's a group
of D files that need to be compiled together as a library or application."


You're right, of course. I guess I wasn't clear about this, and frankly 
I even lost sight of it, but if it HAD been easy and clear to just say 
"hey, dub, I'm bringing along my own buildsystem and opting out of 
yours, ok? thanks dude" and that was that, no muss, no fuss, no 
"tricking" dub into doing what I need, I would've been fine with that.


The problem is that, in my experience, dub's assumptions about it doing 
your build for you tend to be so deeply ingrained into the way it and 
its configuration format all work, that I just don't see attempts to 
separate them out as likely work out all that well. If even at all.


Heck, at this point I feel like most of my attempts to get dub to do 
anything I have in mind have wound up being less "what is the directive 
to do that?" and more "How to I nudge, persuade, or outright trick dub 
into doing what I need?" Even if I just have a compiler switch I want to 
use, or not use, I can't *just use it*. Best case scenario, dub will 
brand my library with a big ugly warning when anyone uses it. More 
likely, I have to go translate it into dub-speak (if I'm LUCKY), or, all 
too frequently, I find myself flailing around, trying to find just the 
right combination of settings to *coax* dub's behavior.


This is a completely *typical* dub experience for me, and frankly, one 
of the more *pleasant* ones:

https://github.com/atilaneves/unit-threaded/issues/106

Did you know dub behaves *differently* if your test configuration is 
named "unittest" verses when it has a different name? I didn't. 
Principle of most surprise, I guess.


THIS is me using dub. Flawless illustration:
https://www.youtube.com/watch?v=QvcFRgJwE2k&t=0m12s


The problem with that approach though (and part of why I think dub doesn't
do that) is that if dub really is set up with the idea that you use whatever
build system you want, then you have the issue of whether the system doing
the build has all of the necessary software to do the build.  Dub doesn't
completely avoid that as-is, since you can depend on certain libraries being
on the system,

> [...]But if dub itself were designed with the idea that you could
> use cmake, scons, make, or whatever build system anyone felt like putting
> together, then there's a fairly high chance when you go to pull in a 
package

> from dub that it's going to require stuff to build that you don't have on
> your system, and since you frequently end up pulling in packages 
recursively


That's why the way it *should* work is: If your build has a dependency 
(another .d lib, a C lib, cmake, rake, scons, whatever), you make a dub 
package for it if there isn't already one. Problem solved.


But once again, dub's assumption that *everything* is a set of *.d files 
for it to complile gets in the way here too.



So, dub's solution of targeting a single build system side steps that issue
to a great extent - not entirely, but enough that it doesn't tend to be a
problem. And on some level, that's a good thing,


No, all it does it create problems and prevent workarouds, as described 
above. If a package needs, ex, scons, to build, it should be simple to 
create a dummy dub package for scons that (best case) offers to install 
scons for you, maybe even a local non-system-wide installation, or at 
the very least, tells the user, "hey, scons not detected, it's a 
dependncy of this package, so you need to install it."


After all, managing dependencies are what package managers are all 
about, and dub isn't handling it very well when it comes to tool 
dependencies (as opposed to "a library of .d files to be linked in" 
dependencies, which is really all it's designed for).




So, I don't know what the right solution is.


The right solution is to give up on dub, as it's too far down the wrong 
design road, and have a package manager that's designed from the ground 
up to be a package manager (not a simplified buildsystem that happens to 
also include dependency-handling features). As a package manager, 
*anything* the package needs, a D library, a C library, an external 
tool, even a compiler version and the package manager itself...is just 
another dependency for the

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 07:11 AM, Kagamin wrote:
On Friday, 9 February 2018 at 11:16:01 UTC, Nick Sabalausky (Abscissa) 
wrote:

On 02/09/2018 05:31 AM, Kagamin wrote:

version(none)q{ FOO }; is likely to work for most stuff too.


/+ +/ is likely to work for most stuff, too.


So do /* */


Seriously, are you trying to troll? (Not rhetorical, genuinely wondering.)

No. No, /* */ isn't likely to work with most stuff. Not in any codebase 
that actually USES /* */. Not without it being granted nestability. And 
no, I'm not talking theoretically or speculating here, this is speaking 
from years of direct experience on codebases that use /* */.

Re: Being Positive

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/12/2018 06:54 PM, Arun Chandrasekaran wrote:
Sorry if I'm hurting someone's sentiment, but is it just me who is 
seeing so much negative trend in the D forum about D itself?


1. Can't fix a problem without first identifying a problem.

2. "We're all entitled to our opinions" does NOT come with the 
qualification "...but only if it's a happy glowing positive opinion that 
sprouts rainbows and makes the rabbits and lions sing together in 
blissful harmony."


I don't 
remember seeing so much negative about Rust on rust forum and so on.


Rust has pretty much gone on record as deliberately using social 
engineering to squelch all disagreement by way of drumming out any and 
all dissenters:


https://www.youtube.com/watch?v=dIageYT0Vgg

We don't do Orwellian here.

Do 
you think it will help in reminding people not to post any negative 
things?


No. God no. Again, that's straight out of the 1984 playbook. (Or maybe 
it's more Brave New World - don't know, don't care, it's sick and 
disturbing either way.)

Re: Multiple Alis

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/12/2018 09:38 PM, Walter Bright wrote:

On 2/12/2018 4:47 PM, Ali Çehreli wrote:
Nothing serious but in case you are confused, there are at least three 
separate and awesome Alis frequenting these newsgroups. :)


We can definitely use some more awesome Alis!


I know another Ali I've tried to turn onto D, but he's pretty happy with 
Python. Oh, well.

Re: Multiple Alis

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/12/2018 11:47 PM, Jonathan M Davis wrote:

On Monday, February 12, 2018 23:33:54 Nick Sabalausky  via Digitalmars-d
wrote:

On 02/12/2018 09:38 PM, Walter Bright wrote:

On 2/12/2018 4:47 PM, Ali Çehreli wrote:

Nothing serious but in case you are confused, there are at least three
separate and awesome Alis frequenting these newsgroups. :)


We can definitely use some more awesome Alis!


I know another Ali I've tried to turn onto D, but he's pretty happy with
Python. Oh, well.


Well, we don't want to there to be _too_ many of them. If the density gets
high enough, we'll end up with a black hole. ;)



Or just a lot of confusion with names!

I'm just glad we're not all named "Smurf". (Ooooh, I think I just gave 
myself an idea for an esolang! "Just when you thought 'static' was too 
overloaded..." ;))

Re: GSOC 2018 - no slots for D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/12/2018 09:49 PM, Mike Parker wrote:

On Tuesday, 13 February 2018 at 02:38:28 UTC, psychoticRabbit wrote:



In any case, I think it would be great if the foundation setup a 
process whereby everyday people can contribute funds to projects.


Stay tuned.


Oh? I am anxiously not touching that dial...

Re: OT: Photo of a single atom by David Nadlinger wins top prize

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/13/2018 08:11 PM, David Nadlinger wrote:

On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote:

David (aka klickverbot) is a longtime D contributor […]


… who is slightly surprised at the amount of media interest this has 
attracted. ;)


  — David


Heh, dude, you photographed an atom! "Shoulders of giants" or not, that 
is *seriously* cool. How many people can say they did that? :)


Not only that, it's a damn cool-looking image overall, too!

Re: OT: Photo of a single atom by David Nadlinger wins top prize

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/14/2018 03:44 AM, Nick Sabalausky (Abscissa) wrote:

On 02/13/2018 08:11 PM, David Nadlinger wrote:

On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote:

David (aka klickverbot) is a longtime D contributor […]


… who is slightly surprised at the amount of media interest this has 
attracted. ;)


  — David


Heh, dude, you photographed an atom! "Shoulders of giants" or not, that 
is *seriously* cool. How many people can say they did that? :)


Not only that, it's a damn cool-looking image overall, too!


I'd be fascinated to read more about how this was done, and the 
"back-of-the-envelope calculation showed the numbers to be on my side".

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/18/2018 08:34 PM, Manu wrote:


Apparently gmail has a new trick... reply to thread == reply-all.
That's never happened before.
Can the forum software strip out the HTML if it detects it in the
post? I'm astonished this isn't a bigger problem; surely gmail is the
worlds most popular mail client, by like, 50x...?


Well, it's also the world's most inconsistant and 
statndards-disregarding. We're talking 1990's MS-level behavior here. 
It's *always* causing trouble for something or another.

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/19/2018 03:52 AM, Manu wrote:

On 18 Feb. 2018 10:25 pm, "Walter Bright via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:

On 2/18/2018 7:52 PM, Nick Sabalausky (Abscissa) wrote:


Well, it's also the world's most inconsistant and statndards-disregarding.
We're talking 1990's MS-level behavior here. It's *always* causing trouble
for something or another.



And the great thing about NNTP is that the user gets to choose the client.
Not the server. If you don't like the way your client behaves, use another
one.


Except in this case it's you that doesn't like the way my mail client
behaves.



Because your mail client is BROKEN.


I don't want to install software, I'll continue using Gmail, undoubtedly
the world's most popular mail client...


Then petition *Google* to fix their shitty fucking software. You've 
already been told it has fuck all to do with NNTP.


Seriously, why the fuck would ANYONE think that by relying on Google 
software they're somehow NOT being dragged along by the ear on Google's 
every whim and misstep. Christ, we've already been through all this SAME 
EXACT shit in the 90's with Microsoft, let's try actually *learning* 
from it and move on.

Re: NNTP client configuration

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/21/2018 01:21 AM, Manu wrote:

Incidentally... I was kinda hoping it'd be back in the states this
year, since I'm actually in the states now... but I'm still holding
out to see if I can get to Germany.


I've had fingers crossed for another San Fransico DConf, too. I'm at the 
other end of the country, but I have some relatives in that city I could 
stay with. It'd provide a perfect excuse, too!

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/23/2018 08:47 AM, biocyberman wrote:


 From my experience with forum platforms like vBulletin, phpBB, Invision 
Power, and even interfaces of Google group, and Github Issues, I still 
find it very difficult to understand the logics of using dlang's forum. 


I really don't see what there is to not understand, for the most part. 
The only real tricky point, really, is just that it's a threaded format 
and the web interface (unfortunately, and mistakenly IMO) insists on 
defaulting to an unthreaded view of an inherently threaded system.


Aside from that though, it's just like any other email or message board 
system:


1. Read the posts in the threads (topics).

2. Hit "reply" on a post.

3. Type your reply.

4. Send.

That's all there is to it: It's nothing fundamentally different from 
anything else that's ever existed (except maybe Google Wave, but, 
well...umm, yea...that was that ;) )


So, how do you guys 
overcome these problems:


=
1. No post editting. After clicking send, and found out that you made 
mistakes in the post, but you can't edit the post anymore.


1. Proofread *before* sending. (Just like any letter or email.)

2. Follow-up post if there's any important corrections (hardly a big deal)

3. Don't be a perfectionist (it's just a forum, not a doctorial thesis.)

2. Old-day quoting presentation. I always feel reluctant to read texts 
that stays after two levels of quotes, like this:

  >First post quoted
  >>Second post quoted
  >>>Third post quoted
  >>Second post quoted




If you mean the angle-bracket syntax: What's the big deal? Surely not 
just that it *isn't* something brand-new, I would hope?


If you mean reading *all* the quoted text: Don't bother. Just skim 
enough to know what it is that's being replied to, then move on the 
actual message.



3. No Rich-text format support. No minimal bold/italic support. Some 
tools to emphasize important points will make it easier to let the 
readers know what the posters want to say.


Anything beyond *doing this* for emphasis is just wasting your time 
futzing with trivialities that don't matter. You probably have better 
things to be doing. It's just a forum, not a journal article.


4.  No code formatting. Same feeling here. I am reluctant to post more 
than 5 lines of code.


Just mark it like anyone else does:

---
code here
---

Or post a link.

5. No image support. In many cases a screenshots will be helpful to 
communicate problems.


Just post a link.

6. Last but not least, a trendy feature: tags, keywords for threads so 
we can locate related threads easily.


That's would be like adding tags to your emails. Waste of bother. This 
is for discussions, it's not really meant as a database.


If I may say it honestly, and despite the useful 'save unsent draft' 
feature, the forum is by far the most user-unfriendly forum platform 
ever (by appearance).


You don't like its appearance? I think the web interface is WAY 
nicer-looking than any phpbb forum or the latest versions of the popular 
webmail clients, but I guess to each his own. But that's one of the nice 
things about it being a newsgroup instead of a web message board: You 
can use whatever interface you want. Personally, I use thunderbird (I 
even get to use a dark theme that way.)


Aside from maybe code formatting, these are all very trivial, 
unimportant features, and I strongly beleive the second half of the 
following is appropriate here (ie, the "Fire and Motion" aka "Covering 
Fire" stuff):

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/23/2018 11:24 PM, psychoticRabbit wrote:


(in the 90's companies made their name for not being Microsoft. As 
Microsoft wanted to dominate the world. I wonder if that same situation 
exists now, except, now its not being Google).


Oh, it DEFINITELY does. The only difference is that instead of a 
monopoly, it's now an oligopoly of Google/Facebook/Apple each trying to 
pull the same shit MS was famous for running in the 90's, in each of 
their respective domains.

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/23/2018 10:18 AM, Steven Schveighoffer wrote:


TB has these, though I prefer plain text. It supports a crude form of 
markdown, so *bold*, _underline_ all are enhanced by TB. Emoticons turn 
into graphics too ;)




I turned those off in my TB installation. I hate having my software 
messing with my content.

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/23/2018 11:57 AM, Kagamin wrote:


Bold and italic is a wrong way to format text because it's visual 
formatting that lacks semantic.


Bleh. That's actually my #1 favortie example for how the web world has 
gone completely, utterly insane.


For one thing, bold and italic have *always* carried a semantic meaning 
of "emplasis". That's the whole fucking reason anyone *ever* used bold 
or italic in the first place. (Well, that, and to turn late-90's emails 
and web pages into eye-cancer - which is exactly what happends when you 
treat "bold" and "italic" as instances of "style" instead of "emphasis").


Secondly, when has anybody EVER come up with a legitimate, practical 
application for programatically determining the emphasised portions of a 
sentence? Not even the content-thief sites can make any use out of THAT 
psuedo-"semantic web" clue.

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/24/2018 08:31 PM, psychoticRabbit wrote:


NNTP is not the future..it's the past.


Uhh, so? This isn't fasion. Merit matters, not fad-compliance.

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/28/2018 12:48 PM, Vang Le wrote:
I don't mean to go into the good vs bad direction. What I was saying is 
that it is hard to get comfortable and use the forum the most 
effective/convenient ways. The forum should not be a technical barrier 
for members to communicate conveniently.


With that said, I am glad that I put up the questions and got a bunch of 
useful tips to use the forums. FYI, the most useful one is to install a 
NNTP client and use the 'forum' the way it is, a NNTP server with a web 
interface.


Speaking of which, and I apologize if this is inappropriate context, but 
has anyone found a good Android NNTP reader for this? I wasn't really 
able to find much when I looked, so I just use DFeed when I'm on the go, 
which is great (fantastic, really!) as far as web interfaces go, but a 
proper native reader would be really nice if anyone has any good tips!

Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

(I'm posting this here instead of D.learn because it isn't really a "How 
to do XYZ in D?", but rather to invite discussion on high-level 
solutions to a problem.)


Here's a common problem:

1. A project (ex, some library) uses travis-ci (and/or other) to ensure 
compatibility with a range of compiler versions. The travis 
configuration file includes a manually-curated list of compiler versions.


2. CI tests are triggered by new commits/merges/PRs in the project.

3. New compiler versions are released.

4. Compiler updates may or may not trigger new tests with the new 
compiler, depending on the project.


5. Project maintainer must manually update the list of compilers. (And 
this isn't one task, but rather O(n), where n=number of projects the 
given person is maintaining).


The challenge: What is the best way to automate this? (ie, #4 and #5)

We do already have certain approaches to at least certain facets of the 
problem (ex: some third party libs are included in DMD's CI testing), 
but there are still limitations and downsides (ex: D tester has limited 
resources, and it doesn't address manually updating the travis config's 
list of compilers or notifying authors their project's compiler list 
needs updated.)


Another sample point of discussion: One possible approach is to have a 
bot generate PRs to update project's compiler lists. But that leads to 
other questions: How/when is the bot triggered? On what machine does it 
run? Is there an existing jumping-off point for creating such a bot? How 
does it approach the task of modifying `.travis.yml` (how smart/dumb 
does it need to be)? Any security concerns to be mindful of? Etc.

Re: Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/02/2018 02:24 AM, Jacob Carlborg wrote:


Travis CI allows you to specify a D compiler in the following ways:

*  - the latest version of the specified compiler
* -beta - the latest beta
* -nightly - the nightly build
* - - a specific version of the compiler

Where  is "dmd", "ldc" or "gdc".

Combine the above with a scheduled build that builds once every day 
you're pretty well covered. For an example, see the Travis CI 
configuration for DStep [1]. I'm building the latest version of DMD and 
LDC on Linux and macOS, but the betas and nightly are only built on 
Linux, due the the limited resources of macOS builds on Travis CI.


[1] https://github.com/jacob-carlborg/dstep/blob/master/.travis.yml



Certainly a possible approach, but has downsides:

- Maybe there's a simple setting I've overlooked, but when a build job 
fails on travis, the author does not get proactively notified. The 
author only finds out next time they go into travis. (I've been 
surprised many times to discover failed builds that had occured several 
days ago, or more.)


- A project author will still need to: 1. Actively notice new compiler 
releases and 2. Manually update the .travis.yml files for each of their 
projects. Certainly there's room for more automation here.


- Except when "nightly" is desired, this leads to many unnecessary 
redundant builds/tests, especially across all the various D projects. 
(Though I don't know how much that would matter on travis. Maybe it'd be 
a drop in their bucket.)

Re: Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/03/2018 10:22 AM, Jacob Carlborg wrote:

On 2018-03-03 07:39, Nick Sabalausky (Abscissa) wrote:
- Maybe there's a simple setting I've overlooked, but when a build job 
fails on travis, the author does not get proactively notified. The 
author only finds out next time they go into travis. (I've been 
surprised many times to discover failed builds that had occured 
several days ago, or more.)


You should get an email notification about failed builds [1] [2],


Weird. Never worked for me. Will have to check into that.

- A project author will still need to: 1. Actively notice new compiler 
releases and 2. Manually update the .travis.yml files for each of 
their projects. Certainly there's room for more automation here.


No. If you specify "dmd" (without any version) in the list of compilers 
[5], it will build the latest version. For example, this build [3], 
which ran 23 hours ago uses DMD 2.078.3, while this one [4], 29 days 
ago, uses 2.078.2. As you can see on the commit in Travis CI, it's the 
same commit.




No. That is only sufficient *temporarily*, that is, until the next time 
the label "dmd" is updated to another new release once again. At *some* 
point, .travis.yml will still need to be manually updated...


Scenario 1-2-3:

1. Suppose a library supports DMD v2.071.0 and up. Because of this, 
.travis.yml includes:


  - dmd  # Ie, dmd-2.079.0, ATM
  - dmd-2.079.0
  - dmd-2.078.2
  - dmd-2.078.1
  - dmd-2.078.0
  - dmd-2.077.1
  - dmd-2.077.0

Summary: CI now tests 2.076.1 through 2.079.0.

2. Release of DMD 2.080.0 occurs. "dmd" now points to 2.080.0 (and 
forget reproducibility: if 2.080.0 contains an unexpected regression 
then using travis's "Restart Job" on the "dmd" job will break overall 
reproducibility.)


Summary: CI now tests 2.076.1 through 2.080.0.

So far so good, right? Until...

3. Release of DMD 2.081.0 occurs. "dmd" now points to 2.081.0. Unless 
.travis.yml has been manually updated, it still contains:


  - dmd  # Ie, dmd-2.081.0, now
  # WTF?!?! dmd-2.080.0 is no longer being tested
  - dmd-2.079.0
  - dmd-2.078.2
  - dmd-2.078.1
  - dmd-2.078.0
  - dmd-2.077.1
  - dmd-2.077.0

Summary: CI *stops* testing dmd-2.080.0.

FAIL.

Re: Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/04/2018 02:05 AM, Nick Sabalausky (Abscissa) wrote:


No. That is only sufficient *temporarily*, that is, until the next time 
the label "dmd" is updated to another new release once again. At *some* 
point, .travis.yml will still need to be manually updated...


Scenario 1-2-3:

1. Suppose a library supports DMD v2.071.0 and up. Because of this, 
.travis.yml includes:


   - dmd  # Ie, dmd-2.079.0, ATM
   - dmd-2.079.0
   - dmd-2.078.2
   - dmd-2.078.1
   - dmd-2.078.0
   - dmd-2.077.1
   - dmd-2.077.0

Summary: CI now tests 2.076.1 through 2.079.0.

2. Release of DMD 2.080.0 occurs. "dmd" now points to 2.080.0 (and 
forget reproducibility: if 2.080.0 contains an unexpected regression 
then using travis's "Restart Job" on the "dmd" job will break overall 
reproducibility.)


Summary: CI now tests 2.076.1 through 2.080.0.

So far so good, right? Until...

3. Release of DMD 2.081.0 occurs. "dmd" now points to 2.081.0. Unless 
.travis.yml has been manually updated, it still contains:


   - dmd  # Ie, dmd-2.081.0, now
   # WTF?!?! dmd-2.080.0 is no longer being tested
   - dmd-2.079.0
   - dmd-2.078.2
   - dmd-2.078.1
   - dmd-2.078.0
   - dmd-2.077.1
   - dmd-2.077.0

Summary: CI *stops* testing dmd-2.080.0.

FAIL.


Additionally, what happens when said project above doesn't receive 
commits/merges between steps 1 and 3 (ie, during the time period where 
2.080.0 is the latest release)? Any incompatibilities with 2.080.0 go 
completely unnoticed because CI never ends up testing with 2.080.0.


The "dmd" label does NOT solve the problem.

Re: Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/04/2018 02:23 AM, Nick Sabalausky (Abscissa) wrote:


Oops, proofread failures. Naturally, I meant this (fixes emphasized):

-

1. Suppose a library supports ***DMD v2.077.0*** and up. Because of 
this, .travis.yml includes:


   - dmd  # Ie, dmd-2.079.0, ATM
   - dmd-2.079.0
   - dmd-2.078.2
   - dmd-2.078.1
   - dmd-2.078.0
   - dmd-2.077.1
   - dmd-2.077.0

Summary: CI now tests ***2.077.1*** through 2.079.0.


Summary: CI now tests ***2.077.0*** through 2.079.0.

(Argh, maybe it's bedtime... ;))

Re: Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/04/2018 02:05 AM, Nick Sabalausky (Abscissa) wrote:


1. Suppose a library supports DMD v2.071.0 and up. Because of this, 
.travis.yml includes:


   - dmd  # Ie, dmd-2.079.0, ATM
   - dmd-2.079.0
   - dmd-2.078.2
   - dmd-2.078.1
   - dmd-2.078.0
   - dmd-2.077.1
   - dmd-2.077.0

Summary: CI now tests 2.076.1 through 2.079.0.



Oops, proofread failures. Naturally, I meant this (fixes emphasized):

-

1. Suppose a library supports ***DMD v2.077.0*** and up. Because of 
this, .travis.yml includes:


  - dmd  # Ie, dmd-2.079.0, ATM
  - dmd-2.079.0
  - dmd-2.078.2
  - dmd-2.078.1
  - dmd-2.078.0
  - dmd-2.077.1
  - dmd-2.077.0

Summary: CI now tests ***2.077.1*** through 2.079.0.

Re: Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/04/2018 02:05 AM, Nick Sabalausky (Abscissa) wrote:

On 03/03/2018 10:22 AM, Jacob Carlborg wrote:


You should get an email notification about failed builds [1] [2],


Weird. Never worked for me. Will have to check into that.



Ahh, it looks like travis disregards the github email address (perhaps 
it can't access it, or indirectly tell github to email me?), and the 
only way to receive travis email notifications is to expose the desired 
email address to the general public via either .travis.yml or the git 
commit author.


(Un)fortunately, I have a far more effective, reliable method of 
filtering spam than the "state of the art" gmail heuristics: I run a 
mail server, create domain-specific email addresses, and delete any 
accounts that get spammed (knowing full well who it was that leaked my 
email). I was never stupid enough to configure git with a legitimate 
email address I actually check...I have better things to do than fight 
spam and regularly check some "spam folder".


Travis (not to mention Git itself) doesn't appear to support the 
post-1980 reality of email, ie, "Publicly-posted addressed WILL be 
spammed, hard"), thus, even though I get GitHub notifications just fine, 
I haven't been getting notifications from travis even though its linked 
to my github account.

Re: Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/05/2018 02:42 AM, Nick Sabalausky (Abscissa) wrote:

On 03/04/2018 02:05 AM, Nick Sabalausky (Abscissa) wrote:

On 03/03/2018 10:22 AM, Jacob Carlborg wrote:


You should get an email notification about failed builds [1] [2],


Weird. Never worked for me. Will have to check into that.



Ahh, it looks like travis disregards the github email address (perhaps 
it can't access it, or indirectly tell github to email me?), and the 
only way to receive travis email notifications is to expose the desired 
email address to the general public via either .travis.yml or the git 
commit author.


(Un)fortunately, I have a far more effective, reliable method of 
filtering spam than the "state of the art" gmail heuristics: I run a 
mail server, create domain-specific email addresses, and delete any 
accounts that get spammed (knowing full well who it was that leaked my 
email). I was never stupid enough to configure git with a legitimate 
email address I actually check...I have better things to do than fight 
spam and regularly check some "spam folder".


Travis (not to mention Git itself) doesn't appear to support the 
post-1980 reality of email, ie, "Publicly-posted addressed WILL be 
spammed, hard"), thus, even though I get GitHub notifications just fine, 
I haven't been getting notifications from travis even though its linked 
to my github account.





Hooray "web 2.0" :/

Re: Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/04/2018 03:42 AM, Jacob Carlborg wrote:


Aha, you mean like that. Seems a bit difficult to fix. Perhaps 
specifying a range of compiler versions would do?


Yea, there's really no two ways around it: Ultimately, each new compiler 
release will need to get added to .travis.yml (or any other CI's 
equivalent) either sooner or later. (Unless the project eschews anything 
beyond "latest versions ONLY", but that comes with its own downsides, 
especially for libraries.)


Luckily, this is definitely automatable, at least as far as 
auto-submitted PRs, if nothing else. The devil is just in the details.

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/18/2018 11:43 PM, Norm wrote:


We don't want to be treated special. We don't want to give back. This is 
the *entire* point.




An attitude like that and there's any wonder it didn't work out? Sheesh.

This is the thing about OSS: The business willing to give back (and 
there are many such businesses) are the ones that reap benefits. The 
companies that wilfully cling to zero-sum bullshit are on their own, by 
their own choice, and open themselves to allowing their competitors to 
take the advantage for themselves. That is the way of the world, that is 
the way of reality.


D can't be held responsible for self-defeating zero-sum, "us vs them" 
mentalities. Sheesh.

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/18/2018 11:28 PM, Manu wrote:


I know these feels so well.
People take their one experience, and that's the truth on the matter.
The sad part is, it's actually a massive missed opportunity! If these
colleagues posted here, and instead were greeted by recognition of
their issue, and provided a satisfactory work-around, or even a prompt
fix, they would have taken a COMPLETELY different message away from
their interaction; it would be "this D comunity is so awesome, I can
have confidence that our issues will be handled in a personalised
way!", and there's very strong value in that for a business...



Well *of course* they would love any group that does custom work for 
them for free! ;)


But I think, therein lies one of the big shortcomings we have in 
promoting D:


Around here, we complain and whine and...erm...b***h (don't need another 
of Walter's secret PC-enforment emails) about "this is a volunteer 
project, we're not getting paid for this, blah blah blah"...


*AND YET*: We don't have NO crystal clear, obvious way for people to 
actually say "I need this, SO HERE, TAKE MY MONEY IN EXCHANGE FOR IT!!!" 
(Sure, we know that Walter's been open to stuff like that, but do 
prospective D users know that?)


That's what we need. Solves everyone's problems. Improves D. Gets us 
around the "not backed by a company" problems. Brings businesses into D 
instead of turning them away at the gates. I mean, shoot: *We* want 
users, we want money, we want to get paid to work on/with D. *They* have 
money and want things done. Let's get together, right?!! Everybody happy!

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/22/2018 09:44 PM, Jonathan M Davis wrote:

On Thursday, March 22, 2018 21:25:11 Nick Sabalausky  via Digitalmars-d
wrote:

On 03/18/2018 11:43 PM, Norm wrote:

We don't want to be treated special. We don't want to give back. This is
the *entire* point.


An attitude like that and there's any wonder it didn't work out? Sheesh.

This is the thing about OSS: The business willing to give back (and
there are many such businesses) are the ones that reap benefits. The
companies that wilfully cling to zero-sum bullshit are on their own, by
their own choice, and open themselves to allowing their competitors to
take the advantage for themselves. That is the way of the world, that is
the way of reality.

D can't be held responsible for self-defeating zero-sum, "us vs them"
mentalities. Sheesh.


While I do think that there's a lot to be said for companies who are willing
to use open source and give back to the community in the process, there are
plenty of people (and not just companies) who just want a tool to get things
done. And I don't think that there's anything wrong with that. 


I agree. The problem is with saying "I want X, and I'm not willing to 
offer anything for it." And then wondering why it doesn't work out.

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/22/2018 09:43 PM, Nick Sabalausky (Abscissa) wrote:

On 03/18/2018 11:28 PM, Manu wrote:


I know these feels so well.
People take their one experience, and that's the truth on the matter.
The sad part is, it's actually a massive missed opportunity! If these
colleagues posted here, and instead were greeted by recognition of
their issue, and provided a satisfactory work-around, or even a prompt
fix, they would have taken a COMPLETELY different message away from
their interaction; it would be "this D comunity is so awesome, I can
have confidence that our issues will be handled in a personalised
way!", and there's very strong value in that for a business...



Well *of course* they would love any group that does custom work for 
them for free! ;)


But I think, therein lies one of the big shortcomings we have in 
promoting D:


Around here, we complain and whine and...erm...b***h (don't need another 
of Walter's secret PC-enforment emails) about "this is a volunteer 
project, we're not getting paid for this, blah blah blah"...


*AND YET*: We don't have NO crystal clear, obvious way for people to 
actually say "I need this, SO HERE, TAKE MY MONEY IN EXCHANGE FOR IT!!!" 
(Sure, we know that Walter's been open to stuff like that, but do 
prospective D users know that?)


That's what we need. Solves everyone's problems. Improves D. Gets us 
around the "not backed by a company" problems. Brings businesses into D 
instead of turning them away at the gates. I mean, shoot: *We* want 
users, we want money, we want to get paid to work on/with D. *They* have 
money and want things done. Let's get together, right?!! Everybody happy!


Shoot, *just* noticed now this new opencollective stuff *does* offer that!

That needs to go straight up on the dlang front page, stat!!!

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/23/2018 03:35 AM, Jordan Wilson wrote:


I suppose it's about finding that balance between growing the D user 
base, and trying to get said user base to give back.


Say I was offered a car with no windscreen...I have 3 responses:
1. Cool! I'll put in a windscreen myself, as this car has a great engine.
2. Thanks. This car does a great job getting from a to b, pity about all 
these bugs flying in my face though. Wish I knew more about windscreens.

3. No thank you, I'll just stick with the train. Nice spinner rims, btw.

Regarding D, I fall into (2), but sometimes I wonder if catching the 
train would be easier...


I used to be (2) with D, but that was something like ten years ago. At 
this point, it's more like a brand new sedan, well-built, reasonably 
priced, great mileage, a few minor things I've tweaked or done 
differently if I had a magic wand, but otherwise a car that leaves me 
wondering "Why are people whining about the lack of spinner support and 
iPhone whiz-bangery? Big effing deal."


That's NOT a comment on Manu's OP here, of course. Something like "Why 
is x^^y *still* not CTFE-able???" is the kind of thing I completely 
sympathize with. Can't imagine that sort of thing being a blocker 
though, especially if I were still doing a lot of work in C or C++.

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/23/2018 02:09 PM, Manu wrote:

If I have to continue to generate
tables offline and paste big tables of data in the source code (and
then re-generate them manually when I change something); then
situation is identical to C++, therefore, stick with C++.\



WAT?

When in the world would anyone ever need to do any of that? And I mean 
*regardless* of language? What kind of build system are you even using, 
punch cards and sneakernet?


Just run your custom generator tool from your buildscript (it's a 
trivial one-liner), and have it generate a full-fledged .d file ready 
for import (or a data file which is then string-imported by your main 
program).


It's quick and trivial, I've been doing it for a project written in Haxe 
(and just converted it to C# the other day as part of a big Flash -> 
Unity3D conversion) and it works quick-and-easy even there (of course, 
the Haxe/C#-generating tool is written in D, the tool was just easier to 
write that way).


DMD itself used to do that too when it was still C-based. Nobody ever 
needed to manually re-regenerate it (it was automatically invoked when 
necessary by the makefile), and *certainly* nobody ever needed to go 
copy-pasting any generated data.

Re: rvalues -> ref (yup... again!)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/23/2018 07:46 PM, Jonathan M Davis wrote:

On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d wrote:

It never made any sense to me that there could be any problem
with the compiler automatically creating a temporary hidden
lvalue so a ref could be taken. If there IS any problem, I can
only imagine it would be symptomatic of a different, larger
problem.


It can be a serious API problem if you can't look at ref and know that the
intention is that the original argument's value will be used and then
mutated (whereas with out, it will be mutated, but the original value won't
be used).


???. That's equally true when an lvalue is passed in.


However, that could be solved by having a different attribute indicate that
the idea is that the compiler will accept rvalues and create temporaries for
them if they're passed instead of an lvalue. Then, the situation is clear.


Why require the callee's author to add boilerplate? Just do it for all 
ref params that are given an rvalue.



As for rvalue references in general, I can never remember what exactly the
problem is. IIRC, part of it relates to the fact that it makes it impossible
for the compiler to know whether it's dealing with an actual lvalue or not,


As long as the compiler takes the advocated "automatic hidden temporary" 
approach, then it *is* an actual lvalue. We're talking nothing more than 
sugar here. Sugar for what we're already forced to do manually. There 
*cannot* be a technical problem here that isn't *already* a problem with 
the author manually creating a temp var.

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/24/2018 09:53 AM, H. S. Teoh wrote:

On Sat, Mar 24, 2018 at 01:42:56AM -0700, Walter Bright via Digitalmars-d wrote:
[...]

I can't recall ever seeing anyone else use this technique (other than
Nick!), but it works and isn't that bad.


It's not all that uncommon.  I've worked with projects (and still do)
where code is generated by a tool at build time, and then #include'd by
other source code.  Any project that uses lex/yacc (or their clones
flex/bison) does this. One of my own recent projects involved a clever
(IMO) trick of using the C preprocessor on a C header file (truetype, to
be precise) to generate D code that then gets compiled by a D compiler,
by suitably (re)defining certain macros.



And the excellent, classic book "The Pragmatic Programmer" promoted it 
as a technique worth having in one's toolbelt (That book, along with 
"Writing Solid Code", left a big lasting impact on me.)


IIRC, in the earlier days of Gameboy Advance homebrew (back when I still 
had time for that sort of thing!) it was also the first common technique 
for including images/audio in a ROM image. (Until other tools were 
developed to handle the task better.)

Re: CTFE ^^ (pow)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/24/2018 12:37 PM, Manu wrote:


I understand table generation, that is the standard approach. It's


Huh? Then I guess I don't understand why you implied that the 
alternative to CTFE was manually regenerating and copy-pasting tables:


>> On 3/23/2018 11:09 AM, Manu wrote:
>>> Like, in this particular project, being able to generate all tables at
>>> compile time is the thing that distinguishes the D code from the C++
>>> code; it's the *whole point*... If I have to continue to generate
>>> tables offline and paste big tables of data in the source code (and
>>> then re-generate them manually when I change something);



I'm not sure why I seem to have to defend the idea that it's a *great
thing* that D (in theory; according to the advertising brochure) does
away with these requirements.


No need to defend it, we're all sold on it already. To clarify: I wasn't 
saying "no need for CTFE", I was saying: "If you *have* to work around 
an unfortunate CTFE limitation, like the missing x^^y, then it's not 
hard to do so *without* all that manual work you suggested".



> made awkward by the fact that build systems are hard,

The decent ones aren't. (And if you happen to be stuck with MSBuild, 
well, then my sincere condolences. I periodically use Unity3D and I wish 
s much it wasn't tied to MSBuild...or CLR for that matter, but I 
digress...frequently ;))


Frankly, if a buildsystem makes doing XYZ (ex: "executing a CLI command 
upon build") harder than it would be in a shellscript, then the given 
buildsystem sucks and you may as well replace it with a plain old script.



> and a user of a lib with such build requirement inherits that baggage
> into their project.

Meh, its about half an ounce of baggage for the user. (But again, yes, 
CTFE is still better...at least when it doesn't slow down their build 
too much). And its zero-baggage if the generated files aren't dependent 
on the user's code, though I see now (below) that's not the case for 
your project.




It just occurred to me too that it's not even that simple. The
instantiation sites (which are in user code) dictate what tables need
to be emit. It's not feasible to generate all possible tables...
there's a combinatorial explosion of possible inputs. I instantiate
only what tables the user needs on demand. It's impossible to
pre-generate 'all' tables; there's no such quantity.


I guess that does complicate it somewhat (and again, to be clear, being 
able to just do CTFE would obviously be far better than this) but FWIW, 
that still might not be difficult to overcome, depending on the exact 
nature of the problem: Whatever inputs are necessary for table 
generation, let the user specify them as cmdline args to your generator 
tool. Again, not ideal, but a perfectly feasible workaround in a pinch, 
and doesn't require abandoning all the *other* benefits of D.

Re: rvalues -> ref (yup... again!)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/24/2018 03:03 AM, Jonathan M Davis wrote:

On Saturday, March 24, 2018 01:37:10 Nick Sabalausky  via Digitalmars-d
wrote:

Why require the callee's author to add boilerplate? Just do it for all
ref params that are given an rvalue.


Because if the point of the function accepting its argument by ref is
because it's going to mutate the argument, then it makes no sense for it to
accept rvalues, 


1. That *isn't* always the core point of a function which takes a 
non-const ref argument.


2. It's the caller who decides whether or not the ref-result is needed, 
not the callee.


3. The frequent recurring complaints about no rvalue references are a 
testament that this is too common a use-case for the current "manually 
insert temporaries" workaround to be satisfactory.


4. If the whole point of disallowing rvalue references is to prevent 
accidents due to callers not realizing a param is being passed by ref 
(as it sounds like you're suggesting), then it's nothing but a broken 
half-solution, because it fails to provide that safety (and thus fails 
its own charter) when that same caller, once again not realizing a param 
is ref, passes an *lvalue* without expecting it to change. *If* the 
problem we want to solve here really is making sure a caller knows when 
a param is ref, we've failed, and the only way to actually accomplish it 
is the C# approach: Require callers to mark their ref args with "ref" 
and raise an error when they don't.

Re: rvalues -> ref (yup... again!)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/23/2018 09:06 PM, Jonathan M Davis wrote:


My biggest concern in all of this is that I don't want to see ref start
accepting rvalues as has been occasionally discussed. It needs to be clear
when a function is accept an argument by ref because it's going to mutate
the object and when it's accepting by ref because it wants to avoid a copy.



That ship sailed ages ago: It's already unclear. If we want to fix that, 
we can fix it, but blocking rvalue ref does nothing for that cause.

Re: rvalues -> ref (yup... again!)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/24/2018 12:03 AM, Manu wrote:

Why aim for "it often works", when we want "it always works"? Forcing const
upon people who want to pass rvalues by reference is just not good enough.
It is bad language design.


I think you need to re-read the whole thread, and understand what
we're even talking about.
Nobody wants to pass rvalues by mutable-ref... 


I do. The ban serves no useful purpose (at least not any purpose that D 
doesn't *already* fail at - like knowing at the callsite whether a param 
is intended to be mutated). And it would permit the "avoid a copy" 
benefits in a completely orthogonal way - *without* relying on the param 
fitting D's transitive const requirements.

Re: Favorite GUI library?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/24/2018 08:44 AM, Uknown wrote:
Even on linux, back in the day, GTK apps looked out of place on 
QT systems and vice versa.


That's still true even now, albeit maybe not to the same extent (that 
is, until you try to save/open a file...).


We REALLY need a lib that provides the GTK API/ABI and converts to Qt. 
(Might be a nightmare to maintain though, the way GTK loves 
changing/removing things on a whim...)

Re: Favorite GUI library?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/23/2018 11:46 PM, Nerve wrote:
The user DOES NOT CARE how easy it is 
for you to maintain your codebase.


That needs to be painted on every wall, and etched into every computer, 
and tattooed onto every forehead, at every developer workspace in the world.

Re: Favorite GUI library?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/24/2018 08:29 AM, Adam D. Ruppe wrote:
like I did a wysiwyg editor for work that is a redistributable 
server exe they run locally, but the ui is in a browser. You get better 
results on firefox than chrome due to a bunch of little things.)


Yea, Chrome is kind of notorious for random breakages compared to other 
browsers. Google seems to still be a fan of that "move fast to break 
everything" fad that (unsurprisingly) has been biting Facebook in the ass.


Same with deprecation. Web stuff breaks somewhat frequently, and new 
features requiring bleeding edge won't always be there.


Honestly, I find that if my web sites exhibit browser-compatibility 
issues, it means I've over-engineered something. Even in Chrome, the 
HTML/CSS basics are pretty stable. It's only when you start getting into 
the "newer is better" bleeding edge "this week's version of webdev best 
practices" stuff, and toolkits and the like, that things start falling 
apart.

Re: Favorite GUI library?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/24/2018 10:30 AM, Thomas Brix Larsen wrote:


I'd recommend dqml[1] or full Qt using Calypso[2] instead of QtE5. I'm 
currently using dqml in a project and it is working out great.


Why not QtE5? I've been meaning to give it a try.

Re: Favorite GUI library?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/24/2018 02:43 PM, H. S. Teoh wrote:


This reminds me of Nick Sabalausky's rant once that back in the 80's we
used to run programs on 64KB RAM and 8kHz CPUs, and lived with the slow
performance, and nowadays we have GB's of RAM and multicore GHz CPUs,
and we are finally able to write web apps that do basically the same
things with about the same slow performance as in the 80's (but with
many orders of magnitude greater resource consumption).  Software has
come a long ways indeed. :-D



Except that I don't think I ever once experienced the degree of 
text-entry delay or random stutters on my Apple II that I regularly 
experience on my "modern" PC which is more than capable of, ex., far 
surpassing Myst-level imagery in real-time, among other supercomputer feats.


Now that we have ARM, GPU computing, Gates is retired and MS isn't the 
big dog it used to be, I think we need to bring back and update the old 
"What Andy giveth, Bill taketh away" saying ;)

Re: Favorite GUI library?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/25/2018 05:49 AM, Chris wrote:


I recently had this issue with Chrome [1] and it is honestly annoying. I 
found out that it had been reported several times and what do Chrome 
devs say? Issue closed, it's an effin feature. To me it looks like they 
were over-intellectualizing the issue and came up with a "feature" that 
is counter-intuitive.


The thing about (Google) Chrome is this: unlike IE, it used to comply 
with web standards. No surprises, no stupid work arounds required, no 
two sets of code. IE went down, Chrome went up, and justly so. But now 
Chrome is becoming the new old IE (Mind you, even MS copped it that they 
had to comply with the standards!). And not to mention the built-in data 
"leakage". 


Yea. Google's pretty much decided they own the web and related 
standards. (If silicon valley has its way, in a few years time we won't 
even have an internet, we'll just have Facebook and Google. Heck, we're 
lucky that hasn't already happened...although...in some ways it arguably 
has...)


Funny thing is, and I'm no MS apologist, but back when MS was the one 
trying to decide how the web should operate, at least they actually made 
some vastly BETTER design choices than the W3C did. Ex, IE's old box 
model and its JS API for handling separate mouse buttons were actually 
SANE compared to the ridiculous equivalents from the W3C (can't help 
wondering if the W3C went contrary to MS on those designs just to spite 
MS (not that I can completely blame them), though I don't know how the 
timeline went and who's designs came first).


But fast-forward to now when it's now Google instead of MS saying "We'll 
be the ones designing the web standards, thank you very much, W3C.", 
they don't even have the benefit of making BETTER designs like MS did, 
they're just making random contradictory decisions. Quirk's Mode 
 is constantly finding new Google 
Chrome "interpretations" that are just...well, at best, they're not an 
improvement over W3C.


> But like IE back in the day, everybody uses Chrome by default.

Well yea, all the hipster nerds say Google is God and Chrome is what you 
should be using, so it must be so. ;)


At the very least, I just wish there was a good choice. Mozilla used to 
be the Burger King of browsers ("Your way, right away."), but they've 
spent the last decade hopping on silicon valley's "Our developers matter 
more than our users" bandwagon, too. (The "Soup Nazis" of software.)

Re: Favorite GUI library?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/25/2018 10:31 PM, Nick Sabalausky (Abscissa) wrote:


Yea. Google's [complain, gripe, blah, blah, blah...]
I found this to be a very interesting, and not particularly surprising, 
peek at the way things work^H^H^H^Hoperate inside Google-ville:


https://mtlynch.io/why-i-quit-google/

I guess it indirectly explains many things. Like why my Android device 
can't even handle basic WiFi things like...oh...not loosing my wireless 
password every-single-time. Or...connecting to another machine *on the 
same freaking network* without using a Google-hosted service (erm, 
sorry, I mean "cloud") as a go-between. Well, no matter, just like my 
laptop, I'll just ditch the pack-in OS in favor of Linux...oh wait...crap.

Re: Found on proggit: Krug, a new experimental programming language, compiler written in D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/26/2018 01:13 PM, arturg wrote:


why do people use this syntax?

if val == someVal

or

while val != someVal

it makes editing the code harder then if you use if(val == someVal).


The theory goes:

A. "less syntax => easier to read".
B. "There's no technical need to require it, and everything that can be 
removed should be removed, thus it should be removed".


Personally, I find the lack of parens gives my brain's visual parser 
insufficient visual cues to work with, so I always find it harder to 
read. And regarding "B", I just don't believe in "less is more" - at 
least not as an immutable, universal truth anyway. Sometimes it's true, 
sometimes it's not.

Re: Favorite GUI library?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/26/2018 03:20 PM, Johannes Pfau wrote:


Maybe this will help:
https://puri.sm/shop/librem-5/

Hope is the last thing to die ;-)



Thanks for the link, looks interesting. Don't quite understand how that 
distributed telephony is supposed to work though, while still 
(hopefully) interoperating with the standard telephone network.


Fingers crossed for that device or something like it, but not holding my 
breath (and as much as I hate Google/Android, anything without a 
built-in point-tipped stylus is useless to me and has basically zero 
chance of replacing my Galaxy Note - unfortunately).


Thing is, there's been so many attempts at iOS/Android alternatives 
already, and by much bigger organizations too. Even MS couldn't hold on, 
and that's the same company that was able to force their way into the 
notoriously tough-to-crack game console market by sheer financial force 
alone (by weathering a loss that even dwarfed the Dreamcast). So I fear 
that "hope" is ALL there is at this point. But I hope I'm wrong ;)


(And even if it does pan out, it's not like many people could just 
install it on an existing device: Those stupid things are locked down 
far tighter than any modern PC BIOS.)


I'll definitely keep an eye on that though.

Re: Found on proggit: Krug, a new experimental programming language, compiler written in D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/26/2018 06:47 PM, H. S. Teoh wrote:


If "less is more" were universally true, we'd be programming in BF
instead of D.  :-O  (Since, after all, it's Turing-complete, which is
all anybody really needs. :-P)



Yea. Speaking of which, I wish more CS students were taught the the 
inherent limitations of "Turing-complete" vs (for example) "Big-O". 
There's fr too many people being taught "Turing-complete means it 
can do anything" which, of course, is complete and total bunk in more 
(important) ways than one.


I see the same thing in other areas of CS, too, like parser theory. The 
formal CS material makes it sound as if LR parsing is more or less every 
bit as powerful as LL (and they often straight-up say so in no uncertain 
terms), but then they all gloss over the fact that: That's ONLY true for 
"detecting whether an input does or doesn't match the grammar", which is 
probably the single most UNIMPORTANT characteristic to consider when 
ACTUALLY PARSING. Outside of the worthless "does X input satisfy Y 
grammar: yes or no" bubble, LL-family is vastly more powerful than 
LR-family, but you'd never know it going by CS texts (and certainly not 
from those legendary-yet-overrated Dragon texts).

Re: Found on proggit: Krug, a new experimental programming language, compiler written in D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/26/2018 08:03 PM, H. S. Teoh wrote:

On Thu, Apr 26, 2018 at 07:14:17PM -0400, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:

On 04/26/2018 06:47 PM, H. S. Teoh wrote:


If "less is more" were universally true, we'd be programming in BF
instead of D.  :-O  (Since, after all, it's Turing-complete, which
is all anybody really needs. :-P)



Yea. Speaking of which, I wish more CS students were taught the the
inherent limitations of "Turing-complete" vs (for example) "Big-O".
There's fr too many people being taught "Turing-complete means it
can do anything" which, of course, is complete and total bunk in more
(important) ways than one.


Actually, Turing-complete *does* mean it can do anything... well,
anything that can be done by a machine, that is.  There are inherently
unsolvable problems that no amount of Turing-completeness will help you
with.



It's directly analogous to the LR vs LL matter, and LR's "Well, I can 
tell you this input does/doesn't satisfy the grammar, but I can't help 
ya with much more than that":


Turning-completeness only tells you whether a given Turing-complete 
system (ie, "language", machine, etc) *can* compute XYZ if given 
infinite time and memory resources. That's it, that's all it says. 
(Granted, that *is* still a useful thing to know...)


However, Turing-completeness says nothing about whether the given 
language can accomplish said task *in the same time complexity* as 
another Turing-complete language. Or any other resource complexity, for 
that matter.


And Turing-completeness also says nothing about what inputs/outputs a 
language/system has access to.


Ex: VBScript is Turing-complete, but it can't do direct memory access, 
period, or invoke hardware interrupts (at least not without interop to 
another language, at which point it's not really VBScript doing the 
direct memory access, etc). This means there are things that simply 
cannot be done in VBScript.


Another example:

Alan's Turing machine (as well as the BF language) is incapable of O(1) 
random-access. Accessing an arbitrary memory cell is an O(n) operation, 
where n is the difference between the target address and the current 
address. But many other languages/machines, like D, ARE capable of O(1) 
random-access. Therefore, any algorithm which relies on O(1) 
random-access (of which there are many) CANNOT be implemented with the 
same algorithmic complexity in BF and it could be in D. And yet, both BF 
and D are Turing-complete.


Therefore, we have Turing-complete languages (BF, VBScript) which are 
INCAPABLE of doing something another Turing-complete language (D) can 
do. Thus, Turing-completeness does not imply a language/machine "can do 
anything" another language/machine can do.


And then, of course, *in addition* to all that, there's the separate 
matter you brought up of how convenient or masochistic it is to do ABC 
in language XYZ. ;)




And actually, speaking of Big-O, one thing that bugs me all the time is
that the constant factor in front of the Big-O term is rarely
considered.
[...]
And that's not even beginning to consider practical factors like the
hardware you're running on, and why the theoretically-superior O(1) hash
is in practice inferior to supposedly inferior algorithms that
nevertheless run faster because they are cache-coherent, whereas hashing
essentially throws caching out the window.  Thankfully, recently there's
been a slew of papers on cache-aware and cache-oblivious algorithms that
are reflect reality closer than ivory-tower Big-O analyses that
disregard reality.



Certainly good points.


Well, LR parsing is useful for writing compilers that tell you
"congratulations, you have successfully written a program without syntax
errors!".  What's that?  Where's the executable?  Sorry, I don't know
what that word means.  And what?  Which line did the syntax error occur
in?  Who knows!  That's your problem, my job is just to approve or
reject the program in its entirety! :-P


Exactly! :)

(Ugh, I would've saved myself so much bother if ANY of that had been 
even remotely clear from any of the parsing books I had read. But nope! 
One of the items on my bucket list is to write a "CS Theory for 
Programmers" book that actually fills in all this stuff, along with 
going easy on the math-theory syntax that you can't realistically expect 
programmers to be fluent in. The average CS book is the equivalent of 
marketing a "How to speak German book" in the US...but writing it in 
French. Sure, *some* Americans will be able to read it, but...)



(And don't get me started on computability theory courses where the sole
purpose is to explore the structure of the hierarchy of unsolvable
problems.  I mean, OK, it's kinda useful to know when something i

Re: Favorite GUI library?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/27/2018 06:29 AM, Chris wrote:
On Thursday, 26 April 2018 at 02:31:07 UTC, Nick Sabalausky (Abscissa) 
wrote:

On 04/25/2018 05:49 AM, Chris wrote:

Well yea, all the hipster nerds say Google is God and Chrome is what 
you should be using, so it must be so. ;)


At the very least, I just wish there was a good choice. Mozilla used 
to be the Burger King of browsers ("Your way, right away."), but 
they've spent the last decade hopping on silicon valley's "Our 
developers matter more than our users" bandwagon, too. (The "Soup 
Nazis" of software.)


Technology, science etc. are no exception to (natural) human behavior: 
do as everybody else does, sure it's good. The problem is that 
pragmatism ("I have to write in JS, if I want to write a web app") turns 
into an ideology/relgion ("It's the best thing we have, if it wasn't, 
we'd be using something else, wouldn't we?"). Rationalizing irrational 
bs and irrationalizing the rational is a defense mechanism of humans. 
Groupthink and tribalism (hippsters) are part of our DNA, sometimes it 
makes sense, sometimes it's an obstacle.




That may be so, but a big part of being a participant in civilized 
society, and far more than that, being a professional, means having the 
basic will, ability and responsibility to utilize our higher-level 
cognitive functions (which we've also evolved and are baked into our 
genetics) to selectively override the baser instincts, and to discern 
when and where it's appropriate to do so.


It's a basic responsibility of being human, and it's a fundamental 
qualification of being a professional in a technical field.

Re: A strategic vision for D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/01/2018 10:27 PM, Joakim wrote:


Those are specific technical priorities that hint at a strategy, as you 
say, but it is better to lay out that strategy itself. Not knocking that 
vision document, as I called for a concrete document like that for 
years, but a conference keynote is a good place to lay out a strategy too.


I think the "overall strategy" is simply: "Identify the most important 
things for the core folk to work on, prioritize those things." Really 
don't think anything beyond that really matters or exists. We're not 
exactly pitching to VC's here.

Re: Found on proggit: Krug, a new experimental programming language, compiler written in D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/01/2018 10:51 PM, TheDalaiLama wrote:


There's no substituion for taste...some have it.. some don't.

'Experience' is irrelevant.



Honestly, there's a lot of truth to this. People can certainly learn, of 
course (well, at least some people can), but experience definitely does 
not imply learning has actually occurred.


Contrary to popular belief (especially common HR belief), experience is 
NOT a consistent, commoditized thing. There's such a thing as quality of 
experience, and that has far more impact than quantity.

Re: auto: useful, annoying or bad practice?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/30/2018 05:35 PM, H. S. Teoh wrote:


Also, design by introspection.  Dependence on explicit types is so last
century.  Design by introspection FTW!  Decoupling your code from
explicit types makes it more encapsulated, and gives you incentive to
write more defensively, resulting in better, more change-resilient code.
When an upstream library changes a return type, you can just recompile
and go, rather than waste time patching the 150 different places where
the explicit type was named.  Let the machine do the work for you!



There's a lot about that I like too, but I really wish D didn't use 
structral typing to do it. I still think the only reason D's structral 
typing hasn't blown up in our faces is because it's still mostly limited 
to the basic ranges isn't not a prevalent part of most internal and 
external APIs. Structural typing basically amounts to a form of global 
namespace (which can also work out ok *if used sparingly*, not that I'd 
want to try). At first, D thankfully killed off the global namespace for 
the most part...but then it brings its pitfalls right back in the form 
of structural typing. Grrr...


Structral typing isn't "If it walks like a duck and quacks like a 
duck...". Structural typing is "If it walks and it talks, then it must 
be a duck, because ducks walk and have their own form of talk, so 
clearly anything that walks and talks must be a duck."

Re: When will the final DConf videos surface on YouTube?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/03/2018 05:09 PM, IM wrote:

I can't wait to watch.


Not sure if you're specifically talking about the videos being split up 
per talk, but you can rewatch the full first two days livestreams here:


Day 1 Afternoon (Apparently morning was lost, I hear):
https://www.youtube.com/watch?v=HvqsUO77FGI

Day 2:
https://www.youtube.com/watch?v=0UZuRNujLGQ

Re: auto: useful, annoying or bad practice?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/02/2018 10:05 AM, H. S. Teoh wrote:


I've been using structural typing / design by introspection to good
success in my latest project, actually.


I don't doubt that. Similar to global namespace, if the structural 
typing is only used heavily by one or two components of a project (ie, 
libs, etc), then it's not too difficult to avoid problems. The real 
danger and problems come when a project uses several components that all 
make heavy use of either a global namespace (which D luckily doesn't 
really have) or structural typing.



Structral typing isn't "If it walks like a duck and quacks like a
duck...".  Structural typing is "If it walks and it talks, then it
must be a duck, because ducks walk and have their own form of talk, so
clearly anything that walks and talks must be a duck."


How else would you do DoI, though?  With Concepts?  The advantage of
using structural typing over concepts for DoI is that you would need an
exponential number of concepts to catch up with a linear number of
optional fields in a structural typing model.  Sure, structural typing
has its warts, but it's at least more scalable in this respect.


With a slight variation on structural typing that's augmented with 
mandatory opt-in. I'll explain:


The problem with structural typing is that it's unable to distinguish 
between intended matches and accidental, unintended matches. This is 
because it doesn't REQUIRE types/functions/etc to clearly state, "Yes, I 
*intend* to be implementing interface XYZ". Or perhaps more accurately: 
"Yes, I *intend* for this to satisfy isXYZ!T". (Where "isXYZ" might be 
something like "isInputRange" or "isInfiniteRange", or both, etc.)


Note the all-caps "REQUIRE" in the paragraph above. That is to say, it's 
not enough for the developer of struct Foo to toss in...


static assert(isXYZ!Foo);

...because the problem doesn't lie with the "intended matches". The 
problem lies with the "unintended matches". And that static assert does 
nothing to help isXYZ figure out that some other type, Bar, from some 
other package, is NOT deliberately designed to satisfy isXYZ even if it 
just happens to *look* like it satisfies it purely by chance.


As an aside: Think you're not likely to hit false positives with 
structural typing? Well, in all honestly, unless you're really sloppy, 
you're not likely hit name collisions in the global namespace 
either...UNTIL you reach the point where projects are composed of many 
third-party packages, and most third party packages start using the 
global namespace in their own way. Then it becomes a distinct possibility.


The same dynamic applies here because, like global namespaces, 
structural typing (by default) has no mechanism for scope-limiting or 
compartmentalization, and (intentionally) operates on unqualified names.


We address the global namespace's lack of scope-limiting and 
compartmentalization through...well, namespaces. The namespaces may be 
implied by classes (old-school Java), by compilation units (D), or 
specified manually (C++). But how do we address structural typing's lack 
of scope-limiting and compartmentalization? Currently, we don't. And 
that's the problem.


So back you your question: How else would you do DoI?

Answer: By making isXYZ!T reject all T which DO NOT satisfy a 
deliberate, cannot-be-an-accident, condition of isXYZ's choosing.


Thus, type T *cannot* satisfy isXYZ without T's developer saying "Yes, I 
hereby certify it is my deliberate intention that T satisfies isXYZ and 
that, if it does satisfy, it is by my own intention and not by 
coincidental happenstance."


The exact details of this condition aren't terribly important, but I 
like Neia's suggestion of utilizing UDAs for this purpose. An old idea I 
had before UDAs existed was to require a dummy member enum named 
something like _satisfies_module_foo_bar_isXYZ, which of course would be 
abstracted away by something more convenient...a mixin or such (but 
nobody seemed remotely interested). But I like the UDA idea better.

Re: auto: useful, annoying or bad practice?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/04/2018 03:56 AM, Laeeth Isharc wrote:

On Friday, 4 May 2018 at 04:12:09 UTC, Nick Sabalausky (Abscissa) wrote:

On 05/02/2018 10:05 AM, H. S. Teoh wrote:

[...]


I don't doubt that. Similar to global namespace, if the structural 
typing is only used heavily by one or two components of a project (ie, 
libs, etc), then it's not too difficult to avoid problems. The real 
danger and problems come when a project uses several components that 
all make heavy use of either a global namespace (which D luckily 
doesn't really have) or structural typing.


[...]


Have you seen Atila's concepts library?


Yea, last I checked, it doesn't address what I'm talking about at all. 
That lib's basically just this:


struct Foo {...}
static assert(isXYX!Foo);

But with more detailed diagnostics. (Plus it can help you write the 
isXYZ function.)


Unless something's changed since last looked at it, it didn't address my 
#1 key point: If struct Foo's author *doesn't* include the lib's 
"@models!(Foo, isFoo)", then isFoo!Foo should return false.

Re: auto: useful, annoying or bad practice?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/04/2018 12:54 PM, H. S. Teoh wrote:


This is a good point.  However, I'm failing to see it as a big problem,
because for it to be a problem in the first place, you have to have
*deliberately* passed an object of said type into a function that
expects that particular concept.


First of all, just to be clear in case I wasn't, I didn't mean that it's 
equally dangerous as globals, just that it's analogous. Globals are, of 
course, more dangerous.


Regarding the need to deliberately pass an object of said type to a 
function in order to cause a problem, that's not always true: It could 
be a matter of the compiler choosing the wrong overload. Or sticking it 
in the wrong parameter on certain templated functions.


Also, generally speaking, even without structural typing, the danger of 
passing an object of the wrong type to the wrong 
parameter/function/overload IS considered to be significant enough to 
help justify the whole premise of static typing. (Well, at least 
according to a certain faction of programmers, anyway ;) )


And ultimately, from a design standpoint, I really see no compelling 
reason *not* to require a formal declaration of "This deliberately 
implements isXYZ", other than just...some people just dislike it. So 
like, yea, we *can* get by without it...but...why would we want to?

Re: D for microservices

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/05/2018 02:30 PM, Nick Sabalausky (Abscissa) wrote:

On 10/23/2017 06:02 PM, Adam Wilson wrote:

On 10/23/17 05:08, Jacob Carlborg wrote:

* Database drivers for the common databases (PostgreSQL, MySQL, SQLite)
compatible with vibe.d
* Database driver abstraction on top of the above drivers, perhaps some
lightweight ORM library


I've been looking pretty extensively at these two items recently.

If the database drivers are compatible with Vibe.d AND we wish to 
provide a common abstraction layer for them (presumably via Phobos) 
then order for the abstraction layer to aware of the whether the 
driver is making a blocking or non-blocking call we must include 
Vibe.D in the abstraction layer.


Mysql-native is vibe.d-compatible, but also works when you have zero 
vibe.d dependencies (in which case it switches to Phobos's sockets 
instead of using Vibe's sockets.)


Sorry, didn't notice this was a half-year-old thread.

Re: D for microservices

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 10/23/2017 06:02 PM, Adam Wilson wrote:

On 10/23/17 05:08, Jacob Carlborg wrote:

* Database drivers for the common databases (PostgreSQL, MySQL, SQLite)
compatible with vibe.d
* Database driver abstraction on top of the above drivers, perhaps some
lightweight ORM library


I've been looking pretty extensively at these two items recently.

If the database drivers are compatible with Vibe.d AND we wish to 
provide a common abstraction layer for them (presumably via Phobos) then 
order for the abstraction layer to aware of the whether the driver is 
making a blocking or non-blocking call we must include Vibe.D in the 
abstraction layer.


Mysql-native is vibe.d-compatible, but also works when you have zero 
vibe.d dependencies (in which case it switches to Phobos's sockets 
instead of using Vibe's sockets.)

Re: Binderoo additional language support?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/07/2018 01:24 PM, Ethan wrote:

On Monday, 7 May 2018 at 03:33:19 UTC, Norm wrote:

See, that just sounds a bit too much like a Sumatran Rat Monkey to me.



That sounds like a coffee-based cocktail to me ;)

Re: Two really good looking GUI libraries that can work for D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/11/2018 05:43 PM, aberba wrote:
>
> https://littlevgl.com/
>

On 05/12/2018 03:03 PM, aberba wrote:

On Friday, 11 May 2018 at 23:13:06 UTC, Rubn wrote:


https://github.com/ocornut/imgui
https://github.com/Extrawurst/cimgui


Compare imgui with Nuklear (https://github.com/vurtun/nuklear) and see 
the difference in the features and polish.


Y'know, even though I'm normally very "native UI or bust!" (outside of 
videogames anyway), I have to say, for non-native, LittlevGL and Nuklear 
are *REALLY* nice looking. It's also very, very cool that they seem to 
be designed with embedded in mind.


Also very cool that imgui appears to have been used for that cool Wonder 
Boy 3 remake.


I'll definitely have to remember these if I need to do an embedded or 
in-game-engine UI.

Re: Is D releasing too often?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/14/2018 03:20 AM, Joakim wrote:
There have been 6 major releases of dmd over the last year, with ldc 
trying to keep pace, currently only one release behind. This is a big 
jump up from the previous release schedule, I see 2 major releases in 
2014, 3 in 2015, and 3 in 2016.




This is just a return to the old original pace. It used to be about this 
often, but improved focus on avoiding regressions and packaging mistakes 
had a side effect of delaying releases down to as low as 2/year. But the 
improved "checks and balances and procedures" have finally become 
streamlined enough that the delays have been overcome and we're back to 
where we already were.


Personally, I like it. Keep in mind, availability of an update does not 
mandate immediate upgrading. It's just means its *available*. In an 
ideal world, improvements should be available immediately. In the real 
world, we have need to allow for both automated and manual checks for 
regressions. Therefore, the only things that should delay deployment of 
a project's new releases are:


A. Automated regression tests (and fixing found regressions).
B. A formal "beta" cycle (and fixing found regressions).
C. The existence of improvements (without improvements, what's the point 
of a new release?).


If dependent projects/libs have trouble keeping up with an increased 
rate of releases, that only means that we need better tools for 
automating the tasks involved in supporting newer releases.


If there's motivation to delay releases, that's a clear indication that 
dependent projects are in simply need of better automation/processes/etc.


Summary (That's "TL:DR" in hipster parlance): **Available** updates are 
always a good thing, as long as they're checked for regressions. Any 
issues keeping up with updates only indicate we have a *good* problem: 
That the ecosystem has room for "process" improvements and isn't 
currently being constrained by lack of progress in dependencies.

Re: Is D releasing too often?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

Ie, as long as there's no regression problems: If the rate of releases 
makes us feel like we have an embarrassment of riches, it doesn't mean 
that we *NEED* fewer releases. It means we need to be more appreciative 
that there's all those enhancements we don't have to wait for.

Re: Is D releasing too often?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/14/2018 04:35 AM, Uknown wrote:


Agree, but I think LTS releases are worth considering. A yearly release 
that gets only bug fixes would be useful for stability.


A fair point. I have no disagreement with something like that.