Re: Erasing passwords from ram?

[Nick Sabalausky via Digitalmars-d-learn]

On Tuesday, 30 April 2019 at 08:15:15 UTC, Dukc wrote:
I am currently programming a server. So I got the idea that 
after I've generated all the hashes I need from a password, I 
want to erase it from RAM before discarding it, just to be sure 
it won't float around if the server memory is exposed to 
spyware by some buffer overflow. Is this wise caution, or just 
being too paranoid?


I've seen this done, and regardless of likelihoods, it doesn't 
hurt as a precaution.


The memutils lib offers a tool for this, 'SecureMem':
http://code.dlang.org/packages/memutils

In addition to memory-zeroing, it can also prevent it from 
getting "dumped to disk on a crash or during OS 
sleep/hibernation."

Re: New Initiative for Donations

[Nick Sabalausky via Digitalmars-d-announce]

On Friday, 26 October 2018 at 02:38:08 UTC, Joakim wrote:
On Thursday, 25 October 2018 at 22:35:40 UTC, Nick Sabalausky 
wrote:


And yet it's still by far the most common payment method. So 
what if it isn't trendy. Deal with it.


In the US maybe, not in most of the world, where they're still 
using cash. ;) I almost never use my cards, and like that 
crypto-currencies have more in similar to cash.


I was referring to internet payments, as that was the 
conversation's context.


And you're right that cash is extremely common outside the net. 
Note that cash is considerably older than even credit/debit cards.



On Thursday, 25 October 2018 at 23:10:50 UTC, H. S. Teoh wrote:


Common fallacy: new == better.


As with D, sometimes the new _is_ better, so perhaps you 
shouldn't assume old is better either.


Nobody claimed otherwise.

Re: New Initiative for Donations

[Nick Sabalausky via Digitalmars-d-announce]

On Wednesday, 24 October 2018 at 10:25:17 UTC, Joakim wrote:
On Wednesday, 24 October 2018 at 10:18:51 UTC, Mike Parker 
wrote:

On Wednesday, 24 October 2018 at 10:12:50 UTC, Joakim wrote:



Any effort underway to take Bitcoin Cash, Ether, or Ripple as 
donations? The current payment options seem fairly 
antiquated: credit cards, wire transfers, and the like.


Not that I'm aware of. I'd hardly call credit cards 
antiquated, though :-)


60-year old tech seems pretty old to me:

https://en.m.wikipedia.org/wiki/Credit_card#BankAmericard_and_Master_Charge



And yet it's still by far the most common payment method. So what 
if it isn't trendy. Deal with it.

Re: D now has a dangerous competitor

[Nick Sabalausky via Digitalmars-d]

On Tuesday, 28 August 2018 at 21:57:28 UTC, solidstate1991 wrote:


Thanks to my education, I first wanted to approach every 
problems in programming from an object-oriented viewpoint, 
since that was the only one we were taught.




Sounds like you were more or less lucky compared to average: For 
a long while, OOP wasn't just the only thing taught, it was 
frequent taught specifically to be "the one and only right way."


It's not so much OOP itself that's hated: It's the late 90's 
early 2000's obsession that OOP is the one right way to do 
EVERYTHING that gets a lot of (much deserved) hate.


I used to do a lot of OO myself (in fact, Tango was very heavily 
rooted in OOP design), but the more I use D2 and other things, 
the more convinced I am that there are just simply better 
mechanisms (provided the language in question supports them well 
enough) to get the benefits offered by traditional 
inheritance-based OOP, without so much of the now-well-known 
downsides. I'm 90% convinced that an equivalent of traditional 
Java-style OOP could be constructed out of these meachanisms 
without too much trouble, and is effectively a subset of them. If 
I were a grad student, I would totally do a thesis around that.

Re: GitHub could be acquired by Microsoft

[Nick Sabalausky via Digitalmars-d-announce]

On Saturday, 9 June 2018 at 00:54:08 UTC, Kapps wrote:


Personally I think the fear of Microsoft ruining GitHub is 
completely unfounded. Just look at what they did to Xamarin. 
They bought an interesting product and then made it free for 
individuals, open sourced it, and improved it drastically. And 
they sure do hate Linux nowadays with dotnet CORE being 
partially to improve Linux / cross-platform support.


These days, I don't think the "evil" of MS is the thing to be 
concerned about. I'm more concerned about unpredictably and 
unreliability. The potential for mess-ups or mind-changing or 
other surprises down the road. Not that it necessarily WILL 
happen, but I think being MS its worth being prepared, just in 
case.

Re: DUB colored output proposal/showcase

[Nick Sabalausky via Digitalmars-d]

On Friday, 8 June 2018 at 13:35:36 UTC, gdelazzari wrote:

Take a look at these screenshots:

https://imgur.com/a/3RJyd6m



Very nice!

But related to your motivation for  this, I do really wish dub 
had far less output by default. For example, I don't need to be 
told over and over that each of my dependencies are up-to-date 
(or which version was chosen. I can always look at 
dub.selections.json or use --verbose if I need to check that.) 
And I dont need to be reminded about --force every time my build 
succeeds. Or for that matter, be told whether or not the compiler 
gave an error. If there are errors I can already see that they're 
there. Etc.

Re: auto: useful, annoying or bad practice?

[Nick Sabalausky via Digitalmars-d]

I'm a die-hard static typing fan, hate dynamic languages, heck I 
dont even like structural typing (ex, as used by D ranges). And 
that's exactly why I *love* auto. It lets you have static typing 
without turning programming into a 2000's-era C++/Java-style 
royal anti-DRY PITA.


I also think auto is especially nice for NOT requiring a 
heavy-weight IDE, because it makes refactorings and type renaming 
much simpler.


In the very rare case that I'm not clear what type a var is, 
first of all, that's usually a sign something else is wrong with 
the code, and secondly, that's trivially answered by tossing in a 
"pragma(msg, typeof())".


Now, all that said, using auto for a function signature's return 
type shouldn't usually be done, except in very careful, specific 
"voldemort type" kinds of situations (and even then, I dont see a 
real big point).

Re: auto: useful, annoying or bad practice?

[Nick Sabalausky via Digitalmars-d]

I'm a die-hard static typing fan, hate dynamic languages, heck I 
dont even like structural typing (ex, as used by D ranges). And 
that's exactly why I *love* auto. It lets you have static typing 
without turning programming into a 2000's-era C++/Java-style 
royal anti-DRY PITA.


I also think auto is especially nice for NOT requiring a 
heavy-weight IDE, because it makes refactorings and type renaming 
much simpler.


In the very rare case that I'm not clear what type a var is, 
first of all, that's usually a sign something else is wrong with 
the code, and secondly, that's trivially answered by tossing in a 
"pragma(msg, typeof())".


Now, all that said, using auto for a function signature's return 
type shouldn't usually be done, except in very careful, specific 
"voldemort type" kinds of situations (and even then, I dont see a 
real big point).

Re: A strategic vision for D

[Nick Sabalausky via Digitalmars-d]

On Tuesday, 1 May 2018 at 22:20:53 UTC, John Gabriele wrote:

On Tuesday, 1 May 2018 at 17:20:54 UTC, Ali wrote:
It is very clear, and feel free to read between the lines, on 
what might be the long term strategy


I think point 1 in the vision is very telling

1. Lock down the language definition


Sorry, I'm not understanding. To me that says the core team 
values multiple implementations that adhere to the same spec. 
Does it imply something else?


I think it means stop making changes to the language, and all 
further changes are limited to library-only. (Could be wrong. 
Hope I'm wrong. But that is the impression I've been getting that 
Andrei's been pushing for for quite awhile.)

Re: CTFE ^^ (pow)

[Nick Sabalausky via Digitalmars-d]

On Saturday, 24 March 2018 at 00:08:17 UTC, Jonathan M Davis 
wrote:
On Friday, March 23, 2018 23:37:18 Nick Sabalausky via 
Digitalmars-d wrote:
I would think any self-respecting project would WANT to lower 
the barrier to being notified of problems, not put roadblocks 
in the way: That's what outsourced call centers are for!


Part of the problem with that is the sheer number of spammers 
out there. Signing up is a pretty minimal barrier to entry, and 
it's mostly prevented spam from showing up in bugzilla. And if 
someone isn't willing to take a few minutes to sign up for a 
bugzilla account, that implies that they don't care very much.


Yes, we want the barrier to entry to be minimal, but that 
doesn't mean that it makes sense to make it zero.




Yea, but there are less obtrusive ways of preventing spam posts. 
Like the modern crop of captchas.

Re: CTFE ^^ (pow)

[Nick Sabalausky via Digitalmars-d]

On Friday, 23 March 2018 at 20:38:38 UTC, Manu wrote:


I'm not suggesting switch to github. I've never suggested that. 
I

understand it's inferior.
I'm suggesting supporting openauth.


OAuth is a phisher's paradise.

But that aside, it's never made any sense to me for projects to 
self-impose a policy of "If you've found a bug, and you're 
non-registered, we don't want to hear about it."


I would think any self-respecting project would WANT to lower the 
barrier to being notified of problems, not put roadblocks in the 
way: That's what outsourced call centers are for!

Re: CTFE ^^ (pow)

[Nick Sabalausky via Digitalmars-d]

On Friday, 23 March 2018 at 18:22:06 UTC, Manu wrote:

On 23 March 2018 at 03:16, Walter Bright via Digitalmars-d


(BTW, there's a way to do it without the CTFE fix. One can use 
the approach I've always used in the past for C, which is 
write a separate program to generate the tables. This was used 
in the DMD build, and was gradually replaced with CTFE. It 
still exists in the backend, which is still in C++.)


Right, but then there's no reason to use D.


Of course there is. It's called "all the other million things D 
does better than C++ besides CTFE pow".


When D undermine's its own proposed usefulness, it loses 
against C++ every time, no competition.


Not when it's isolated examples instead of the language as a 
whole. It's not D's fault programmers are terrible at basic 
cost/benefit analysis.

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

[Nick Sabalausky via Digitalmars-d]

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

Re: D's type declarations seem to read right to left.

[Nick Sabalausky via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 20:07:09 UTC, tipdbmp wrote:

D's type declarations seem to read right to left.


int an_integer;

int[10] an_array_of_10_integers;
int[10]* a_pointer_to_an_array_of_10_integers = 
_array_of_10_integers;


int*[10] an_array_of_10_pointers_to_integers;
int*[10]* a_pointer_to_an_array_of_10_pointers_to_integers = 
_array_of_10_pointers_to_integers;


int[3][2] an_array_of_2_arrays_of_3_integers;
int[string] a_hashtable_with_string_keys_and_integer_values;

int[3][string][2] 
an_array_of_2_hashtables_with_string_keys_and_array_of_3_integers_values;


int function(float) 
a_pointer_to_a_function_that_takes_a_float_and_returns_an_integer;
int function(float)[10] 
an_array_of_10_functions_that_take_floats_and_return_integers;



I think this is a big improvement over C's "spiral" way of 
reading types: 
http://www.unixwiz.net/techtips/reading-cdecl.html

I guess it could've been left to right, but... it's okay.


The way I see it, English "of" flips its operands backwards 
compared to English's [adjective][noun] syntax:


int an_integer;
int* an_integer_pointer;
int[] an_integer_array;
int[3]* an_integer_array(length 3)_pointer;

But granted, in English, "of" is more scalable than 
[adjective][noun].

Re: Documentation for any* dub package, any version

[Nick Sabalausky via Digitalmars-d-announce]

On Tuesday, 27 February 2018 at 15:49:37 UTC, Basile B. wrote:


At first glance i can say that this will work perfectly for DUB 
packages. Once DCD gives a file, the IDE just have to look the 
parent folders to get the SemVer tag.
If the file is in a git repository things might be more 
complicated.


In most cases its pretty easy from a git repo too, just run 'git 
describe'. That'll give you the latest (annotated) tag (which 
SHOULD be the semver number, and generally is for dub projects) 
and no other output. Nothing to parse or scrape.


If theres been extra commits since the last tag, then there's a 
little extra suffix appended to git describe's output, but its 
trivial enough to parse/remove if you need to.

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

[Nick Sabalausky via Digitalmars-d]

On Friday, 9 February 2018 at 22:38:23 UTC, H. S. Teoh wrote:


Proposal: unittests should only be compiled if the module it's 
found in is being compiled (i.e., among the modules listed on 
the command-line), even with -unittest.


if I'm using a 3rd party library, why should I care to run 
*their* unittests?  I'm only interested in testing my own code.


What do you think?



Currently being discussed in another thread, but that's an 
emphatic "YES, definitely". I proposed that awhile back and there 
was a bunch of hemming and hawing and ultimately nothing, but I 
really hope something will come of it this time.

Re: Which language futures make D overcompicated?

[Nick Sabalausky via Digitalmars-d]

On Saturday, 10 February 2018 at 01:24:55 UTC, Timon Gehr wrote:
The fundamental issue is that D's type system has no parametric 
polymorphism,


Pardon my ignorance, but isn't that what D's templated functions 
do? This sounds interesting but unclear exactly what you mean 
here and how it relates to inout and its problems.

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky via Digitalmars-d]

Ouch. I guess "the real WTF" is that 2's complement leads to 
supporting one value that cannot be negated. But still, I thought 
we had value range propagation rules to avoid this sort of 
nonsense when possible (such as the example above)?

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky via Digitalmars-d]

On Sunday, 9 July 2017 at 22:02:51 UTC, Meta wrote:


There's a couple posts he's made here but a lot of it's spread 
out across various talks, articles (I think) as well as 
newsgroup posts. Here's what I found with a quick google:


https://www.reddit.com/r/cpp/comments/4jqg5z/andrei_alexandrescu_on_c_concepts/
https://www.reddit.com/r/programming/comments/4jlkhv/accu_2016_keynote_by_andrei_alexandrescu/d391585/

And there's a ton of info on the internet about the C++ 
concepts proposal.


Ah, I guess it is very similar after all, except it'd be based on 
top of and coexist with all of D's design by introspection stuff 
(rather than exist without it as with C++), thus avoiding a lot 
of the downsides and getting best of both worlds.

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky via Digitalmars-d]

On Sunday, 9 July 2017 at 20:42:39 UTC, Meta wrote:


I'm sorry if I misunderstood what you're proposing, but isn't 
this exactly what C++ set out to do with concepts? If that's 
the case, I'd recommend you look up some of Andrei's refutation 
of concepts in favour of template guards and `static if`.


Shit, I hope not :/ I gave up following C++ developments 15 years 
ago. Happen to have a link handy to that refutation?

Re: Can we get rid of non-raw write?

[Nick Sabalausky via Digitalmars-d]

Vetoed after several years of nothing:
https://issues.dlang.org/show_bug.cgi?id=9776#c7

I'm getting really fucking tired of D making up excuses to throw 
"do the right thing by default" straight into the gutter. D 
steering didn't used to be this way, and that was exactly what 
make D into something worthwhile in the first place. Now we're 
just diving head-first into C++-management (minus the committes).

Re: Of the use of unpredictableSeed

[Nick Sabalausky via Digitalmars-d]

On Monday, 27 February 2017 at 00:10:31 UTC, cym13 wrote:


The only thing that saves you here is that your 
DefaultCryptoRand isn't seedable. Note that I'm not saying that 
to bash you or anything, it just happens to show well why I 
think my article was necessary.


Oh, don't get me wrong, I'm very much in favor of your article, 
ESPECIALLY if people are using the phobos rng in security 
contexts.


Keep in mind though, if my Hash_DRBG implementation were 
seedable, it wouldn't be a valid implementation of Hash_DRBG 
anyway. (A good example, I think, of why we coders shouldn't be 
inventing crypto algorithms, only implementing establised ones 
created and well-studied by the math/crypto experts.)

Re: two points

[Nick Sabalausky via Digitalmars-d-announce]

On 02/09/2017 04:49 AM, Walter Bright wrote:

On 2/8/2017 11:09 PM, Nick Sabalausky wrote:

And any PRs I have managed to get through were all uphill battles the
whole way.


You have contributed 5 PRs to dmd:

   https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aabscissa

 1 is open (it's controversial)

 1 closed (today by me)


Well, I suppose I brought that one on myself by complaining about it 
being ignored :/




 3 merged
 1 in 6 days
 2 in 1 day

Overall, I think you've done well.


Note that those quickly merged ones were several years ago, back before 
the battles to get anything accepted reached ridiculous levels.




In any case, shouldn't it be an uphill battle to merge things?


No. There should be appropriate checks and reviews, yes. But, no, every 
little fix and improvement shouldn't feel like trying to get somewhere 
in a year-long tabs vs spaces debate or making a big-budget sales pitch 
to Indecisives Anonymous.

Re: two points

[Nick Sabalausky via Digitalmars-d-announce]

On 02/09/2017 01:08 AM, Joakim wrote:

I agree that "coercion," or more accurately the tyranny of the default,
is the dominant factor in language popularity even today, but you're
reaching when you apply that to web frameworks too.


Fair enough. It was just another example trying to make the point that 
"if you want to do X, then you have little choice but use Y" is, as you 
say, the dominant factor in language popularity. I can grant that the 
web framework examples are weaker examples.



D's problem on the client is that the popular platforms are still very
much tied to certain favored languages:

iOS - ObjC and Swift
Android non-game apps - Java
Android games - C/C++
Windows - C# or C++
Web - Javascript

Three of the four major client platforms all allow other languages (with
the fourth starting to with WebAssembly), but you're often fighting the
tide if you choose a non-default language so most don't bother.


That's a good way of explaining it, I like that.


We can make the dev experience more pleasant on those platforms, as I
believe has happened now that we support the MS toolchain on Windows,
but D is unlikely to become popular without a killer app that
demonstrates its suitability.  That's not coercion, but something we can
actually control.


I hope you're right, but I worry that even "killer app example" may not 
be enough, and that the lack of one may turn out to be just another red 
herring excuse for "why aren't using D". After all, I think vibe's 
approach to server development comes very close to "killer app" yet, far 
as I've seen, it doesn't appear to have proven a major win for D so far.


Then again, having D in the "my secret weapon" category has certain 
benefits, too, so I guess I can't be TOO sour ;)



On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote:

I think the D leadership are too busy addressing broader issues with
the language at the moment, so this specific case is just not a high
priority.  Also, if it's not a priority to the them, then anyone that
does attempt to work on it will just suffer an eternity in pull
request purgatory.

So, I would not recommend it as a project for anyone until the D
leadership decides to get involved.


I think this misunderstands how open source works: the whole point is
that you don't need anybody's permission to go do this. Walter and
Andrei, or any other OSS core team, are much more likely to approve
something if you have an implementation that works well.  Look at Ilya
and what happened after he showed them Mir.



You're right, in theory. But Mike is unfortunately very right about the 
whole "suffer an eternity in pull request purgatory."


I fixed an issue where "///"-style doc comments resulted in excessive 
paragraph breaks...must've been over a year ago. Simple fix for a 
nagging bug. The fix worked. Caused no problems. No controversy. And to 
this day, just went completely ignored despite my periodic nagging about 
it. Eventually got tired wasting my time babysitting the constant need 
for rebasing and manual merge fixes just for something that proved 
guaranteed to be ignored. And any PRs I have managed to get through were 
all uphill battles the whole way.


We have far too high a threshold for letting things actually happen. It 
didn't used to be that way, and that was a key reason why D became as 
good as it's gotten in the first place.


So I'm not surprised people familiar with D go to lengths to avoid 
putting the effort into PRs that are much more major than my 
comparatively trivial PRs: It's proven to come with a depressingly high 
likelihood of turning out to be a complete waste of time.


At the risk of sounding hyperbolic, I think this is D's next biggest 
problem after the lack of any "If you want to do X, your only real 
choice is D". Though I admit I might be a little biased on this 
particular point though.

Re: Questionnaire

[Nick Sabalausky via Digitalmars-d-announce]

On 02/08/2017 01:27 PM, Ilya Yaroshenko wrote:

1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some tasks
then with any other system language


x. Because I'm self-employed so I get to choose the best tool for the 
job instead of whatever some know-nothing manager thinks "must be good 
because its popular". Also, all of the above.



2. Does your company uses C/C++, Java, Scala, Go, Rust?


Not when I can help it.


3. If yes, what the reasons to do not use D instead?


If, for whatever reason, my hands are tied and it's just not a 
possibility. Usually platform/framework compatibility. Or somebody above 
me deciding "You must use language X". (But, after having had more than 
enough PHP/VB/Java/C++/Python/etc in my life, I'm more inclined now to 
simply avoid situations that would involve such restraints. Life's too 
short to suffer bad tools for bad reasons.)



2. Have you use one of the following Mir projects in production:


No. I keep hearing about Mir, but still haven't quite wrapped my head 
around what it is, or how/where to use it. (and that bugs me)



3. If Yes, can Mir community use your company's logo in a section "Used
by" or similar.


N/A


4. Have you use one of the following Tamedia projects in your production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount


First I've heard of them. I'll take a look.


5. What D misses to be commercially successful languages?


A groupthink mentality and loads of bad ideas and broken reasoning. Ie, 
the basic requirements for anything to be popular in the computing arena.


Seriously. I'm not joking.

Well, that and, nobody's ever really been in a situation where they're 
more or less FORCED to use D. Many, heck probably most, big-name 
languages got big because there were enough people who didn't have much 
of a choice:


- Earlier days of Unix/Linux dev? Hard to avoid C/C++.
- Work for a company that's heavily invested in MS tools? Hard to avoid 
VB (90's) or C# (2000's).
- Work for a non-MS-based enterprise? Hard to avoid Java, because that's 
what the higher-ups had already been sold on.

- Need to use a relational DB? SQL, period.
- Need client-side scripting on a web page? JavaScript, period (until 
just recently).
- If you wanted an MVC web framework, for a short while Ruby was the 
only choice. I guarantee Ruby would be more popular today if that time 
period had been longer. It's undeniable nobody would've ever heard of 
Ruby were it not for Rails.
- Need to run something on an affordable commodity server in the late 
90's/2000's? PHP, period. Unless you paid an extra $5-$10/mo. and 
restricted your choice of providers - then you could use VBScript/ASP, 
which was basically the same exact thing as PHP, but just incompatible.
- Need low-level hardware access, memory management or other direct 
control over performance and resource usage? Until recently, had to be 
C/C++.


Then once onboard, stockholm syndrome sets in. Instant popularity.

Coercion (and perceived coercion[1] for that matter) makes technologies 
popular far more than any other factor. The computing sector is NOT a 
meritocracy, not by a longshot. That right there is D's #1 biggest 
marketing flaw, period. If you nail that coercion part, it doesn't 
matter HOW badly you do on any other technical or marketing aspect. Been 
proven time and time again. And if you DON'T have that coercion, you 
face an uphill battle no matter how good you do on technical and 
marketing fronts. Also been proven time and time again.


[1] The "I must keep up or get left behind" thought train. See also 
"Cover Fire" and the Fire and Motion stuff here: 
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/



6. Why many topnotch system projects use C programming language nowadays?


Partly inertia, but also because there was a decade or two (that only 
ended a few years ago) where nearly all language designers obsessed over 
VMs and eliminating low-level capabilities, and in general dumbing down 
their languages to the point of uselessness for anyone but novices, 
hobbyists, and those who could afford to throw money/hardware at any and 
all performance/resource/scalability issues[2]. Because of that, for 
many C/C++ users, there simply was no realistic alternative, period.


[2] I'm sure 90's Sun LOVED their JVM/Java - it virtually guaranteed 
"optimization" could only mean "rent/buy more hardware" - Everything 
else besides reducing algorithmic complexity was deliberately banned by 
both the language and the VM...as a self-proclaimed "feature" no less. 
That "feature" allegedly being for safety, but decades of security 
patches and exploits for every VM on the planet proved that to be a load 
of...male cow.

Re: Passing variables, preserving UDAs: A Gripe

[Nick Sabalausky via Digitalmars-d]

On 02/08/2017 01:00 PM, Nick Sabalausky wrote:


But even if that did compile, it still wouldn't work because doStuff
wouldn't be able to access "foo.s" since "foo" isn't getting passed in
in any way.



I mean, in order to *set* a value for "foo.s", not *just* access UDAs.

Re: Passing variables, preserving UDAs: A Gripe

[Nick Sabalausky via Digitalmars-d]

On 02/08/2017 07:38 AM, Kagamin wrote:

try this:
void main()
{
 auto foo = new Foo();
 doStuff!(Foo.s);
}


Same result:
Error: need 'this' for 'doStuff' of type 'pure nothrow @nogc @safe void()'

But even if that did compile, it still wouldn't work because doStuff 
wouldn't be able to access "foo.s" since "foo" isn't getting passed in 
in any way.

Passing variables, preserving UDAs: A Gripe

[Nick Sabalausky via Digitalmars-d]

Suppose I have some code that operates on a variable's value and its 
UDAs. And I want to refactor that code into a reusable function. Sounds 
simple enough, right?


So, consider a basic example:


class Foo
{
@("Hello")
string s;
}

void doStuff(alias var)()
{
var = "abc";

import std.traits;
assert(hasUDA!(var, "Hello") == true);
}

void main()
{
@("Hello")
string s;
doStuff!(s);

auto foo = new Foo();
// Error: need 'this' for 'doStuff' of type 'pure nothrow @nogc 
@safe void()'

doStuff!(foo.s);
}


Note the error. Naturally, that cannot compile, because you can't 
instantiate a template based on the value of a variable at runtime (ie, 
based on the value of `foo`).


This can be made to *compile* if you pass by runtime ref instead of alias:


void doStuff(T)(ref T var)
{
var = "abc";

import std.traits;
assert(hasUDA!(var, "Hello") == true); // Fail!
}

void main()
{
auto foo = new Foo();
doStuff(foo.s); // Ok
}


But as expected, the UDAs are not preserved because UDAs are attached to 
declarations, not values.


This CAN be made to work, albeit very awkwardly:


class Foo
{
@("Hello")
string s;
}

void doStuff(alias var)()
{
var = "abc";

import std.traits;
assert(hasUDA!(var, "Hello") == true);
}

void doStuffMember(string memberName, ObjType)(ObjType obj)
{
__traits(getMember, obj, memberName) = "abc";

import std.traits;
assert(hasUDA!(__traits(getMember, obj, memberName), "Hello") == true);
}

void main()
{
@("Hello")
string s;
doStuff!(s);

auto foo = new Foo();
doStuffMember!("s")(foo);
}


But now it's:

1. A complete freaking mess

2. An unintuitively inconsistent interface

3. A blatant DRY violation

4. AFAICS, cannot be DRY-ed up particularly well without either running 
into the original problem, resorting to string mixins (which comes with 
its own problems), or saying "to hell with using D's UDA interfaces 
within my function" and just passing the result of getUDAs into the 
function to be used instead, and recreating stuff like hasUDA to operate 
on the results of getUDAs instead of the symbols directly.


5. Did I mention it's A COMPLETE FREAKING MESS for what seems like a 
very simple problem?

Re: mysql-native: preview3 (docs)

[Nick Sabalausky via Digitalmars-d-announce]

https://github.com/Abscissa/mysql-native-experimental
Tag: v0.2.0-preview3

Just a few doc updates this time:

- Docs now include the `mysql.db.MysqlDB` to `mysql.pool.MySqlPool` 
change from preview2

- Clarified "Prepared" vs "PreparedImpl"
- Clarified "exec" vs "query"
- Rewrite the docs for ResultSet and ResultRange.

New docs:
http://semitwist.com/mysql-native-docs/v0.2.0-preview3

Re: Name That Technique!

[Nick Sabalausky via Digitalmars-d]

On 02/03/2017 06:50 PM, Ali Çehreli wrote:

"the imp idiom" might do but imps have a very
insignificant appearance in Harry Potter.


But they have much significance in Doom :)

...part of which takes place on Phobos ;)

Re: mysql-native: preview2

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 09:46 AM, Suliman wrote:

Could you explain real case if rangification of ResultSet

http://semitwist.com/mysql-native-docs/v0.2.0-preview1/mysql/result/ResultSet.html


Does it's mean that I can write
foreach(x;result.empty) ? Or how to use it?


.empty just checks whether the range is empty, it returns true/false. 
You can't iterate over that. But yes, you can iterate over the ResultSet 
itself. Of course, ResultSet is random-access, so you can also index it 
like an array: "resultset[0]" returns the first row.

Re: mysql-native: preview2

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 02:22 AM, Suliman wrote:
> Am I right understand that if I use pool I can create connection
> instance one time in DB class constructor end every new connection
> will be created on demand?

No. You create the pool once (wherever/whenever you want to). Then, 
every time you want to use the database you obtain a connection by 
calling MySqlPool.lockConnection.




Ok, I read articles about pool, as I understood it's depend on of the
implementation. For example method `close` in pool mode should not close
connection, but return it to pool.



Calling 'close' will always close the connection. If you got you 
connection from the pool, then it will automatically return to the pool 
when you're no longer using it. No need to do anything special for that.



Could you tell about your implementation. Also actual question is can I
open connection in constructor (during class instance creation) ?


You can open a connection in a constructor if you wish. Or wherever you 
want to.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 04:33 AM, Suliman wrote:

ResultSet querySet(Connection conn, string sql, ColumnSpecialization[]
csa = null)

Could you explain last parameter?

`ColumnSpecialization[] csa = null`. I can't understand how to use it.



The vast majority of the time, you don't need to worry about that 
parameter, just omit it. It's just for if the fields you're pulling from 
the DB are very, very large and you want to handle the data as it comes 
in, rather than waiting for all the data to download. If you want to 
know more, it's in the documentation here:


http://semitwist.com/mysql-native-docs/v0.2.0-preview1/mysql/protocol/extra_types/ColumnSpecialization.html



Also I think it's better to remove old deprecated methods at all,
because it's add only mess.


They're still there for new just for backwards compatibility. But they 
are deprecated and will be removed in a later release.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 03:23 AM, Suliman wrote:

mydb.lockConnection() does create a new connection if it needs to. And
that WILL throw an exception if there's a problem connecting to the DB
server. So your code above WILL catch an exception if the connection
information (server address/port/login/etc) is wrong.


But it does not. I am getting Access Violation instead of the exception
if connection credentials is wrong:

Authentication failure: Access denied for user 'root'@'111.111.111.111'
(using password: YES)

object.Error@(0): Access Violation

0x004436C0 in void database.Database.connect() at
D:\code\CMS\source\database.d(34)
0x00403130 in _Dmain at D:\code\CMS\source\app.d(17)
0x00593C6F in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x00593C33 in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x00593B34 in _d_run_main
0x004433CC in main at D:\code\CMS\source\app.d(7)
0x005F0929 in mainCRTStartup
0x769262C4 in BaseThreadInitThunk
0x774D0FD9 in RtlSubscribeWnfStateChangeNotification
0x774D0FA4 in RtlSubscribeWnfStateChangeNotification
Program exited with code 1



I'm unable to reproduce this problem. Are you trying to use the 
connection after it fails to connect? It looks like that's what's 
happening, you're using a null reference.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 07:10 AM, aberba wrote:


* Moreover, how do I close a connection or does it auto close?



It closes in its destructor (although AIUI there are times when dtors 
don't get run). But it can be closed manually with Connection.close();



* Does it support mysql_real_escape_string() like in php? This factor-in
the db encoding to do he appriate encoding for '/\" ...


There is a function like that one that was contributed, 
mysql.escape.mysql_escape:


https://github.com/Abscissa/mysql-native-experimental/blob/master/source/mysql/escape.d#L4

But, it's better to use prepared statements, because then no escaping is 
needed, and there's no worry about forgetting to escape:


Prepared prepared = prepare(connection, "SELECT * FROM `someTable` WHERE 
i=? AND s=?");

prepared.setArgs(7, "hello");
ResultRange results = prepared.query();

The prepared statement is reference counted and will automatically be 
released when there are no references to it left.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/02/2017 03:23 AM, Suliman wrote:

mydb.lockConnection() does create a new connection if it needs to. And
that WILL throw an exception if there's a problem connecting to the DB
server. So your code above WILL catch an exception if the connection
information (server address/port/login/etc) is wrong.


But it does not. I am getting Access Violation instead of the exception
if connection credentials is wrong:

Authentication failure: Access denied for user 'root'@'111.111.111.111'
(using password: YES)

object.Error@(0): Access Violation

0x004436C0 in void database.Database.connect() at
D:\code\CMS\source\database.d(34)
0x00403130 in _Dmain at D:\code\CMS\source\app.d(17)
0x00593C6F in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x00593C33 in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x00593B34 in _d_run_main
0x004433CC in main at D:\code\CMS\source\app.d(7)
0x005F0929 in mainCRTStartup
0x769262C4 in BaseThreadInitThunk
0x774D0FD9 in RtlSubscribeWnfStateChangeNotification
0x774D0FA4 in RtlSubscribeWnfStateChangeNotification
Program exited with code 1



Ahh, ok, that's a bug. Will fix.

Re: mysql-native: preview2

[Nick Sabalausky via Digitalmars-d-announce]

Made a couple more long-needed changes while I'm at it:

https://github.com/Abscissa/mysql-native-experimental
Tag: v0.2.0-preview2

- For better clarity, renamed `mysql.db.MysqlDB` to `mysql.pool.MySqlPool`.

- Package mysql.connection no longer acts as a package.d, publicly 
importing other modules. To import all of mysql-native, use `import mysql;`

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/01/2017 01:54 PM, Suliman wrote:

Also I can't understand what is SQL Command and what exec is doing if
it's returning ulong?




"struct Command" should not be used. It is old, and a bad design. This 
new release attempts to replace it with a better design. Hopefully, 
"struct Command" will be deleted in a later release.


The "exec" functions are for commands like INSERT, UPDATE, DELETE, 
CREATE, etc (it is *not* for SELECT). It is for things that do NOT 
return actual rows of data. The "exec" functions return "rows affected" 
- the number of rows that were affected by your INSERT, or UPDATE, etc. 
Usually people ignore that number, but it's information the server sends 
back, and is sometimes useful to some people. For example, SQL 
administration tools usually tell you "# rows affected" after you run an 
INSERT/UPDATE/etc.


If you are doing a SELECT, then you do NOT use "exec", you use "query" 
for SELECT. "query" returns a set of rows.


Summary:
-

SELECT: Use query() or querySet() or queryRow(), etc.

INSERT/UPDATE/DELETE/CREATE/DROP: Use exec(). Return value tells you how 
many rows were added/changed/deleted/etc.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/01/2017 10:34 AM, Suliman wrote:

On Wednesday, 1 February 2017 at 14:06:39 UTC, Suliman wrote:

Am I right understand that Connection instance should created at
constructor and be one single for all class (and it will be reused by
fibers) or am I wrong?

If yes, where I should to close it? To put
scope(exit) c.close();

In destructor?

If yes, does it behavior should be same as for working in vibed pool
and without?


I'm not sure I understand the question here.

Whether you should use a vibed connection pool or not is completely up 
to you and your program. And the choice of when to create the 
connection, and when to close the connection, is also up to your own 
program's needs.


If you're using a connection pool, you shouldn't need to worry about 
closing the connection. The whole point is that the connections stay 
open until you need to use one again. When your program ends, then 
connections will close by themselves.




If I right understand class MysqlDB do not throw any exceptions, So I
can't understand how to handle wrong connection.

if(connection is null)
{
 try // useless
 {
 connection = mydb.lockConnection();
 }
 catch(Exception e)
 {
 writeln(e.msg);
 }
}


mydb.lockConnection() does create a new connection if it needs to. And 
that WILL throw an exception if there's a problem connecting to the DB 
server. So your code above WILL catch an exception if the connection 
information (server address/port/login/etc) is wrong.


Side note: That reminds me, I need to rename the MysqlDB class (and the 
mysql.db module). It's a connection pool (using vibe-d's connection 
pool), but their names make that very unclear.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 02/01/2017 05:04 AM, Suliman wrote:

Plz update dub package on code.dlang.org


It's deliberately not in the main mysql-mative package just yet. I will 
put it there once people have a chance to try this, and it becomes clear 
there aren't any big problems with the redesign.


For now, this preview can be used like this:

$ git clone https://github.com/Abscissa/mysql-native-experimental.git
$ dub add-local mysql-native-experimental

And then, when you're doing using this preview:

$ dub remove-local mysql-native-experimental

Re: Snap packages for D compilers and core projects

[Nick Sabalausky via Digitalmars-d]

On 01/30/2017 09:40 AM, qznc wrote:


Is it legally possible to distribute DMD this way? Afaik only dlang.org
is allowed to distribute it publically due to the backend licence issue.


I don't understand where people keep getting that idea. It very clearly 
states that all you need is to ask permission. It's always been that 
way, and no reasonable request (or any at all to my knowledge) has ever 
been denied.

Re: mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

On 01/30/2017 02:49 AM, Sönke Ludwig wrote:


What about directly going for 1.0.0? At least after it has gotten enough
real-world exposure, I'd say that the first API overhaul is a good
opportunity for that.


Good point.

mysql-native: API Refresh RC

[Nick Sabalausky via Digitalmars-d-announce]

I've been working on a big refresh of mysql-native's API, to take care 
of various issues that have appeared with it. It involves some major 
breaking changes (although I've tried to keep old interfaces around for 
the moment, but marked deprecated), so I wanted to post it before 
committing to it so those interested have a change to take a look, give 
feedback, catch problems, etc.


Summary of these changes:

API overhauled for better safety, reliability and ease-of-use. 
Deprecated and replaced entire Command struct with better design. Better 
handling of null. Various bugs fixed and more rigorously tested.


--

For right now, the changes are in a separate fork, here:

https://github.com/Abscissa/mysql-native-experimental

The readme there has sample code and an overview of the new interface.

Changelog: 
https://github.com/Abscissa/mysql-native-experimental/blob/master/CHANGELOG.md


API ref: http://semitwist.com/mysql-native-docs/v0.2.0-preview1

---

So take a look, let me know if there's any big issues with it. If all 
looks good, this will soon be released as mysql-native v0.2.0.

Partial arrays reclaimed?

[Nick Sabalausky via Digitalmars-d-learn]

Suppose an array is being used like a FIFO:

---
T[] slice;

// Add:
slice ~= T();

// Remove:
slice = slice[1..$];
---

Assuming of course there's no other references to the memory, as this 
gets used, does the any of the memory from the removed elements ever get 
GC'd?


Also, if this is a long-running process, isn't there a potential danger 
in the array just marching through the address space and running out of 
room? (ie either running out of of continuous space, or hitting 0xFFF)

Re: Gui in D: I miss this project

[Nick Sabalausky via Digitalmars-d]

On 01/16/2017 02:39 AM, Jacob Carlborg wrote:

On 2017-01-09 22:41, aberba wrote:

This seemed to be an effort (among others) to bring GUI cross platform
to standard D but some language/compiler/Phobos/Deimos/manpower issues
were the drag.

https://github.com/Devisualization


We now have DLangUI.

I wonder what the current drag is.



There's DWT [1] as well. Works on Windows and Linux, uses native drawing.

[1] https://github.com/d-widget-toolkit/dwt



There's also QtE5 https://github.com/MGWL/QtE5

Looks pretty good, from what I can see.

Re: What's the oldest Mac targeted by D programmers?

[Nick Sabalausky via Digitalmars-d]

On 12/06/2016 08:11 AM, Guillaume Piolat wrote:


optimizing for the users which
already have the fastest machines is not going to make a difference
while optimizing for the lower end does.


Very wise. "Latest is greatest" has become such a sacred cow in the tech 
sector that far too few developers these days understand basic 
common-sense logic like that.

Re: OT: for (;;) {} vs while (true) {}

[Nick Sabalausky via Digitalmars-d]

On 11/24/2016 05:09 PM, Dennis Ritchie wrote:

On Thursday, 24 November 2016 at 22:04:00 UTC, LiNbO3 wrote:

As you can see [1] the `while (true)` is lowered into `for (;true;)`
so it's all about what construct pleases you the most.

[1]
https://github.com/dlang/dmd/blob/cd451ceae40d04f7371e46df1c955fd914f3085f/src/statementsem.d#L357



OK, thanks.

The next question is:
What principles guided when choosing between `for (;;) { ... }` and
`while (true) { ... }` ?


Personal preference. Nothing more. Programmers have far better things to 
do that fret over the relative merits of two identical constructs that 
have no relative (de)merits over each other.

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

[Nick Sabalausky via Digitalmars-d-announce]

On 11/16/2016 03:50 AM, Kagamin wrote:

On Wednesday, 25 May 2016 at 16:47:30 UTC, Nick Sabalausky wrote:

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.


https://github.com/andlabs/libui/pull/80


Yea, I spotted that. Looks nice, I hope it gets merged, but I'm not 
holding my breath:


- As its notes say, it is still incomplete

- The pull's author has stated (in discussion for #30) he doesn't intend 
to finish it


- Plus it's just been sitting unmerged since May

- The libui author himself still maintains he doesn't want Qt support 
and feels it's redundant since Qt exists (which makes me wonder what he 
feels the point of his own lib is in the first place, since, why use 
libui when Qt exists and can do native look on everything 
*including* GTK-based environments?). :(


Anyway, I'm glad there's D bindings for this, but I do wish the libui 
author would change his stance and allow a Qt backend, because that 
would make this a very attractive lib.


*Or* maybe GTK could just add support for Qt themes (without then 
removing the feature in a point release), but we all know that will 
never happen :/

Re: [OT] D Lang installation on Windows, dependency on Visual Studio?

[Nick Sabalausky via Digitalmars-d]

On 11/15/2016 03:33 AM, Vladimir Panteleev wrote:

On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky wrote:

the ONLY time I ever have speed issues


"Speed issues" is one thing. Having most operations be INSTANT is
another. It MASSIVELY transforms your workflow; UIs where each key press
launches a command (e.g. magit, background builds...) become sensible
and usable "blindly", and can easily multiply productivity by an order
of magnitude.

If you don't have an SSD in your work machine (but can afford one), you
simply don't value your time.



I don't really use emacs, and (thought I admit I'm not 100% certain), I 
don't think much of what I use launches (or at least needs to launch) 
separate commands for each keypress (sounds like bad software 
engineering to me, but that's just my gut impression, maybe I'm wrong).


That does remind me though: Are hybrid drives still a thing? They 
sounded like a good idea (at least for laptops, where you can usually 
only have one internal drive), but I seem to remember hearing that they 
tended to have reliability problems. Has that been sorted out, or have 
the hybrids just gone away entirely?

Re: GitHub now supports editing the target branch for PR

[Nick Sabalausky via Digitalmars-d]

On 11/15/2016 06:33 AM, Dicebot wrote:

On 11/12/2016 12:34 PM, Sönke Ludwig wrote:

Not sure if this is common knowledge already, but it was new for me. If
you click the edit button at the top of a pull request on GitHub, you
now get a drop down to change the base branch to which the request will
be pulled. Really handy for PRs that should be targeted at a stable
branch, but instead target master.


I think I have sent 3 or 4 support request to GitHub asking about it and
finally it arrives! :) Makes even bigger difference if one has to
maintain multiple version branches as opposed to plain stable/master.



This should be really nice to have for Deimos. Back when I had submitted 
something to Deimos, the way the whole project is set up, I found the 
whole process to be borderline unworkable - purely because GitHub 
provided no way to target any branch other than master.

Re: [OT] D Lang installation on Windows, dependency on Visual Studio?

[Nick Sabalausky via Digitalmars-d]

On 11/15/2016 03:33 AM, Vladimir Panteleev wrote:

On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky wrote:

SSDs are still far too small.


Hmm...

http://arstechnica.com/gadgets/2016/08/seagate-unveils-60tb-ssd-the-worlds-largest-hard-drive/



I mean "too small at reasonable prices". A $10k SSD doesn't really count.

Re: D Lang installation on Windows, dependency on Visual Studio?

[Nick Sabalausky via Digitalmars-d]

On 11/14/2016 01:04 PM, fdjfgj wrote:

On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky wrote:

On 11/14/2016 08:44 AM, Patrick Schluter wrote:


have their windows system partition on a smallish SSD.


Well, in all honestly, that IS going to cause problems regardless. The
larger SSDs are fine (enough) for a phone, but for a PC that's used
for anything more than the average joe's web/email/word combo, SSDs
are still far too small.

I still have an "old fashioned" HDD-only in my PC (a laptop):
dirt-cheap: <$100 for 1TB (try to find an SSD that remotely compares),
and the ONLY time I ever have speed issues in either Win or Lin is
when I'm running far too much crap and start hitting virtual memory
swapping (or when some badly coded program soaks up all the CPU
recourses, but SSDs cant help with that anyway).


In 2005 a 250Gb magnetic HDD costed the same as nowadays 250Gb SSD.


Eh? 2005 has nothing to do with anything.

In 2016, magnetic HDDs are not purchased at 2005 prices.

In 2016, a 250GB magnetic HDD costs vastly less than a 250GB SSD.

In 2016, you can even get a 1TB HDD for less than a 250GB SSD. Even in 2.5".

In 2016, 250GB is quite small as far as general-purpose PC storage goes.

In 2016, I picked up a 5TB USB3 HDD drive for HALF the price of a 1TB SSD.

But most importantly:

In what alternate 2016 reality is a 250GB drive insufficient to be able 
to spare 3Gb to install a core dev tool?

Re: D Lang installation on Windows, dependency on Visual Studio?

[Nick Sabalausky via Digitalmars-d]

On 11/14/2016 04:33 AM, AB wrote:

On Monday, 14 November 2016 at 09:06:18 UTC, Kagamin wrote:

DMD can generate 64-bit object files just fine, you only need to link
them, and DMD can invoke ms linker for you, that's all.


It is unreasonable to pull in the many GBs of Visual Studio as a
dependency only to use its 64-bit linker.



The Linux and Mac versions rely on Linux/Mac's native C linkers, 
regardless of 32/64 bit. If Win's native linker is too large, or can't 
be obtained as part of a small enough package, that's really a Microsoft 
problem. You can't blame Samsung if there's nothing good to watch on TV.

Re: D Lang installation on Windows, dependency on Visual Studio?

[Nick Sabalausky via Digitalmars-d]

On 11/14/2016 08:44 AM, Patrick Schluter wrote:


have their windows system partition on a smallish SSD.


Well, in all honestly, that IS going to cause problems regardless. The 
larger SSDs are fine (enough) for a phone, but for a PC that's used for 
anything more than the average joe's web/email/word combo, SSDs are 
still far too small.


I still have an "old fashioned" HDD-only in my PC (a laptop): 
dirt-cheap: <$100 for 1TB (try to find an SSD that remotely compares), 
and the ONLY time I ever have speed issues in either Win or Lin is when 
I'm running far too much crap and start hitting virtual memory swapping 
(or when some badly coded program soaks up all the CPU recourses, but 
SSDs cant help with that anyway).

Re: [OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/12/2016 11:02 AM, Jacob Carlborg wrote:

On 2016-11-09 20:07, Nick Sabalausky wrote:


Although I have my doubts it would explain all the issues I've hit upon
with git's CLI. For example: I don't see why annotated tags aren't the
default. Or why non-annotated ones even exist at all. When I made
, I noticed that it'll
*only* work if the version tags are "annotated" tags. Because otherwise
"git describe" doesn't retrieve the tag. Doesn't even matter one bit
*what* the tag's message is, just that it exists. Why? Who knows! It's
git!


If you add the --tags flag to "describe" it will work.



Ok, I see (sorta). But it does work without --tags if it's an annotated 
tag. Clear as mud.


Yea, see, these are the reasons I consider git's cli to be god-awful.

Re: Release D 2.072.0

[Nick Sabalausky via Digitalmars-d-announce]

On 11/11/2016 08:30 AM, Dicebot wrote:

On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:

Run the new dmd. If it fails, either fix your code or go temporarily
go back to the old dmd until you can fix your code.


D will never be considered production ready as pong as this attiude
remaind. Your described scenario in practice works like this:

- You decide to delay fix until you have time to investigate


I've gone through a lot of compiler upgrades on a lot of D projects, and 
in my experience, this "investigate and fix for the new dmd" has always 
been trivial (aside from one instance where Phobos's standard function 
deprecation policy wasn't followed).


Some things should certainly have a smooth transition path (like above, 
when replacing a Phobos function with a different one), but really, not 
everything needs to be.



- Half of users of your library you (or your colleagues) complain that
they can't upgrade their projects because you areso slow
- You desperately find time to do required fix which proves bavkwards
incompatible


AFAICT, That's not the case with this particular cycle detection matter.

Re: Release D 2.072.0

[Nick Sabalausky via Digitalmars-d-announce]

On 11/11/2016 04:54 AM, Kagamin wrote:

On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer wrote:

Only possibility is just to ignore ALL cycles, and print them if any
are detected.


Run the new detector and if it fails, run the old one, if it succeeds,
print a message.


Or:

Run the new dmd. If it fails, either fix your code or go temporarily go 
back to the old dmd until you can fix your code.

Re: [OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/10/2016 09:31 AM, Dicebot wrote:

On 11/10/2016 06:07 AM, Nick Sabalausky wrote:

Its things like that. I'd be surprised if that has much to do with git's
nature as a "dumb" DAG tool. It's just the general good-design principle
of "The thing you *want to* or *should* do or *expect* 99% of the time
should be the DEFAULT, not the obscure incantation".


I think it is related, but is not necessary consequence. My
understanding is that for a long time command line design was given zero
thoughts on its own - it was directly exposing whatever git does
internally with no usability considerations. Which is why it is so
awkward to use unless you really do know internal object model in great
details.



Yea, see that's the stuff I mean when I say I dislike git's CLI, and 
would really like to fix with a front-end. A few years back, someone 
here compared it to driving a car by leaning under the hood pulling on 
various wires. I like that comparison. Git always did give off that 
kinda feel to me.


Somebody else pointed out gitless. At a quick glance, it looks like it 
has at least some potential. I'll have to take a closer look. Although I 
suspect I'll find a bunch of "oh, hmm, I'd have done that differently" 
just because...well, I tend to be like that ;)

Re: [OT] web/desktop dying

[Nick Sabalausky via Digitalmars-d]

On 11/10/2016 05:14 AM, qznc wrote:

On Wednesday, 9 November 2016 at 16:00:45 UTC, Nick Sabalausky wrote:


But it probably will take over anyway, because, let's face it, when
the fuck has being complete and utter fucking shit ever stopped a
computing tech from becoming a runaway success?:


I don't believe that.

Software developers need a big machine, because these days you have to
run a bunch of VMs to get anything done. Unless we migrate to
Cloud-IDEs, we will use PCs in the foreseeable future and I don't see
Cloud-IDEs happening.

Office Workers who are happy with MS Office alone could use Android.
However, there is always this old internal app, which barely works on
newer Windows versions. It will take a few decades until those are
replaced.

Executives could move to pure mobile and probably already did. Reading
reports and writing emails works well already.

I believe the PC is just as tenacious as the x86 architecture, which is
still backwards compatible over the last three decades.


I hope you're right, because I definitely need to use an "old-fashioned" 
machine in order to get things done without wasting enormous time & effort.


But I've experienced this pattern far too many times to be confident in 
that:


- I use XYZ all the time, just like everyone else. It has a few things 
that could use improvement, and would be entirely feasible to fix, but 
for the most part works fine.


- Instead of XYZ's existing, easily solvable, problems actually BEING 
solved by those in a position to do so, somebody (maybe even the same 
people) comes out with UVW, with tons of fanfare because of one or two 
little things it does better. But, for the MOST part, UVW is total shit 
and vastly inferior to XYZ.


- UVW's hype begets more hype as people worldwide mistake hype (and 
"newness") for worthiness.


- Most people delude themselves into pretending UVW's downsides 
(compared to XYZ) don't exist, because after all, it's newer and has 
hype so therefore it's unquestionably better. Or, they just simply 
tolerate UVW's downsides, because, again, it's the hot new shit, so it 
MUST be the right tool for the job, right?


- Eventually, more and more people are forced to migrate from XYZ to UVW 
because of both market and industry pressures and because of XYZ 
becoming harder to obtain and getting less and less attention, shrinking 
ecosystem, etc.


- UVW marginalizes XYZ.

- A small faction of UVW users actually recognize UVW's downsides (or at 
least recognize there are "dinosaurs" who are holding out and must be 
converted for their own good). So the UVW folk make a half-assed amateur 
attempt to "fix" the downsides, only UVW still never actually reaches 
parity with XYZ. And why bother trying? XYZ's already been all but 
killed off.


I've seen it over, and over, and over. Unless people finally wise up and 
quit mistaking hype for worthiness (highly unlikely), I fear the same is 
poised to happen to PC's. I'm already forced to rely on these god-awful 
"modern" smartphones far more than I'd like to.

Re: [OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/09/2016 11:27 PM, Stefan Koch wrote:

Please cut down on the OT guys.

This thread serves as my development log :)
As well as providing a place for discussion of the new engine.

Though that discussion seems to be very quiet at the moment.


Although the default web-based front-end for this newsgroup suggests 
otherwise, this *is* a tree-based message system. Uninteresting 
sub-trees can simply be ignored without resorting to content policing.

Re: [OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/08/2016 11:40 PM, Chris Wright wrote:

On Tue, 08 Nov 2016 11:44:50 -0500, Nick Sabalausky wrote:

I really wish Google would take that to heart. They seem to make a habit
of ripping things out *before* having replacements in place.

I think they just simply love deleting code.


I've seen this more internally than externally. The joke was that there
are two versions of everything: the deprecated one, and the one that
doesn't work yet.



It's REALLY poor project management.

[OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/08/2016 02:11 PM, Antonio Corbi wrote:
>
> Maybe this one is useful for you:
>
> http://eagain.net/articles/git-for-computer-scientists/
On 11/08/2016 03:01 PM, H. S. Teoh via Digitalmars-d wrote:

Nothing immediately comes to mind, but thanks to Dr. Google, I found
this page that's sorta helpful:

http://ericsink.com/vcbe/html/directed_acyclic_graphs.html

And perhaps these:

http://eagain.net/articles/git-for-computer-scientists/
http://marklodato.github.io/visual-git-guide/index-en.html



Ok, so it looks like each node in the DAG is a commit. I'll definitely 
have to read further. Thanks, both.


Although I have my doubts it would explain all the issues I've hit upon 
with git's CLI. For example: I don't see why annotated tags aren't the 
default. Or why non-annotated ones even exist at all. When I made 
, I noticed that it'll 
*only* work if the version tags are "annotated" tags. Because otherwise 
"git describe" doesn't retrieve the tag. Doesn't even matter one bit 
*what* the tag's message is, just that it exists. Why? Who knows! It's git!


So it means that unlike hg users, who can just make their tags with "hg 
tag v1.2.0" and everything's fine, git users can't just say "git tag 
v1.2.0". In git, making a tag like that will work for SOME use-cases but 
not all. Instead, git users have to use the less-obvious "git tag -a 
v1.2.0 -m '...whatever...'" incantation or else "git describe" won't 
freaking work right, therefore gen-package-version won't be able to 
determine the working copy's current tag name.


So then why do the non-annotated tags even exist? Why not just have 
"annotated" tags with *optional* messages? Why even have the "-a" flag 
for "git tag" at all? Why not have "git tag tagname" make a tag with no 
message, and "git tag tagname -m '...'" to make a tag with a message, 
and ditch the whole "-a" nonsense? Because it wouldn't be stupid enough 
that way? I don't get it.


Its things like that. I'd be surprised if that has much to do with git's 
nature as a "dumb" DAG tool. It's just the general good-design principle 
of "The thing you *want to* or *should* do or *expect* 99% of the time 
should be the DEFAULT, not the obscure incantation".




Or maybe I should write my own article about git being based on a DAG.
:-P



You should! :)

I've given a lot of thought over the years to the concepts of learning 
and teaching. As I see it, the big key to both is taking seemingly 
complex things, finding a model that makes them simple, and then finding 
a way to communicate that model in a way that preserves its inherent 
simplicity.


The big key there is actually having a simple, well-understood mental 
model, and it sounds like you have that on this, so I'd love to read 
anything you'd have to write about it.

Re: [OT] web/desktop dying

[Nick Sabalausky via Digitalmars-d]

On 11/05/2016 02:00 AM, Joakim wrote:


Nothing is ever "completely replaced"- somebody somewhere is still using
a mainframe or a UNIX workstation- but yes, PCs will basically
disappear, just as you never see those old computers anymore.  Android
7.0 has a full multi-window mode, just dock your smartphone with a
monitor and keyboard/mouse and start working:

http://arstechnica.com/gadgets/2016/03/this-is-android-ns-freeform-window-mode/



I'd hardly call that a "full" multi-window mode.

I've been (begrudgingly) using android on a daily basis for years now, 
and honestly, OS support for freeform windows is the least of what 
Android needs to be worthwhile as a PC replacement. Hell, even on the 
desktop, I usually have everything maximized anyway. Even with freeform 
windows, I'd sooner use *Win8*, of all things, on the desktop than 
fucking android.


There are four main areas that are currently making Android and absolute 
shit as a desktop replacement: The OS itself, the look style 
guidelines, the entire 3rd party ecosystem, and the form factor. Ie, 
basically everything.


And the idea that plugging in a mouse, keyboard and monitor fixes the 
form factor issues is ludicrous, because seriously, compare that to them 
already just *being* there as with a laptop (yea, laptop keyboards and 
trackpads suck, but not remotely as badly as what's built-in on a 
smartphone/tablet). Or compared to, you know, not having to deal with a 
plugging in a hub, connecting all that shit, clumsily propping the 
stupid little thing up, OR bluetooth for that matter, because, let's be 
honest, fucking NOBODY other than us power users can figure out that 
obtuse "pairing" shit.


But it probably will take over anyway, because, let's face it, when the 
fuck has being complete and utter fucking shit ever stopped a computing 
tech from becoming a runaway success?: Windows, C++, Java2, 
Web-as-a-platform, JS/Ajax/Toolkit-overload, walled-garden services, 
zero-privacy private surveillance, non-tactile "touch"-screens, 
intrusive forced-update systems, removing-features-as-a-feature, 
widescreens for general computing purposes, iOS/Android "phones", etc. 
People are goddamned morons, and you know what? These motherfuckers 
DESERVE to have their privacy stolen, waste all their time futzing 
around with fucking broken software & devices, lose their data, and die 
while text-driving (or while letting GPS/Google drive their car, which 
mark my words, will be the next thing). I'd hope the whole fucking world 
burns, but it looks like I don't *need* to hope for that, it's pretty 
much guaranteed at this point anyway.

Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/08/2016 05:54 PM, Nick Sabalausky wrote:

On 11/08/2016 02:30 PM, Patrick Schluter wrote:

I describe git not as a vcs but as exacly what Linus Torvalds described
it when he first presented it the Kernel mailing list: a directory
content state recorder optimized for text files.



...that's incapable of comprehending the concept of empty directories,
contrary to every major file system in use.

I never bought the argument about "b/c it tracks content, not files". If
that really did explain the limitation, then it wouldn't be capable of
handling empty *files* either, and yet it does.



(Pardon the OT)

Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/08/2016 02:30 PM, Patrick Schluter wrote:

I describe git not as a vcs but as exacly what Linus Torvalds described
it when he first presented it the Kernel mailing list: a directory
content state recorder optimized for text files.



...that's incapable of comprehending the concept of empty directories, 
contrary to every major file system in use.


I never bought the argument about "b/c it tracks content, not files". If 
that really did explain the limitation, then it wouldn't be capable of 
handling empty *files* either, and yet it does.

Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

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


The thing about git is that at its core, it's really very simple. Dumb,
even.  It's basically a program for managing a directed acyclic graph
(DAG).  That's all there is to it. The rest is just frills.

Trying to rationalize git in terms of traditional version control
systems is what usually causes lots of confusion, incomprehension, and
frustration.  To truly grok git, you have to just forget about
traditional version control concepts, and think purely in terms of DAGs.
Once you do, everything falls into place and it all makes sense in its
own peculiar way (including all the flaws :-P).



I don't suppose you have a handy link to an "Understanding Git as a DAG 
manager instead of VCS" document?

Re: What is the right level of abstractions for D?

[Nick Sabalausky via Digitalmars-d]

On 11/07/2016 02:00 AM, Danni Coy via Digitalmars-d wrote:


When I mean high quality I mean competitive with Qt (the current least bad
cross platform toolkit), DLangUI gets compared to the Java UI offerings
which leaves me somewhat cold. I have never met a java program with a UI I
liked.



Yea. DLangUI sounds nice and all to me, but the lack of native UI 
backend is a nonstarter.


Have you tried QtE5? I admit I haven't had a chance to try it out yet 
myself, but from what I can tell, it looks like what I've been wanting 
in a D GUI lib: https://github.com/MGWL/QtE5




In the former case it might be nice to have some syntactic sugar in the way
that maxscript does.

for a in group where a.count > 0 do (



I know I'm not a group 3 person, but I find that difficult to read, and 
its similarity to SQL's undisciplined syntax frightens me.



is easier to approach than

foreach (a; group.filter!(a.count > 0)()) {

but that is a fairly minor qwibble.



I like to "stack" for/foreach/if's:

foreach(group; setOfGroups)
foreach(a; group)
if(a.count > 0)
{
//...
}

[OT] Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/05/2016 04:57 PM, Andrei Alexandrescu wrote:


That's good thinking - leave short term to the short term and long term
to the long term. As the Romanian proverb goes: "Don't sell the skin of
the bear before you shoot it." -- Andrei



I really wish Google would take that to heart. They seem to make a habit 
of ripping things out *before* having replacements in place.


I think they just simply love deleting code.

Re: CTFE Status

[Nick Sabalausky via Digitalmars-d]

On 11/05/2016 11:48 AM, Marc Schütz wrote:

On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch wrote:


I recently lost 3 days of work because of my git-skills.


Unless you haven't committed your work yet, almost everything in Git can
be undone. Make a copy of your entire project directory (including .git)
and then have a look at `git reflog` around the time the disaster
happened. It will show you commit IDs that you can check out.


Yea, but unless you're a git-fu master, sometimes figuring out how to 
fix whatever got messed up can lose you 3 days of work ;)


I really want to make a saner CLI front-end for git, but that would 
require learning more about git than I really ever want to know :(

Re: Why doesn't std.variant.visit automatically call the provided delegates?

[Nick Sabalausky via Digitalmars-d]

On 11/05/2016 04:22 PM, Adam D. Ruppe wrote:

On Saturday, 5 November 2016 at 20:15:14 UTC, Kapps wrote:

That feels like it should be a compiler warning.


I'm now of the opinion that the {} delegates should be deprecated
(instead use () {} delegates)... this comes up a lot and there's a few
other places too where it is a pain... and it isn't that worth keeping imo.


I didn't even know you could create a delegate with just {} and no 
parens. Kinda confusing since, normally, {} by itself creates a scope, 
not a delegate.

Re: Release D 2.072.0

[Nick Sabalausky via Digitalmars-d-announce]

On 10/30/2016 09:27 PM, Martin Nowak wrote:


This is the release ships with the latest version of dub (v1.1.0),


Changelog for dub 1.1.0?

Re: What is the right level of abstractions for D?

[Nick Sabalausky via Digitalmars-d]

On 10/27/2016 02:22 AM, Joakim wrote:


1. low-level compiled languages like C++, D, Rust, and Swift, meant for
performance and usually experts who want to squeeze it out

2. mid-level bytecode languages like Java and C#, meant for the vast
middle of day-to-day programmers to crank out libraries and apps that
perform reasonably well

3. high-level "scripting" languages like Ruby and Python, meant for
those who don't care too much for performance but just want to get
working code

I think D is positioned somewhere between 1 and 2, though closer to 1.
However, there is sometimes talk of using D for all three, though
perhaps that is only meant as an added benefit for people already using
it for 1 or 2, ie those who already know the language better.



You're falling into the common fallacy that those groups are mutually 
exclusive and that a single language can't be appropriate for more than 
one. D is all about proving that wrong, and is meant for, and good at, 
all three.


I've noticed that, for many of the people who don't "get" D, the problem 
they're hitting is that they're minds are so twisted around by the 
"polyglot" culture, that they're looking for "the one" tiny little niche 
that D is for, not seeing that, and thus missing the whole entire point.

Re: Comparing compilation time of random code in C++, D, Go, Pascal and Rust

[Nick Sabalausky via Digitalmars-d-announce]

On 10/27/2016 02:43 AM, Sebastien Alaiwan wrote:


 From the article:

Surprise: C++ without optimizations is the fastest! A few other
surprises: Rust also seems quite competitive here. D starts out
comparatively slow."


These benchmarks seem to support the idea that it's not the parsing
which is slow, but the code generation phase. If code
generation/optimization is the bottleneck, a "ccache-for-D" ("dcache"?)
tool might be very beneficial.

(However, then why do C++ standard committee members believe that the
replacement of text-based #includes with C++ modules ("import") will
speed up the compilation by one order of magnitude?)



How many source files are used? If all the functions are always packed 
into one large source file, or just a small handful, then that would 
mean the tests are accidentally working around C++'s infamous #include 
slowdowns.

Re: Linus' idea of "good taste" code

[Nick Sabalausky via Digitalmars-d]

On 10/26/2016 06:42 AM, Walter Bright wrote:


Reminds me of:

1. newbie - follows the rules because he's told to
2. master - follows the rules because he understands them
3. guru - breaks the rules because he understands that they don't apply


I always liked that principle. Tao Te Ching, if I'm not mistaken (though 
I might be).

Re: Can we get unitests to not run with program start ?

[Nick Sabalausky via Digitalmars-d]

On 10/26/2016 09:25 AM, Adam D. Ruppe wrote:

On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:

What would be possible is a "-fdmain" switch (force dummy main).


It should just be implied by -unittest!

The only cast I'd be worried about is an explicit version(unittest)
main() {}... then maybe the user wanted something special. And even
then, meh, 99% of those cases are just fixing the broken default anyway.

Otherwise, let's make the default sane.


+1

Re: If you do something dumb enough, the test runner won't print out your test failures

[Nick Sabalausky via Digitalmars-d]

On 10/23/2016 05:52 PM, Jonathan M Davis via Digitalmars-d wrote:


import core.sys.posix.unistd;

unittest
{
 close(2);
 assert("hello" == "7");
}



Ouch! I like the punchline here :)


However, it does highlight the fact that if you just look at the output of
running the unit tests and not the exit code, you might think that your
tests succeeded when they actually failed. But fortunately, that's not
terribly likely (much as I managed to do it), and if you're using dub, it
does check the exit code.



Honestly, it's gets worse than that IMO:

I've had a bunch of time over the course of using D, with any build tool 
from bud/xfbuild (remember those?), to rdmd, to dub, where a slip-up in 
my buildscript, project configuration, or a missing import, etc would 
result in one or all of my unittests *silently!* failing to run.


I even hit it again just this week - where most tests in mysql-native 
were running...except for one, because of a missing import. The only 
reason I caught it was because I had learned to be pedantic and 
temporarily tossed in a writeln "just to be ABSOLUTELY sure...". Good 
thing I did.


This example is not only easier to hit than yours, but it's also worse 
because even the exit code will report "A-ok!".


These are all examples of why I was always opposed from the beginning to 
D's default of "no output unless a test fails": Because it makes 
"success" indistinguishable from certain types of failures.


That's why I always tried to add some "Testing blah blah whatever..." 
output at the start of every test in most of my projects: so I *KNOW* 
that what merely looks like unittest success actually *IS* unittest success.


That's also one of the biggest things I like about unit-threaded: It 
does that automatically, AND (IIRC), it shows a count of how many tests 
were run - so when I have any project with more than 
like...five...tests, I can look at that number and *know* that I'm not 
overlooking a "Hey, wait, this list of tests run is missing 'Testing 
fizzbar'!!!"

Re: Pattern matching in D?

[Nick Sabalausky via Digitalmars-d]

On 10/23/2016 11:55 PM, Nick Sabalausky wrote:



// An equivalent std.variant.Algebraic would be clunky by comparison:
  variant RgbColor {
| Red
| Yellow
| Green
| Different {
red : float;
green : float;
blue : float;
  }
  }



Just to compare to equivalent D:


struct RgbColor_ // Don't clutter the namepsace
{
struct Red {}
struct Yellow {}
struct Green {}
struct Different {
float red;
float green;
float blue;
}
}
alias RgbColor = Algenraic!(
RgbColor_.Red,
RgbColor_.Yellow,
RgbColor_.Green,
RgbColor_.Different,
}


It's just...I mean, yea, it works, and you could probably DRY it up a 
little with a type contructing template ("alias RgbColor = 
DoMagic!RgbColor_"), but...meh...


And then the pattern matching end would be similarly "ehh...meh...":


RgbColor color = ...;
auto x = color.visit(
(RgbColor_.Red a) => "red",
(RgbColor_.Yellow a) => "yellow",
(RgbColor_.Green a) => "green",
(RgbColor_.Red a) =>
mixin(interpolateStr!`rgb(${a.red}, ${a.green}, ${a.blue})`),
);


Again, technically works, but...ehh, it's like doing slices or 
high-order funcs in C.

Re: Pattern matching in D?

[Nick Sabalausky via Digitalmars-d]

On 10/23/2016 03:38 PM, Chris M wrote:

On Friday, 21 October 2016 at 19:00:55 UTC, Nick Sabalausky wrote:

What I've been really wanting for a long time is the one-two combo of
Nemerle's variants and pattern matching:

https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching


There is std.variant, though I haven't used it much myself and don't
know how well it compares. Seems like that library would provide a good
basis for providing pattern matching though.


This is one of those things where language support makes a big 
difference (like slices).


Algebraic is the *closest* thing in D that compared to Nemerle's 
variants...But honestly, saying std.variant compares to Nemerle's 
variants is like saying C can do high-order functions, OOP, and has a 
module system. Yea, *technically* you can, but it's so clunky by 
comparison that you're really not getting much of the real benefit.


One of the first examples on that page really highlights how it differs 
from D:



// An equivalent std.variant.Algebraic would be clunky by comparison:
 variant RgbColor {
   | Red
   | Yellow
   | Green
   | Different {
   red : float;
   green : float;
   blue : float;
 }
 }

string_of_color (color : RgbColor) : string
{
  match (color) {
| RgbColor.Red => "red"
| RgbColor.Yellow => "yellow"
| RgbColor.Green => "green"
| RgbColor.Different (r, g, b) => $"rgb($r, $g, $b)"
  }
}


D can get close, but it's just not so clean, wouldn't scale as well, and 
that really does make a difference (just like how many of D's features 
are argued by others to be "not that big a deal", but we know that it is 
because we use it and know that extra bit of polish D gives makes a big 
difference).


And, yea, yea, Manu has a far better color color lib in D, but of course 
this is just an illustration of the language construct. It's one of 
those things (of which D really does have many - just not this one), 
that once you have it available and start using it, it's very 
liberating, and loosing it feels like having your hands tied.


It's not my #1 missed feature in D, but it would be nice.

Re: Pattern matching in D?

[Nick Sabalausky via Digitalmars-d]

On 10/20/2016 10:16 PM, Chris M. wrote:

So I know you can do some pattern matching with templates in D, but has
there been any discussion about implementing it as a language feature,
maybe something similar to Rust's match keyword
(https://doc.rust-lang.org/stable/book/patterns.html)? What would your
guys' thoughts be?



What I've been really wanting for a long time is the one-two combo of 
Nemerle's variants and pattern matching:


https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching

Re: mysql-native v0.1.7

[Nick Sabalausky via Digitalmars-d-announce]

On 10/21/2016 05:35 AM, Martin Tschierschke wrote:

On Thursday, 20 October 2016 at 21:25:50 UTC, Nick Sabalausky wrote:

Minor update to 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).

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

In v0.1.7:
- New: Test suite automatically tests with both Vibe and Phobos
sockets, not just Phobos. (@Abscissa)
- Change: Drop support for DMDFE 2.066.1 and below. Compiles on DMDFE
2.067.1 through 2.072.0.
- Fixed: Fix an import deprecation message for DMD 2.071. (@Abscissa)
- Fixed: #57: Added support for passing null parameters in prepared
statements by using Variant(null) (@machindertech)
- Fixed: #63/#69: Add escape module to package import (@Marenz)
- Fixed: #68: Update alias syntax (@Marenz)

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

I know I've said docs and examples are a top priority for
mysql-native, but it's become clear that the API is in serious need of
a refresh, so for the most part, I've held off on the docs this time
to avoid wasted effort documenting to-be-deprecated interfaces.

Unless any pressing issues appear, expect the next release to be an
experimental branch showcasing a beta of a new API. If possible, I'd
like to have at least one release where the old API is still
functional, but deprecated.


Please consider to look at the APIs of the other mysql libs, maybe there
is one
which you can use. I found it easier to use the APIs of  mysql-d
(https://github.com/paxa/mysql.d) but mysql-lited
(https://github.com/eBookingServices/mysql-lited) looks more enhanced.


Hmm, actually, there appears to be a lot of similarity with part of what 
I had in mind:


https://github.com/mysql-d/mysql-native/issues/83

In particular, I *really* want to pretty much get rid of the Command 
struct. Minimizing heap activity is also a goal, albeit separate from 
this API refresh.



But here too:


Documentation is not ready yet


I would be very happy, if in the end there would be only one superior
mysql-lib for D, so
all can work together to improve this one.



mysql-native gets very few PRs. :(

Reflection: Order of fields guaranteed?

[Nick Sabalausky via Digitalmars-d-learn]

When using reflection to obtain the fields of a class/struct, is there 
any guarantee that the order is the same as the order the fields are 
defined?

mysql-native v0.1.7

[Nick Sabalausky via Digitalmars-d-announce]

Minor update to 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).


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

In v0.1.7:
- New: Test suite automatically tests with both Vibe and Phobos sockets, 
not just Phobos. (@Abscissa)
- Change: Drop support for DMDFE 2.066.1 and below. Compiles on DMDFE 
2.067.1 through 2.072.0.

- Fixed: Fix an import deprecation message for DMD 2.071. (@Abscissa)
- Fixed: #57: Added support for passing null parameters in prepared 
statements by using Variant(null) (@machindertech)

- Fixed: #63/#69: Add escape module to package import (@Marenz)
- Fixed: #68: Update alias syntax (@Marenz)

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

I know I've said docs and examples are a top priority for mysql-native, 
but it's become clear that the API is in serious need of a refresh, so 
for the most part, I've held off on the docs this time to avoid wasted 
effort documenting to-be-deprecated interfaces.


Unless any pressing issues appear, expect the next release to be an 
experimental branch showcasing a beta of a new API. If possible, I'd 
like to have at least one release where the old API is still functional, 
but deprecated.

Re: [OT] Re: Binding rvalues to const ref in D

[Nick Sabalausky via Digitalmars-d]

On 10/20/2016 04:32 PM, Steven Schveighoffer wrote:

On 10/20/16 12:50 PM, Nick Sabalausky wrote:


You can't bind individual values? Is there something wrong with
"bindParameter(value, paramIndex)"? (I mean, besides the fact that it
takes a ref, and, like the rest of the lib, isn't really documented
anywhere outside of the code itself.)

[...examples involving out-of-scope data...]

Now, there is bindParameters(Variant[]), which binds the *value* stored
in each parameter to the fields. This was the only way I could do it
without having to allocate space for individual values. But you must
bind everything at once!


Ok, I see. Right.

Actually I hit the same problem myself yesterday adding a test for a PR 
that added support for setting null via Variant(null) instead of 
setNullParam. The bindParameters(Variant[]) was the only one I could use 
because you can't pass a null literal by ref.




Honestly, the most egregious issue is the lifetime management. In some
cases, if you pass or copy resource wrappers, the destructor will close
the connection, or the above thing about having to allocate a place for
values so you can bind parameters without worrying about their lifetimes
going away. Wrapping mysql-native (which should be concerned mostly with
low-level stuff) so I can make more suitable ranges out of the data was
really hard, I ended up having to use RefCounted to make sure all the
resource handles didn't go away!



Right, gotcha.

I hadn't really hit that much myself in the past because for a while I 
hadn't really been using the prepared statements much, nor using it 
without vibe's connection pool. But you're right, this stuff definitely 
needs fixed.



I'll take a look when I can. One other thing API-wise that is horrendous
is the handling of null parameters (especially when you have to insert
multiple rows with the same prepared statement, and sometimes you have
some fields that should be null). Nullable!T works awesome for vibe, I
think mysql-native should use that model.



Yea, nulls were kind of always an awkward thing in the lib. I think the 
lib's original design might predate Nullable, which, I too am a fan of.


I think I'm going to try to put out first-try pass at a new API in a 
separate branch, try to get that out as soon as I can, and post it for 
experimentation/feedback.

Re: [OT] Re: Binding rvalues to const ref in D

[Nick Sabalausky via Digitalmars-d]

On 10/20/2016 09:33 AM, Steven Schveighoffer wrote:


Yes, it does work. However, one thing that I *sorely* miss is the
ability to simply bind an individual value.

At the moment, in order to bind a value, you have to pass an array of
Variant for all the values. I currently have a whole wrapper around this
library to make it more palatable, and to fix the lifetime issues.



You can't bind individual values? Is there something wrong with 
"bindParameter(value, paramIndex)"? (I mean, besides the fact that it 
takes a ref, and, like the rest of the lib, isn't really documented 
anywhere outside of the code itself.)


I do agree though, mysql-native *definitely* needs an API refresh. (In 
fact, I just happened to post several issues regarding that yesterday, 
and another person posted one as well. I want to take care of this ASAP, 
especially b/c it makes sense to do so before fixing the near-total lack 
of docs, which is already in desperate need of addressing.)


Since you've found the need to wrap the API, would you mind taking a 
look through the current list of issues I've tagged "api" (although I 
see several of them are yours), and post any thoughts or add any 
additional issues you might have? I'd like to address these things ASAP, 
and input from people who use the lib and have issues with the API would 
be highly valuable:


https://github.com/mysql-d/mysql-native/issues

Re: gdc in Linux distros recommended?

[Nick Sabalausky via Digitalmars-d]

On 10/20/2016 08:21 AM, ketmar wrote:

On Thursday, 20 October 2016 at 05:43:47 UTC, Nick Sabalausky wrote:

Not sure what your point is here. If you're writing a library and want
to avoid giving your users deprecation messages due to the import
changes, then you need to test on 2.070 or newer. Clean compilation on
pre-2.070 does not guarantee clean compilation on 2.070+.


actually, any import deprecation messages may come only from sloppy
coding, like using "implicitly imported identifier from 3rd module".
tbh, none of my code ever triggered such a warning when DMD finally
(almost) fixed it's import scheme. not 'cause i am a brilliant, but
'cause doing it "D way" (local selective imports in the closest scope)
almost automatically prevents such bugs.


I hit tons of messages, mostly because of FQN now being more broken than 
ever.

[OT] Re: Binding rvalues to const ref in D

[Nick Sabalausky via Digitalmars-d]

On 10/19/2016 07:04 PM, Chris Wright wrote:


Right. For instance, binding query parameters with mysql-native. The
thing you're binding is passed by reference and I'm not sure why.



It's been like that since mysql-native's original release, by the 
original author, some years ago.


I suspect the idea was a rudimentary ORM-like approach: to have the 
prepared statement params semi-permanently tied to actual variables (ie, 
"bound" to them). Ie, so you could re-exectute the same prepared 
statement with different values just by changing the values and calling 
`execPrepared` again, without calling any of the bind functions again.


I'd have to check whether or not that usage pattern currently works though.

Re: Binding rvalues to const ref in D

[Nick Sabalausky via Digitalmars-d]

On 10/19/2016 04:50 PM, Ali Çehreli wrote:


My off-topic contribution to this thread: I won't be surprised when C++
will eventually be classified as a case of mass hysteria.



That'll happen at the same time modern web technology stacks are 
classified similarly.


Much as I'd love to see that day, I'm not holding my breath...

But seriously, every time I look at anything going on in C++ the last 
several years, it looks more and more like it just simply wants to *be* 
D, takes a couple drunken steps in that direction, and falls flat on its 
face.

Re: gdc in Linux distros recommended?

[Nick Sabalausky via Digitalmars-d]

On 10/19/2016 05:13 PM, Iain Buclaw via Digitalmars-d wrote:

On 19 October 2016 at 18:01, Nick Sabalausky via Digitalmars-d


The last GDC release is stuck all the way back at DMDFE v2.066, which is
over two years old. Very few libs/projects are going to still be supporting
that, there's just too much limitation going back that far. LDC had been
keeping up much better.



...

And GDC is using the 2.068 feature set, plus a lot of bug fixes from
later versions.  I guess you could call it 2.068.5.  :-)



Maybe there's a certain amount of truth to that, but not completely: In 
all my projects anyway, the latest available GDC on travis always broke 
at exactly the same time DMD 2.066 and below broke. I don't think I have 
any remaining projects that still work on GDC, but several still work on 
DMD 2.067.1 (not sure about 2.067.0, don't use that one in my 
.travis.yml files since 2.067.1 came out).


Maybe there's a newer GDC build that isn't on travis yet? Current 
lastest (using "gdc" in .travis.yml), checked as of 13 hours ago, is 
reporting this:


gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 
20150825-2.066.1-58ec4c13ec) 4.9.3


There's also a "gdc-5.2.0" that (checked as of this past April, anyway - 
not sure if there would be a newer "gdc-5.2.0" though), reports:


gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 
20150825-2.066.1-dadb5a3784) 5.2.0




If his lib isn't tested to support up-to-date D compilers (especially the
import changes in 2.070, but there's other stuff as well), that's going to
prevent a lot of people from being able to use his lib. So much for
availability to the masses.



The fixes to import behaviour only breaks forwards compatibility, not
backwards compatibility.



Not sure what your point is here. If you're writing a library and want 
to avoid giving your users deprecation messages due to the import 
changes, then you need to test on 2.070 or newer. Clean compilation on 
pre-2.070 does not guarantee clean compilation on 2.070+.



The problem with compatibility is a library problem, not a compiler IMO.



Since compiler versions and druntime/phobos versions are still pretty 
much a packaged deal, the distinction is irrelevent.

Re: gdc in Linux distros recommended?

[Nick Sabalausky via Digitalmars-d]

On 10/18/2016 07:02 PM, Ali Çehreli wrote:

I have a friend who has started writing a library in D.

Although I recommended that he should use a recent dmd or ldc, he thinks
gdc is a better candidate because it's "available to the masses" through
Linux distros similar to how gcc is. Although he has a good point, the
gdc that came with his distro does not even support @nogc.

Thoughts? Can you please tell him to change his mind! :p

Ali


The last GDC release is stuck all the way back at DMDFE v2.066, which is 
over two years old. Very few libs/projects are going to still be 
supporting that, there's just too much limitation going back that far. 
LDC had been keeping up much better.


Due to incompatibilities and necessary features/bugfixes, pretty much 
all of my projects have already been forced to drop support for DMDFE 
v2.066, and GDC in the process. And I *prefer* to maintain compatibility 
as far back as I can.


If his lib isn't tested to support up-to-date D compilers (especially 
the import changes in 2.070, but there's other stuff as well), that's 
going to prevent a lot of people from being able to use his lib. So much 
for availability to the masses.


And LDC (and DMD, frankly) is every bit as "available to the masses" as 
GDC. The "available to the masses" just seems based more on general 
perception of "GCC" being a big, major name rather than anything concrete.

Re: [OT] Re: UDA and trait for non-GC managed pointers

[Nick Sabalausky via Digitalmars-d]

On 10/15/2016 02:50 PM, Basile B. wrote:


I've given up with the idea of proposing my stuff in phobos. About
memory there would also have be:
- allocators-based factory (https://github.com/dlang/phobos/pull/4062)
- @nogc dispose (https://github.com/dlang/phobos/pull/4351)

But each time the PR was a failure. Since last spring I've stopped to
think that my stuff would be useful and I hole up in my user library.

Even some simple bug fixes can be completely ignored during weeks, even
if reviewed:
- https://github.com/dlang/phobos/pull/4439
- https://github.com/dlang/phobos/pull/4475
- https://github.com/dlang/phobos/pull/4296

After a while it becomes clears that it's a loss of time.


Mere weeks? Try over a year:
https://github.com/dlang/dmd/pull/4745

Re: I close BIP27. I won't be pursuing BIPs anymore

[Nick Sabalausky via Digitalmars-d]

On Sunday, 16 October 2016 at 22:17:15 UTC, deadalnix wrote:
Long story short, it si clearly a waste of time. Qualifying the 
process would be an understatement.


Some specifically DIP27 has been written in Feb 2913, following 
various discussion at that time. I pushed it at the time. I 
moved it to the new git DIP repository. Got mostly irrelevant 
feedback (Hi Martin) and more generaly the loop time is 
measured in month.


I'm doing this on my free time. I have other things to do.

The DIP process is beyond broken. It essentially goes as :
 - If you are Andrei or Walter, then your DIP is just a 
formality. No matter how bad it is, it is in (Hi DIP25, inout 
turned out so great for type qualifier we clearly need that for 
lifetime).
 - If anybody else does it, you have no idea what you are 
getting into. You'll be still there in 5 years with no end in 
sight.


I've been a sucker for long enough. I'm not playing anymore and 
I'd suggest to anyone playing to stop. I've probably be playing 
longer than pretty much anyone here. Trust the bitter old man, 
he knows.


It's not just DIPs, that pretty much fits my experience with 
dmd/phobos PRs, too. The only feedback is trivial nitpicking, and 
then you spend a year or so babysitting an endless stream of 
rebases just for it to keep getting ignored.

Escaping ref to stack mem sometimes allowed in @safe?

[Nick Sabalausky via Digitalmars-d-learn]

This compiles. Is it supposed to?

@safe ubyte[] foo()
{
ubyte[512] buf;
auto slice = buf[0..$];
// Escaping reference to stack memory, right?
return slice;
}

Or is the escaping reference detection not intended to be 100%? Or 
something else I'm missing?


Should I file @ bugzilla?

Re: Phobos func for string -> enum member?

[Nick Sabalausky via Digitalmars-d-learn]

On 10/13/2016 07:14 PM, H. S. Teoh via Digitalmars-d-learn wrote:

On Thu, Oct 13, 2016 at 07:11:15PM -0400, Nick Sabalausky via 
Digitalmars-d-learn wrote:

I'm sure it'd be easy enough to write, but does phobos have a simple
way to convert the name of an enum member from a runtime string to the
enum type?

Ie, something like:

enum Foobar { foo=1, bar }
Foobar a = doesThisExistInPhobos!Foobar("foo");

I'm not finding anything like it in the docs, but I'm wondering if I
just missed it somewhere.


import std.conv : to;
Foobar a = "foo".to!Foobar;

:-)


T



Ah. Right. ;)

Thanks all.

Phobos func for string -> enum member?

[Nick Sabalausky via Digitalmars-d-learn]

I'm sure it'd be easy enough to write, but does phobos have a simple way 
to convert the name of an enum member from a runtime string to the enum 
type?


Ie, something like:

enum Foobar { foo=1, bar }
Foobar a = doesThisExistInPhobos!Foobar("foo");

I'm not finding anything like it in the docs, but I'm wondering if I 
just missed it somewhere.

Auto-gen list of D compiler versions: Improvements

[Nick Sabalausky via Digitalmars-d-announce]

The automatically-updated list of D compiler versions available on 
Travis-CI (and which front-end/back-end version they each use) has had a 
few small improvements lately:


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

- Now includes beta versions available for DMD (starting at v2.072.0) 
and LDC (starting at v1.1.0). GDC betas will automatically be supported 
if/when the "gdc-beta" label becomes available on travis.


- Fixed: Incorrectly parses LLVM version for LDC v1.0.0 and up

- Added links going directly to DMD/LDC/GDC sections. (No longer have to 
scroll through DMD entries to find LDC/GDC.)


- On-hover row highlighting.

As before, the list is currently set to automatically update once daily 
(although I can adjust that if need be. I just don't want to put an 
undue burden on travis by checking too often.)

Re: URI parsing

[Nick Sabalausky via Digitalmars-d]

On 10/05/2016 06:19 AM, John C wrote:

What packages do people use when they want to parse URIs? I rolled my
own but it's incomplete and as it's a fairly common need there must be
one out there? In fact, I'm surprised there isn't one in Phobos yet.


IIRC there's one in vibe I used not too long ago.

SDLang-D v0.10.1 - Small bugfix

[Nick Sabalausky via Digitalmars-d-announce]

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

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



Small bugfix update, v0.10.1, fixing one issue:

- Fix #50: Outputs certain floating point numbers in unsupported 
scientific notation.

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

Re: The XML and JSON library

[Nick Sabalausky via Digitalmars-d]

On 09/29/2016 04:14 PM, Szabo Bogdan wrote:

On Thursday, 29 September 2016 at 14:46:10 UTC, Nick Sabalausky wrote:

On 09/28/2016 05:40 PM, Szabo Bogdan wrote:


How about Json... there is something that is stopping the D community to
move the `vibe.data.json` to `phobos`?



Why does it need to be in phobos? It's already usable as-is. Only
libraries within a std lib are valid?


Well... the json format can be used in a lot of cases not only for the
web and I think it does not make much sense to include a web framework
in order to use this format.


You don't have to USE the web framework stuff to the use json part.

This sort of question has come up before, but I've really never 
understood the problem. Sounds more ideologic than anything real to me.

Re: The XML and JSON library

[Nick Sabalausky via Digitalmars-d]

On 09/28/2016 05:40 PM, Szabo Bogdan wrote:


How about Json... there is something that is stopping the D community to
move the `vibe.data.json` to `phobos`?



Why does it need to be in phobos? It's already usable as-is. Only 
libraries within a std lib are valid?

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

[Nick Sabalausky via Digitalmars-d-announce]

On 09/27/2016 04:55 AM, Chris wrote:


I was actually thinking of using SDL for pseudo code non-programmers
could write, e.g. to create rule files that a program could execute. It
could work nicely with `if` and `else` tags + attributes.


A simple programming language that's SDLang-compliant would definitely 
be interesting!