don't ever call me nicholas

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

don't ever call me nicholas

It's "Nicolas", not "Nicholas", unless it's non-gov, in which case it's "Nick"

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

I took a time-warp and googled my name. Found this page calling me 
"Nicholas": https://wiki.dlang.org/Articles (Yes, I was previously a 
regular here in a past life.) I'm middle-aged and I've spent my entire 
life putting up with people who clearly can't even fucking read calling 
me "Nicholas". I expect that from common every-day morons. But I expect 
basic literacy from programmers. (And for that matter, it's always been 
"Nick", never "Nich?olas" outside of government bullshit)


I can't even get my worthless piece-of-shit union to get my goddamn name 
right. I'd expect people here could manage to not fuck up a basic memcpy.


If it REALLY MUST be long-form, just think about sticking a bullshit "h" 
into this guys name: https://en.wikipedia.org/wiki/Nicolas_Cage

Work = Resources * Efficiency

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

Work = Resources * Efficiency

Applicable to IT, CS, and any other form of engineering.

Just putting that out there, FWIW.

Sources:
-

"Efficiency": Merriam-Webster 
:


1: the quality or degree of being efficient ("X is X! Yawn, tell me 
something that means something!")


2.a: efficient operation (ehh? Ehhh!?!?!)

2.b.1: effective operation as measured by a comparison of production 
with cost (as in energy, time, and money): (Ahh, so: efficiency is 
"produced work" vs "resources required to produce that amount of work"!!!)


2.b.2: the ratio of the useful energy delivered by a dynamic system to 
the energy supplied to it: (Ahh, so, once again: "produced work vs 
resources required to produce that amount of work")


3: efficiency apartment: "a small usually furnished apartment with 
minimal kitchen and bath facilities" --- ummm...not relevant...?




"Efficiency": Dictionary.com 

1. the state or quality of being efficient, or able to accomplish 
something with the least waste of time and effort; competency in 
performance.


"Able to accomplish something" (ie, "work") "with the least waste of 
time an effort" (ie, using minimum "resources")


2. accomplishment of or ability to accomplish a job with a minimum 
expenditure of time and effort: The assembly line increased industry's 
efficiency. ("ability to accomplish a job" == "work", "expenditure of 
time and effort" == "resources")


3. the ratio of the work done or energy developed by a machine, engine, 
etc., to the energy supplied to it, usually expressed as a percentage. 
("work done or energy developed by a machine, engine, etc." == "work", 
"the energy supplied to it" == "resources"...ie: "the ratio of ["work"] 
to ["resources"]" == "efficiency")


4. efficiency apartment: "a small apartment consisting typically of a 
combined living room and bedroom area, a bathroom, and a kitchenette." - 
Not relevant.

mysql-native v3.0.0: Update from `vibe-d:core` to `vibe-core`

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

The mysql-native package is a native all-D client library for MySQL and 
MariaDB. If vibe-d is included in your project, it will use vibe-d 
networking, otherwise it will use Phobos networking.


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

In this update, mysql-native's vibe-d support has switched from the old 
`vibe-d:core` package to the new `vibe-core` package. Several other 
improvements are included as well. See the changelog for details: < 
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md >. Big 
thanks to @SingingBush and @schveiguy for their contributions in this 
release.


On the near horizon, work on v3.1.0 and v4.0.0 is already well underway 
which will make much of mysql-native @safe. This is necessitating a 
change away from using Phobos's Variant for data, but we think this will 
be well worth it as the new replacement offers a much nicer API. And of 
course, effort is being made to make migrating go as smoothly and simply 
as possible.

Re: D Forum Mobile Version - Beta

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

I'm actually quite surprised by some of the responses. I use the web 
interface web whenever I'm visiting these forums from my phone, and 
personally, I think the CSS/layout in your version is a HUGE 
improvement. Most fantastic of all is that the thread list page and 
certain code samples are actually *readable* in your version without 
constantly needing to switch back and forth to landscape.


Granted, that's not to say there isn't room for tweaking. I'd maybe 
slightly decrease the vertical spacing on the list of subforums (ie, 
"general", "announce", "Community", "GDC", etc). Being able to ditch the 
need for most of the JS would, of course, be a huge benefit. And on the 
list pages (list of subforums and list of threads), yea, a little touch 
of left margin wouldn't hurt there, just for visual balance. Keeping the 
thread overview would be nice.


But I'd leave the actual posts exactly as-is.

1. I find the text size to be exactly what I wish most sites would use. 
Most sites just assume everyone's on some kind of "Apple iSuperMini for 
Oompa-Loompas With The Fingers of Five-Year-Olds" and crank up the font 
size to absurd levels to compensate. The result is not merely an 
enormously waste of screen real-estate on a form factor notorious for 
every last millimeter being crucial, but the fonts themselves actually 
manage to be uncomfortably large to read in the first place.


(Frankly, devices and users quite *obviously* should be able to just set 
their own preferred font size globally. And accordingly, that's exactly 
how HTML *1* was designed. But now that ships's sailed and we're left 
with the complete f&*$%#@ s*@%storm that is HTML 4/5...)


2. The only reason extra margins would be needed on the actual 
post-viewing pages would be as a workaround for those goofy phones with 
the nonsensical misfeature of "edge-to-edge" screens the manufacturers 
have been trying to push (just because they can, and because they figure 
its harder for their competitors to copy). Handheld touchscreens obviously
need borders (that's just basic HCI common-sense), and requests for 
applications/websites to add them back in just proves its nothing more 
than a glaring flaw of the phone itself. People with better 
practicality-oriented phones shouldn't have to sacrifice their own 
perfectly usable real estate just because of some *other* phones' 
MBA-driven lunacy.


In any case, I think this visual refresh is a huge improvement, I love it.

Re: Proposal for porting D runtime to WebAssembly

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 11/23/19 3:48 PM, Sebastiaan Koppe wrote:

On Saturday, 23 November 2019 at 15:23:41 UTC, Alexandru Ermicioi wrote:


I was wondering whats your position on Fibers?


I am not going to support them in this initial port. And to be honest I 
rather see us moving towards stackless coroutines.


I really hope you're right. I've been pushing for those for years, but 
never got the impression anyone else cared. The fact that C# has had 
them for eons and D still seems to have no interest in coroutines that 
*don't* involve the overhead of fibers bothers me to no end.


I did started working on a couple DIPs for them, though. Interestingly, 
I just found out today about C++'s proposed coroutines and was shocked 
by how similar they are to what I was designing; even right down to 
details like how the existence of a yield instruction is what triggers 
the compiler to treat the function as a coroutine, and the requirement 
that a coroutine's return type be a special type that includes the state 
information.


Still, a few differences, though. For example, unlike the C++ proposal, 
I'm hoping to avoid the need for additional keywords and heap 
allocation. And I also started a secondary DIP that builds on the 
coroutine foundation to make a much cleaner user-experience using the 
coroutines to generate ranges (what I would expect to be the most common 
use-case).

Re: dud: A dub replacement

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 11/19/19 3:29 AM, Robert Schadek wrote:
On Monday, 18 November 2019 at 16:31:09 UTC, Nick Sabalausky (Abscissa) 
wrote:
As has been discussed elsewhere a few months ago, dependency 
resolution should be outsourced to an established SAT 
<https://en.wikipedia.org/wiki/Boolean_satisfiability_problem> solving 
lib, to avoid re-inventing a notoriously difficult wheel. This is what 
all the serious package managers have been moving towards, after 
invariably hitting problems (much like dub) trying to roll-their-own.


OT: By saying "all the __serious__" you effectively ended this part of 
the thread.

You basically say, that whatever I do, solve P=NP for instance, dud will
never be a __serious__ package manager because it does not use an
existing SAT solver.
That's just bad arguing.


Dude, it's just casual speech, not formal logic. A colloquialism, not a 
formal claim of "For all X, X always necessarily implies Y".


The thing I want from dud, is to tell me what dependency chain let to 
conflicts

and this I find hard to extract from current SAT solvers.
Most I have worked with just told me: "This solution works" "NO"
Also the debug experience is not really great most of the time.


Ok, now that I wasn't aware of.

Re: dud: A dub replacement

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 11/19/19 11:30 AM, Steven Schveighoffer wrote:


And I would complain that the fact json exists as a file format already 
screws up dub add -- using dub add removes ALL comments in an SDL file, 
and rewrites the file in the order it sees fit.


result: I don't use dub add any more.


Oops, that's probably actually my fault, not dub's. Those are current 
limitations of the sdl lib, SDLang-D.


1. The (pull) parser doesn't currently emit comments (and consequently 
the DOM doesn't support them either, not that it matters for dub which 
uses the pull parser directly). IIRC, the comments are currently being 
ignored in the lexer. Shouldn't be TOO terribly hard to fix, though. 
Modify the lexer to emit them as a new token type, and adjust the 
parser's grammar logic to accept them and to emit them as a new pull 
parser event. (PR's always welcome!)


2. IIRC, the lib's only method of generating sdl involves using the DOM, 
and TBH, I don't remember offhand just how friendly/unfriendly it is to 
maintaining a specific ordering. I'd have to look into that. Ideally, 
there should probably be a range-based reverse-pull-parser that just 
takes user-generated pull parser events and spits out an sdl doc.

Re: dud: A dub replacement

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 11/18/19 7:59 AM, Joseph Rushton Wakeling wrote:

   - I would imagine getting dependency resolution really right
     would be top of the list -- it would be good to aim to fix
     issues like https://github.com/dlang/dub/issues/1732


As has been discussed elsewhere a few months ago, dependency resolution 
should be outsourced to an established SAT 
 solving 
lib, to avoid re-inventing a notoriously difficult wheel. This is what 
all the serious package managers have been moving towards, after 
invariably hitting problems (much like dub) trying to roll-their-own.

Re: dud: A dub replacement

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 11/18/19 3:54 AM, Jacob Carlborg wrote:


Perhaps this ship has already sail. But YAML would have been a better 
choice. It's a superset of JSON. All the existing JSON description files 
would have worked as is.
YAML's grammar is a convoluted read-only mess. Every time I have to 
write it I feel like I'm just guessing and hoping I'm magically writing 
it correctly. I've even had silent problems on travis-ci that turned out 
to be .travis.yml not being parsed the way I thought. That sort of thing 
shouldn't even be *possible* on a config file format.


Especially irritating to me is even just the basic nesting - the whole 
"sometimes you HAVE to use a hyphen and sometimes you have to OMIT the 
hyphen (or it'll silently be interpreted wrong)". And yea, yea, "Object 
vs array", whatever, but when you're using YAML for hand-written config 
files, the whole distinction between what should be objects vs arrays is 
just a big pile of arbitrary pointlessness (a flaw it inherits from JSON).


And the grammar being a superset of JSON doesn't really help much in 
practice, because real idiomatic YAML in the wild (including config file 
examples) doesn't use it.

Re: dud: A dub replacement

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 11/11/19 8:44 AM, Robert Schadek wrote:


The goal of dud is mostly do what dub does, but more understandable.
dud will/does aim for a tasteful subset of dub's features.
Meaning, most dub files should be good with dud.
If they are not, you will/should get an error message telling you whats 
wrong.
The bigger goal, at least personally, is to have a code base of pure 
functions

that is "trivial" to understand and debug.
The rules of thumb is: "When your line gets longer than 80 characters,
restructure your code!", "Branch statements are code smells."



Sounds cool!

Only a few percent are not ingestable by dud, and those are in IHMO not 
valid

anyway (to be fair, there is some strange  out there).


From what I've seen, dub tends to take the approach of "silently ignore 
anything in dub.sdl I don't recognize as valid". I'll admit that may be 
an important approach for a tool that has no concept of its own changing 
versions (which is somewhat strange for dub, considering half of dub is 
a package manager.) But the flipside is that this fosters and breeds 
errors and invalid files in the wild (see: 90's era web browsers).


I'm curious, are there any particular anti-patterns you've noticed as 
being common in the uningestible repos?

Re: Ownership and Borrowing in D

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 7/15/19 10:58 AM, Mike Parker wrote:


The blog:
https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/



Very interesting!

One formatting issue though:
"D has a history of using function attributes to alter the semantics of 
a functionfor example"


Note the "".

Re: Let's celebrate Dlang on D day

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/25/19 1:03 AM, Walter Bright wrote:

On 5/24/2019 9:00 PM, Mike Franklin wrote:

On Saturday, 25 May 2019 at 03:22:50 UTC, Murilo wrote:
On the 6th of June(6/6) we celebrate the D day on Normandy, but I 
have decided to turn it into our own holiday to celebrate the D 
language.


I'm sure you mean well, but I will be spending D-Day remembering the 
sacrifice of these men: 
https://en.wikipedia.org/wiki/Normandy_landings#/media/File:Normandy_American_Cemetery_and_Memorial,_June_2012.jpg 



Perhaps you could find a way to use the D language to honor them.


I think it's alright. I was invited to teach a D seminar in Holland a 
few years back around Memorial Day. They were happy to conflate the two 
(it was their idea), and the Dutch revere the sacrifice of the Allies on 
D-Day.


My father was a D-Day veteran, too, and I very much doubt he would have 
been offended by it. My Dutch friends were thrilled to find out my 
father was a vet, and they certainly would have shown him a good time 
had he come along. They even gave me some D-Day gifts.


The D for D-Day thing was all in good fun all around.

When I was a boy nobody cared my father was a vet. Everyone's dad was a 
vet. My neighbor next door was a paratrooper who'd lost his leg. My 
dad's best friend had his face burned off. It was kinda normal.


But in his later years, people started to acknowledge the remaining 
veterans, and my father really enjoyed that. If you are lucky enough to 
know one, tell him thanks. You'll make his day.




Wise words, but I'll add another perspective also worth noting:

My grandfather and *at least* one (to my immediate knowledge) of my 
great uncles were WW2 veterans. For all I know, they could have been 
D-Day, or any other involvement, but nobody in our family would ever 
know because they made a point of never talking about it (hence my 
uncertainty about how many more there may have been). One of them even 
declined a major award (purple star or metal of honor, was never clear 
on which)...or maybe it was that he was sent one, but never acknowledged 
it...either way, same sentiment.


They're both gone now for unrelated old-age reasons, but from what I've 
been able to piece together, the idea was that their participation was 
something that needed to be done, but should NEVER involve taking pride 
in - as that would be an unethical validation of war and the unspeakable 
actions that it made necessary. (That, and the whole "true heroes don't 
survive" thing.) Frankly, I think that's a rather appropriate attitude 
to take toward such service.

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/28/19 6:50 PM, Abdulhaq wrote:

On Tuesday, 28 May 2019 at 20:54:59 UTC, Robert M. Münch wrote:
.


The software we sell, would still fit on one floppy disk (if there are 
still people knowing what it is). And I'm always saying: "Every good 
software fits on one floppy-disk." Most people can't believe that this 
is still possible.


I'd argue games are the obvious exception, just on account of the 
graphics/sound/etc assets, but you definitely make a fair point.




I remember VisiCalc.com.
And I remember when no program would need more than 640k RAM.
But I also remember installing msoffice from 31 floppy discs


I think I still have a stack of floppies from an early version of MS 
Visual C/C++. Plus similar floppy stacks from other 90's compilers[1] 
But 31 install disks is quite impressive, I'm not sure I can match 
that[2]. I tip my retro-hat to you, good sir!


[1] I realize others have me beat here, but just the memory of taking 
college classes that utilized Visual Basic 6 makes me feel old...


[2] I think my earliest version of Office is new enough to be on CD-ROM 
- back from the "Encarta" era - anyone remember that? I actually kinda 
miss it, it made heavier use of audio/video than Wikipedia does. Heck, 
it made the future seem much brighter than what we ended up with! (And, 
interestingly, it also served as an early example of MS disregarding 
their OS's UI design guidelines in their own apps. Still relevant today!)

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/28/19 2:37 AM, Robert M. Münch wrote:


We are considering MT. A GUI should never stuck, as a user I'm the most 
important part and my time is most valuable. So, an application should 
never ever slow me down.




It's incredibly refreshing to hear a developer say that, instead of the 
usual, "As a *developer*, I'm the most important part and my time is 
most valuable. So, my users should just go buy faster hardware."

Re: Let's celebrate Dlang on D day

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/26/19 9:16 PM, Ola Fosheim Grøstad wrote:

On Monday, 27 May 2019 at 00:56:50 UTC, Nick Sabalausky (Abscissa) wrote:
in defense against the benign. So congrats those pretending to be 
anti-Nazi while utilizing that to build the NEXT new fundamentalist 
regime.


I have to admit that I do use gmail, but I wonder if it is healthy that 
NSA have access to basically all letters exchanged by millions or 
billions of people across the globe…


But then… gmail is so convenient…

Convenience and a lack of principles is our weakness as a society. And 
we are all guilty at one level or another.
I run my own mail server, but I'll admit that has more to do with my own 
unique approach to spam prevention, and my dislike of webmail 
interfaces, than it does anything else. (And I do have gmail as a backup 
in case of server failure.)


No argument here, I'm just as guilty of the occasional sacrifice of 
principles for convenience as any other normally-headstrong brd (I 
didn't used to be...but then my 20's ended, and most of my 30's, and 
wouldn't you know...I ran out of my double-dose of teenage angst ;) Just 
wanna get by now, like any stereotypical late-30-something... ;) )


It's extremely difficult in modern society to stick to principles that 
matter. It really does put you at a notable disadvantage, which, I 
imagine, is why most people never even give it a second thought to begin 
with.


At least in the US, I've become convinced this is (at least in large 
part) a fundamental, inseparable, consequence of the legal guidelines 
ruling corporate entities (namely, the fact that profit is, by law, 
*required* to be a corporation's top priority).


I suspect our closest hope may lie with something like this: 
<https://en.wikipedia.org/wiki/Social_purpose_corporation> Although, 
even that only seems a mere "step in the right direction", rather than a 
solution...(Under it, ethical/societal matters to be weighed must be 
spelled out during incorporation, otherwise they're still not legally 
permitted to be considered in decision-making, and there's apparently no 
requirement for even having any such clauses at all). But anything 
*better* than that (or even full-50-state-deployment as-is) is unlikely 
to ever happen in the US: Anything that doesn't directly facilitate 
"money is power, might makes right" just gets labeled "communist" or 
"socialist" and rejected outright by the nationalist rednecks we've been 
overrun by ever since 9/11. (Go figure, they attack us...and we respond 
by throwing away any credibility we ever had. Figures, coming from the 
same fine folks who brought the world such hits as "Puritanism", "Witch 
Trials" and "Shorten a War by Nuking Civilians - But Still Claim The 
Moral High-Ground")

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/26/19 11:46 PM, Ola Fosheim Grøstad wrote:

On Monday, 27 May 2019 at 03:35:48 UTC, Nick Sabalausky (Abscissa) wrote:
suggestion that Robert could get this going an order of magnitude 
faster without too terribly much trouble. Luckily, Ethan explained my 
stance better than I was able to.


I think you guys overestimate the importance of performance at this 
early stage.


The hardest problem is to create a good usability experience and also 
provide an easy to use API for the programmer.




Again, I don't think anyone actually said that it absolutely needs to be 
done *at this early stage*. I know I certainly didn't.


Besides, from what Robert described, it sounds like he already has it 
decoupled and modular enough that performance *can* likely be improved 
later (probably by an order of magnitude) without too much disruption to 
it's core design. So, on that, believe it or not, it sounds like we 
already agree. ;)


And I'll point out *again*, the only points I was trying to make here 
were to dispel the misunderstandings, misinformation, and frankly 
knee-jerk reactions towards game engines and, more importantly, 
game-engine-like approaches.


But please understand, (and I strongly suspect this also speaks to the 
reason for Ethan's arguably abrasive tone): It gets REALLY, *REALLY* 
tiring when you spend the majority of your life studying a particular 
discipline (videogame code) and, as far as you've EVER been able to 
tell, pretty much the ENTIRE so-called-professional community outside of 
that specific discipline has absolutely 100% verifiably WRONG ideas 
about your field, and then they go and defend those falsehoods and 
prejudices with more misinformation and dismissal.


And @Robert: FWIW, I *am* definitely curious to see where this project 
goes. Also: While it *looks* in the video like a simple grid being 
resized, you've commented that under-the-hood it's really more of a 
flexbox-like design. This suggests that the computations you're doing 
are (or will be) capable of far more flexibility than what is apparent 
in the video. I'm curious what sorts of CSS flex-like features are 
currently being accommodated for in the computations, and are projected 
in the (hopefully?) near future?

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/26/19 9:52 PM, Manu wrote:


Unity is perhaps the worst possible comparison point. That's not an
example of "designing computer software like a game engine", it's more
an example of "designing a game engine like a GUI application", which
is completely backwards. Optimising Unity games is difficult and
tiresome, and doesn't really have much relation to high-end games.
There's virtually no high-end games written in Unity, it's made for
small hobby or indy stuff. They favour accessibility over efficiency
at virtually all costs.


While I agree completely (based on direct experience), I also feel 
compelled to point out, just as an aside:


I've seen some games that make Unity look WAY worse than it really is. 
Ex: The PS4 versions of "The Golf Club 2" and "Wheel of Fortune". As 
much as I admit I enjoy *playing* those games, well...Unity may have its 
technical drawbacks, but cooome ooon!!, even at that, it's still WAY 
more capable than the steaming joke those games make Unity appear to be. 
I've seen indie games on PS3 that did much a better job with Unity.



They do have the new HPC# ECS framework bolted on the side though,
that's the start of something sensible in Unity.


I'm chomping at the bit for that, particularly "Project Tiny". I'm 
converting some old flash stuff to unity/webgl and that framework would 
be fantastic for it. Only problem is I'm currently relying on some 
things (like procedural geometry, though I suppose I could potentially 
change that...) that AFAICT aren't yet supported by Project Tiny. But, 
maybe if I'm lucky (or realllyyy sll) it'll get there by the 
time I'm done with the basic flash->unity conversion and ready to 
re-architect it some more.

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/26/19 9:32 PM, Ola Fosheim Grøstad wrote:> > Why do you guys insist 
on him doing it your way?
I never said that. And just to further clarify, I also never said he 
should USE a game engine for this.


I was only responding to the deluge of misinformation about 
game-engine-like approaches, all stemming from Manu's suggestion that 
Robert could get this going an order of magnitude faster without too 
terribly much trouble. Luckily, Ethan explained my stance better than I 
was able to.

Re: Let's celebrate Dlang on D day

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/26/19 8:42 PM, Ola Fosheim Grøstad wrote:

On Monday, 27 May 2019 at 00:12:51 UTC, Nick Sabalausky (Abscissa) wrote:
Don't know about Europe, but here in the US, an unfortunate part of 
the basic culture is that people tend to spend their entire lives here 
going around LOOKING for reasons to be offended, and by golly, they 
WILL be CERTAIN to find it whether it exists or not.


Keep in mind that we in Europe still have a memory in society of nazi 
boots walking in our streets, ripping people out of their beds and 
sending them to concentration camps.


And we know there are some people in our society that are willing to 
pick up that ideology. A small group perhaps, but there is a 
subconscious fear that those will rise again in a new shape or form. It 
wasn't only Germans that were nazis, they were everywhere. They were 
among our own people too.


Here in the US we already have *leaders* with more or less that very 
same...I'm going to call it a mal-ideology. So, we're not in such 
terribly different boats. Arguably, US is closer to a repeat of that 
right now. Heck, look at the new "Federal ID" and modern TSA - it's 
basically 1930's "traveling papers" all over again, and just like then, 
everyone's too pumped full of nationalism bull ("U..S..A!..U..S..A!..") 
and scapegoat-searching to notice.


Further still, that same Nazi, or ISIS, or whatever other evil 
fundamentalist mal-ideology ALL stems directly from getting all bent out 
of shape over what's benign and setting as sacred cows in defense 
against the benign. So congrats those pretending to be anti-Nazi while 
utilizing that to build the NEXT new fundamentalist regime.

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/25/19 7:23 PM, Ethan wrote:


[...]


+1 (trillion)

In my entire software career, I have yet to ever come across even one 
programmer without direct game engine experience who actually has 
anything intelligent (or otherwise just simply NOT flat-out wrong) to 
say about game programming. People hear the word "game", associate it 
with "insignificant" and promptly shut their brains off. (Much like how 
average Joes hear the word "computer", associate it with "difficult", 
and promptly shut their brains off.)

Re: Let's celebrate Dlang on D day

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/25/19 5:56 PM, Murilo wrote:


Sorry people, I did not mean to disregard the heros of D Day. It is 
because I am latin american and here nobody cares about the second WW 
cause we didn't participate much. I didn't know that in the US you 
people had all of that respect for D Day.


Don't know about Europe, but here in the US, an unfortunate part of the 
basic culture is that people tend to spend their entire lives here going 
around LOOKING for reasons to be offended, and by golly, they WILL be 
CERTAIN to find it whether it exists or not.

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/23/19 5:01 PM, Ola Fosheim Grøstad wrote:

On Thursday, 23 May 2019 at 20:20:52 UTC, Nick Sabalausky (Abscissa) wrote:
flexibility. And I think you're *SEVERELY* underestimating the 
flexibility of modern game engines. And I say this having personally 
used modern game engines. Have you?


No, I don't use them. I read about how they are organized, but I have no 
need for the big gaming frameworks which seems to look very bloated, and 
frankly limiting. I am not really interested in big static 
photorealistic landscapes.


Wow, you're just deliberately *trying* not to listen at this point, 
aren't you? Fine, forget it, then.

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/23/19 3:52 PM, Ola Fosheim Grøstad wrote:

On Thursday, 23 May 2019 at 19:32:28 UTC, Nick Sabalausky (Abscissa) wrote:
Game engines *MUST* be *EFFICIENT* in order facilitate the demands the 
games place on them. And "efficiency" *means* efficiency: it means 
minimizing wasted processing, and that *inherently* means *both* speed 
and battery.


I think there is a slight disconnection in how different people view 
efficency. You argue that this is some kind of absolute metric. I would 
argue that it is a relative metric, and it is relative to flexibility 
and power.


This isn't specific to games.

For instance, there is no spatial datatructure that is inherently better 
or more efficient than all other spatial datastructures.


It depends on what you need to represent. It depends on how often you 
need to update. It depends on what kind of queries you want to do. And 
so on.


This is where a generic application/UI framework will have to give 
priority to being generally useful in the most general sense and give 
priority to flexibility and expressiveness.


A first person shooter game engine, can however make a lot of 
assumptions. That will make it more efficient for a narrow set of cases, 
but also completely useless in the most general sense. It also limits 
what you can do, quite severely.




Of course there's always tradeoffs, but I think you are very much 
overestimating the connection between inherent performance limitations 
and things like API and general usefulness and flexibility. And I think 
you're *SEVERELY* underestimating the flexibility of modern game 
engines. And I say this having personally used modern game engines. Have 
you?


FWIW, On 80's technology, I would completely agree with you. And even to 
some extent on 90's tech. But not today.

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/22/19 8:34 PM, H. S. Teoh wrote:

And this isn't just for mobile apps; even the pervasive desktop browser
nowadays seems bent on eating up as much CPU, memory, and disk as
physically possible -- everybody has their neighbour's dog wants ≥60fps
hourglass / spinner animations and smooth scrolling, eating up GBs of
memory, soaking up 99% CPU, and cluttering the disk with caches of
useless paraphrenelia like spinner animations.

Such is the result of trying to emulate game-engine-like behaviour.


No, that resource drain is BECAUSE they're trying to do game-like things 
WITHOUT understanding what game engine developers have learned from 
experience about how to do so *efficiently*.



 And
now you're recommending that everyone should write code like a game
engine!



Why is it so difficult for programmers who haven't worked on games to 
understand the basic fundamental notion that (ex.) 0.1 milliseconds of 
actual CPU/GPU work is ALWAYS, ALWAYS, ALWAYS *both* faster *and* lower 
power drain than (ex.) 10 milliseconds of actual CPU/GPU work. And that 
*that* is *ALL* there is to software efficiency! Nothing more!


So yes, absolutely. If you *are* going to be animating the entire screen 
every frame for a desktop UI (and I agree that's not always a great 
thing to do, in part for battery reasons), then yes, I'd ABSOLUTELY 
rather it be doing so in a game-engine-like way so that it can achieve 
the same results with less demand on the hardware. And if you're NOT 
animating the entire screen every frame, then I'd STILL rather it take 
advantage of a game-engine like architecture, because I'd rather my 
static desktop UI take 0.01% CPU utilization than 2% CPU utilization 
(for example).




(Once, just out of curiosity (and no small amount of frustration), I
went into Firefox's about:config and turned off all smooth scrolling,
animation, etc., settings.  The web suddenly sped up by at least an
order of magnitude, probably more. Down with 60fps GUIs, I say.  Unless
you're making a game, you don't *need* 60fps. It's squandering resources
for trivialities where we should be leaving those extra CPU cycles for
actual, useful work instead, or *actually* saving battery life by not
trying to make everything emulate a ≥60fps game engine.)


Yes, this is true. There's no surprise there. Doing less work is more 
efficient. Period. But what I'm continually amazed that the majority of 
non-game developers seem to find so incredibly difficult to grasp is 
that NO MATTER WHAT FRAMERATE or update rate you're targeting: What is 
MORE efficient and what is LESS efficient...DOES NOT CHANGE!!! PERIOD.


If you ARE cursed to run a 60fps GUI desktop, which would you prefer:

A. 80% system resource utilization, *consistent* 60fps, and 2 hours of 
battery power. Plus the option of turning OFF animations to achieve 1% 
system resource utilization and 12 hours of battery.


or:

B. 100% system resource utilization, *inconsistent* 60fps with frequent 
drops to 30fps or lower, and 45 minutes of battery power. Plus the 
option of turning OFF animations to achieve 15% system resource 
utilization and 4 hours of battery.


Which is better? Because letting you have A instead of B is *exactly* 
what game engine technology does for us. This is what efficiency is all 
about.

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/23/19 3:29 PM, Ola Fosheim Grøstad wrote:

On Thursday, 23 May 2019 at 19:13:11 UTC, Nick Sabalausky (Abscissa) wrote:
Serious photographers and videographers use things like JPEG and MPEG 
which are *fundamentally based* on cutting imperceptible corners and 
trading accuracy for other benefits. The idea of a desktop GUI 
absolutely requiring perfect pristine accuracy in all things is 
patently laughable.


What do you mean?

Besides, it is wrong. If you create a font editor you want accuracy. If 
you create an image editor you want accuracy. If you create a proofing 
application you want accuracy. If you create a PDF application you want 
accuracy.


They want accuracy TO THE EXTENT THEY (and others) CAN PERCEIVE IT. That 
is the key. Human perception is far more limited than most people realize.

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/22/19 6:33 PM, H. S. Teoh wrote:

On Wed, May 22, 2019 at 02:18:58PM -0700, Manu via Digitalmars-d-announce wrote:

On Wed, May 22, 2019 at 10:20 AM Ola Fosheim Grøstad via
Digitalmars-d-announce  wrote:

[...]

But you shouldn't design a UI framework like a game engine.

Especially not if you also want to run on embedded devices
addressing pixels over I2C.


I couldn't possibly agree less; I think cool kids would design
literally all computer software like a game engine, if they generally
cared about fluid experience, perf, and battery life.

[...]

Wait, wha...?!  Write game-engine-like code if you care about *battery
life*??  I mean... fluid experience, sure, perf, OK, but *battery
life*?!  Unless I've been living in the wrong universe all this time,
that's gotta be the most incredible statement ever.  I've yet to see a
fluid, high-perf game engine *not* drain my battery like there's no
tomorrow, and now you're telling me that I have to write code like a
game engine in order to extend battery life?

I think I need to sit down.


You're conflating "game engine" with "game" here. And YES, there is very 
meaningful distinction:


Game engines *MUST* be *EFFICIENT* in order facilitate the demands the 
games place on them. And "efficiency" *means* efficiency: it means 
minimizing wasted processing, and that *inherently* means *both* speed 
and battery.


The *games*, not the engines, then take that efficiency and use it to 
fill the hardware to the absolute brim, maximizing detail and data and 
overall lushness of the simulated world (and, in the case of indie 
titles, it's also increasingly used to offset sloppy game code - with 
engines like Unity, indie game programming is increasingly done by 
people with very little programming experience). THAT is what kills 
battery: Taking an otherwise efficient engine and using it to saturate 
the hardware, thus trading battery for either maximal data being 
processed or for lowering the programmer's barrier to entry.


Due to the very nature of "efficiency", the fundamental designs behind 
any good game engine could just as easily be applied to minimizing 
battery usage as they can be to maximizing CPU/GPU utilization.

Re: D GUI Framework (responsive grid teaser)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/22/19 6:39 PM, Ola Fosheim Grøstad wrote:
There's a reason games can simulate a rich world full of dynamic data 
and produce hundreds of frames a second, is


Yes, it is because they cut corners and make good use of special 
cases... The cool kids in the demo-scene even more so. That does not 
make them good examples to follow for people who care about accuracy and 
correctness. 


Serious photographers and videographers use things like JPEG and MPEG 
which are *fundamentally based* on cutting imperceptible corners and 
trading accuracy for other benefits. The idea of a desktop GUI 
absolutely requiring perfect pristine accuracy in all things is patently 
laughable.

Re: bool (was DConf 2019 AGM Livestream)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/12/19 1:43 AM, Walter Bright wrote:

On 5/11/2019 7:27 PM, Mike Franklin wrote:
I think Walter is conflating how bool is stored in memory with its 
semantics.


That's exactly what I'm deliberately doing.

I'm currently considering using D's rich modeling features to create a 
new boolean type that behaves more like a boolean and less like a 
bit.  But it's unfortunate and disappointing we have to resort to 
something like that.


I understand. Every programmer, sooner or later, decides to step up and 
take a swing at inventing boolean.


No, not really. Only the ones using languages that either lack a 
high-level notion of boolean or conflate it with an integer.


(I have too - did you know that D 
used to have a `bit` builtin type?)


Yes. I remember those days. It was renamed "bool" to better reflect its 
actual real-world use-cases.


The programming landscape is 
littered with the corpses of one after another.


Only in languages that either lack a built-in bool or conflate it with 
integers.


Phobos has multiple ones 
- RefCountedAutoInitialize .yes and .no,


Basically the same as the "struct Yes and No" below...(and if it's 
somehow *diffe rent* from the normal struct yes/no, then that sounds 
like a very clear Phobos failing...)


and even a struct Yes and a 
struct No.


Which Andrei *intentionally* created as a library-based substitute for 
*named arguments*, if you'll recall without contorting the true history.


std.bitmanip has an enum A{True,False}. std.json has enum 
E{True=true}. std.typecons has the bizarre enum 
issue10647_isAlwaysTrue=true;.

> (One wonders what would happen if it was
> set to false. Would it cause a rip in the fabric of space-time? I dare
> not experiment with that!)


Yet more examples of how D either sucks at bool and/or needs named 
arguments. Thus, completely failing to provide support for the patently 
false "Every programmer, sooner or later, decides to [...] take a swing 
at inventing boolean" claim.


The C++ Committee currently is fiercely debating adding a "Boolean" 
construct in one of the longest threads I've ever seen. One of their 
problems is it conflicts with the endless "Boolean" types added to 
existing C++ code, along with every variation "Bool", "Bool", "boolean", 
etc.


Alex, I'll take "Languages which conflate boolean with integer" for 
$500, please...


Daily double

All this effort strongly implies that there's no such thing as a 
satisfactory bool type.


Correction:

All this effort strongly implies that there's no such thing as a 
satisfactory bool type *in languages which conflate booleans with integers*


On a final note, C++ added a std::vector special case, which works 
unlike any other vector type. Years of experience have shown that to 
have been a mistake, just like all the others, and it is widely derided 
as a complete failure.


Ohh, I see..So...you're saying that special-casing an *aggregate* of a 
type **cough**char**cough** is bad. And furthermore, that in turn, 
demonstrates that the element type of a special-cased aggregate must 
therefore be unsound as well.


Or is it that applying correct semantics to a type's aggregate without 
also applying them to the type itself is a recipe for disaster?

Re: DConf 2019 AGM Livestream

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 5/11/19 10:27 PM, Mike Franklin wrote:

On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote:


Regarding the discussion of how bool is handled...


It's a one bit integer so it should behave like a one bit integer

https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h17m50s


I think Walter is conflating how bool is stored in memory with its 
semantics.


I find this tends to be an unfortunately *very easy* trap to fall into 
for programmers highly-experienced in low-level work: the conflation of 
abstraction vs implementation. This conflation is something they're more 
accustomed to, more comfortable with, and more tolerant of, than other 
programmers.


The real key here is this:

Do we have 'bool' because a 1-bit integer is useful, or do we have 
'bool' because a "true vs false" abstraction is useful?


The answer to that dictates the correct semantics.

I'm currently considering using D's rich modeling features 
to create a new boolean type that behaves more like a boolean and less 
like a bit.  But it's unfortunate and disappointing we have to resort to 
something like that.


Please do! Way I figure, it'll either work great and be a fantastic tool 
to have, or at the very *worst*, if there turns out to be any downsides 
to using it (vs a well-made built-in bool), then it will still serve to 
help root out any areas where D can improve its in-library modeling 
capabilities.

Re: DConf 2019 Livestream

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

"When joining: Please connect using Internet Explorer, not Google 
Chrome or another web

browser."

You guys can't be serious, you're using WebEx?


Not us. The venue.

[...]

> Sorry about that.  It was supposed to be streaming to YouTube, but it
> fell through the cracks.  We are looking into it now.
[...]

>> I had to click Audio Connection -> Computer to get audio.
>
> You mean the "Call using computer" option.  That gives me an error:
>
> "Can't Call Using Computer, We're having a problem connecting to audio
> using your computer. Choose another audio connection option or try 
again."

[...]

> I gave up. I hope they will record the conference and publish it later.

[...]
> Now I get to bring the bad news. There's an issue right now with YouTube
> flipping the video horizontally in the livestream such that everything
> is backwards. They've been trying to find a solution for it but are so
> far unable to.
[...]

> The venue is not recording the videos through WebEx, so there's nothing
> to publish. There's another guy running a separate camera for the
> recordings.
[...]
[...]
[...]

This sort of stuff happens literally EVERY year! At this point, you can 
pretty much guarantee that for any Dconf, Day 1's keynote doesn't get 
professionally livestreamed, if its recorded at all. At the very LEAST, 
it makes us look bad.


Is there SOMETHING we can do about this moving forward? Maybe use 
Dconf/Dfoundation funds to hire a proven video crew not reliant on 
venue, or something...?

Re: Beta 2.086.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

Wow! A whole bunch of great, long-awaited stuff! There's --lowmem, 
reflection of privates, less optlink, import std, copy ctors...


The changelog has some formatting errors in the section "dub run will 
now automatically fetch a package if it's not found locally".

Re: New DConf Blog Post

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 4/11/19 10:11 AM, wjoe wrote:


No offense, but http://motherfuckingwebsite.com/



That is the best website EVER. Times a billion. Says exactly the things 
I've been wanting to scream at jet-engine volume straight into the faces 
of every web designer and full-stacker in the world.


"Responsive web" always made me cringe. HTML-freaking-version-ONE was 
responsive. And semantic. It was specifically *designed* to be. But then 
the designers and the know-nothing software managers came, hated that 
stuff, and killed it all with fire. Then when the sausage-finger small 
screens came (not to mention browser diversity and "emerging markets"), 
they shit a brick and started over-re-engineering everything that was 
already there all along (plus some extra garbage nobody needs). Idiots.

Re: [OT] Cleanest look is a UI design failure (was Re: New DConf Blog Post)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 4/9/19 1:27 PM, Ali Çehreli wrote:

On 04/09/2019 08:45 AM, Nick Sabalausky (Abscissa) wrote:

 > I do think a lot of
 > designers these days go overboard with removing as much as they can

I've been setting the keyboard layout of my OS interfaces to Dvorak for 
20 years. Many Windows and Linux environments included...


I simply could not figure out how to do the same thing on a Windows 10 
work laptop. I had to find the answer on the good old internet. It turns 
out, I had to click something on the screen which gave no indication of 
clickability. What a design failure...




Yup. But I'm a little surprised it still lets you do that at all - the 
big trendy thing in tech these days is removing features. The minimalism 
obsession really has gotten out of hand. But then the tech world never 
really has been any good with moderation and comprehending the fallacy 
of "If a little of X is good, then more must always be better!" It's 
just one silver bullet obsession after another.

Re: New DConf Blog Post

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 4/8/19 12:42 PM, matheus wrote:


For example let's take this Forum (https://forum.dlang.org):

Like I said above I think this forums has an excess of borders and I'd 
prefer something like this: https://i.imgur.com/OQCPojN.png than what 
you have today, but this is a personal taste.


That's actually a really nice improvement, IMO. I do think a lot of 
designers these days go overboard with removing as much as they can (and 
forgetting the "...bot no more" part). But that mockup strikes a very 
nice balance.


If anything, I'd play around with adding a slight emphasis to the column 
headings ("Group", "Last Post", etc), maybe by putting them in bold. As 
they are in the mockup, they tend to disappear to the mind. Took me 
awhile to realize they were even still there, and that was only because 
I was looking for them.


But, that is really nice overall. I'd love to see the forum adopt it. 
(Although I normally use the NNTP interface, so take the opinion for 
whatever it's worth.)

Re: New DConf Blog Post

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 4/6/19 6:30 PM, bauss wrote:


Just going to respond to this:

"If you haven’t visited the site in a while, you’ll surely notice that 
it’s been redesigned. The old version was not responsive and was quite 
annoying to manipulate on small screens."


The design is terrible and it really looks unprofessional.

While the old site wasn't responsive, the design was at least slightly 
better.


It just doesn't look very well done.

I'm not trying to be negative or anything, but it looks like someone who 
just learn html/css in 1999 tried to make the design of the page.




Aside from perhaps an overuse of padding on the left navbar, it looks 
good to me. Whaddya want, a bunch of those vaguely-relevant full-screen 
introductory images you have to scroll past just to get to any nuggets 
of actual content there might be?


The vast majority of "responsive" pages I've seen out there are 
absolutely god-awful for both aesthetics and practicality. This design 
is far better than any of them. Bear in mind too, that not playing an 
endless game of follow-the-crowd with design is a far cry from looking 
"terrible" or "unprofessional".


Not saying there isn't room for improvement, but "The design is terrible 
and it really looks unprofessional." makes it seem like you're looking 
at completely different site than I am.

Re: Phobos now compiling with -dip1000

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 3/22/19 11:06 PM, Walter Bright wrote:
Many thanks to Sebastian Wilzbach, Nicholas Wilson, Mike Franklin, and 
others!


It's been a long and often frustrating endeavor, but we made it and I'm 
very pleased with the results.


At the risk of embarrassing myself: Am I the only one who finds they 
need to google a DIP number every single time in order to have any idea 
what it refers to? (And then massage the query to get to the right place.)


On the off chance I'm not alone:
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md

Ie DIP1000: "Scoped Pointers": "...provides a mechanism to guarantee 
that a reference cannot escape lexical scope" in large part to aid 
non-GC memory management.


With that aside, this does indeed sound like a great milestone (not that 
I doubted!). Kudos and congrats all around!

Re: graphqld: A graphql backend written in D

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 3/20/19 1:44 PM, Robert Schadek wrote:

At Symmetry [6] we needed a graphql [1] backend.
So I wrote one.



Awesome! I only just learned about graphql very recently and was getting 
a bit envious of other languages supporting it. Very glad to have one 
less item on my list of "projects I'm itching to make happen".

Re: Containerize Your D Server Application

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 3/14/19 8:38 AM, Mike Parker wrote:
One of the items on my list of "things I'd like to do if I only had the 
time" is to create a Mud server with D and deploy it with Docker. Just 
for kicks. If I ever do get around to it, my ignorance of all things 
Docker will not be the time sink it could have been thanks to this 
latest post on the D Blog by Kai Nacke.


The Blog
https://dlang.org/blog/2019/03/14/containerize-your-d-server-application/

Reddit
https://www.reddit.com/r/programming/comments/b0zqck/containerize_your_d_server_application/ 



Interestingly, this appears to be by far the best introduction to docker 
I've ever come across - and that's *including* docker's own vacuous website.

Re: The D Programming Language has been accepted as a GSoC 2019 organization

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 2/27/19 11:05 AM, JN wrote:

On Wednesday, 27 February 2019 at 16:01:15 UTC, Bastiaan Veelo wrote:

On Tuesday, 26 February 2019 at 22:34:45 UTC, Seb wrote:


The D Language Language got accepted as a Google Summer of Code 
organization!


Awesome!



Or be turned off. If I didn't know about D, from that description I'd 
think it's some experimental language for whom Boost wasn't crazy enough 
with templates. "The best, most innovative ways to use the D language 
are yet to be discovered." That's great. But it doesn't answer the most 
important questions - what can it be used for, what makes it different 
than say C++ or Java.


In my experience, when non-D-users are asking that question, what 
they're REALLY looking for is one (and only one) gimmick that the entire 
D language (and ONLY D) takes religiously at the negligence of all else. 
And since "pragmatism" isn't a trendy silver-bullet ideology like Java's 
"Everything is an object", or JS's "Everything is a variant", Python's 
"Everything is a variant AND we have 'Zen'", Haskell's "Though shalt not 
do imperative", or Go's "ZOMG, It's from teh Google Gods!!!", so they 
gripe about not being spoon-fed marketing BS and walk away. Habitual 
consumerists. They're lost souls, slaves to pack mentality, so forget 
about them. Target leaders and thinkers instead.


Although frankly, I have to admit, this whole "Fast code, fast" thing is 
complete and utter rubbish compared to the "Better C++" that we've now 
decided to be politically incorrect (very ironically, despite active 
promotion of "betterC").

mysql-native v2.3.0 - With a request for assistance

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

Small update to mysql-native (A fully-D client library for MySQL/MariaDB 
that doesn't depend on any external MySQL/MariaDB libs).


The most interesting thing in v2.3.0 is that, thanks to @jpf91, the 
column names for a result set can now be obtained directly from the Row 
(via `Row.getName(columnIndex)`).


Aside from that, this release just involves some internal cleanups (with 
much more still to come) and a rather major reworking of the test runner 
script.


--

One important note for mysql-native users to be aware of (And this goes 
for all of mysql-native, not just this particular version):


Starting with MySQL Server v8.0.4, the server's default authentication 
mechanism was changed. Unfortunately, mysql-native does not yet support 
this new authentication style. For now, if you have sufficient admin 
privileges for your DB server, you can temporarily work around the issue 
like this:


https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues

Naturally, I consider fixing this the current top priority for 
mysql-native. But as I've been rather busy lately I haven't had as much 
time for this as I would like, so I would encourage any able-bodied 
coders to please beat me to it! Other mysql-native users will be 
appreciative. More details on the issue here:


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

--

mysql-native Home on GitHub:
https://github.com/mysql-d/mysql-native

mysql-native on Dub:
http://code.dlang.org/packages/mysql-native

mysql-native API reference:
http://semitwist.com/mysql-native

Re: D compilation is too slow and I am forking the compiler

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 11/26/18 11:53 AM, Guillaume Piolat wrote:


How many times have you been in this conversation:

--

- What language are you using?
- D.
- I know next to nothing about D.
- Oh, it's very good, I even built a business on it! arguments and features>.
- Oh no thanks. I should try Rust, it's secure, fast, modern blah blah; 
facts don't matter to me. But in reality I won't even learn a new 
language, I'm happy with a language without multi-threading.


--

It happens to me ALL THE TIME.
This pattern is so predictable it's becoming boring so now I just keep 
silent.




That's no surprise. The modern tech world is absolutely flooded with 
imbeciles and fashion-driven people.

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: Spasm - webassembly libary for single page applications

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

Nifty, I'll have to look into this. Any idea what it would take to get 
this doing some WebGL? (Or playing audio?) Or is this more for HTML-ish 
sorts of stuff?


What are the main current limitations?

[OT] My State is Illegally Preventing Me From Voting In The Upcoming 2018 US Elections

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

I sincerely apologize for the OT, but AFAIK, I don't have anywhere else 
to post. Please rm/delete/ban/etc... as appropriate, I take full 
responsibility. This is a (potentially inappropriate) "CYA" (Covering my 
"A 55") posting, so please delete/rm/ban/etc. as necessary, if applicable.


https://semitwist.com/articles/article/view/my-state-is-illegally-preventing-me-from-voting-in-the-upcoming-2018-us-elections

I am a 36-year-old, legal resident of Willoughby, Lake County, Ohio, 
United States. I have been a legal resident of this county for most of 
my life, and a legal resident of this state for my entire life, since 
the day I was born (an event which is also documented to have occurred 
in Willoughby, Lake County, Ohio, United States). I have never been 
arrested (nor convicted) of a felony, nor a misdemeanor. Yesterday 
(September 8, 2018), I (along with most of the city) received the 
following letter in the mail:


http://semitwist.com/Ohio_Letter_Front.jpeg
http://semitwist.com/Ohio_Letter_Back.jpeg

Note six things:

1. As most United States citizens are implicitly aware (though the 
government assumes NO responsibility to ensure citizens are aware of 
this), to vote in a United States of America election and have the vote 
legally *count*, a United States citizen MUST vote on the exact day of 
elections, from the exact location determined to be the correct voting 
location for said citizen. This correct voting location is determined 
based on the citizen's address of residence (ie, the mailing address 
where they live). Or at least, this is my best understanding based on 
what I've been told as a natural born citizen of the United States. If 
there is any inaccuracy, it has never been communicated to me either 
directly, nor through any school I have ever attended, nor any mail I 
have ever received, nor anyone I have ever had any contact with.


2. The exception to #1 is by voting through an absentee ballot (which 
comes with its own additional set of regulations and conditions which 
will invalidate the ballot).


3. I have NOT received any other correspondence, besides this exact 
letter, which gives me any information regarding the correct location to 
vote nor how to find the correct location to vote.


4. The letter does NOT tell me where I am supposed to go to vote. 
Instead, it tells me to use the website "www.myohiovote.com" to find out 
where I am supposed to go to vote.


5. If you go to "www.myohiovote.com" (with JavaScript enabled), it 
redirects to "https://www.sos.state.oh.us/elections/voters/;


6. The current Ohio Secretary of State is Jon Husted (Republican): 
https://en.wikipedia.org/wiki/Jon_Husted


Here's the clincher: On said website, "www.myohiovote.com" (ie, 
"https://www.sos.state.oh.us/elections/voters/;), via the one and only 
link to "Find My Polling Location", if you select my county (Lake 
County) and provide my address[1], the only response the [clearly 
badly-designed] website provides is "Based upon the data input, no 
records have been found. Please modify your search criteria."


[1] The official street name is precisely "Smugglers Cove" (That's 
correct, no apostrophe. And yes, the street name is unintentionally 
hilarious.) For privacy purposes, I obviously won't provide the exact 
house number, but given basic Internet map searching abilities, it 
shouldn't be difficult to come up with a valid four-digit house number 
beginning with "3".


I have already informed both the website and the Secretary of the 
State's office (via both email and via the website itself, via 
https://www.sos.state.oh.us/secretary-husted-office/contact-our-office/contact-us-agency/) 
of this problem. We'll see what, if anything, comes of it. I will update 
as I receive any information.

Re: expectations 0.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 09/04/2018 12:05 AM, Paul Backus wrote:
On Monday, 3 September 2018 at 21:55:57 UTC, Nick Sabalausky (Abscissa) 
wrote:
By contrast, a function that returns an `Expected!T` does *not* force 
its caller to acknowledge it. If an error occurs, and the caller 
never checks value or hasValue...nothing happens.


That's called squelching an error, and its EXACTLY the same problem as 
using non-Expect return values to indicate errors. I'd regard that as 
very notable hole in any Expected design as it breaks one of the core 
points of using Expect vs returning plain error codes: The user can 
still accidentally (or deliberately) squelch an error.


If you receive an `Expected!T`, you have the following choices available 
to you:


1. Handle the success case locally, and the failure case non-locally 
(i.e. use `value` directly).
2. Handle both the success case and the failure case locally (i.e. check 
`hasValue`).
3. Handle both the success case and the failure case non-locally (i.e., 
pass the `Expected!T` along untouched).


The difference between `Expected`, on the one hand, and both `Success` 
and plain-old exceptions, on the other, is that `Expected` gives you 
choice #3, and the other two don't.




I think you may be getting hung up on a certain particular detail of 
Vladimir's exact "draft" implementation of Success, whereas I'm focusing 
more on Success's more general point of "Once the object is no longer 
around, guarantee the error doesn't get implicitly squelched."


You're right that, *in the draft implementation as-is*, it can be 
awkward for the caller to then pass the Success along to some other code 
(another function call, or something higher up the stack). *Although*, 
still not impossible. So #3 still isn't eliminated, it's simply made 
awkward...


But reference counting would be enough to fix that. (Or a 
compiler-supported custom datatype that's automatically pass-by-moving, 
but that's of course not something D has).


And you haven't actually directly addressed the issue I've raised about 
failing to guarantee errors aren't implicitly squelched.


Why is choice #3 important? Because it doesn't branch. Both success and 
failure follow the same code path. That makes functions that use 
`Expected` much easier to compose than ones that throw exceptions. For 
example, if you throw an exception in the middle of a range pipeline, 
the entire thing comes crashing down--but an `Expected!T` will pass 
right through, and let you handle it when it comes out the other end.


Right. And as described above, I'm advocating an approach that preserves 
that (even for void) while *also* improving Expect so it can not 
*merely* improve things "in most cases", but would actually *guarantee* 
errors are not implicitly squelched in ALL cases where Expect!whatever 
is used.


I don't see the laziness here as being the core point. The laziness is 
the "how", not the raison d'etre. The laziness is simply a tool being 
used to achieve the real goals of:


- Allowing the caller the decide between foo/tryFoo versions without 
the API duplication.


- Decreasing exception-related overhead and increasing utility of 
nothrow.


The laziness (on the part of the caller, i.e., the code that *receives* 
the `Expected!T`) is important because it's what makes choice #3 
possible. It's an essential part of the design.


Again, what I'm proposing still preserves that.

Re: expectations 0.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 09/03/2018 02:49 AM, Paul Backus wrote:
On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky (Abscissa) 
wrote:
Note that the above has *nothing* to do with retrieving a value. 
Retrieving a value is merely used by the implementation as a trigger 
to lazily decide whether the caller wants `foo` or `tryFoo`. Going out 
of scope without making the choice could also be considered another 
trigger point. In fact, this "out-of-scope without being checked" 
could even be used as an additional trigger for even the non-void 
variety. After all: what if an error occurs, but the caller checks 
*neither* value nor hasValue?


The thing is, triggering on explicit access lets you handle errors 
lazily, whereas triggering at the end of the scope forces you to handle 
them eagerly.


Vladimir's `Success` type is, essentially, a way for a function to send 
something back up the stack that its caller is forced to acknowledge.


Yes, that's correct.

Throwing an exception is *also* a way for a function to send something 
back up the stack that its caller is forced to acknowledge.


Yes, but it's heavier-weight AND prevents the callee from being nothrow.

but when it comes to overall control-flow 
semantics, they are basically equivalent.


Control-flow semantics, sure, but as I pointed out in my previous 
sentence, there's more relevant things involved here than just control 
flow semantics.


By contrast, a function that returns an `Expected!T` does *not* force 
its caller to acknowledge it. If an error occurs, and the caller never 
checks value or hasValue...nothing happens.


That's called squelching an error, and its EXACTLY the same problem as 
using non-Expect return values to indicate errors. I'd regard that as 
very notable hole in any Expected design as it breaks one of the core 
points of using Expect vs returning plain error codes: The user can 
still accidentally (or deliberately) squelch an error.


To clarify: If the caller never checks value or hasValue, that does NOT 
mean the caller has carefully and deliberately chosen to disregard the 
error. It *could* mean that, but it could also mean they simply messed 
up. Deliberately squeching an error should NEVER be implicit, it should 
always require something like:


catch(...) { /+ Do nothing +/ }

or

if(!x.hasValue) { /+ Do nothing +/ }

That's what being lazy 
means: if you never open the box, it doesn't matter whether the cat is 
alive or dead.


I don't see the laziness here as being the core point. The laziness is 
the "how", not the raison d'etre. The laziness is simply a tool being 
used to achieve the real goals of:


- Allowing the caller the decide between foo/tryFoo versions without the 
API duplication.


- Decreasing exception-related overhead and increasing utility of nothrow.



Having one specialization be lazy and one be eager 
would be a nightmare for anyone trying to use the library.


Vladimir's Success vs Expect!T is NOT an example of "eager vs lazy". In 
BOTH cases, the callee treats errors lazily. And in BOTH cases, the 
caller (or whomever the caller passes it off to) is expected to, at some 
point, make a deliberate, explicit choice between "handle or throw". And 
as I said before, allowing the caller to accidentally (or implicitly) 
squelch the error is a fundamental breakage in the whole point behind 
Except.

Re: expectations 0.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 09/02/2018 11:23 PM, Paul Backus wrote:


This is a really clever technique. As you said, hard to say whether it's 
worth it compared to just throwing an exception normally, but still, 
really clever.


IMO, it's worth it. First of all, it decreases the asymmetry between 
`Expected!void` and other `Expected!T`. But more than that, there's one 
of the core benefits of of expected:


What's awesome about expected is that by providing only one function, 
the caller can decide whether they want a `foo()` that throws, or a 
`tryFoo()` that lets them manually handle the case where it doesn't work 
(and is potentially nothrow).


Note that the above has *nothing* to do with retrieving a value. 
Retrieving a value is merely used by the implementation as a trigger to 
lazily decide whether the caller wants `foo` or `tryFoo`. Going out of 
scope without making the choice could also be considered another trigger 
point. In fact, this "out-of-scope without being checked" could even be 
used as an additional trigger for even the non-void variety. After all: 
what if an error occurs, but the caller checks *neither* value nor hasValue?


There's only one possible downside I see:

What if the caller *intentionally* wants to ignore the error condition? 
Yes, that's generally bad practice, and signifies maybe it shouldn't be 
an exception in the first place. But consider Scriptlike: It has 
functions like `tryMkdir` and `tryRmdir` with the deliberate purpose 
letting people say "Unlike Phobos's mkdir/rmdir, I don't care whether 
the directory already exists or not, just MAKE SURE it exists (or 
doesn't) and don't bother me with the details!"


I suppose for cases like those, it's perfectly worth leaving it up to 
expectation's user to design, create and document a "Don't worry about 
the failure" variant, should they so choose. Probably safer that way, 
anyway.

Re: Assertions in production code on Reddit

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 08/30/2018 05:31 PM, Walter Bright wrote:
https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/ 


>
>High reliability is not achieved by making perfect designs, it is 
>achieved by making designs that are tolerant of failure. Runtime 
>checking is essential to this, as when a fault is detected the program 
>can go into a controlled state doing things like:

>
>aborting before more harm is done
>alerting the user that the results are not reliable
>saving any work in process
>engaging any backup system
>restarting the system from a known good state
>going into a 'safe mode' to await further instructions
>

I'm totally all for all of this in principle.

But here's the problem:

Aside from "abort the process immediately once...uhh, once the faulty 
process itself has already successfully *detected itself to be faulty*" 
(ie, already a violation of the basic principles being promoted in the 
article), we don't actually HAVE ready-to-use facilities for any of this.


Since we don't actually have such facilities, getting people to actually 
code by them IS going to be an even bigger uphill battle than trying to 
get them to unittest without any ready-to-use unittesting facilities.


And then THAT leads to yet another problem: If they're not actually 
coding by those principles (which they're obviously not doing because 
the facilities to do so aren't there), then they ARE occasionally going 
to be needing *some* code to be run after the fault occurs:


For example:
- Evaluating the assert condition to even detect something went wrong at 
all.

- Generating the assert failure reporting string.
- Generating the stack trace.
- Sending the failure string and stack trace to the logging process. Oh 
wait, we don't have an external logging process facility...

- Directly reporting and logging and the failure string and stack trace.

(And that list still ignores any cleanup the OS can't/doesn't know to do 
on our behalf.)


And, shit, if it's even POSSIBLE to do any of that within "the process 
that's already in an undefined state", then clearly we already have 
enough successful intra-process compartmentalization that the "At this 
point, we can't rely on ANYTHING!!!" notion is demonstrably bogus anyway.


Don't get me wrong, I'd LOVE to be able to do things as you suggest: To 
have all my fault-handling functionality and STILL have zero-reliance on 
the faulty process. But we DON'T have those facilities, therefore, 
nobody outside aeronautics, pacemaker firmware, etc, is realistically 
going to be able to justify going to all bother of creating such 
facilities to go along with their website, or text editor, or 
number-crunching tool, or videogame, etc... (IF the programmer in 
question even has the expertise to implement such a system correctly 
anyway - and most don't).

Re: SDLang-D v0.10.4 - Minor maintenance release

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 07/18/2018 01:57 PM, Anton Pastukhov wrote:

On Monday, 16 July 2018 at 04:14:12 UTC, Nick Sabalausky (Abscissa) wrote:

announce.sdl:
==

[...]


http://sdl.ikayzo.org/ is down, so maybe remove links to it from 
sdlang.org?


Yea, it has been for a looong time :( I keep hoping it'll come back, but 
I guess it doesn't look like that's going to happen.

SDLang-D v0.10.4 - Minor maintenance release

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

announce.sdl:
==

// SDLang-D
// -
// A library to read (pull parse or dom) and write (dom)
// SDLang data (such as used by DUB's dub.sdl files).
//
// SDLang
// ---
// A text-file format similar to XML/JSON/YAML, but is
// less verbose than XML/JSON and has simpler grammar
// rules than YAML, and supports more basic datatypes
// than just strings.

// Changes in this version:
version "v0.10.4" desc="Minor maintenance release" {
release-date 2018/07/15
changes {
fixed "TimeZone.getTimeZone deprecation hotfix" \
issue=55 author="@ZILtoid1991"
tests "Updated CI compiler list"
tests "Fix tests on DMD 2.081"
tests "Test on OSX (Travis) and Windows (AppVeyor)"
}
}

// Marketing...
links {
sdlangurl="https://sdlang.org/;
sdlang-d  url="https://github.com/Abscissa/SDLang-D;
dub   url="https://code.dlang.org/packages/sdlang-d;
changelog 
url="https://github.com/Abscissa/SDLang-D/blob/master/CHANGELOG.md;

}

==

Re: Encouraging preliminary results implementing memcpy in D

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/14/2018 05:01 AM, AnotherTorUser wrote:


sorry. but what world do you live in?


Note this part of what I said:

>> If I worked in such an organization that tracked its employees
>> activities *outside the workplace*

That part is KEY, but it sounds like you an errExit have chosen to 
ignore that part.


If all such people stopped working for such companies, what do you think 
the economic impact would be?


What do you think is the social impact if they don't? And don't even try 
to pretend the companies can't trivially solve the "economic" issues for 
themselves in an instant by knocking off the behaviour that causes loss 
of talent.

Re: Encouraging preliminary results implementing memcpy in D

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/14/2018 02:34 AM, errExit wrote:


The D Foundation now subjects all users having an ip originating from a 
tor exit node, to having their posts moderated (but by whom, when, how, 
criteria ?? etc).


Literally millions of people could, and probably would, be using that 
exit node.


So that is plain discrimination. It's not spammer management.

Forcing people to identify themselves, is also not about spammer 
management either.


The D Foundation IS now discimantory against those that want that 
believe that freedom and privacy is some to be protected.


This becomes problematic for those of us who work in 'certain 
organisations', that insist on tracking it's employees online activities 
(even outside of the workplace).


It's a shame the D Foundation has finally succumed to the big brother 
mentality - under the guise of protecting you from spam.


https://blog.torproject.org/dont-let-facebook-or-any-tracker-follow-you-web



I'm with you on a lot of that, however, this part troubles me:

"This becomes problematic for those of us who work in 'certain 
organisations', that insist on tracking it's employees online activities 
(even outside of the workplace)."


If I worked in such an organization that tracked its employees 
activities *outside the workplace*, I'd LEAVE it ASAP, and I'd strongly 
suggest anyone else do the same. I mean what insane workplace is that, 
the 1920's mob? Apple?


Honestly, if you believe strongly enough in Tor to use it, why in the 
world would you willfully aid and abed an organization that does that 
sort of thing? It doesn't make any sense at all. It's EXTREMELY 
self-contradictory and completely erodes your entire stance. If you're 
going to preach for personal freedom and privacy, at least have the 
basic integrity to LIVE the basic ideals you're preaching even when 
doing so ISN'T so trivial as installing a mere web browser.

Re: Arrogant - HTML5 dom with CSS selectors

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/13/2018 02:25 PM, Andrea Fontana wrote:
On Wednesday, 13 June 2018 at 18:06:02 UTC, Nick Sabalausky (Abscissa) 
wrote:
Does this mean that it requires the raw HTML input to already be fully 
conformant HTML5 or simply that it supports and outputs valid HTML5?


The second one. If you parse invalid html it tries to fix it and output 
valid html5.


And that it can parse correctly any valid html5 syntax. Or at least it 
should!




Awesome. I'll have to check it out.

Re: Arrogant - HTML5 dom with CSS selectors

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/13/2018 09:23 AM, Andrea Fontana wrote:
> On behalf of the company I work for [1] today I released a new library:
> arrogant.
>

Nice!


It is a fully conformant HTML5 dom library with CSS selectors.



Does this mean that it requires the raw HTML input to already be fully 
conformant HTML5 or simply that it supports and outputs valid HTML5?

Re: GitHub could be acquired by Microsoft

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/09/2018 08:29 PM, bauss wrote:

On Saturday, 9 June 2018 at 23:41:43 UTC, Nick Sabalausky (Abscissa) wrote:

(I just hope it doesn't lead to GitLab running out of cash too.)


And then Microsoft acquires both and everyone moves to Bitbucket.

Endless cycle :)


Ahhh! Time to make my own then! Wouldn't mind getting $7mil from MS :)

Re: GitHub could be acquired by Microsoft

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/09/2018 11:06 AM, Paolo Invernizzi wrote:


[1] 
https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/ 



From the link:
"It has been a crazy 24 hours for GitLab. More than 2,000 people tweeted 
about #movingtogitlab. We imported over 100,000 repositories, and we've 
seen a 7x increase in orders. We went live on Bloomberg TV. And on top 
of that, Apple announced an Xcode integration with GitLab."


I find it honestly hilarious that MS buying GitHub has been a huge boost 
to GitLab. But then, I do love irony :)


(I just hope it doesn't lead to GitLab running out of cash too.)

Re: GitHub could be acquired by Microsoft

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/09/2018 03:56 AM, Kagamin wrote:

On Saturday, 9 June 2018 at 07:06:23 UTC, Nick Sabalausky (Abscissa) wrote:
Whether web API or web scraping: Either way, you still have to submit 
an HTTP request, parse the results according to the format the server 
has chosen to spit out, and possibly follow up with additional HTTP 
requests.


https://docs.gitlab.com/ee/user/project/import/github.html done?


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

Re: SecureD moving to GitLab

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/09/2018 01:47 AM, Walter Bright wrote:


Oh, employers do try that. I would negotiate what is mine and what is 
the company's, before signing. In particular, I'd disclose all projects 
I'd worked on before, and get a specific acknowledgement that those were 
not the company's. When I'd moonlight, before I'd do so, I'd describe 
the project on a piece of paper and get acknowledgement from the company 
that it is not their project.


And I never had any trouble about it.

(These days, life is a bit simpler. One thing I like about Github is the 
software is all date stamped, so I could, for instance, prove I wrote it 
before joining company X.)




Maybe naive, maybe not, but my policy is that: Any hour of any day an 
employer claims ***ANY*** influence over, must be paid for ($$$) by said 
employer when attempting to make ANY claim on that hour of my life. Period.


There are already far too many 
would-be-slavedrivers^H^H^H^H^H^H^employers who attempt to stake claim 
to the hours of a human being's life WHICH THEY DO *NOT* COMPENSATE FOR.


If an employer *does not* pay me for an hour of my life which they 
*claim control over*, then the employer WILL NOT BE MY EMPLOYER. Period.


If others held themselves to the same basic standards, then nobody in 
the world would ever be slave^H^H^H^H^Hpersonal-property to a business 
which makes claim to a human life without accepted compensation.

Re: GitHub could be acquired by Microsoft

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/08/2018 06:02 PM, Brad Roberts wrote:


Essentially (if not actually) everything on github is available through 
their api's.  No need for scraping or other heroics to gather it.


That does make things a little bit simpler, but web scraping really 
isn't all that much more complicated.


Whether web API or web scraping: Either way, you still have to submit an 
HTTP request, parse the results according to the format the server has 
chosen to spit out, and possibly follow up with additional HTTP 
requests. The main differences are just: Web scraping can occasionally 
get thwarted by changes in the webapp's presentation layer. Whereas web 
API can occasionally get thwarted by business rules changing what 
is/isn't accessible via API (this has been known to happen).


Ie, scraping needs to deal with UI changes, but unlike API, it cannot be 
selectively hindered/disabled (unless the primary website itself is 
hindered/disabled, too).


Thus, a robust tool will support both published web API and web 
scraping, and select the answers from whichever one works.

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: GitHub could be acquired by Microsoft

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

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

but the valuable associated information like PR
discussions is specific to Github and there is no easy way (if there's a
way at all!) to export this data and import it elsewhere.


For importing, you may be right. For exporting, I'm not sure I agree. 
With curl and something like Adam's HTML DOM (or heck, even just regex) 
it shouldn't be too difficult to crawl/scrape all the information into a 
sensible format. That's a technique I've been wanting to do a LOT more 
with than I've had a chance to.


Although granted, that's still far more complicated than it SHOULD be, 
and doesn't help much if there's nowhere to import it into.



It's 2018, and history has shown that standard, open data formats are
what stands the test of time.


Yup. Unfortunately, history has also shown that closed-off and locked-in 
tend to be more lucrative business models. Which is why all the big 
muscle in the tech world is usually working *against* open standards.

Re: GitHub could be acquired by Microsoft

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/07/2018 04:36 AM, Walter Bright wrote:

On 6/6/2018 10:28 PM, Nick Sabalausky (Abscissa) wrote:
Keep in mind, if we had been commoditizing and decentralizing 
repository hosting, issue tracking, PRs, user accounts, etc. right 
from the start like we should've been, then this MS buyout of GitHub 
would've been entirely irrelevant to everyone outside GitHub itself. 
That's what happens with single points of failure. And the reason 
VCSes even went DVCS in the first place.


Bugzilla for issue tracking is independent of Github.


Yea, it certainly does have that going for it. And I have no real big 
objections to bugzilla. It would be nice, though, if it were better (and 
more cleanly) integrated with GitHub/GitLab/BitBucket/etc., and if its 
data were all distributively stored in git.


Oh, also, just in case I wasn't clear, when I said "if we had been 
commoditizing and decentralizing..." I meant "we" as in the worldwide 
programmer community in general, not the D community specifically.

Re: GitHub could be acquired by Microsoft

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 06/03/2018 11:51 PM, Anton Fediushin wrote:


What's your opinion about that? Will you continue using GitHub?



The obvious question is "Will MS use evil/strongarm shenanigans with 
GitHub?"


That would've been the one and only right question if this were the 
90's. (And the answer probably would've been, "Duh, yes.")


But, while I am somewhat concerned about that possibility (mainly in the 
long term), with modern MS I think I'm really more concerned about 
GitHub being marred by bone-headed ideas and/or sheer ineptitude. Way I 
see it, that's kinda been MS's main MO the last decode or so. (Heck, 
their games and OS divisions can barely even count numbers. 
One...three-hundred sixty...one again...eight...point one...ten...)


Let's face it, evil or not, when MS touches stuff, how often do they NOT 
wind up damaging it one way or the other? Sometimes maybe, but not usually.


I don't think this is a "sky is falling" omen for GitHub (...although 
there WAS codeplex...but then again, codeplex was kinda inferior to its 
competitors anyway). And I don't think there will be any immediate 
problems (even MS isn't that stupid, and if they are...it'd take time to 
implement anyway).


But, based on MS record, I do think it's likely there will be some 
facepalm/WTF moments for GitHub users down the road. The big questions 
are "What?", "When?" and "Will they be promptly reverted/mitigated?"


I've always felt GitLab was better than GitHub (in large part because 
they're sensible enough to support self-hosting), so it's tempting to 
use this as a great reason to move to GitLab. I won't though, unless 
MS-GitHub starts doing things that irritate me. Then I probably will.


In any case, I've always thought it was absolutely sick that that even 
though GitHub/BitBucket/GitLab/Launchpad/etc. all provide basically the 
same features on top of the standard ***distributed*** version control 
systems, they are all completely incapable of talking to each other or 
acting as interchangable viewers on a single set of common project data. 
So much for the "distributed" in "DVCS".


What I've ALWAYS felt we needed, and even moreso now, is a tool to 
commoditize these "VCS Plus" services. So we can just FORCE the choice 
of GitHub/BitBucket/GitLab to be "Whatever frontend the user prefers", 
and everything gets cross-synced and interlinked, etc., and bring the 
"distributed" back to DVCS, rather than chaining each project to a 
centralized walled garden.


Keep in mind, if we had been commoditizing and decentralizing repository 
hosting, issue tracking, PRs, user accounts, etc. right from the start 
like we should've been, then this MS buyout of GitHub would've been 
entirely irrelevant to everyone outside GitHub itself. That's what 
happens with single points of failure. And the reason VCSes even went 
DVCS in the first place.

Re: AppVeyor-D: Project to track recommended appveyor.yml (Win CI)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/31/2018 07:03 AM, jmh530 wrote:


Thanks for this. Is there something similar for Travis?


D support is already built-in on travis so it's not really needed there. 
See:


https://docs.travis-ci.com/user/languages/d/
https://wiki.dlang.org/Continuous_Integration

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

(That last one specifically talks about travis, but really it's 
applicable to anything that uses the D installer script Seb mentioned.)


And many D projects on GitHub already have a .travis.yml you can use as 
examples.

AppVeyor-D: Project to track recommended appveyor.yml (Win CI)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

I wanted to use AppVeyor to add Windows CI to some of my D projects, but 
when I tried the appveyor.yml config on the DWiki[1], I found it needed 
some work.


So after quite a bit of tinkering (and throwing semi-random bits at the 
wall to see what would work), I finally got it running properly in my 
project: including support for older/newer versions of DMD/LDC in both 
32/64-bit.


Then, I merged in some improvements DUB had made, plus laid some 
groundwork for download mirrors (just needs URLs now), and pushed it up 
as a project on GitHub for all to steal:


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

One nice thing about this (compared to the DWiki page) is that its 
actually being tested by AppVeyor itself. Plus, it now has full GitHub 
Issues/PR support for managing enhancement/submissions/discussion, all 
in one central place.


[1]: https://wiki.dlang.org/Continuous_Integration

Re: Looks like Digital Mars C++ is on the front page of HN at the moment!

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/23/2018 09:01 PM, Walter Bright wrote:


It's been a great thread. Everyone was very nice.

Now that it's gone from the front page, here's the direct link:

https://news.ycombinator.com/item?id=17129678


Whoa, I didn't even realize D was now used in some of the DMC++ source. 
That's a very cool switch-around from when D was implemented entirely in 
C++. Must be very satisfying.


"C++, now powered by D" :)

Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/21/2018 01:43 PM, Steven Schveighoffer wrote:
Nice idea, I wonder if the compiler couldn't do this automatically with 
alias, however. It already does this in some cases (e.g. string instead 
of immutable(char)[]).


This would help solve the problem that error messages aren't going to 
get better when you pass it into something that only accepts the aliased 
type. However, for the most part, these are non-template functions anyway.


That was discussed and rejected some years ago. IIRC, Walter just didn't 
like it.


I'd certainly be in favor of it though. But in lieu of that...

Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/21/2018 01:30 PM, Paul Backus wrote:


I'm not sure making `_data` private is really a good idea. For example, 
this only works if `_data` is public:


import std.algorithm;
import std.range;
import std.stdio;

struct MyType
{
 auto _data = iota(10);
 alias _data this;
}

void main()
{
 MyType x;
 x.each!writeln;
}


Ouch, and the error message isn't very helpful either. I wonder what 
causes this to fail though, and whether it might simply be a compiler bug?

Re: Complicated Types: Prefer “alias this” Over “alias” For Easier-To-Read Error Messages

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/21/2018 12:36 PM, Arredondo wrote:
> One typo:
>
>> 1. Although the alias this means MyType...
>> 2. Although the alias this means MyType...

On 05/21/2018 01:43 PM, Steven Schveighoffer wrote:
> The list has two "1." headers.

Looks like the blog software got confused by my multi-paragraph "1. " 
(Maybe that's not strictly kosher from a writing perspective anyway?)

Re: iopipe v0.0.4 - RingBuffers!

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/12/2018 08:14 AM, Steven Schveighoffer wrote:


But I am not expecting any miracles here. GNU grep does pretty much 
everything it can to achieve performance -- including eschewing the 
standard library buffering system as I am doing. I can probably match 
the performance at some point, but I doubt it's worth worrying about. 


I wonder if there's realistic real-world cases where you could beat it 
due to being a library solution and skipping the cost of launching grep 
as a new process. Granted, outside of Windows, process launching is 
considered to be fairly cheap, but it still isn't no-cost.


That would still be a nice feather in D's cap: Comparable to grep for 
large data, faster than spawning a grep process for smaller data.

Re: unit-threaded v0.7.45 - now with more fluency

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/08/2018 05:05 AM, Cym13 wrote:


I wouldn't say it's an abuse, the dot means exactly the same thing as 
everywhere else in the language.


No, it really doesn't mean the same thing at all. Not when you look away 
from the unimportant implementation details and towards the big picture:


Normally, saying "x.y" denotes composition and membership: It means "y, 
which is a member of x". Saying "x.y" does NOT normally denote "The 
boundary between word 'x' and word 'y' in an english-grammared phrase".


But with things like "should.not.be", it's very much NOT a 
composition/membership relationship: A "be" is not really a 
member/property/component/etc of a "not", except in the sense that 
that's how the english-like DSL is internally implemented. A "should" is 
not really something that is composed of a "not", except in the sense 
that that's how the english-like DSL is internally implemented. (IF it 
even is implemented that way at all. I didn't look, so for all I know it 
might be opDispatch.)


I'm not saying that "should.not.be" OR "~" are abuses, I'm just saying 
whether or not they are, they're definitely both in the same category: 
Either they're both abuses or neither one is, because they both do the 
same thing: utilize use existing syntax for something other than the 
syntax's usual semantic meaning.


Formal "operator overloading" isn't the only way to alter (or arguably 
abuse) a language's normal semantics.

Re: sumtype 0.3.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/07/2018 05:35 PM, Paul Backus wrote:


Personally, I consider [pattern matching] an essential 
feature--arguably *the* essential feature--


After having used Nemerle, I tend to agree.

I haven't gotten around to using this yet, but I did take a look at the 
source and was blown away by how small and simple it is. Kudos!


Oh, and I love that it's much easier to remember how to spell than 
"Algebraic" :)


That said, it would be really nice if D made it possible for a tool like 
this to support more things being defined in-line. For example, in 
Nemerle, it's possible to define a binary tree like this:


-
// Mainly from:
// https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching
variant Tree {
  | Node {
  left  : Tree;
  elem  : int;
  right : Tree;
}
  | EmptyLeaf
}
-

But AFAIK, in D, each part would have to be defined separately, making 
the overall structure less clear:


-
struct Node {
Tree* left;
int   elem;
Tree* right;
}
struct EmptyLeaf {}
alias Tree = SumType!(Node, EmptyLeaf);
-

Of course, that's not your lib's fault, just an unfortunate limitation of D.

Re: unit-threaded v0.7.45 - now with more fluency

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/07/2018 11:57 PM, Johannes Loher wrote:

On Monday, 7 May 2018 at 09:19:31 UTC, Dechcaudron wrote:
I think I'm siding with Johannes here. Much as the overloads look 
nice, I don't really see the advantage over `shouldEqual`. Also, 
what's with `all.these.identifiers`? Any particular reason why you are 
more fond of them rather than of good ol' pascalCase?
Fluent assertions have one major advantage over using pascalCase 
assertions: There is no ambiuguity about the order of arguments.


When using e.g. assertEquals, how do you know wheter is is supposed to 
be assertEquals(actual, expected), or assertEquals(expected, actual)? 
The first one is the only one that makes sense wirh UFCS, but it is not 
clear directly from the API. On top of that, some popular Frameworks 
(I‘m looking at you, JUnit...) do it exactly the other

way round.

With fluent assertions, you don‘t have this Problem, it is much more 
clear that it should be actual.should.equal(expected) and not 
expected.should.equal(actual), because it fits naturally in the chain of 
ufcs calls.




I don't think that's the issue. At least, it isn't for me.

It's not a question of "assert equals" vs "should equal" (Though I am 
convinced by your argument on that matter).


The question is: Why "should.equal" instead of "shouldEqual"? The dot 
only seems there to be cute.


Not that I'm necessarily opposed to any of it (heck, I like cuteness in 
any sense of the word), it's just that: If the "~" thing is operator 
abuse, then I don't see how "should.equal", "should.not.be" etc, 
wouldn't fall into the same category.

Re: Diamond mentioned in stackshare.io article

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 05/05/2018 04:45 PM, Gheorghe Gabriel wrote:

On Saturday, 5 May 2018 at 20:34:05 UTC, Gheorghe Gabriel wrote:

[...]


Sorry for my english mistakes. I am very tired right now and english is 
not my main language. I cannot correct that 2 it's -> to -> its.


No worries, even most native English speakers get it's/its mixed up.

mysql-native v2.2.2: Minor updates

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

An all-D MySQL/MariaDB client library:
https://github.com/mysql-d/mysql-native
==

Tagged release, 'v2.2.2'.

Sorry, no "zero date" fix just yet, but I think we're getting close (#65).

In this version:
- Fixed #177: Update unit-threaded, and don't lock mysql-native to a 
specific version of unit-threaded. (@ghost91)
- Fixed #178, #179: Fix deprecation message in DMD v2.080.0: Replace 
enforceEx by enforce (@ghost91)


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

Re: LDC 1.9.0 beta

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 04/26/2018 03:11 AM, Joakim wrote:


I don't know how those links are relevant. Yes, some projects are 
supporting WebAssembly, but that doesn't mean the web hasn't been 
declining, so this port likely isn't worth the effort.


Nobody is stopping anyone from doing the port though: ldc has some 
support for even more niche platforms like linux/PowerPC, simply because 
Kai wanted to do it. I'm just warning people who haven't seen those 
linked numbers that it likely isn't worth it.


Not disagreeing at all, and not trying to twist anyone's arm, but 
speaking purely personally, I'd love to see WebAsm/Asm.js support 
(FWLIW). I'm converting an old Flash-based thing to Unity3D/WebGL right 
now (still web-based due to factors beyond my control), and (for various 
reasons) I'd love to sometime build a nice 2D engine in D and use it to 
move this project to D. Unfortunately, I've checked into GCC and LLVM 
docs before and GCC/LLVM hacking seems to be beyond me.


I'm not making any particular point there. Just chatting, fwiw.

Re: std.variant Is Everything Cool About D

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/29/2018 01:30 PM, 12345swordy wrote:


There are some quite criticisms being made in the comments section.


Some of them I actually agree with. Much as I love D, its 
Variant/Arithmetic *is* a terribly inferior hack compared to various 
languages that have built-in sum types. (Like Nemerle).

Re: The D Language Foundation at Open Collective

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/19/2018 12:31 AM, Tony wrote:


 I believe they only mentioned the time
factor, but it is also labor intensive to manually pour the water.


Yup [nod, nod]. That's why decades ago they invented machines to pour 
the hot water over the coffee for us ;) It even heats up the water, too!

Re: The D Language Foundation at Open Collective

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/18/2018 04:18 PM, Tony wrote:

On Thursday, 15 March 2018 at 12:36:24 UTC, Meta wrote:



Sorry to derail, but I had to ask: where does 1 coffee (even extra 
large) cost $5 USD? Let me know so I know to never move there.


I have seen regular coffee at $4.50 and as high as $5.50 in the USA (and 
not always a large), but in order to get there, it has to be "single cup 
pour over" made, as opposed to coming out of a machine into a pot. And 
the beans have to be organic or they are telling you exactly where they 
were grown and giving you alleged "flavor notes" and maybe they roasted 
them in-house or locally, and the place has to have an upscale or luxury 
vibe. But Starbucks in the USA gives you a 20oz out-of-a-machine for 
under $3. McDonald's beats everybody - $1 for a large. Although I am not 
a big fan of the McDonalds coffee (maybe psychological due to the low 
price). 7/11 convenience stores and Chevron gas stations both have 
several varieties of coffee on tap that they sell for under $2 for a 
large, that I think tastes good.


McDonald's and Wendy's both have pretty good coffee, but the catch is 
they often let it sit around far too long, at which point it can get 
pretty bad. So it's kind of coffee roulette. (And McDonalds $1/large 
thing seems to have gone away, I think it was just a temporary 
promotion. At least around here, anyway (Cleveland area, in the US)).


I'll never understand the whole "pour over" coffee movement. It's 
basically the same exact technique everyone's the cheap consumer level 
coffee machine already does far more conveniently: Hot water poured over 
coffee grounds sitting in a filter. I've been to one of those pour over 
places, and it was mediocre at best (not to mention slow and expensive). 
I've had better coffee from fast food joints. But then again, I've never 
been very hipster-compatible ;) There's a couple (non-fast food) chains 
we have around here, Panera and Arabica, that make some of the best 
coffee I've ever had, without doing the whole pour-over fad, for about $2.

Re: Vision document for H1 2018

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/16/2018 02:35 PM, Tony wrote:

On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:

Are you sure that you are talking about phobos and not tango? :)
I'm eager to find how I'm uninformed.


Tango doesn't use UFCS, while phobos and .net framework are big on 
extension methods. Also tango uses object oriented console IO, while 
phobos and .net framework use procedural style for it.


I thought C# was like Java and does not allow free procedures. Can you 
give an example of C# procedural-style IO?




It doesn't (last I used it), buy you CAN mark individual member 
functions to be usable UFCS-like. IIRC, I think it might have to be 
static member function.


It's been awhile, so I don't remember it exactly, but it's something 
like this:


class Bar {}

class Foo {
static void SomeFunc(extention Bar bar, int num) {...}
}

class MyApp {
static void Run() {
Bar bar = new Bar();
bar.SomeFunc(2);
}
}

Re: Vibe.d web interface tutorial

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/13/2018 09:42 AM, Daniel Kozak wrote:

Yes PHP is always to blame :)



From my archives:

https://semitwist.com/articles/article/view/10-fun-facts-about-php

Re: Vision document for H1 2018

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/11/2018 11:31 PM, Laeeth Isharc wrote:


C# slices look great.


I wonder if that might open the door for D on the CLR. I know that was 
attempted once a long way back, but was deemed infeasible and abandoned. 
IIRC, inability to implement slices was the main blocker.

Re: Vision document for H1 2018

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/10/2018 05:47 AM, Dylan Graham wrote:

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents don't care 
about betterC. Why is betterC on the priority list?


Yeah. Why should D worry about tying itself into C when it can't even 
interface with itself through DLLs?


First of all, betterC is about far more than interfacing with C. In 
fact, interop with C isn't really what betterC is about at all - that's 
a separate aspect of the language. (And those C/C++ users who still 
haven't come to D - for many of them the holdout is *because* of the 
issues betterC aims to address. Make no mistake, for all the stockholm 
syndrome in the C and C++ worlds, there *are* a lot people openly 
wanting to jump ship but don't have a sufficient option yet. Heck, *I'm* 
a C/C++ -> D convert.)


But more importantly:

The D language itself is specifically designed and intended to be 
multi-purpose. Because of that, D users (and potential D users) are 
*highly* diverse. Everybody here has their own use-cases, their own 
needs and priorities, and their own list of things they want fixed 
yesterday.


In a group this diverse, there just simply *isn't* much on the D 
wishlist that's crucially important to a *majority*, because we all need 
completely different things.


Personally, better DLL support have little to no impact on me. Obviously 
it does for you, and I sympathise. Some of the things most important to 
me for D to improve you probably wouldn't care one bit about - and 
that's ok. We work on different sorts of things.


Improved betterC is something I would find very nice if I ever have time 
or opportunity to get back into embedded software. But outside of that, 
yea, it doesn't impact me much more than it does for you.


But here's the rub: In this crowd here, probably far more than most 
languages, we all have such wildly varying needs that 29% *is* what 
qualifies as significant around here. Most wishlist items are going to 
have similarly non-majority numbers. And they have to pick *something* 
to focus on. Luckily, as the vision document clearly states, there are 
*several* such "somethings" the dlang foundation is committing to 
working on.

mysql-native v2.2.1: Bugfixes

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

An all-D MySQL/MariaDB client library:
https://github.com/mysql-d/mysql-native
==

Tagged bugfix release, 'v2.2.1'.

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

This fixes a pretty big regression (for vibe.d users) from v2.1.0 (#170: 
Assertion when concurrently using multiple LockedConnection), as well as 
a few other issues for users of the latest DMD (2.079.0) and vibe.d (0.8.3).

Re: mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/08/2018 06:57 AM, bauss wrote:


But if you can't store the pools anywhere, how are you supposed to use 
them with vibe.d?


You can store the pools wherever you need to, just don't hold onto a 
Connection past the end of a vibe task.


Creating a new pool for every thread seems expensive and dosn't that 
defeat the purpose of using pools in the first place?


I mean a 1000 people could connect to a website and potentially that 
could create a thousand threads (It probably won't, BUT it could.) and 
thus it can't be afforded to create a pool per request.


This is more a question for vibe's Sonke, to be honest.

What I do know is that vibe's basic task distribution typically involves 
one task/request per *fiber*, not per thread. And that vibe is based 
heavily around handling multiple simultaneous requests/tasks/fibers 
within a single thread.


Beyond that, I have no idea how vibe deals with threads, hence my 
suggestion that if you're having trouble, it might be worth seeing 
whether going totally thread-local with everything might help. Just a 
thought. At the very last it might help narrow it down.



I mean it's kind of a corner case, but it's a common corner case for big 
applications.


I don't create any explicit threads.

But like I said, it seems to work after I stopped returning the 
connection and just the pool.


so I think the problem wasn't the pool, but the connection itself.

At least I can't reproduce it and tried with hundreds of queries at once 
and before I could reproduce with less than 10.




I admit I'm unclear at this point which problem you're referring to, and 
whether or not you're saying it's fixed now. (Pardon my confusion - been 
a long day.)


If you mean issue #153, then I wonder if that might be the same cause as 
#170 (Same symptoms at least: "Acquiring waiter that is already in use"):


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

Sonke figured out just a few hours ago, and I confirmed, that #170 is 
caused by a bug in MySQLPool.lockConnection introduced in v2.1.0. I plan 
to have that fixed with a new release today.


That bug turned out to be caused by MySQLPool.lockConnection allowing 
the LockedConnection!Connection it received from vibe to degrade down to 
a plain Connection (because of alias this allowing implicit conversion). 
So MySQLPool.lockConnection would then return the *raw* Connection 
instead, thus allowing LockedConnection to go out of scope and reclaim 
the connection as soon as MySQLPool.lockConnection returned.


Sonke's been putting thought into how to adjust vibe's LockedConnection 
so this can't happen by accident. Maybe your lib fell prey to the same 
accident mine did?



And yes I need support for multiple connection strings. It's not an 
application, it's a library for writing enterprise websites/webapis and 
thus it should be scalable, since most enterprise solutions uses 
multiple databases.


Ah, I see. Fair enough.

Re: mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/08/2018 02:14 AM, Bauss wrote:


By any chance, are you ever storing a Connection or a ResultRange 
anywhere? I don't mean as a function-local variable or a a function 
parameter: I mean like as a class/struct member or as a global? (Well, 
not that D really has true globals, but a "global" at the module-level.)


If you keep around a Connection (or a ResultRange, which has a 
reference to its own Connection) past the end of the vibe.d task that 
was using it, then that can definitely cause this kind of problem.


(AIUI, vibe.d wants to make the connections you obtain from a pool be 
Scoped. That would help prevent users from accidentally storing 
something they shouldn't and running into this issue.)


Yeah I stores the result range which I assume was the issue, but I'm 
returning results as arrays now so it probably solved it.


That behavior should be documented though, I don't recall reading that 
anywhere and it's kind of a gotcha




Agreed. Please file a ticket for this so I don't forget.

Re: mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/07/2018 04:53 PM, bauss wrote:


I can't seem to reproduce it now, but I'll keep an eye for it and see if 
it still happens, but I think the problem is when you return the 
connection from a function.


I had similar issues returning a raw connection created.


By any chance, are you ever storing a Connection or a ResultRange 
anywhere? I don't mean as a function-local variable or a a function 
parameter: I mean like as a class/struct member or as a global? (Well, 
not that D really has true globals, but a "global" at the module-level.)


If you keep around a Connection (or a ResultRange, which has a reference 
to its own Connection) past the end of the vibe.d task that was using 
it, then that can definitely cause this kind of problem.


(AIUI, vibe.d wants to make the connections you obtain from a pool be 
Scoped. That would help prevent users from accidentally storing 
something they shouldn't and running into this issue.)

Re: mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/07/2018 02:32 PM, bauss wrote:


Wait why has it been updated to array() ? So it's not a real range 
anymore? Or was it always represented as an array behind the scenes?


I just feel like allocating it into an additional array is a waste of 
memory? But if it was always like that I guess it doesn't matter.




query() returns an input range. You can only access one element at a 
time (as its read from the network) and you don't know how many there 
are ahead of time, BUT it avoids allocating a whole array to store 
everything.


In addition to query(), there used to also be a querySet(). The 
querySet() would allocate an array and read ALL the results into it so 
you could get random-access. But that's exactly what you already get 
when you call array() on an input range (such as the input range 
returned by query), so querySet was deemed redundant and eliminated.


So if you had code that *did* need an array allocated to store all the 
results, then "querySet()" has been replaced with "query().array". But 
like you said, if you don't really need the array, then there's no need 
to call array() and waste the memory.




However idk what I changed, but the issue stopped for me.

However I still have this issue:

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

(Currently trying to see if I can make a minimal example, but it's kinda 
hard to make a minimal example since it's from my Diamond MVC (vibe.d) 
library and it isn't used until deep nesting of the application.


Anyway before I report anything else I could easily be doing something 
wrong. There hasn't exactly been any good examples on how to use it with 
vibe.d so it has pretty much been a trial and error thing for me.


Using mysql-native with vibe.d isn't any different from using it without 
vibe.d.


It's recommended to use MySQLPool to make a Connection rather than doing 
"new Connection" directly simply because connecting is faster that way 
(though "new Connection" will still work).


But aside from that, there is absolutely nothing different about 
mysql-native whether you're using vibe.d or not.



So basically I keep an associative array of connection pools based on 
connection strings like below:


private static __gshared MySQLPool[string] _pools;

And then I retrieve a connection with the function below.

Perhaps I'm not supposed to make a new pool every time, but there is 
someway to retrieve a pool already? Maybe that's what I'm doing wrong?


private static shared globalPoolLock = new Object;

private Connection getMySqlConnection(string connectionString)
{
   auto pool = _pools.get(connectionString, null);

   if (!pool)
   {
     synchronized (globalPoolLock)
     {
   pool = new MySQLPool(connectionString);

   _pools[connectionString] = pool;
     }
   }

   return pool.lockConnection();
}

After I retrieve the connection then it's basically like the code I 
showed you, but that seem to be correct, yes?


Does your application need to support multiple connection strings while 
it's running? That's pretty rare unless you're making something like 
phpMyAdmin (and even then, I'd probably do it a little differently). 
Normally you'd just make one connection pool:


MySQLPool pool;

Then "new" that once with your connection string when you start up, and 
you're good.


I guess I can imagine some potential use-cases that get more complicated 
than that, but that's really up to your own project's needs.


> However I still have this issue:
>
> https://github.com/mysql-d/mysql-native/issues/153
>
> (Currently trying to see if I can make a minimal example, but it's kinda
> hard to make a minimal example since it's from my Diamond MVC (vibe.d)
> library and it isn't used until deep nesting of the application.

I'm only guessing here, but I wonder if that might be because you seem 
to be trying to share pools and connections across threads. I don't know 
whether vibe is designed to share TCP connections across threads or not. 
I'd say, try ripping out all that shared/__gshared/synchronized stuff 
and see how that works.

Re: mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/06/2018 01:31 PM, bauss wrote:


I can't seem to find any examples on how they were updated and what 
exactly to change in my code.




Also, FWIW, mysql-native uses semantic versioning (semver), so anything 
that worked in v2.0.0 should still continue working in all v2.x.x.

Re: mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/07/2018 05:23 AM, Sönke Ludwig wrote:

Am 06.03.2018 um 05:31 schrieb Nick Sabalausky (Abscissa):
(...) Also, AFAIK, vibe doesn't offer socket support like it does TCP, 
so vibe users would loose out on the automatic yield-on-io that's a 
cornerstone of vibe's concurrency design.


There currently appears to be something broken, but vibe-core does 
support UDS (by setting a UDS address in the connectTCP call; the legacy 
name of that function is going to get changed during the next releases). 
There is also an open PR for the legacy core module:


https://github.com/vibe-d/vibe.d/pull/2073


Ahh, thanks. Filed under "I'm glad to be wrong" ;)\

Re: mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/06/2018 01:54 PM, bauss wrote:

On Tuesday, 6 March 2018 at 18:36:45 UTC, bauss wrote:


Like more specifically do I still call lockConnection() on a MySQLPool?


If you're using vibe.d and MySQLPool, then yes. But that's completely 
unrelated to prepared statements, it has nothing to do with whether or 
not you're using them, or how you're using them.




I think it would be easier to help me if I put some examples.

I just tried changing stuff and I can't seem to get it working.

I kept using lockConnection() as before, I assume it's the right way.

Then I changed the way I retrieve prepared statements from:

   auto prepared = prepare(connection, sql);
   prepared.setArgs(params);

to:

   auto prepared = connection.prepare(sql);
   prepared.setArgs(params);



Either way works. That's just a matter of whether you're using D's 
"UFCS" (uniform function-call syntax) feature or not.



Then ex. for reading many entries:

From:

   return prepared.querySet().map!((row)
   {
     auto model = new TModel;
     model.row = row;
     model.readModel();
     return model;
   });

To:

   return connection.query(prepared).map!((row)
   {
     auto model = new TModel;
     model.row = row;
     model.readModel();
     return model;
   });

But it doesn't seem to work.

I get the following exception:

"Attempting to popFront an empty map" which I assume is because the 
result is empty.




Ok, now that one is a little weird. Should work as far as I can tell. 
I'd say file a ticket here with a minimized test case I can just run on 
my machine to reproduce the error. Please make sure the test case shows 
the return type of the function in question (and whether or not it's 
simply "auto") and how its used that leads to the error:


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

Also, be aware that the updated equivalent to `querySet` is 
`query(...).array()`, not plain `query(...)`. However, based on the 
portion of code you've posted, I don't see why it shouldn't work as-is. 
I'd have to examine a complete test-case to get to the bottom of that.


My best guess is that the code which is CALLING your functions above may 
be doing something wrong with the range being returned. But again, 
without a complete test-case, the best I can do is make guesses.

Re: mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/07/2018 04:16 AM, aberba wrote:

On Tuesday, 6 March 2018 at 10:15:30 UTC, Martin Tschierschke wrote:

On Tuesday, 6 March 2018 at 07:39:00 UTC, aberba wrote:
UNIX sockets provide a way to securely connect in an 
enclosed/isolated environment without exposing connection externally. 
This is used in my company in our microservice infrastructure on 
Google Cloud: we connect to our db instance using a proxy and its the 
recommended approach in microservices.


Its a very common security practice. The default approach on Google 
Cloud. I would do the same for any db I want to prevent external 
access to. If vibe.d doesn't support it then its missing a big piece 
of a puzzle.
Having sockets would be better, but you may configure your mysql to 
allow only

local connects. So external requests are blocked.

https://dba.stackexchange.com/questions/72142/how-do-i-allow-remote-mysql-access-to-all-users 



Look at the first answer to set the right privileges for your 
environment.


Additionally blocking the mysql port 3306 (beside many others) from 
outside the network would make sense.


The MySQL instance is running in a managed cloud instance. You don't get 
to tweak things like with vps.  Proxy based connection its what's used. 
Not just in my case...it supported in all major mysql libraries 
"socketPath".


I'd say, please file a ticket here:

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

The more clearly the case is presented, the more likely it is to be 
given appropriate priority.


I'd also encourage yourself, and others who may care about this issue, 
to please consider working on a PR for this. I am only one person and 
only have so many resources to go around, so if those who do find this 
important can offer an implementation, that's the best way to get a 
feature included ASAP. If it's left to me to implement, then it has to 
compete with all the rest of my projects and priorities.


I'd be more than glad to offer any help I can in either understanding 
the codebase, or in any other way I can help improve the "bus factor" of 
this project. Just ping me through a ticket on github, or privately via 
https://semitwist.com/articles/contact/form/contact-us  (and yes, I know 
the captcha system there is woefully out-of-date :/ )


To be clear, please understand, this ISN'T a "no" by any means. I am 
fully open to this feature getting implemented, and I want this lib to 
be as useful to as many people as possible. It's just that I only have 
so much resources of my own, and I don't get paid for this, so if it's 
left completely up to me then it has to compete with everything else 
vying for my attention.

Re: mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/05/2018 09:23 AM, aberba wrote:
On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) 
wrote:

An all-D MySQL/MariaDB client library:
https://github.com/mysql-d/mysql-native
==

[...]


Is unix socket connection supported? I'm not seeing any information 
about it in the docs.


It's not currently supported. From the "Additional Notes" section of the 
readme:


"Normally, MySQL clients connect to a server on the same machine via a 
Unix socket on *nix systems, and through a named pipe on Windows. 
Neither of these conventions is currently supported. TCP is used for all 
connections."

  - https://github.com/mysql-d/mysql-native#additional-notes

I'm not opposed to it being added, but I'm not aware of what benefit it 
would provide that would big enough to make it a priority. Also, AFAIK, 
vibe doesn't offer socket support like it does TCP, so vibe users would 
loose out on the automatic yield-on-io that's a cornerstone of vibe's 
concurrency design.

Re: Article: Why Const Sucks

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/05/2018 12:38 PM, H. S. Teoh wrote:


This broke the by-value
assumption inherent in much of Phobos code,


Wait, seriously? Phobos frequently passes ranges by value? I sincerely 
hope that's only true for class-based ranges and forward-ranges (and 
more specifically, only forward ranges where copying the range and 
calling .save are designed to do the exact same thing). Otherwise, 
that's really, *REALLY* bad since non-forward ranges *by definition* 
cannot be duplicated.


Honestly, I think this is the one big flaw in the otherwise really nice 
design of ranges.


The definition of "what is a forward/non-forward range" for struct-based 
ranges should have been "is this() @disabled (non-forward range), or is 
this() enabled *and* does the same thing as .save (forward range)?"


Without that, this is a serious hole in non-forward ranges.

mysql-native v2.2.0: Maintenance Release (and news)

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

An all-D MySQL/MariaDB client library:
https://github.com/mysql-d/mysql-native
==

Tagged 'v2.2.0'.

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

This is primarily a maintenance release including some bugfixes, and the 
beginning of some internal cleanups.


Particularly noteworthy:

I've been increasing focus on addressing the backlog of older issues. As 
part of that, this release fixes the oldest issue in the tracker: #13 
("No support for type modifiers in prepared statement parameters."). 
With that, the oldest open issue has moved from an embarrassing 2013 up 
to 2014 (Or 2015 if you discount issues tagged "can't reproduce / need 
info").


Things are moving along!

Which brings up another point, and a call for help:

I've recently done a once-over checking all the currently-open issues, 
addressing/updating/closing whatever I could. I've tagged some of the 
open issues with "can't reproduce / need info":


https://github.com/mysql-d/mysql-native/issues?q=is%3Aissue+is%3Aopen+label%3A%22can%27t+reproduce+%2F+need+info%22

These are issues I cannot close without YOUR help. Please, if you are 
the OP or you have ever experienced any of these, then update the ticket 
with:


1. whether or not you are still experiencing the issue, and

2. whether or not you are able to check if it still occurs on the latest 
mysqln-native (and if not, then what, if anything, is blocking you from 
upgrading).


In case the OP's have moved on, it would be hugely beneficial if anyone 
can help me determine if any such issues are still relevant, and if so, 
a test case.


Unless a reasonable argument convinces me otherwise (and I am open to 
arguments), I'm going to set a tentative (ie, subject to change) 
deadline of one year before issues tagged "can't reproduce / need info" 
are assumed to be already resolved or invalid, and eligible to be closed 
on account of "inactivity on an issue requiring followup".


--

Roadmap:
https://github.com/mysql-d/mysql-native/milestones

(Roadmap Note: I often postpone scheduled issues to later milestones. 
This is deliberate because, in most cases, I would rather issue a new 
stable release, than delay the release of already-in-master fixes and 
enhancements just because more improvements aren't ready yet.)

mysql-native v2.1.0

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

An all-D MySQL/MariaDB client library:
https://github.com/mysql-d/mysql-native
==

Tagged 'v2.1.0', which mainly adds a few new features, including greatly 
simplified shortcut syntax for prepared statements (with automatic, 
implicit caching and re-use):


---
int i = 5;
string s = "Hello world";
conn.exec("INSERT INTO table_name VALUES (?, ?)", i, s);
conn.query("SELECT * FROM table_name WHERE id=? AND name=?", i, s);

// Also works:
Prepared stmt = conn.prepare("INSERT ...blah... (?, ?)");
conn.exec(stmt, i, s);
---

As well as additional tools for optional micro-management of 
registering/releasing prepared statements.


It also fixes #28: "MYXProtocol thrown when using large integers as 
prepared parameters."


Full changelog
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md#v210---2018-03-02

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.

mysql-native v2.1.0-rc3

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

Third release candidate, `v2.1.0-rc3`: Snuck in a long-overdue fix for 
#28: "MYXProtocol thrown when using large integers as prepared parameters."


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

---

In other news, there will likely be another release immediately after 
v2.1.0 (Though I'll probably skip the release-candidate period on that 
one). Current progress on the follow-up to v2.1.0:


https://github.com/mysql-d/mysql-native/milestone/4?closed=1