Re: Linking D code into existing C programs

[Nick Sabalausky via Digitalmars-d]

On 09/26/2016 07:32 PM, Walter Bright wrote:


How much of an issue is this with D? Is it something we need to address?


I don't know anything about the technical side of this issue, but I do 
think it's an important thing to have working well, since I believe it's 
important for us to start marketing our D-based libraries as easily 
usable from C:


https://semitwist.com/articles/article/view/we-re-overlooking-a-key-part-of-c-c-d-user-migration

Re: SDLang-D v0.10.0 - Big convenience improvements

[Nick Sabalausky via Digitalmars-d-announce]

On 09/25/2016 06:12 PM, Nick Sabalausky wrote:


-
// A few basic values
first "Joe"
last "Coder"
ip "127.0.0.1" port=80

// Supports child tags
folder "myFiles" color="yellow" protection=on {
 folder "my documents" {
 document "resume.pdf"
 }
}
-


Example of using some of the new API features:

-
import sdlang;

Tag root = parseFile("the-above.sdl");

string first = root.expectTagValue!string("first"); // Required
string last  = root.getTagValue!string("last"); // Optional

// Custom default values (if omitted, default value is T.init):
string ip = root.getTagValue!string("ip", "192.168.1.1");
int port = root.getTagAttribute!int("ip", "port", 8080);

Tag folder = root.expectTag("folder");
string folderName = folder.expectValue!string();
assert(folderName == "myFiles");
bool folderProtection = folder.getAttribute!bool("protection");

string subfolderName = folder.getTagValue!string("folder");
assert(subfolderName == "my documents");
-

Re: [OT] Stackless fibers/coroutines

[Nick Sabalausky via Digitalmars-d]

On 09/26/2016 02:42 AM, Jacob Carlborg wrote:

On 2016-09-25 20:16, Nick Sabalausky wrote:

I don't see why not, but there would be one notable drawback: You could
only have one instance existing at a time (per thread).


But how does it work in languages which don't pass in the state
explicitly, like with "yield" in C#?

Or async/await? I guess one doesn't call the function multiple times in
the same way instead it's done automatically under the hood, passing in
the state which might be stored in the "Task" that is returned?



I don't know about async/await, because all my C# work was with versions 
of C# that predated those. But as for C#'s yield functions, yes, that's 
my understanding: It's hidden magic automatically inserted by the compiler.


As a side note, that actually makes D's opApply a very interesting case, 
really:


Instead of doing like the other implementations and "yielding" by 
removing the top function from the callstack (ie "returning"), opApply 
does the oppposite: It yields by pushing whatever function it's yielding 
*to*, *onto* the callstack. So its state is stored on the stack, no need 
for magic. The downside is, that's exactly what makes it impossible for 
opApply to be used as a range (at least without introducing a true fiber 
to save/restore the callstack): popFront *must* return in order for the 
user's algorithm to call front and obtain the current element - because 
that's how the range interface works.




The above code compiles, after removing the extra "return+case:".



Really? I may have to look into this more then.

Hmm, well for starters, according to 
:

"It is illegal for a GotoStatement to be used to skip initializations."

Although if that's true, I don't know why that example compiled. Maybe 
because "foo" wasn't used from "case 2:" onward? Maybe it failed to 
notice the initialization since it was in an if condition? Or maybe the 
compiler forgot to implement the same "can't skip initialization" check 
for switch/case?

SDLang-D v0.10.0 - Big convenience improvements

[Nick Sabalausky via Digitalmars-d-announce]

https://github.com/Abscissa/SDLang-D

New in v0.10.0:
Big convenience enhancements to DOM interface and an improved pull 
parser interface. Plus documentation improvements and a couple bugfixes.


Full changelog:
https://github.com/Abscissa/SDLang-D/blob/master/CHANGELOG.md

===

SDLang-D is a D library to read and write SDLang. Both a DOM and a Pull 
Parser are provided.


SDLang  is similar to XML/JSON/YAML, but much simpler 
and less verbose. It look like this:


-
// A few basic values
first "Joe"
last "Coder"
ip "127.0.0.1" port=80

// Supports child tags
folder "myFiles" color="yellow" protection=on {
folder "my documents" {
document "resume.pdf"
}
}
-
Language Guide: https://github.com/Abscissa/SDLang-D/wiki/Language-Guide

Re: [OT] Stackless fibers/coroutines

[Nick Sabalausky via Digitalmars-d]

On 09/25/2016 01:06 PM, Chris Wright wrote:

On Sun, 25 Sep 2016 01:36:57 -0400, Nick Sabalausky wrote:

The "turning functions inside-out" effect of continuation passing is
exactly what input ranges suffer from[1] - and is exactly what stackless
coroutines *avoid*.


The compiler inverts them for you.



Basically, yea. Soo much nicer than writing/maintaining inverted 
code by hand!



You may want to give C's protobuf or C#'s yield-based generator
functions a try. Yes, true, they're not as convenient as actual fibers,
but there's a LOT they let you do painlessly (far more painlessly than
writing input ranges[1]) without the fiber overhead - think opApply but
without the complete and total incompatibility with functions that
operate on ranges.


Yeah, I really want something transparent.



Ah. Yea, totally transparent they are not. But I find them to be a solid 
enough abstraction that I have no issue whatsoever.


Keep in mind though, fibers and threads aren't really all that 
transparent either, there's a bunch of behind-the-scenes magic there 
too. Saving/restoring register state. Your threads will just *stop* at 
arbitrary points while some other code halfway across the codebase is 
executed. Etc. But they're solid enough as abstractions that we prefer 
the abstraction to dealing with the underlying mess transparently.


The same applies to nearly all programming constructs, even something as 
basic as function calls. Bunch of opaque hidden magic there. But it 
pretty much *just works* so we rarely need/want the transparency.



[1] Note I mean actually writing an input range itself. *Using* an input
range is wonderfully pleasant. But writing them turns all my logic
inside out, somewhat like Node.js-style callback hell (or ActionScript2
back in my day).


Agreed. It's relatively easy to compose ranges, which is nice, but
whenever I have to write one from scratch, I get a little sad.



That's why some solid abstraction magic would be very, very nice! :)

Re: [OT] Stackless fibers/coroutines

[Nick Sabalausky via Digitalmars-d]

On 09/25/2016 06:39 AM, Jacob Carlborg wrote:


I find it quite difficult to find correct definitions with many of these
terms like: coroutine, fiber, stackless thread, resumeable function.
Because many languages use the same name of different things and they
use different names for the same things.



FWIW, and this is at least the way I see it:
(BTW, any domain experts please chime in if I'm wrong. I'm thinking it 
may be worth reposting this as a blog entry, as long as I'm not too far 
off-base.)


Fiber:
--
Like a thread, but lighter-weight. Multiple fibers can run within one 
thread.


Like a thread, a fiber has it's own stack, and upon suspend/resume 
various state is saved/restored (I assume that "state" means "CPU 
registers").


Unlike a thread, a fiber's multitasking is sequential and cooperative, 
NOT simultaneous and preemptive: Ie, One fiber must willfully relinquish 
control (by calling a "yield" function) before another fiber in the same 
thread can resume. I'm assuming this sequential/cooperative what allows 
it to be lighter-weight than a true thread, but I'm not 100% certain.


Coroutine:
--
A function that can "yield" (ie, it can choose to temporarily exit so 
that it can be resumed from the same place later on). Often a return 
value is emitted upon yielding, so these are usually used as generators, 
because they're a convenient way to generate a series of values in an 
easy procedural style.


Coroutines are commonly implemented as fibers, so it is often said that 
fibers and coroutines are the same thing. That's partially accurate, 
except for two things:


1. "Coroutine" refers to a specific function, whereas "fiber" refers to 
the overall sequence of execution.


2. This is probably a debatable matter of semantics, but coroutines 
don't have to be implemented using fibers. For example, opApply is 
essentially a coroutine (it yields by calling the delegate that was 
passed in).


Stackless Thread/Fiber:
---
Not a true thread or fiber. It's called a "stackless thread" or 
"stackless fiber" simply because it's *like* a thread or fiber (closer 
to a fiber, really), but without a separate stack for each, 
umm..."fiber". Protothreads is an example of a stackless thread/fiber.


A stackless thread/fiber is much more lightweight than even a fiber. But 
it comes with a limitation:


With a true fiber, any function in the callstack can yield. When it 
yields, it suspends the fiber's entire callstack. So inside a fiber, 
your coroutine can call a function and have *that* function yield your 
fiber. That feature requires a separate callstack for each fiber, so you 
cannot do that with the stackless versions.


Instead, in a stackless thread/fiber, yielding will ONLY suspend the 
current function, not a full callstack (since it doesnt have a callstack 
of its own to suspend).


In other words, yielding a stackless thread/fiber works much like a 
normal "return" statement:


---
void foo() {
bar();
}
void bar() {
return; // ONLY return from bar

return from BOTH bar AND foo; // IMPOSSIBLE!!!
}
---

A stackless thread/fiber works the same (psuedocode):

---
void coroutineFoo() {
coroutineBar();
}
void coroutineBar() {

// Stackless fiber: ONLY suspends coroutineBar.
// Regular fiber: Suspends ENTIRE callstack.
yield;

yield from BOTH bar AND foo;// IMPOSSIBLE with stackless

// More code here
}
---

Luckily, you can work around it, just like you can with normal returning 
(psuedocode):


---
void coroutineFoo() {
bool shouldYield = coroutineBar();
if(shouldYield)
yield;

// More code here
}
// Yielded value: Should the caller yield?
bool coroutineBar() {
yield true; // Yield both bar and foo
// More code here
}
---

I'd argue opApply's approach technically qualifies as a stackless 
thread/fiber, since it yields (by calling the delegate it received) and 
does not involve any extra callstack. Plus, like any other stackless 
thread/fiber, it cannot suspend any further up the callstack than just 
itself.


However, from what I've seen, a stackless thread/fiber is typically 
implemented the way Protothreads works:


When the "stackless coroutine" function is called, the first thing done 
inside the function is jump to wherever the function last left off.


Then, every "yield" is constructed as an *actual* "return" followed by a 
jump label. When a function yields, it returns three things:


1. An optional value being yielded (like a normal return value).

2. Which jump label to jump to next time the function is resumed.

3. Any local variables that need to be preserved upon resume (or just 
all local variables).


With a really nice stackless thread/fiber system, like C#'s, this is all 
handled behind-the-scenes.


Stackless Coroutine:

A coroutine that uses a stackless 

Re: [OT] Stackless fibers/coroutines

[Nick Sabalausky via Digitalmars-d]

On 09/24/2016 09:14 PM, Chris Wright wrote:

On Sat, 24 Sep 2016 11:49:24 -0400, Nick Sabalausky wrote:

My understanding is that C#'s coroutines, under the hood, work the same
way as C's Protothreads library:


You mean async/await, which is a compiler-provided CPS transformation on
top of the Task API.



No, I mean "yield". My C# work was all before async/await.


First, only C#'s coroutines can yield, not regular functions called by a
coroutine.


Because it's the continuation passing style, not a full thread of
execution. That makes it moderately painful to use under normal
circumstances and entirely unsuitable in other cases.



If I understand correctly what you mean by "continuation passing style", 
then yes, it sort of is, but only behind-the-scenes. The only 
recognizable effect of that is that yield can only break out of one 
level of the call stack at a time (just like how return only ever 
returns from the current function, no further - unless you use Ruby, but 
well, let's not go there...).


The "turning functions inside-out" effect of continuation passing is 
exactly what input ranges suffer from[1] - and is exactly what stackless 
coroutines *avoid*.




Look at Node.js and Vert.x. It's not a barrier to the market to force
programmers to manually execute the CPS transformation.


Speaking as a long-time web developer, most (not all) web developers are 
fully-acclimated to eating shit sandwiches and convincing themselves 
they like it. Hence their tolerance for what Node.js does to their code 
(among other issues with it, like...using JS...on the server...).


Obviously I'm being colorfully figurative there, but I'm sure you knew 
that ;)




Fibers are more convenient. They also have a large, upfront cost, but
they have the advantage of treating the stack like a stack. It breaks
fewer assumptions about performance.



You may want to give C's protobuf or C#'s yield-based generator 
functions a try. Yes, true, they're not as convenient as actual fibers, 
but there's a LOT they let you do painlessly (far more painlessly than 
writing input ranges[1]) without the fiber overhead - think opApply but 
without the complete and total incompatibility with functions that 
operate on ranges.


[1] Note I mean actually writing an input range itself. *Using* an input 
range is wonderfully pleasant. But writing them turns all my logic 
inside out, somewhat like Node.js-style callback hell (or ActionScript2 
back in my day).

Re: Interesting talk about language design and evolution

[Nick Sabalausky via Digitalmars-d]

On 09/24/2016 02:11 PM, Brad Anderson wrote:


Relevant is this list of C++17 features (many of which already work in
popular compilers).

http://stackoverflow.com/a/38060437/216300

I've got to admit, the D side of me is jealous of a few things on this
list. Structured bindings, init ifs (one of those "why did it take so
long to come up with this?" ideas), and constructor IFTI. Not sure if
it's in C++17 yet but the stackless coroutines look nice too.

The baby steps toward CTFE are welcome, of course. It appears C++ still
has a long way to go though.


Every time I go back and look at it, C++'s evolution just seems more and 
more like "Let's do a poor imitation of D, without really admitting it, 
and without doing the real fundamental cleanups that D did and C++ still 
desperately needs."


All the work that's gone into C++ the past decade...if even half of that 
had been directed into D instead, then years ago they would have already 
been far ahead of where they are now. But they just keep building more 
and more on top their busted foundation.


C++ was already kind of a monster of a language during the period I was 
using it most (late 90's, early 2000's). Instead of improving my opinion 
of it, all of this new stuff from C++11 onward merely makes me even more 
terrified of ever going near it again, because all it does is add more 
cruft when "too much cruft" was already its biggest problem to begin with.


I don't care if the political correctness wind IS blowing against it - I 
*still* think D's biggest strength is that it's "C++ done right". That's 
what drew me to D in the first place, and that's what keeps me here.


About the "if inits": Those do seem take make a lot of sense, I've hit 
cases where it could be used, and I have zero objection to it...but it 
still seems incredibly minor to me, and it just strikes me as "really, 
C++, you have *far* better things to be focusing on then adding yet more 
syntax, just for minor benefit". Like, oh, I don't know, modules maybe? 
Compiling in under a day? And fixing up that goofy ".cpp vs .hpp" system 
where so many people honestly believe it's "implementation vs 
interface", but if you really look at it you find the *genuine* truth of 
"what goes in which file" is really far, FAR more random than that. 
Seriously, last time I used C++, I was amazed: It is INSANE how much of 
a load of BS the conventional wisdom is about header files being 
"interface" - there is a TON of implementation shit that must be in the 
so-called header. May have been true in C (if you ignore macros), but 
definitely not in C++.

[OT] Stackless fibers/coroutines

[Nick Sabalausky via Digitalmars-d]

On 09/24/2016 10:20 AM, Jacob Carlborg wrote:

On 2016-09-24 15:12, Nick Sabalausky wrote:


+1.

Although I haven't given it too much thought, I'd bet that could also be
used to provide, in library, my #1 most wanted missing D feature: Input
ranges (maybe even forward, too) written as stackless coroutines
(C#-style, heck, even C can do it in lib). So we could write input
ranges without turning the whole freaking algorithm completely
inside-out, or requiring the overhead of a full fiber.


Yeah, I've been thinking of that as well. It should be fairly easy to
implement something like Protothreads [1]. Not sure about stackless
coroutines though, if they need to save the state of the function on
suspension and restore the state when the function resumes.

[1] http://dunkels.com/adam/pt/



"Protothreads"! I've been trying to remember the name of that lib and 
couldn't find it. I used that the last time I was working on a C/C++ 
thing, and it was very helpful.


AIUI though, that IS stackless coroutines, same thing AFAIK. The 
Protothreads lib refers to itself as "extremely lightweight stackless 
threads". And the way it's used is definitely what I'd consider a coroutine.


Protothreads solves the problem of saving/restoring state by doing two 
things:


1. You put all your locals (at least, any that need preserved across 
save/restore) in a struct, together with the appropriate jump label to 
be jumped to upon resume. Then when yielding, this struct gets passed 
out, and when resuming you pass it back in.


2. Yielding can ONLY be done by a coroutine, itself, NOT by any 
functions it calls (unless those are also coroutines and return some 
flag signaling the first coroutine to also yield). This is the one big 
key that makes stackless fibers/coroutines/etc possible in the first place.


My understanding is that C#'s coroutines, under the hood, work the same 
way as C's Protothreads library:


First, only C#'s coroutines can yield, not regular functions called by a 
coroutine. Then, the C# compiler "lowers" the coroutine function into a 
big switch statement, with the current state (values of the locals and 
the hidden "case" target to jump to) passed in and out as a hidden argument.


Since the compiler does the conversion, it can safely deal with 
saving/restoring the locals, and crossing scope boundaries and such 
(which C is just plain not concerned with at all).


So really, C#'s coroutines (AIUI) are just like C's Protothreads, but 
with nicer sugar.


But about implementing it in D:

I'm not so sure that's realistic right now. I mean, I think something 
like it is *technically* possible, and I would have done so myself long 
ago, except that I see two major problems:


1. You'd have to write the entire coroutine as a string, which would 
really mess with IDE/editor features and the compiler's error reporting. 
And I'm not sure I see any way to do this in D without writing the 
coroutine as a string (or, you know, using AST macros ;) ).


2. Compared to C, D has much stricter rules about where a switch's 
"case" labels can do. Ie, they can't really cross scope boundaries. So 
*all* the coroutine's "yield" statements would have to be within the 
same scope *and* at the same nesting-level (or at the very least, 
there'd be some big annoying restrictions). Otherwise, when it gets 
converted to a "case:", the resulting code would be invalid.


We could use "goto" instead of case, but that has many of the same 
issues, plus (IIRC) the issue of goto-ing past a variable declaration 
(which IIRC is disallowed, or maybe had some other problem).


I'm not sure how you could get around problem #1 without AST macros or 
just implementing the whole feature in the compiler, like C#.


Even if you solved that, the only way I see to get around #2 would 
require very careful manual adjustments to the coroutine via a CTFE D 
AST, which (for right now) would be all kinds of bother, and at that 
point you may as well just add the feature built-into the compiler (like 
C#) because it would be more efficient than CTFE, AND it would solve 
problem #1.

Re: What's up with the assert enhancements proposed years ago?

[Nick Sabalausky via Digitalmars-d]

On 09/24/2016 04:03 AM, Martin Nowak wrote:


assertPred!"=="(a, b);
assertPred!"!"(a);
assertPred!(std.range.equal)(a, b);

Seems to do most of what DIP83 does w/ expensive feature design, and
compiler implementation work.
Also http://code.dlang.org/packages/unit-threaded comes with a couple of
test comparators, though it follows ruby rspec's bad idea of giving
every comparator a name (which has to be learnt and documented).


Yea, incidentally, I just started using unit-threaded for the first time 
this week, and so far, for the most part, I really quite like it a lot. 
But those comparator functions give me bad flashbacks of old-school Java.


Hmm, I wonder if Atila would be amenable to a more assertPred-like 
function in unit-threaded. Maybe a `should!"=="(leftSide, rightSide)` 
would fit in well. Or better yet, also adding in something like that 
that trick used in Andre's really nice recently proposed "dump" function 
(or whatever the name of it was), where it also prints out the actual 
argument provided in addition to the argument's value.

Re: What's up with the assert enhancements proposed years ago?

[Nick Sabalausky via Digitalmars-d]

On 09/24/2016 03:34 AM, Jonathan M Davis via Digitalmars-d wrote:

On Friday, September 23, 2016 23:50:03 Nick Sabalausky via Digitalmars-d
wrote:


And then that leads too, to the question of whether such third-party
asserts are a good idea for the doc unittests I like so much... :/


I'd say not. If you're writing a library for general consumption, I don't
think that anyone else who is not actually helping to develop it should have
to know or care what unit testing facilities you're using. assert is
universal and clear, whereas other stuff is not universal and may or may not
be clear to those not familiar with it.



Yea, honestly, that's my thought as well. :(  And it's a big part of why 
I was (and still am) so disappointed that assertPred didn't become 
official even if it is technically usable as third-party. We could've 
already been using that for years by now, standard, if it weren't for 
D's habit of letting perfect be the enemy of progress.



Also, my take on it is that ddoc-ed unittest blocks are really there to just
give examples for the documentation, not to test your code. You want the
examples tested so that you know that they work - which is why ddoc-ed
unittest blocks are such a great feature - but it's not their purpose to
test your library. It would be wholly unreasonable to have thorough tests in
the documentation, and what makes a good example doesn't necessarily make
for a very good test (or vice versa).



I think there's a balance (albeit a difficult one). I agree that being 
pedantic with the examples can make them overly cluttered, so that 
should be avoided. But all major side-cases should still be documented, 
and examples help with that as they do with anything else.


For example, std.path.buildNormalizedPath: It should not only document 
typical cases like `buildNormalizedPath("foo","bar")`, but it's very 
important for its docs to also be clear about various other significant 
cases:


- How does it handle empty strings as arguments?
- What does it return for buildNormalizedPath("foo",".."). It used to 
return empty string which turned out very problematic. Now it returns 
"." which is much better.

- What happens when I do buildNormalizedPath(relativePath,absolutePath)?

These are all very important cases that still need to be documented. And 
examples work excellently as documentation here. (And IIRC, 
buildNormalizedPath docs are doing a good job of this.)


So a good set of examples *do* still test a significant amount of a 
function, even if it isn't exhaustive.


So because of that, and heck, even if your examples *are* overly sparse, 
sometimes you will get a failure in one. Which, of course, is the whole 
point of actually testing them. And when you do, it's a big help for the 
diagnostic output to actually be, well, helpful:


The whole cycle of:

- Search the stack trace for the relevant file/line number.

- Find it:
assert(x.foo(blah...) == y);

- Insert scaffolding:
import std.stdio;
writeln("x.foo(blah...): ", x.foo(blah...));
writeln("y: ", y);

- Recompile/re-run tests (and maybe go back again and fix any stupid 
typos in the scaffolding).


- Finally view key information that COULD'VE been shown right from the 
start.


Gets very tiresome very quickly, even if it's only in the example tests.

Re: What's up with the assert enhancements proposed years ago?

[Nick Sabalausky via Digitalmars-d]

On 09/24/2016 06:52 AM, Jacob Carlborg wrote:

On 2016-09-24 00:02, Seb wrote:


http://wiki.dlang.org/DIP83

(needs polishing and submission to the new dip process)


http://wiki.dlang.org/DIP50 :)



+1.

Although I haven't given it too much thought, I'd bet that could also be 
used to provide, in library, my #1 most wanted missing D feature: Input 
ranges (maybe even forward, too) written as stackless coroutines 
(C#-style, heck, even C can do it in lib). So we could write input 
ranges without turning the whole freaking algorithm completely 
inside-out, or requiring the overhead of a full fiber. Ever try doing LL 
parsing both traditional procedural-style and range-style? The range 
version's a complete unholy mess.

Re: What's up with the assert enhancements proposed years ago?

[Nick Sabalausky via Digitalmars-d]

On 09/23/2016 11:47 PM, Nick Sabalausky wrote:

On 09/23/2016 07:57 PM, Jonathan M Davis via Digitalmars-d wrote:

On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d
wrote:


So...umm...yea...whatever happened to that beefed-up "assert" feature?


[...]



Ugh, so, "It was rejected for being library instead of assert, then it
was rejected for being assert instead of library".

/facepalm

Guess I'll just have to try getting used to awful Java-isms like
x.notEqual(y) :(


And then that leads too, to the question of whether such third-party 
asserts are a good idea for the doc unittests I like so much... :/

Re: What's up with the assert enhancements proposed years ago?

[Nick Sabalausky via Digitalmars-d]

On 09/23/2016 07:57 PM, Jonathan M Davis via Digitalmars-d wrote:

On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d
wrote:


So...umm...yea...whatever happened to that beefed-up "assert" feature?


[...]



Ugh, so, "It was rejected for being library instead of assert, then it 
was rejected for being assert instead of library".


/facepalm

Guess I'll just have to try getting used to awful Java-isms like 
x.notEqual(y) :(

What's up with the assert enhancements proposed years ago?

[Nick Sabalausky via Digitalmars-d]

Some ages ago, a whole suite of "assertPred" functions were written 
(giving better diagnostic info, like showing "expected vs actual"), were 
totally awesome, were submitted to phobos...and were rejected because it 
was deemed both easy enough and preferable to get these features by 
modifying DMD to add behind-the-scenes AST magic to "assert".


So...umm...yea...whatever happened to that beefed-up "assert" feature?

Documentation unittests are seriously awesome

[Nick Sabalausky via Digitalmars-d]

Just had to say it. Been using it a lot this week.

Referring to this stuff:


/// Does foo stuff
void foo()
{}

///
unittest
{
// Tests and docs in one, 2-for-1 win!
}


And all just built-in. Freaking sweet.

Re: [OT] Re: Why I am switching to Go

[Nick Sabalausky via Digitalmars-d]

On 09/22/2016 11:41 AM, Chris wrote:

Around every two years they come up with something new, give or take a
year depending on the topic. In general, I got the impression that once
I've finally got used to using a certain term, it's no longer
(politically or otherwise) correct, e.g. "STD" => "STI" ("disease" is
obviously a bad bad word - unless you want to sell useless drugs for
made-up diseases). It happens all the time.


They've now renamed Syphilis, et al. after Subaru's highest-end Impreza? 
*shakes head*. Who wants to bet *that* little bit of PC rubble-bouncing 
was spearheaded by someone with a vested interest in the Viper or 
Corvette or something?


Fine, ok, so who wants to put together the PR to update Phobos's package 
name accordingly? Any takers?

[OT] Re: Why I am switching to Go

[Nick Sabalausky via Digitalmars-d]

On 09/22/2016 07:43 AM, Steven Schveighoffer wrote:

On 9/20/16 3:14 PM, Intersteller wrote:

TL;DR: I like and have used Go extensively. I glanced at D for 20
minutes and didn't like it.



Grumpy old curmudgeon says: "Harumpf...Why back in my day, we pronounced 
'TL;DR' as 'summary'...or 'abstract' if we wanted to be really really 
fancy" ;)


Never much understood "bouncing rubble" English changes like that, or 
"internet"->"cloud", "preteen"->"tween", etc. Can't tell if the trend is 
accelerating or it's just me getting old.

Re: Custom test runner

[Nick Sabalausky via Digitalmars-d-learn]

On 09/21/2016 02:26 AM, Jacob Carlborg wrote:

On 2016-09-21 07:51, Nick Sabalausky wrote:

IIRC, there is some way to hook in and use a custom unittest-runner. How
does one go about that?


http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester



Cool, thanks.

I got that to work, and FWIW submitted a PR to add an example to the 
docs for that: https://github.com/dlang/druntime/pull/1656

Re: null analysis with control flow

[Nick Sabalausky via Digitalmars-d]

On 09/21/2016 09:10 AM, w0rp wrote:


1. Most languages (including D) do not support pattern matching. If
pattern matching was added, it would be totally alien to any programmers
coming from C, Java, JavaScript, Python, etc. This means this method of
handling null might not be adopted.


I've said it before, and I'm going to keep saying it: Nemerle's 
Algebraic's and pattern matching are freaking awesome and I wish D would 
outright copy it (instead of mucking with the current library solutions).


THIS is how to do Algebraics:
https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching

Re: Why I am switching to Go

[Nick Sabalausky via Digitalmars-d]

On 09/20/2016 03:14 PM, Intersteller wrote:

Vibe.d looks great on the surface but  lack of documentation,


http://vibed.org/docs
http://vibed.org/api

There's also two examples right on the homepage. Did you try scrolling?

I'll grant that the stupid "modern" sales-pitch-first, 
content-hidden-in-small-print-below web design style that's so popular 
and now used on vibe's homepage makes those harder to find than they 
should be, but still, these ARE right there on the homepage, and it's 
very complete.



commonly used functionality,


Not really. Cite examples of such missing functionality?


and that it looks like it is dying suggests that


You're just making that up, aren't you?
Here: https://github.com/rejectedsoftware/vibe.d/commits/master

Not to be a dick, but you really didn't look *at all*, did you?

Re: consequences of removing semicolons in D like in Python

[Nick Sabalausky via Digitalmars-d]

On 09/20/2016 08:20 AM, eugene wrote:

On Tuesday, 20 September 2016 at 12:00:00 UTC, bachmeier wrote:

Without the semicolons, I have to parse the code myself


could you, please, explain, why do you parse code yourself?


That's what happens in the brain when you read code. He's not talking 
about actual LR/LL/etc parsing here, but the mental equivalent. Just 
like you parse a sentence when you read it by noticing the spaces 
defining where words are. And the commas separating sections of a 
sentence, and periods/capitalization separating the sentences, 
in-sentence capitalization signaling proper nouns, etc. All of those are 
*technically* unnecessary too, but notice how much harder it is to read 
(ie, "parse") when they're absent.


thats what happens in the brain when you read code hes not talking about 
actual lr ll etc parsing here but the mental equivalent just like you 
parse a sentence when you read it by noticing the spaces defining where 
words are and the commas separating sections of a sentence and periods 
capitalization separating the sentences in sentence capitalization 
signaling proper nouns etc all of those are technically unnecessary too 
but notice how much harder it is to read ie parse when theyre absent

Re: [OT] Brokerage for the D Language Foundation

[Nick Sabalausky via Digitalmars-d]

On 09/17/2016 12:58 PM, Andrei Alexandrescu wrote:

On 09/17/2016 12:53 PM, Nick Sabalausky wrote:

That's how I hear it worked in the 50's, but does anyone but the brokers
ever gain any real interest from such accounts anymore? From everything
I've ever seen and heard, they pretty much all now work such that
basically all the earnings get scooped off the top by the banks/brokers
themselves (who don't assume any of the risk themselves anymore) leaving
the original investor with nothing more than their original invested
amount. Brokers and managed accounts are turning into the new "savings"
account anymore, you'd (literally) earn more annually just picking up
the loose change you see in a parking lot.


Are you referring to full service brokers, money managers, investment
advisors, and the such? We're not looking for such, only an online
brokerage that allow us to do our own stocks/funds investments. -- Andrei



Ah, yes I was. Guess I misunderstood.

Re: [OT] Brokerage for the D Language Foundation

[Nick Sabalausky via Digitalmars-d]

On 09/17/2016 12:41 PM, Andrei Alexandrescu wrote:

On 9/17/16 11:31 AM, John Colvin wrote:

Ignorant here: Why would the foundation need a brokerage account?


Companies (non-profits included) usually have some cash lying around.
Some of that cash is needed for operational expenses (salaries, rents,
utilities, bills etc) and for more rare expenses (such as DConf). (Our
operational expenses are low, but we expect them to grow.) If there's
more cash than necessary for the company to run for a few months, it
makes sense to invest that cash in order to make more money from it,
which returns back to the coffers of the company. -- Andrei



That's how I hear it worked in the 50's, but does anyone but the brokers 
ever gain any real interest from such accounts anymore? From everything 
I've ever seen and heard, they pretty much all now work such that 
basically all the earnings get scooped off the top by the banks/brokers 
themselves (who don't assume any of the risk themselves anymore) leaving 
the original investor with nothing more than their original invested 
amount. Brokers and managed accounts are turning into the new "savings" 
account anymore, you'd (literally) earn more annually just picking up 
the loose change you see in a parking lot.

Re: consequences of removing semicolons in D like in Python

[Nick Sabalausky via Digitalmars-d]

On 09/17/2016 09:38 AM, eugene wrote:

because a programmer will have a choice of writing or not semicolons, as
one anyway presses "Enter" why not to use it as a line separator, and
one who likes to type semicolons won't be confused if there is backward
compatibility


Other people have already explained the reasons. It all just comes down 
to one thing: There's a class of programmers who will never stop griping 
about trivialities like "Oh my god, I have to type a semicolon?! How 
horrible!"


Can we drop the matter already and get back to something a little bit 
less worthless like tabs vs spaces. If semicolons are such a terrible 
drain, there's always JS and Python. Have fun.

Re: consequences of removing semicolons in D like in Python

[Nick Sabalausky via Digitalmars-d]

On 09/16/2016 07:00 PM, eugene wrote:

Hello everyone,
what if to remove semicolons at the end of each line of code in D like
in Python?
Is it worth it?


Not worth it. Gripes about semicolons are a symptom of only seeing the 
superficial and not really understanding enough about languages to see 
what really is and isn't important. It's like dumping someone because 
you don't like the color of a dress they wore. Superficial, shallow, 
inconsequential bikeshed bullcrap, not even worth debating.

Re: mysql-native v0.1.5

[Nick Sabalausky via Digitalmars-d-announce]

On 09/16/2016 02:41 PM, Rory McGuire via Digitalmars-d-announce wrote:

On 11 Sep 2016 16:57, "Nick Sabalausky via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:

[snip]
... a top priority for mysqln-native at this point.


Hi Nick is that a typo or are you working on a completely different
library? mysqln-native?



Typo. Sometimes mysql-native is referred to shorthand as "mysqln", so I 
guess my fingers just stuttered ;)

Re: mysql-native v0.1.5

[Nick Sabalausky via Digitalmars-d-announce]

On 09/11/2016 07:02 AM, Emre Temelkuran wrote:

There is absolutely no proper documentation (only original's 2011 one).
This is why it's not popular.


Yea, I agree, it's an embarrassment. It's a top priority for 
mysqln-native at this point.

Re: Fully-qualified symbol disambiguation is deprecated???

[Nick Sabalausky via Digitalmars-d-learn]

On 09/09/2016 12:35 PM, pineapple wrote:

On Friday, 9 September 2016 at 11:54:42 UTC, Steven Schveighoffer wrote:

Can you demonstrate the issue? I have never heard of this. imports
should work when done inside a function.

-Steve


Tried and failed to reproduce with a simple example, but any time I've
tried doing it in the code I'm working on I get Symbol Undefined errors
which I had to fix by moving imports out of struct/class methods.


Are those maybe linker errors you're getting? It sounds like maybe the 
build system you're using, rather than the compiler, for some reason is 
rudimentary and isn't using the compiler itself to find dependencies. 
What build tool are you using?

Re: Fully-qualified symbol disambiguation is deprecated???

[Nick Sabalausky via Digitalmars-d-learn]

On 09/08/2016 06:22 PM, Nick Sabalausky wrote:

On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

On 9/8/16 6:02 PM, Nick Sabalausky wrote:

I'm getting deprecation messages ("Package...not accessible here,
perhaps add static import") when simply trying to use fully-qualified
symbol names to disambiguate a symbol. Is this really intended?


Yes.

It's difficult to attribute the message without context, though.


Yea, unfortunately I don't have it narrowed down to a test case, atm.


And
there are still some straggling bugs which cause this message to be
erroneously printed.



I'm pretty sure I've hit one of those :( Can't be certain though until I
examine my specific case further.



Turns out I didn't hit one of those bugs, but one of the problems I was 
hitting was the old problem where package.d completely fucks any and all 
attempts at using a FQN. Worked around with local selective renamed imports.


FQN used to be a real killer feature of D: To deal with name collisions, 
you could *ALWAYS* replace a visible symbol with it's FQN and it would 
*just work*. But now with package.d, UFCS, and 2.071's selective import 
behavior, that benefit's pretty much been shot to hell.

Re: DlangUI 0.9.0: Console backend added

[Nick Sabalausky via Digitalmars-d-announce]

On 09/09/2016 07:21 AM, Vadim Lopatin wrote:

Hello!

Now it's possible to build DlangUI apps to run in console (Linux, Windows).

Some screenshots (from dlangui example1 app):

   http://i63.tinypic.com/2wn1bg9.png
   http://i66.tinypic.com/142yctx.png
   http://i64.tinypic.com/snlc08.png
   http://i64.tinypic.com/2n16vcw.png



Very cool!

Re: Fully-qualified symbol disambiguation is deprecated???

[Nick Sabalausky via Digitalmars-d-learn]

On 09/08/2016 06:22 PM, Nick Sabalausky wrote:

On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

And
there are still some straggling bugs which cause this message to be
erroneously printed.



I'm pretty sure I've hit one of those :( Can't be certain though until I
examine my specific case further.



Oh, although the whole "selective imports don't import the FQN" is a big 
surprise to me. I think at least some of the messages I hit were from 
that. (Can't say I'm a big fan of that particular one, but meh, whatever...)

Re: Fully-qualified symbol disambiguation is deprecated???

[Nick Sabalausky via Digitalmars-d-learn]

On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:

On 9/8/16 6:02 PM, Nick Sabalausky wrote:

I'm getting deprecation messages ("Package...not accessible here,
perhaps add static import") when simply trying to use fully-qualified
symbol names to disambiguate a symbol. Is this really intended?


Yes.

It's difficult to attribute the message without context, though.


Yea, unfortunately I don't have it narrowed down to a test case, atm.


And
there are still some straggling bugs which cause this message to be
erroneously printed.



I'm pretty sure I've hit one of those :( Can't be certain though until I 
examine my specific case further.

Fully-qualified symbol disambiguation is deprecated???

[Nick Sabalausky via Digitalmars-d-learn]

I'm getting deprecation messages ("Package...not accessible here, 
perhaps add static import") when simply trying to use fully-qualified 
symbol names to disambiguate a symbol. Is this really intended?

mysql-native v0.1.6

[Nick Sabalausky via Digitalmars-d-announce]

Another small update, v0.1.6, to fix this: Linker error when using dub 
to import *just* vibe-d:core, but not all of vibe.d.


At least once code.dlang.org notices the new tag.

mysql-native v0.1.5

[Nick Sabalausky via Digitalmars-d-announce]

Tagged a new release of mysql-native: A client driver for MySQL/MariaDB 
written natively in D from scratch via the published protocol specs, 
with no dependency on the C MySQL client library. Supports either Phobos 
or Vide.d sockets (works with or without Vibe.d).


Despite the seemingly low version number, this library is used in 
real-world projects by various people and has been around (with various 
maintainers and contributors) since Steve Teale's original release in 2011.


In this version:
- New: #73: Integration testing via travis-ci. (@Abscissa)
- New: Started this changelog. (@Abscissa)
- Fixed: #20: Contract failure in consume!string (@Marenz)
- Fixed: #50: bindParameters example was wrong (@Abscissa)
- Fixed: #67: Fix unittest for escape (@Marenz)
- Fixed: #70: Check for errors where we expect the greeting packet (@Marenz)
- Fixed: #78: Use vibe-d sub package dependency and a more current 
version (@s-ludwig)
- Fixed: #79: Dub fetch all vibe-d dependencies, even if there is no 
reason (@s-ludwig)


Full changelog:
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md

Future direction:
Priorities need to be a published API documentation and some good docs, 
plus continue addressing the existing issues/PRs.


Github Homepage: https://github.com/mysql-d/mysql-native
On DUB: http://code.dlang.org/packages/mysql-native

Re: D Github contributors - enable 2 factor authentification

[Nick Sabalausky via Digitalmars-d]

On 08/11/2016 05:25 PM, Walter Bright wrote:

On 8/11/2016 7:34 AM, H. S. Teoh via Digitalmars-d wrote:

so no actual code would be lost.


Github dlang is our critical infrastructure, we should treat it
accordingly. I agree we wouldn't lose the code history, but would lose
just about everything else. It would take us days, maybe weeks, to get
things set up again.

Why risk it?


That right there is why gitlab is better. I realize it's too late now, 
but I kinda wish we had standardized on that instead of github. Unlike 
gitlab, github takes all the philosophy, purpose, goals and values of 
git (the very tool it's built for) and throws them straight out the 
window, replacing them with a traditional, very non-git-like 
MS/Facebook-style single-point-of-failure walled garden.

Re: D Github contributors - enable 2 factor authentification

[Nick Sabalausky via Digitalmars-d]

On 08/11/2016 10:56 AM, Kagamin wrote:

On Thursday, 11 August 2016 at 13:35:08 UTC, qznc wrote:

The code is pretty safe thanks to git. The comments get lost.


Irony. Is git still a DVCS? If you lose the central repo, you just lose.


The one big thing that always annoyed me about github is that nearly all 
the features it adds on top of git *lack* all the benefit of using git 
in the first place (ex: decentralization and ability to self-host, git's 
famed speed, etc.)

Re: rdmd configuration files

[Nick Sabalausky via Digitalmars-d]

On 08/11/2016 06:04 PM, Jonathan Marler wrote:

On Thursday, 11 August 2016 at 21:58:35 UTC, Chris Wright wrote:

On Thu, 11 Aug 2016 20:44:12 +, Lodovico Giaretta wrote:

In file rdmd_wrapper.sh:
rdmd -my-special -command-line -parameters $*

When you call it this way:
./rdmd_wrapper mymodule.d


You can add parameters inside the file itself:

#!/usr/bin/rdmd --shebang -m32 -d -I/opt/vibed/source
void main() {}

Maybe not ideal but it works.


This does work when you use rdmd myscript.d does it?  Only when you run
./myscript.d?


And only on posix, not windows.

Re: Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Nick Sabalausky via Digitalmars-d-announce]

On 08/25/2016 06:37 PM, Chris Wright wrote:

On Tue, 23 Aug 2016 12:19:12 -0400, Nick Sabalausky wrote:

Couple very minor updates:


Please, for the love of potatoes, tell people what the project is for!



Oops, right, I did forget that this time, didn't I. Posted too hastily!

Re: Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Nick Sabalausky via Digitalmars-d-announce]

On 08/24/2016 11:16 AM, Martin Nowak wrote:

On Tuesday, 23 August 2016 at 16:19:12 UTC, Nick Sabalausky wrote:


gen-package-version v1.0.4:


What's your stance on including that functionality into dub?


I have nothing against it, I think it would be a fine optional feature 
for dub. I won't be putting together a PR for it though, and I don't 
think there's all that much of a need for it since gen-package-version 
already exists and works AND doesn't require dub to be used as a 
project's build system.


(As much as I love dub for package management, and having the *option* 
of using dub as a build system, dub's built-in build system just isn't 
always the best fit for all projects. Pet peeve: I still find it very 
problematic that there's really no good way to tell dub "don't attempt 
to build this project yourself as this project uses a different build 
system, so just run the following command INSTEAD of directly attempting 
to build". I've tried to fool it into not actually doing the build 
itself, but it's quite messy and problematic. It claims to be usable as 
a package-manager-only, but realistically, that's still only true for 
top-level projects that are never, ever used as a dependency, and not 
for library projects or tools that other projects may wish to rely on.)

Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Nick Sabalausky via Digitalmars-d-announce]

Couple very minor updates:

gen-package-version v1.0.4:
-
Updated docs to include dub.sdl samples, not just dub.json.

https://github.com/Abscissa/gen-package-version


sdlang-d v0.9.6:
-
Issue #39: Remove references to deprecated module std.stream (@lesderid)

https://github.com/Abscissa/SDLang-D

I'm hoping to finally get around to taking care of some of the open 
enhancement requests for sdlang-d soon.

Re: Old COM with D Slides/Presentation?

[Nick Sabalausky via Digitalmars-d]

On 07/29/2016 01:53 PM, ZombineDev wrote:


Is this what you are looking for:
http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

?


Ah, yes, that's it, thanks.

Old COM with D Slides/Presentation?

[Nick Sabalausky via Digitalmars-d]

A few years ago there was a presentation, or maybe only slides were 
posted (I don't recall), that demonstrated D putting C++ and even C# to 
absolute shame for interfacing with COM using some closed in-house D 
library.


I'm trying to search for the slides or any links or anything relating to 
that but can't quite find it. Anyone have anything offhand?

Re: QtE5 - is a wrapping of Qt-5 for D

[Nick Sabalausky via Digitalmars-d-announce]

On 06/20/2016 12:52 PM, MGW wrote:

This my library has about 400 functions from Qt and is quite efficient
for small applications.



Ooh, awesome, this is something D really needs! Definitely going to have 
to give this a try.

Re: Beta release DUB 1.0.0-beta.1

[Nick Sabalausky via Digitalmars-d-announce]

On 06/13/2016 07:31 AM, Kagamin wrote:

On Friday, 10 June 2016 at 17:45:54 UTC, Nick Sabalausky wrote:

On 06/08/2016 11:04 AM, Kagamin wrote:

BTW do people find nested comments particularly useful?


God yes. It's the *only* block comment I ever use. Non-nesting comment
blocks are a worthless PITA with no real benefit: You can't comment
out a block if the block already contains a block comment.


Block comments are low-level: the commented code changes its lexical
structure completely, but you probably don't expect it and want it to
behave and be properly commented at a higher level, which is provided by
version statement.


No, I WANT commenting-out to be low-level, but just not have a stupid, 
useless, badly-chosen rule for when the block ends.


Version(none) is too high-level. I can't use it *within* a statement, 
which means I'd have to use one method to "comment-out" blocks of code 
and a different method when I comment out ex., params, args, or parts of 
an expression (all of which I occasionally do). But why would I want to 
do that when there's one construct (nesting block comments) that works 
perfectly for both AND actually gets highlighted as "disabled" in every 
editor and HTML highlighter out there so I can actually see at a glance 
what's disabled?

Re: Andrei's list of barriers to D adoption

[Nick Sabalausky via Digitalmars-d]

On 06/06/2016 04:15 AM, Russel Winder via Digitalmars-d wrote:


3. Have one lightweight D realized cross platform IDE. Qt us probably
the best widget set to use for this. My model here is LiteIDE which is
a Qt-based Go IDE realized in C++. It should of course be realized in
Go, but there are no Qt bindings for Go, only QML ones.



One thing I've been really wanting to do for awhile (and even moreso 
after switching my main desktop to Linux) is take Programmer's Notepad 2 
(a windows program, but very lightweight and very nice) and try porting 
it to D+Qt (or maybe libui if it gets a Qt backend). Although I don't 
know how realistic Qt on D in right now, and I haven't been able to 
justify the personal time & energy investment, even as much as I'd like 
to :( Just can't find a linux editor I like as much as PN2 :(

Re: Beta release DUB 1.0.0-beta.1

[Nick Sabalausky via Digitalmars-d-announce]

On 06/08/2016 11:04 AM, Kagamin wrote:

BTW do people find nested comments particularly useful?


God yes. It's the *only* block comment I ever use. Non-nesting comment 
blocks are a worthless PITA with no real benefit: You can't comment out 
a block if the block already contains a block comment. You can't include 
a block comment inside documentation's sample code. All for...why?


The only real reason is C-compatibility, which I don't see much of a 
benefit in either - if you're porting C code to D that actually *relies* 
on the goofy behavior of /* */, then the C code's comments are a 
terrible mess and need fixing anyway.


I wish we could just abolish non-nesting comment syntax entirely.

Re: Web page listing all D compilers (and DMDFE version!) on travis-ci

[Nick Sabalausky via Digitalmars-d-announce]

On 06/07/2016 12:05 PM, FreeSlave wrote:

On Tuesday, 26 April 2016 at 06:42:11 UTC, Nick Sabalausky wrote:

https://semitwist.com/travis-d-compilers

That's an auto-generated listing of all versions of DMD, GDC and LDC
available on travis-ci.

[...]


Looks like semitwist.com is down.


Oops. It's back up now.


How about duplicating this list to
github pages?


Not a bad idea.

https://github.com/Abscissa/travis-dc-detect-master/issues/4

Re: Andrei's list of barriers to D adoption

[Nick Sabalausky via Digitalmars-d]

On 06/06/2016 01:49 AM, Ethan Watson wrote:


I linked my DConf talks on a games industry forum, and the first
response was that "It looks like a poor man's Rust". A notion I quickly


The games industry (with some exceptions) has a very deeply rooted 
mentality of "$$$ matters, everything else is teenagers hacking in their 
basement". Naturally leads to: "Rust -> Mozilla -> $$$ -> Valid" vs "D 
-> Volunteers -> Kids dinking around -> Worthless bullcrap". Honestly, I 
wouldn't even bother trying with that crowd. Let them circle the drain 
with their neverending spiral of ballooning-costs.

Re: The Case Against Autodecode

[Nick Sabalausky via Digitalmars-d]

On 06/02/2016 05:37 PM, Andrei Alexandrescu wrote:

On 6/2/16 5:35 PM, deadalnix wrote:

On Thursday, 2 June 2016 at 21:24:15 UTC, Andrei Alexandrescu wrote:

On 6/2/16 5:20 PM, deadalnix wrote:

The good thing when you define works by whatever it does right now


No, it works as it was designed. -- Andrei


Nobody says it doesn't. Everybody says the design is crap.


I think I like it more after this thread. -- Andrei


Well there's a fantastic argument.

Re: [OT] The Case Against... Unicode?

[Nick Sabalausky via Digitalmars-d]

On 06/01/2016 12:26 PM, deadalnix wrote:

On Wednesday, 1 June 2016 at 16:15:15 UTC, Patrick Schluter wrote:

What Joakim does not understand, is that there are huge, huge
quantities of documents that are multi-lingual.


That should be obvious to anyone living outside the USA.



Or anyone in the USA who's ever touched a product that includes a manual 
or a safety warning, or gone to high school (a foreign language class is 
pretty much universally mandatory, even in the US).

Re: The Case Against Autodecode

[Nick Sabalausky via Digitalmars-d]

On 06/01/2016 10:29 AM, Andrei Alexandrescu wrote:

On 06/01/2016 06:25 AM, Marc Schütz wrote:

On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu wrote:


The point is to operate on representation-independent entities
(Unicode code points) instead of low-level representation-specific
artifacts (code units).


_Both_ are low-level representation-specific artifacts.


Maybe this is a misunderstanding. Representation = how things are laid
out in memory. What does associating numbers with various Unicode
symbols have to do with representation? -- Andrei



As has been explained countless times already, code points are a non-1:1 
internal representation of graphemes. Code points don't exist for their 
own sake, their entire existence is purely as a way to encode graphemes. 
Whether that technically qualifies as "memory representation" or not is 
irrelevant: it's still a low-level implementation detail of text.

Re: Dealing with Autodecode

[Nick Sabalausky via Digitalmars-d]

On 05/31/2016 09:36 PM, Adam D. Ruppe wrote:


version(string_migration)
deprecated void popFront(T)(ref T t) if(isSomeString!T) {
   static assert(0, "this is crap, fix your code.");
}
else
deprecated("use -versionstring_migration to fix your buggy code, would
you like to know more?")
/* existing popFront here */



I vote we use Adam's exact verbiage, too! :)



D USERS **WANT** BREAKING CHANGES THAT INCREASE OVERALL CODE QUALITY
WITH A SIMPLE MIGRATION PATH



Yes. This. If I wanted an endless bucket of baggage, I'd have stuck with 
C++.



3) A wee bit longer, we exterminate all this autodecoding crap and enjoy
Phobos being a smaller, more efficient library.



Yay! Profit!

Re: The Case Against Autodecode

[Nick Sabalausky via Digitalmars-d]

On 05/31/2016 01:23 PM, Andrei Alexandrescu wrote:

On 05/31/2016 01:15 PM, Jonathan M Davis via Digitalmars-d wrote:

The standard library has to fight against itself because of autodecoding!
The vast majority of the algorithms in Phobos are special-cased on
strings
in an attempt to get around autodecoding. That alone should highlight the
fact that autodecoding is problematic.


The way I see it is it's specialization to speed things up without
giving up the higher level abstraction. -- Andrei


Problem is, that "higher"[1] level abstraction you don't want to give up 
(ie working on code points) is rarely useful, and yet the default is to 
pay the price for something which is rarely useful.


[1] It's really the mid-level abstraction - grapheme is the high-level 
one (and more likely useful).

Re: The Case Against Autodecode

[Nick Sabalausky via Digitalmars-d]

On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote:

On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote:

On 05/31/2016 03:32 PM, H. S. Teoh via Digitalmars-d wrote:

Let's put the question this way. Given the following string, what do
*you*  think walkLength should return?

şŭt̥ḛ́k̠


The number of code units in the string. That's the contract promised and
honored by Phobos. -- Andrei


Code points I mean. -- Andrei


Yes, we know it's the contract. ***That's the problem.*** As everybody 
is saying, it *SHOULDN'T* be the contract.


Why shouldn't it be the contract? Because it's proven itself, both 
logically (as presented by pretty much everybody other than you in both 
this and other threads) and empirically (in phobos, warp, and other user 
code) to be both the least useful and most PITA option.

Re: The Case Against Autodecode

[Nick Sabalausky via Digitalmars-d]

On 05/30/2016 04:30 PM, Timon Gehr wrote:


In D, enum does not mean enumeration, const does not mean constant, pure
is not pure, lazy is not lazy, and char does not mean character.



My new favorite quote :)

Re: The Case Against Autodecode

[Nick Sabalausky via Digitalmars-d]

On 05/29/2016 09:58 PM, Jack Stouffer wrote:


The problem is not active users. The problem is companies who have > 10K
LOC and libraries that are no longer maintained. E.g. It took
Sociomantic eight years after D2's release to switch only a few parts of
their projects to D2. With the loss of old libraries/old code (even old
answers on SO), all of a sudden you lose a lot of the network effect
that makes programming languages much more useful.



D1 -> D2 was a vastly more disruptive change than getting rid of 
auto-decoding would be.

Re: The Case Against Autodecode

[Nick Sabalausky via Digitalmars-d]

On 05/12/2016 08:47 PM, Jack Stouffer wrote:


If you're serious about removing auto-decoding, which I think you and
others have shown has merits, you have to the THE SIMPLEST migration
path ever, or you will kill D. I'm talking a simple press of a button.

I'm not exaggerating here. Python, a language which was much more
popular than D at the time, came out with two versions in 2008: Python
2.7 which had numerous unicode problems, and Python 3.0 which fixed
those problems. Almost eight years later, and Python 2 is STILL the more
popular version despite Py3 having five major point releases since and
Python 2 only getting security patches. Think the tango vs phobos
problem, only a little worse.

D is much less popular now than was Python at the time, and Python 2
problems were more straight forward than the auto-decoding problem.
You'll need a very clear migration path, years long deprecations, and
automatic tools in order to make the transition work, or else D's usage
will be permanently damaged.


As much as I agree on the importance of a good smooth migration path, I 
don't think the "Python 2 vs 3" situation is really all that comparable 
here. Unlike Python, we wouldn't be maintaining a "with auto-decoding" 
fork for years and years and years, ensuring nobody ever had a pressing 
reason to bother migrating. And on top of that, we don't have a culture 
and design philosophy that promotes "do the lazy thing first and the 
robust thing never". D users are more likely than dynamic language users 
to be willing to make a few changes for the sake of improvement.


Heck, we weather breaking fixes enough anyway. There was even one point 
within the last couple years where something (forget offhand what it 
was) was removed from std.datetime and its replacement was added *in the 
very same compiler release*. No transition period. It was an annoying 
pain (at least to me), but I got through it fine and never even 
entertained the thought of just sticking with the old compiler. Not sure 
most people even noticed it. Point is, in D, even when something does 
need to change, life goes on fine. As long as we don't maintain a 
long-term fork ;)


Naturally, minimizing breakage is important here, but I really don't 
think Python's UTF migration situation is all that comparable.

Scriptlike v0.9.6 - Minor update

[Nick Sabalausky via Digitalmars-d-announce]

This is a minor update to Scriptlike: A utility library to help you 
write script-like programs in D.


- Fixed deprecation warnings with DMD 2.070.x and 2.071.0
- Fixes the Travis-CI build which had been a little bit borked.
- Interact module properly flushes stdout when prompting for user input 
[by Jesse Phillips]


More details in the changelog:
http://semitwist.com/scriptlike/changelog.html

Main site and docs:
https://github.com/Abscissa/scriptlike

On dub:
http://code.dlang.org/packages/scriptlike

Re: IDE - Coedit 2, update 6 released

[Nick Sabalausky via Digitalmars-d-announce]

Also, just a minor wishlist thing, but it'd be nice if the currently 
active file (or project name, or something) was prepended to the 
window's title bar, so it's displays on people's taskbar. That comes in 
handy when using multiple editor windows.

Re: IDE - Coedit 2, update 6 released

[Nick Sabalausky via Digitalmars-d-announce]

On 05/28/2016 09:08 AM, Basile B. wrote:

On Friday, 27 May 2016 at 17:49:18 UTC, Bauss wrote:

On Thursday, 26 May 2016 at 23:44:21 UTC, Basile B. wrote:

Mostly because an important feature of the library manager was not
compatible with DUB > v0.9.24. Otherwise almost nothing.

See https://github.com/BBasile/Coedit/releases/tag/2_update_6 for the
changelog and the binaries.


Is there anyway to get dark theme?


If the native UI of the operating system has a dark theme then Coedit
will have a dark theme too. You just have to adjust the highlighter
attributes, like here:

http://imgur.com/sKCB1Vz


It'd be nice if there was a pre-defined set of dark highlighter 
attributes that could just be selected and then used out-of-the-box or 
as a starting point. In general, manually adjusting editor themes can 
get to be a pain, especially when the color settings are mixed in with 
the rest of the settings.


Seems like a really nice editor though, I just tried it for the first 
time right now. I'd been having a hard time finding an editor I really 
like since switching my main dev machine to Linux (previously had been a 
die-hard Programmer's Notepad 2 user, but it has some issues under wine, 
and of course it doesn't do DCD). Hopefully this one will fit the bill, 
looks nice so far.


Few newbie questions:

- In other editors, I tend to rely very heavily on "Ctrl-Tab" to switch 
between opened files (in most-recently-used order - analogous to Alt-Tab 
in many desktop environments). Is there an entry for that in 
"Options"->"Shortcuts"->"Code editor" so I can set that up? I didn't 
spot one at a glance, but I could've easily overlooked it.


- Regarding "tab vs space" indents, the boolean options eoSpacesToTabs, 
eoTabsToSpaces, and eoTabIndent seem key, but I'm a little unclear on 
exactly how they work, and the "options1"/"options2" in general don't 
appear to be documented (understandable, given how many there are, which 
is nice though, I like configurability. Adjusting software to fit people 
is much better than adjusting people to fit software, and 
"one-size-fits-all" only ever works for hats :) ).


- Mostly wishful thinking but I don't suppose there are any plans for 
elastic tabstops, are there?


- Not an objection really (and I'm sure this has been asked before, so 
pardon that), but I'm curious why it's written in Pascal rather than D. 
Lack of good-enough GUI libs for D? Any plans to port to D down the 
road? It'd likely be easier to get contributors if it were in D, but I 
imagine you probably already figured that. Not trying to push for 
porting of course, I'm just curious.


- I am getting a little bit a weird behavior in a couple places (This is 
on Debian x64, KDE4, FWIW):


When I type 'm' in the editor (without Shift), I get a newline instead 
of an 'm'. The other letters appear to work fine.


Also, in the options editor and the search/replace text box (maybe other 
places as well?), anything I type gets doubled. For example, if I try to 
type in a value of "20", I get "2200". "if" becomes "iiff". Backspace 
works fine, so I can easily erase the extra characters, but something 
seems to have gone weird there.


And the "Find" button doesn't appear to successfully find things even 
when they are there. "Find All" works though.


- It'd be nice if there was a way (if there isn't already?) to set up 
Ctrl-F (or something) to automatically jump to and select the text in 
the "Search" entry box.

Re: Dynamic Bindings to libui (x-platform GUI)

[Nick Sabalausky via Digitalmars-d-announce]

On 05/24/2016 04:52 PM, extrawurst wrote:


So here are the inofficial Derelict Bindings to it:
https://github.com/Extrawurst/DerelictLibui



Some D-oriented docs and example code would be nice.

>
> find libui on github:
> https://github.com/andlabs/libui

Hmm:

> uses the native GUI technologies of each platform it supports
> ...
> Windows: Windows Vista SP2 with Platform Update or newer
> Unix: GTK+ 3.4 or newer
> Mac OS X: OS X 10.7 or newer

Drives me nuts when people count "Always uses GTK on Linux" as "Native 
UI". It's like those programs that do everything completely 
Ubuntu-centric whenever possible and then advertise "Linux Support". I 
*really* wish GTK would just die already.

Re: Github names & avatars

[Nick Sabalausky via Digitalmars-d]

On 05/13/2016 01:19 PM, Adam D. Ruppe wrote:


Actually, given the blatant misogyny frequently on display on this
forum,


Don't claim things that inflammatory when they obviously aren't true.

Re: File size of exe: DMD vs LDC

[Nick Sabalausky via Digitalmars-d]

On 05/09/2016 06:58 AM, Chris wrote:

I have a program whose size is 3.2 MB when compiled with LDC, and 6.3 MB
when compiled with DMD. Both are release builds. That's almost twice as
big.


FWIW, keep in mind that doesn't necessarily imply the same 2x scale will 
still hold for larger programs. Could be as much as 2x, could be as 
little as a constant +3MB.

Re: Command line parsing

[Nick Sabalausky via Digitalmars-d]

On 05/02/2016 08:52 AM, Andrei Alexandrescu wrote:

I found this in https://peter.bourgon.org/go-best-practices-2016/:

"I said it in 2014 but I think it’s important enough to say again:
define and parse your flags in func main. Only func main has the right
to decide the flags that will be available to the user. If your library
code wants to parameterize its behavior, those parameters should be part
of type constructors. Moving configuration to package globals has the
illusion of convenience, but it’s a false economy: doing so breaks code
modularity, makes it more difficult for developers or future maintainers
to understand dependency relationships, and makes writing independent,
parallelizable tests much more difficult."

This is interesting because it's what std.getopt does but the opposite
of what GFLAGS (http://gflags.github.io/gflags/) does. GFLAGS allows any
module in a project to define flags. I was thinking of adding
GFLAGS-like capabilities to std.getopt but looks like there's no need
to... thoughts?



Vibe.d uses a system (built on top of getopt, IIRC) that allows 
different modules to define and handle their own flags. It seems to be 
useful for framework-style libraries where there are certain common 
flags automatically provided and handled by the framework, and then 
individual app developers can add their own program-specific flags. You 
may want to ask Sonke about his specific reasons and experiences with 
that design.

Re: Walter's Famous German Language Essentials Guide

[Nick Sabalausky via Digitalmars-d]

On 05/06/2016 07:04 AM, Chris wrote:

On Friday, 6 May 2016 at 10:46:22 UTC, Andrei Alexandrescu wrote:

We've had several remarks at DConf that the traffic on this forum
makes it intractable. There's good information, but it's drowned by
the immense off-topic discussions.

We plan to create one more forum to address that, but one thing we
could all do to contribute is to refrain from continuing off-topic
comments, or at least mark them with [OT] in the title.


That said, [OT] comments are also important in a community as they bring
people together in a more casual way.



People may object to them, but really, I've BEEN involved in forums that 
tried hard to curb offtopic discussion because the higher-ups were so 
opposed to it, and what inevitably winds up happening is the entire 
forum/community as a whole just implodes and disappears entirely. I do 
NOT want to see D go down that route. Trust me, I've been there, I know, 
it's a mistake. It's a classic case of the cure being worse than the 
disease.

Re: Walter's Famous German Language Essentials Guide

[Nick Sabalausky via Digitalmars-d]

On 05/02/2016 05:49 PM, H. S. Teoh via Digitalmars-d wrote:


Of course, the other great difficulty is the [Chinese] writing system, which
requires the memorization of between 1000-2000 different glyphs just to
be able to read with some fluency.


I'd argue that's really about the same as English:

It is, of course, mostly a myth that English is phonetic (it's what I 
would call "psuedo-phoenetic"). Partly because of that (and contrary to 
popular belief) reading/writing English is done per-word, not per-letter 
(much like Chinese) and requires memorization of thousands of "words", 
each one of which realistically amounts to a complex combination of 
several basic component glyphs (much like Chinese, see next paragraph 
below). And in English (unlike Chinese, to my knowledge) there can be up 
to six different versions of each word, depending on the combination of 
cursive-vs-print and lower-vs-capitalized-vs-all-caps (and that's 
ignoring the fact that there are two different versions of non-cursive 
lower-case 'g', which is a matter of font, not specific to the word itself).


What many westerners who haven't studied Chinese (or Japanese, which 
also uses the Chinese glyphs) don't realize is that all those thousands 
of Chinese glyphs are primarily built as combinations of basic 
"radicals". And there are only around 100 common radicals. That still 
sounds like a lot, but it's really about on par with English: While 
English is said to have 26 "letters", there can be up to four different 
versions of each one (uppercase, lowercase, and print/cursive versions 
of each).


So what we have between English and Chinese writing systems is:

- Both construct words as combinations of component parts.
- Both have around 100 symbols used as component parts.
- Both require heavy memorization of what components are used to 
construct each word.
- Both have alternate ways to write many words (Chinese: Simplified vs 
Traditional. English: Lower/Capital/AllCaps/Cursive/Print)


I say English and Chinese writing systems have roughly equivalent 
difficulty.



But hey, that beats learning
Japanese, which has *three* different writing systems, all of which you
must master in order to be able to read at all!



That's not entirely true if you count English as having one writing system.

Two of the Japanese alphabets (Hiragana and Katakana) are phoenetic 
(much more phonetic than English, in fact), and while they're commonly 
called separate alphabets, it's more accurate to compare them to 
uppercase-vs-lowercase. They're exactly the same set of ~46 letters (not 
counting the ones like "d"/"p"/"b" etc that are treated more as mere 
variations on other letters), each one just comes in both a "Hiragana" 
version and a "Katakana" version. Much like how English letters come in 
an "Uppercase" version and "Lowercase" version (AND, "Cursive" and 
"Print" versions of each of those).


Granted, an alphabet of around 46 seems like a lot, but unlike English 
it has a grid-style organization (vertically: five vowels, then 
horizontally: each consonant combined with each vowel: 
http://www.textfugu.com/wp-content/uploads/2010/01/hiragana-stroke-order-chart.pdf 
). The organization makes it a lighter cognitive load than if you were 
to take English and simply toss in 20 more letters.


The only big difference here between English (upper/lower/cursive/print) 
and Japanese (hiragana/katakana) is *when* each character set is 
selected: For English, it's a matter a grammar (upper/lower) and font 
(cursive/print), for Japanese it's mainly whether the word is native or 
foreign. Note that, if anything, this makes English arguably more 
complicated, in that there's more variety in how each individual word 
might be written.


So if you want to compare to English, Japanese really comes down to two 
writing systems, not three: The phonetic "-kana"s and the Chinese set 
(And even then, depending on target audience, such as for kids, they may 
go easy on using the Chinese set or include the phonetic pronunciation 
right next to the Chinese character).



Japanese and Korean appear to be language isolates, and their respective
grammars are quite unique.


While I know nothing of Korean grammar, what I do find interesting is 
that the system of vocal sounds are very similar for those languages 
(also with Hawaiian, too): Both based largely on vowels and 
"consonant-then-vowel" combinations. I don't see that much in most other 
languages, but it appears to be a trait shared among Japanese, Korean 
and Hawaiian.


The geography suggests to me that Indonesian languages might also be 
like that, but as I have zero awareness of those, I wouldn't know.



Both [Japanese and Korean]
languages also sport a system of honorifics that mostly doesn't exist in
European languages, and may be difficult for an L2 learner to pick up --
addressing somebody with the wrong honorifics can sound extremely
insulting or needlessly polite.



True, but those are pretty 

Re: Walter's Famous German Language Essentials Guide

[Nick Sabalausky via Digitalmars-d]

On 05/05/2016 10:52 AM, H. S. Teoh via Digitalmars-d wrote:

The older, more complex system preserves some of the arguably
flagrant shenanigans by ancient Chinese scribes who went overboard with
the whole derivation from radicals idea and invented some of the most
ridiculously complex characters that nobody uses. This was perceived to
be superior because, well, it was more "literary" (whatever that
means!),


Sounds like "literary" means "enterprisey".

Re: Walter's Famous German Language Essentials Guide

[Nick Sabalausky via Digitalmars-d]

On 05/02/2016 12:22 PM, Jonathan M Davis via Digitalmars-d wrote:


In any case, learning any new language is hard - especially the farther it
is from your own (e.g. Asian languages are going to generally be pretty
brutal to learn for someone speaking a European languages).



That sounds reasonable to expect, but I'm a native english speaker who's 
(attempted to) study both german and japanese, and I found german 
considerably more difficult than japanese. But maybe I'm just weird.


I like to assume the reason was *because* german is so much more similar 
to english (and english makes no sense even to a native speaker!) The 
word genders didn't help, either.


Japanese seemed a little simpler and more logical and consistent overall 
(ex: not only no word genders, but very little singular/plural, and 
answering a negative question is straightforward instead of completely 
backwards like in english[1]). But that perception could have simply 
been due to being a novice at it.


I really do think I never would've been able to learn english if it 
wasn't native to me.


[1] "Did you NOT go to the store?" If it's true that you didn't go, the 
expected answer is..."No". Really?!? Or you could answer either "Yes, 
that's correct" or "Yes, I went" which are *opposite* answers despite 
both being "yes". WTF?!? Even I often have to pause when answering a 
negative question in english. I chalk it up to too many native english 
speakers being stupid and not knowing how to answer questions sanely ;)

Re: So, About That Official Blog...

[Nick Sabalausky via Digitalmars-d]

On 05/06/2016 03:48 AM, maik klein wrote:

On Friday, 6 May 2016 at 03:01:07 UTC, Dicebot wrote:

On 05/06/2016 04:26 AM, Jack Stouffer wrote:

Also, I can just include a simple JS library for the same
auto-highlighting functionality.


Please prefer static generators and pygment-like highlighters to JS
whenever possible. Demanding JS enabled for simple programming blog to
be rendered decently it simply outrageous.


I would also recommend a static site generator, I currently use Hugo
https://gohugo.io/ though it is written it Go haha. Jekyll got really
slow after 30 blog entries, especially if you want to do the syntax
highlighting offline.


I've been moving the direction of hybrid approaches. Kinda like static 
site generating, but the regenerating is done automatically as-needed, 
can receive updates via HTTP GET/POST and do other real-time processing 
during certain requests, etc. I don't know much about off-the-shelf 
website tools out there (or whether there are any that work this way), 
but it's what I did for the travis d compiler list ( 
https://semitwist.com/travis-d-compilers ):


It's fully dynamic templated, driven by Vibe.d and a database, new 
entires are added automatically via HTTP POST, etc, it has REAL 
server-side logic running. But instead of regenerating the HTML page on 
every request (or dynamically regenerating a JSON/XML description of the 
data on every request for client-side JS to then render - an approach I 
never really understood), the Vibe.d-based site simply regenerates a 
static HTML page when the *data* changes, which on most web pages is 
much less frequent than actual page requests.


There are other ways to adjust static/dynamic balances too. There's 
usually a LOT of components on even a fully-dynamic page that ARE 
pre-cachable, even if the page as a whole isn't:


For example, a classic case where a static site generator wouldn't work: 
An online shopping search results page. You can't predict ahead of time 
what queries will be run and pregenerate entire results pages, but you 
CAN pregenerate divs for how each individual item will be displayed when 
it does appear in someone's results page. Then when someone runs a 
search you just write the appropriate pre-built divs to the output 
stream, one after the other.


In short: Hybrid site generating :) Only generate on-the-fly what NEEDS 
to be on-the-fly. Only regenerate things when they change, not every 
time they're viewed (unless they change more than they're viewed, like 
maybe an admin-only site webstats page, but such cases are rare).

Re: So, About That Official Blog...

[Nick Sabalausky via Digitalmars-d]

On 05/05/2016 05:25 PM, Jacques Müller wrote:

On Thursday, 5 May 2016 at 18:22:50 UTC, Jack Stouffer wrote:

blog: http://officaldlang.tumblr.com/


That's nice! But it seems like you misspelled the blog title.



It's a feature, it keeps with web 2.0 tradition! :)

Re: How are you enjoying DConf? And where to go next?

[Nick Sabalausky via Digitalmars-d]

On 05/06/2016 10:13 AM, Andrei Alexandrescu wrote:

The atmosphere here is great, and I'm curious how it feels for those who
are watching remotely. Is the experience good? What can we do better?



The livestream videos requiring flash was a bit of an issue.


Also: we're talking about the DConf 2017 location. Please share any
initial thoughts!



Cleveland!

Re: Web page listing all D compilers (and DMDFE version!) on travis-ci

[Nick Sabalausky via Digitalmars-d-announce]

On 05/07/2016 05:44 AM, Johan Engelen wrote:

What I mean is: currently the Name column says e.g. "ldc2-0.17.1", but
in the travis.yml file you must specify "ldc-0.17.1" to get it (without
the "2").


Ahh, you're right, I hadn't noticed that.

Re: Researcher question – what's the point of semicolons and curly braces?

[Nick Sabalausky via Digitalmars-d]

On 05/04/2016 02:29 PM, Anon wrote:

On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

It's touchy, because I've come across people who actually do genuinely
believe the field has things in place deliberately to exclude
women/ethnicities...even though...those VERY SAME people have never
once been able to provide a SINGLE CONCRETE EXAMPLE of any of these
alleged mechanisms they believe so strongly to exist.


Cognitive biases are a thing. People assume women are bad at math.
People assume black people are violent thugs. People assume Asians are
savant-level geniuses. People assume Native Americans are alcoholics.
People assume Arabs are Muslims. People assume Muslims are terrorists.
Those assumptions and biases dictate how we interact with the world.
Sociology can describe systems and mechanisms that aren't controlled by
people or even intentional. People do not even need to be aware of their
biases. That doesn't make them not exist.



I'm well aware people with those biases do exist. The word for that is 
"bigot". And they often DO attempt to project their hateful biases onto 
others, believing that everyone feels the same way they do and simply 
doesn't admit it. I guess that delusion just helps them feel better 
about themselves, or help justify their twisted perceptions to 
themselves? In any case, they do very strongly and consistently reject 
the fact the rest of us really honestly don't share the same twisted 
biases they do, and will never allow themselves to be convinced otherwise.

Re: Researcher question – what's the point of semicolons and curly braces?

[Nick Sabalausky via Digitalmars-d]

On 05/04/2016 03:15 PM, Chris wrote:

On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

[snip]



Verifiable fact: My sister paid considerably less than I did for each
year of college even though we came from EXACTLY the same economic
background, exactly the same city/town, exactly the same ethnicity,
nearly the same age (and yet she's slightly younger, so if anything,
increasing tuition rates would have worked AGAINST her), and one of
our respective colleges was even the exact same school. And her pay
now is (considerably) higher than mine, and she works in a field
that's known to pay LESS than my field.


There are groups in Europe and the US (and elsewhere I'm sure) who try
to draw attention to this issue, like these guys for example
http://www.avoiceformen.com/.



Unfortunately does no good: Any association with anything like that 
means automatic social black-listing as "women hater". And it's never 
going to convince anyone of anything for the same reason persuasive 
arguing in general never really works: Anyone who doesn't already agree 
will never willingly go anywhere near it, except occasionally with a 
purely "burn the witch" agenda.


Perfect example of why all people worldwide should simply be destroyed:

https://www.youtube.com/watch?v=7M0MW6ON484

Sickening, and not the least bit surprising.

There was another similar thing on a hidden camera show, showing actors 
eating right out of a grocery store produce aisle. When the actor was a 
guy, both men and women bystanders were livid, but when it was a woman, 
both men and women bystanders found it cute and acceptable.


And then there's all the studies out there demonstrating how many times 
more likely a woman with a broken-down car by the side of a road will 
receive assistance than a guy will.


But of course, all of that evidence is merely a plot by us evil men 
trying to wage war on women.



Anti-female systems in place? Bull fucking shit. Anyone who claims
there are: put up REAL fucking examples instead of parroting vacuous
rhetoric or shut the fuck up forever.


My experience with computer science and related fields is that a lot of
young women are into computers, just not into programming. They are
drawn to computers because of multi-media stuff, digital design,
creating videos, creating games (often educational games for kids) with
easy to use frameworks. The closer you get to the machine, the less
women you will find (mind you, this does not mean "no women at all"), to
give you a _rough_ scale of increasing complexity: multi-media and
social networks (e.g. blogs) > app development > Python > Java > C/C++ >
compiler programming / assembly ...



Right. And then all the males in the field get blamed for it when the 
women simply chose of their own volition not to pursue it. It must've 
been our ingrained biases ::rolleyes::. Right, because we have to 
pretend EVERYONE has those moronic biases just because it helps the 
fucking bigots pretend they're really just "normal".


Interesting side note: Notice that, due to another recent thread here, I 
had to use the word "women" rather than "females" in that last sentence, 
but nobody raises an eyebrow at usage of "males" being used to refer to 
people, not even in my earlier post in this thread.

Re: Researcher question – what's the point of semicolons and curly braces?

[Nick Sabalausky via Digitalmars-d]

On 05/04/2016 12:16 PM, deadalnix wrote:

On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

On 05/04/2016 10:23 AM, deadalnix wrote:


We need to acknowledge that there are system of oppression that keep
women and people of color out of programming,


Hard to tell for certain, but you ARE being sarcastic/joking about
this, right?



The concept of sarcasm plays a central role in understanding society's
inevitable development from bourgeois oppression, which, in turn,
amplify existing structures of exclusion. Please educate yourself.



That really doesn't answer the question, but that's ok, wasn't really 
that important of a question to me.

Re: Researcher question – what's the point of semicolons and curly braces?

[Nick Sabalausky via Digitalmars-d]

On 05/04/2016 10:23 AM, deadalnix wrote:


We need to acknowledge that there are system of oppression that keep
women and people of color out of programming,


Hard to tell for certain, but you ARE being sarcastic/joking about this, 
right?


It's touchy, because I've come across people who actually do genuinely 
believe the field has things in place deliberately to exclude 
women/ethnicities...even though...those VERY SAME people have never once 
been able to provide a SINGLE CONCRETE EXAMPLE of any of these alleged 
mechanisms they believe so strongly to exist. Not only that, but I've 
yet to come across an anti-minority or anti-female programmer, and even 
if such creatures exist, they're undeniably var too much in the minority 
to have any real large-scale effect on "keeping people out". The vast 
majority that I've seen are far more likely to *dislike* the field's 
current gender imbalance.


In much the same way programming is predominantly male (or "a goddamn 
sausage-fest" as I see it), nursing is predominantly female. So why did 
none of US pursue careers in nursing? Was it because we hit roadblocks 
with systems in place within the nursing field designed to exclude 
males? Or was it because we just plain weren't interested and had the 
freedom to choose a field we DID have interest in instead?


Systems DO undeniably exist, for this very field, that are very plainly 
and deliberately sexist or racist though...but just not in the way some 
people believe. Unlike the others, I CAN provide a real concrete 
verifiable example: There are a lot of Computer Science grants and 
scholarships for students that list "female" or "non-caucasian" (or some 
specific non-caucasian race) as a mandatory requirement. I came across a 
bunch of those when I was trying to get financial aid for college. But 
there are NONE that require "male" or "caucasian" - it would never be 
permitted anyway, they'd get completely torn to shreds (and for good 
reason). The only ONE I did hear of was only a publicity stunt to point 
out the hypocrisy of all the sexist anti-male grants/scholarships.


Verifiable fact: My sister paid considerably less than I did for each 
year of college even though we came from EXACTLY the same economic 
background, exactly the same city/town, exactly the same ethnicity, 
nearly the same age (and yet she's slightly younger, so if anything, 
increasing tuition rates would have worked AGAINST her), and one of our 
respective colleges was even the exact same school. And her pay now is 
(considerably) higher than mine, and she works in a field that's known 
to pay LESS than my field.


Anti-female systems in place? Bull fucking shit. Anyone who claims there 
are: put up REAL fucking examples instead of parroting vacuous rhetoric 
or shut the fuck up forever.


I've had far more than enough of the mother fucking baby-goddamn-boomers 
and GI-generation dragging THEIR bullshit war-of-the-sexes out the the 
goddamn 1950's where it belongs and forcing it onto MY 1980's+ 
generation. I literally grew up subjected to a constant barrage of 
"*GIRLS* can do/be ANYTHING they want", never a goddamn word about guys 
except to constantly villanize us and demand that we're always the 
enemy, even though *3* motherfucking decades separated me from all YOUR 
historic sexist crap, so, boomers, goddamn GI's, and the younger idiots 
they've infected with their "this is still 1950, and we must war against 
the oppressive males" propaganda, hurry up and die so we can finally be 
rid of YOUR legacy and the sexism you create and maintain. Fuck the 
pendulum, just stop the goddamn thing right in the middle already. 
People are morons.

Re: [OT] Swift removing minor features to piss me off

[Nick Sabalausky via Digitalmars-d]

On 04/28/2016 02:49 PM, Steven Schveighoffer wrote:

This is what bouncing the rubble looks like.

1. Swift 3 will no longer allow mutable variables as parameters.
Instead, your parameters will be immutable, or reference (inout). To fix
this, you can assign your immutable variable to a mutable one
(immutability is always head immutability in swift), or put this weird
statement in your function:

var i = i (which you may think causes i to now be mutable, but in
actuality declares a NEW variable to shadow the old).

2. Swift 3 will no longer accept ++. You must write += 1.

Please, D, don't ever do this kind of stuff! I just gained about 45
warnings in my iOS project. Most of the var function parameters were
suggested by the IDE...

-Steve


Not surprised. Removing features is all the rage in the software world 
these days. This is one fad I can't wait to see die. Hopefully this one 
won't drag on as ridiculously log as pants-sagging did, but I'm not 
holding my breath.


I say forget playing the "fire and motion" game. Just avoid the big five 
"our way-of-the-week or the highway" trend-factories (Google, Apple, 
Mozilla, Microsoft and Gnome) and everything should be (relatively) fine.

Re: Web page listing all D compilers (and DMDFE version!) on travis-ci

[Nick Sabalausky via Digitalmars-d-announce]

On 04/28/2016 04:03 PM, Seb wrote:


FYI you miss the available ldc alpha and betas. On purpose?


Didn't initially occur to me, but I'd say that's a "possible future 
enhancement". It will take more work, and some extra thought, to figure 
out how to handle:


Right now, my tool relies on the ability to say in .travis.yml "just 
give me the latest available version" (by saying, ex "dmd" instead of 
"dmd-2.070.0"). Then my tool checks which version that turned out to be 
and posts it. I'm not aware of an equivalent that includes alpha/beta 
releases. I wonder if it would be easy enough for the folks handling D 
on travis to add? That would be the easiest way for me.


I *could* manually trigger it for each alpha/beta *already* available 
(like I did to initially populate the database with all the earlier 
versions of everything). I guess that would be information worth 
archiving. But that still doesn't give me a way to capture new 
alphas/betas automatically. Hmm, I do have an idea for how to do that, 
but it may be a little convoluted so I'd have to get to it later.


I guess...we'll see ;)

Re: Web page listing all D compilers (and DMDFE version!) on travis-ci

[Nick Sabalausky via Digitalmars-d-announce]

On 04/26/2016 02:42 AM, Nick Sabalausky wrote:

https://semitwist.com/travis-d-compilers

...

- Auto-trigger an update check on a regular basis (I'm thinking once
daily?) so I don't have to stay on top of new compiler versions and
trigger an update manually. (I can use Travis's API to do this.)



The page is now set to automatically check for updates every 24 hours. 
So it should always be automatically up-to-date now. No intervention 
needed by myself or any of the DMD/LDC/GDC developers.

Re: So... let's document dmd

[Nick Sabalausky via Digitalmars-d]

On 04/05/2016 05:40 PM, Walter Bright wrote:


I don't really understand why IDE makers don't use an actual programming
language for plugins


Programmer's Notepad 2 uses Python for plugins. Although the syntax 
highlighting is done through Scintilla which has it's own separate 
(non-programming-language IIRC) system for lex/parse.

Re: the most D-ish GUI library

[Nick Sabalausky via Digitalmars-d]

On 03/30/2016 10:48 AM, Jacob Carlborg wrote:

On 2016-03-29 19:37, Nick Sabalausky wrote:


Win and Mac:
Qt looks native.


For OS X, no not really. Although that might be due to the applications
and not Qt.



Last I used OSX even Apple's own programs were fairly inconsistent with 
each other. I guess that's changed?


In what ways does Qt stuff not look native on OSX? How does it compare 
to GTK on OSX?

Get third part of front-end version number

[Nick Sabalausky via Digitalmars-d-learn]

These days, DMD/DMDFE version numbers are three parts, ex: 2.070.1.

I can get the first two via std.compiler.version_major and 
std.compiler.version_minor. Is there a way to get the third part?


I know I can "dmd --help | grep DMD", but that only works for DMD. GDC's 
"gdc --version" doesn't appear to show the DMDFE version, and I have no 
idea about LDC.


Or is the third part of the DMDFE version completely irrelevant to LDC/GDC?

Re: the most D-ish GUI library

[Nick Sabalausky via Digitalmars-d]

On 03/28/2016 01:21 PM, WebFreak001 wrote:


You are right, i forgot Qt/KDE guys. KDE uses Qt for their programs and
stuff but GNOME and the Ubuntu team and most desktop environments do use
GTK instead of Qt. Qt is more common on OS X and Windows than on linux.
I guess there will never be an absolute winner to something because
there are always people using something different.



Win and Mac:
Qt looks native.

Linux/KDE:
Qt is native.

Linux/GNOME (and any other Linux DE based on GTK):
Use the QGtkStyle theme:

It's a theme for Qt that *uses* GTK to render, therefore actually being 
native. (I've never actually used it though, since I think native 
GTK/GNOME/etc looks visually awful regardless of theme. And those file 
dialogs, ugh! Wish I could nuke those from my entire system.)


Note that an equivalent of QGtkStyle which goes the other way (rendering 
GTK programs using Qt) is no longer possible since GTK recently 
eliminated non-CSS themes (in a point release, no less).


Therefore, Qt *is* the absolute winner here. It's basically native 
everywhere. GTK isn't, and without a major policy reversal, cannot be.

Re: Females in the community.

[Nick Sabalausky via Digitalmars-d]

On 03/25/2016 03:40 PM, ag0aep6g wrote:

On 25.03.2016 15:56, Nick Sabalausky wrote:

On 03/17/2016 01:02 PM, ag0aep6g wrote:

"A female" sounds like you're
talking about an animal.


Not to a native english speaker.


I call bullshit on that. I don't have any strong evidence, and I'm not
even a native English speaker myself, but I simply don't buy it.

Here's the first Google hit I got for "animal documentary male female":

https://youtu.be/kY7SlH3rzhQ?t=430

Didn't take long to find a spot where they talk about "the males" and
"the females", because they always do in animal documentaries.

Note how the speaker switches from "male"/"female" for kangaroos to
"man"/"woman" for humans. That's what I'm talking about.


Of course they switch like that: It's an animal documentary, it helps to 
have an extra verbal cue for clarification when they switch between 
talking about animals vs humans. "Man"/"Woman" implies "Human". 
"Male"/"Female" are more generic than that. That's why they switch. Not 
because "Male"/"Female" implies "Non-Human" (it doesn't), but because 
"Man"/"Woman" DOES imply "Human" - an obviously important distinction in 
an animal documentary.


Regardless of that, the whole matter is dead simple, though many are too 
blinded by fear of offending to see the blatantly obvious:


Any "man" here who TRULY DOES get offended (and not just thinks he 
should get offended, or that other guys might be offended) by being 
called "A *MALE*" can go ahead and argue about "a woman" being 
offensive. Anyone else needs to drop their paranoid, self-contradictory 
bullshit.

Re: Mindset of the D team vs the Rust team

[Nick Sabalausky via Digitalmars-d]

On 03/24/2016 12:50 PM, Bruno Medeiros wrote:

On 24/03/2016 09:16, Walter Bright wrote:


We're doing just fine with NNTP and Vladimir's forum software.


Using old communication software like NNTP is one example of that.
Compare with Rust's Discourse.



The only thing wrong with NNTP is that it isn't trend/hipster-compliant. 
We have better things to deal with than endless Fire and Motion: 
http://www.joelonsoftware.com/articles/fog000339.html




Not understanding the importance of package managers is another (DUB
still not part of official distro?) Compare with Rust's Cargo.



Dub does need work. It's great for simpler projects and libs, but it's 
still next-to-useless for anything that JUST wants to participate in the 
package repository and uses a different build system (or even rdmd for 
that matter). There's some other issues as well. I've spent a lot of 
time and effort trying to fix that, but it's been an exhausting uphill 
battle, both technically and politically.

Re: Females in the community.

[Nick Sabalausky via Digitalmars-d]

On 03/17/2016 01:42 PM, John Colvin wrote:


P.S. what's with calling women "females", is it an americanism? It
sounds super weird to a British ear, we'd normally only say "female" in
a technical setting or about an animal, so it can sound a bit
disrespectful.


I don't know about over there, but in the US political correctness 
issues get everyone whipped into a hysterical frenzy, so words like 
"male"/"female" are an (obviously failed, by the sound of it) attempt to 
sidestep all that "hurt feelings" bullshit by using terms that (we would 
think) couldn't possibly be construed as slurs.


If someone can't even freaking figure out WHY they find a word 
offensive, they have no damn business squaking about it allegedly being 
offensive. For fuck's sake, people.

Re: Females in the community.

[Nick Sabalausky via Digitalmars-d]

On 03/17/2016 01:02 PM, ag0aep6g wrote:


I can't be the only one who is irritated by this use of the word
"female". Why do you avoid "woman"?


"Woman" excludes non-adults. Non-adult, like I was when I started with code.

That's the problem with PC nitpicking, it never ends.


"A female" sounds like you're
talking about an animal.


Not to a native english speaker.

Re: the most D-ish GUI library

[Nick Sabalausky via Digitalmars-d]

On 03/13/2016 06:33 PM, WebFreak001 wrote:


I prefer GtkD, its the most system native one on linux


I dispute that. Many people, like myself, use KDE rather than GNOME or 
Unity, and GTK programs are just as horrible to put up with in this 
environment as they are on Windows. Even more so since the GTK folks 
have now decided it's acceptable to remove an entire theming engine in a 
freaking point release. For that and various other reasons, GTK is a 
plague upon ANY operating system, and a big part of that ultimately 
comes down to colossal mismanagement - the one part of any project 
that's the hardest to fix.

Re: Why don't you use the Github issue system?

[Nick Sabalausky via Digitalmars-d]

On 03/02/2016 07:57 PM, sigod wrote:

On Thursday, 3 March 2016 at 00:27:39 UTC, Walter Bright wrote:

3. If Github goes dark, we still have our local complete copies of the
git database. If Github issues goes dark, we lose it all. We control
the Bugzilla database. This database is ABSOLUTELY CRITICAL to D's
future, and not having a copy of it is absolutely unacceptable.


This annoys me a lot in all repository hosting services.


Hear hear!

Re: Argon: an alternative parser for command-line arguments

[Nick Sabalausky via Digitalmars-d-announce]

On 03/02/2016 02:50 PM, Markus Laker wrote:

https://github.com/markuslaker/Argon

Let me know if you do something interesting with it.

Markus



Reminds me of one I used years ago for C#: I like the approach, it's a 
good one. Getopt by comparison, while very good, always seemed like a 
kludge to accomplish a similar thing without the benefit of user 
attributes (which D lacked at the time).

Re: Running DMD tests on Windows / build requirements

[Nick Sabalausky via Digitalmars-d]

On 02/19/2016 07:25 PM, Martin Krejcirik wrote:

How do I run DMD tests on Windows ? I'm not able to, even with gmake.



Unless things have changed since I last looked, DMD's Windows makefiles 
are written for Digital Mars Make, not gmake. The gmake makefiles are 
for Posix. And don't forget you'll need to specify the correct makefile 
to make "-f win32.mak": Since the windows/posix makefiles are separate 
neither is named "makefile".



Also, is it possible to compile DMD with MSVC ?



I don't know whether MSVC works, but the traditional way to compile the 
C++ parts on Windows is using the Digital Mars C++ compiler, DMC. So 
even if MSVC doesn't work, DMC definitely should.


Keep in mind, you'll also need a D compiler already installed. DMD will 
definitely work, and I *think* LDC and GDC are also supposed to work.



And third question, what are the minimal (by size, not by version)
VS/VC/SDK requirements to compile Phobos with -m64 and -m32mscoff ?



This one I don't know.

Re: [OT] Some neat ideas from the Kotlin language

[Nick Sabalausky via Digitalmars-d]

On 02/19/2016 07:16 AM, Jacob Carlborg wrote:

On 2016-02-19 00:33, Yuxuan Shui wrote:

Just come across Kotlin today, and found some interesting ideas skimming
through its tutorial:

1) Null check

Kotlin has Optional types, suffixed with a '?'. Like 'Int?', same as in
Swift. But instead of explicitly unwrapping them (e.g. var! in Swift, or
var.unwrap() in Rust), Kotlin let you do this:


 var: Int?
 if (var != null)
 //You can use var here



Me want.




2) Smart cast

This is a similar to previous one, instead of:

 var1: Object;
 var2 = cast(String)var1;

You do this:

 if (var1 is String)
 //You can use var1 as a String here


It's similar how it works in D, for Objects:

class Foo {}
Object foo = new Foo;

if (auto o = cast(Foo) foo)
 // use o as Foo here

When casting to a subclass it will return null reference if the cast fails.



It'd be nice if it didn't require a new variable name though. When I do 
that, I usually find I wind up needing to resort to some 
hungarian-notation-inspired "start including the type in the variable's 
name" verbosity. It's a fantastic feature of D, but that Kotlin version 
seems much nicer.

Re: Official compiler

[Nick Sabalausky via Digitalmars-d]

On 02/18/2016 09:22 AM, Dejan Lekic wrote:

Lots of programmers out there use and love languages that are far slower
than any code DMD produces (think JavaScript, Python, Ruby). So I see no
point here.


While that's true, my impression is most of the users and fans of those 
languages use them *because* they're fundamentally dynamic (unlike D), 
deliberately lacks every feature they possibly CAN lack (unlike D), and 
lack all the compile-time safety that D promotes as features.


So regarding those langauges' reduced speed, while many of their users 
don't care one bit ("why aren't you a consumer whore like me? go buy a 
new machine, you dinosaur!"), there seems to also be a large population 
that merely *tolerates* the lower speed for the sake of the dynamicness 
and the lack-of-compile-time-anything that they love. The first group 
will likely never be tempted by D regardless, but for the second group, 
a language that's fast like C/C++ but not nearly as unproductive IS 
appealing, and even seems to be something they're often on the lookout for.

Re: Just because it's a slow Thursday on this forum

[Nick Sabalausky via Digitalmars-d]

On 02/10/2016 02:47 PM, H. S. Teoh via Digitalmars-d wrote:

On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via Digitalmars-d 
wrote:

On 02/10/2016 02:25 PM, Nick Sabalausky wrote:

I see no non-trivial cost.


I, to, am not getting the cost story. H.S. Teoh, could you please
substantiate? -- Andrei


Sorry, I meant technical debt.  My point was that this function needs to
provide more value than what's effectively just an alias for
writefln("%s, %s, %s", x, y, z).



Having used an equivalent to the proposed "dump" for many years (and an 
inferior equivalent at that), I can attest that it definitely provides 
sufficient value over write* functions. With write*, there's always 
either excess verbosity that just gets in the way of my "flow", or I can 
opt the succinct route and wind up looking at a dump of numbers finding 
it difficult to know what number is what variable. Any homemade 
wrapper/alias only creates even MORE work when trying to use it. Anyone 
may be skeptical of the reasons, but it doesn't matter because again, 
this is all direct personal experience, not hypothetical theorizing.


In short: Yes. Yes it does provide sufficient value. And the "technical 
debt" is still vastly less than the time, effort and bother of having to 
defend yet another clear improvement on the D perpetual debate forums.

Re: OT: 'conduct unbecoming of a hacker'

[Nick Sabalausky via Digitalmars-d]

On 02/11/2016 06:53 AM, Dejan Lekic wrote:


I know some will disagree with me, but I will say it anyway: IT
community, especially developers, are known for poor social skills...
People tend to forget that...


There may be a certain *small* level of truth to that, but most of it is 
nothing more than decades of Hollywood's pejorative stereotyping. And 
people being naive enough to believe what they see in the fiction that 
was produced by people who have spent decades proving themselves to have 
zero comprehension of basic reality, let alone even a basic high-school 
level research ability.


It's the standard old Hollywood complete and total disconnect with 
reality - hell, look how they portray Tourette's a having a relationship 
to swearing (which is just plain bizarre to anyone actually capable of 
spending a mere one minute on a basic web search), or how cracking 
security always involves playing a 3D puzzle game. And then there's the 
oddity that any time a writer or director uses a computer in real life, 
the machine is clearly built to detect it's being used by Hollywood 
personnel, so all login systems automatically switch from the normal 
"Username and Password don't match \ Incorrect login \ Password was 
incorrect" to a flashing red "ACCESS DENIED". Because presumably they 
actually see this flashing red "ACCESS DENIED" when they actually do use 
a computer in real life, because they couldn't really be THAT dumb when 
producing a film, right? At least that's the only explanation I can come 
up with for its appearance in otherwise "realistic" movies, at least 
aside from LSD...which really could explain all the rest of their 
delusions too...hmm...


Hollywood mental flakes spend decades inventing and reinforcing their 
own myopic stereotypes, such as "technical ability == dorks with no 
social skills", most likely because they feel threatened by people with 
at least half a function brain (which most of them clearly lack), and 
then the masses believe it, and it becomes *cough* "fact". That's all 
there is to it.

Re: Just because it's a slow Thursday on this forum

[Nick Sabalausky via Digitalmars-d]

On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:


Fair enough.

Personally, though, I find a bunch of comma-separated values very
unhelpful. It would be much better if they were labelled, e.g., if:

int x, y, z;
dump(x,y,z);

outputs:

x=1, y=2, z=3

it would be much better than just:

1, 2, 3

which is unclear which values belongs to which variable. Trivial to
figure out in this case, but it's not as obvious when interspersed
between other program output & debug messages. But maybe that's just a
matter of habit, and difference in personal debugging style.



My understanding is that's the whole point of the "dump" function being 
discussed. Unless I misunderstood?

Re: Just because it's a slow Thursday on this forum

[Nick Sabalausky via Digitalmars-d]

On 02/11/2016 04:44 PM, John Colvin wrote:

On Thursday, 11 February 2016 at 21:38:42 UTC, H. S. Teoh wrote:

On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via
Digitalmars-d wrote:

On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
>[...]

My understanding is that's the whole point of the "dump" function
being discussed. Unless I misunderstood?


IMO `dump` is worthwhile but `print` seems little more than an alias
for `writefln`. I can't find enough justification to warrant `print`.
(Next thing you know, newbies will be asking why there's both `print`
and `write` that do the same thing except different.)


T


yeah, dump is really useful, print is a bit marginal.


Ahh, I missed the "print" stuff. I do agree it's not as useful as 
"dump", plus the name seems to suggest a connection with printf, which 
strikes me as confusing.


I do think the "print" function discussed (ie, like writeln, but 
auto-inserts spaces between the args) is occasionally nice for 
script-like programs. In fact, I think I have a function like that in 
Scriptlike specifically because of that...unless it's back in my older 
utility library instead...


I'd be perfectly happy to have it, particularly if it had a less 
confusing name, but can definitely see it being debatable whether it 
really is Phobos-worthy.

Re: OT: 'conduct unbecoming of a hacker'

[Nick Sabalausky via Digitalmars-d]

On 02/11/2016 04:54 PM, w0rp wrote:

His article is way too long. It seems like an article about whining
about how people whine too much.


It's metawhine! :)