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: 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: 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: 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: [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/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: 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: 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: 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: 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: 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: 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/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 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: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/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: 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/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/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/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: 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 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: 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: 
 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/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: 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: 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: 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 function—for example"


Note the "—".

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: 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/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/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/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 
 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: 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: 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.

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.

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.

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

don't ever call me nicholas

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

don't ever call me nicholas

Re: two points

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

On 02/09/2017 03:02 AM, Walter Bright wrote:


It took me a while to find it, because you were using a pseudonym that I
did not recognize. There are a number of frequent contributors to D
using pseudonyms, and all have this issue with varying degrees.
[...]
I suppose I could write a cheat sheet and tape it to the wall of my
office, but why not just use your name?



Partly because I just like online handles. Also, brevity: "Sabalausky" 
is a bit of a monster and also tends to intimidate the crap out anyone 
trying to pronounce it (and very understandably so). "Abscissa" is 
shorter than my last name alone, easier to spell, plus I've been using 
it for about 20 years, so it's kind of just habit now and almost just as 
much a name to me online as "Nick". Not that it's much easier to 
pronounce (except for those well-versed in uncommonly-used math 
terminology), but it's probably at least a little less panic-inducing, 
pronunciation-wise ;)


And online (in general anyway), I like that "Abscissa" is less 
uniquely-identifiable than my name - unlike my name, there actually ARE 
other people going by "Abscissa". I like having my online identity split 
into multiple ones, and I like the lack of clarity as to which 
"Abscissa" fellas are the same ones: It creates privacy in a frontier 
that is increasingly "privatized big brother". Reliably-unique real 
names like mine are a data miner's dream - may as well be going by my 
social security number. Unlike "Abscissa", anyone going by "Nick 
Sabalausky" is either me or somebody deliberately impersonating me.


In any case, your point is certainly a valid one. I've adjusted my 
newsreader to include Abscissa along with my real name, so hopefully 
that will at least help.

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

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

On 01/07/2017 11:12 AM, Andrei Alexandrescu wrote:

Following https://github.com/dlang/dlang.org/pull/1532, the new-style
docs now also allow editing and running examples. Start at
http://dlang.org/library-prerelease/ and go anywhere to check it out.

Thanks are due to Sönke Ludwig and Sebastian Wilzbach!


Andrei


1. This is pretty awesome.

2. Looks like someone forgot to set a foreground text color for the 
output even though the background is set to white. This makes the output 
text invisible for those using eye-friendly light-on-dark systems.

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

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

On 02/18/2017 11:48 AM, Seb wrote:

On Friday, 17 February 2017 at 16:07:37 UTC, Nick Sabalausky (Abscissa)
wrote:

1. This is pretty awesome.


Thanks a lot :)


2. Looks like someone forgot to set a foreground text color for the
output even though the background is set to white. This makes the
output text invisible for those using eye-friendly light-on-dark systems.


I am not sure I follow. Do you use a custom color scheme or plugin that
sets the body background color to black?


Dark system color scheme, nothing mucking with website CSSes or 
anything. Somewhat bizarrely/irritatingly, there are certain cases 
( and  to my knowledge, maybe others) where browsers 
inherit default color settings from the OS[1] instead of from a built-in 
browser-default CSS.


Since my OS is set up to default to (near-)white text on a (near-)black 
background, the browser decides "Oh, ok, I'll use white text on a black 
background for inputs and textareas." But then the site's CSS tells it 
to use a white background. And says nothing about text color. Browser 
says: "Ok! So, white text (system textbox default) on a white background 
(website CSS)!!"


[1] Browsers taking theme defaults from the OS was appropriate behavior 
back in HTML1 when the whole web was actually designed from the 
ground-up to automatically adapt to the machine being used. But not so 
much now that every site/page in the world uses its own theme and 
formatting system[2], and even the browser's own default css *mostly* 
(with, of course, these broken exceptions) separates itself from the OS, 
leaving occasionally broken readability.


[2] The site-chosen formatting system occasionally being one that 
attempts to partially adapt to the local machine, to varying degrees of 
success. Thanks, legacy of HTML2/4!


Did I mention I hate web browsers? ;)


What exactly would be the best way for you to resolve your problem?
Maybe you can even submit a PR yourself? - the CSS is here:

https://github.com/dlang/dlang.org/blob/master/css/style.css#L1611


I'm working out building the site locally right now so I can test 
(building it seems to be taking awhile), but:


Looks like the site is mostly using #333 for text color. You could just 
toss in "color: #333;" right next to "background: white;" for the 
d_code_output sections (might not matter for the div version, but 
wouldn't hurt either.) That should work.


Or it might be better to just toss this in around the top of the CSS:

--
input, textarea {
background-color: white;
color: #333;
}
--

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

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

On 02/18/2017 08:42 PM, Nick Sabalausky (Abscissa) wrote:


Or it might be better to just toss this in around the top of the CSS:

--
input, textarea {
 background-color: white;
 color: #333;
}
--



K, just tested it, works for me:

https://github.com/dlang/dlang.org/pull/1576

mysql-native v1.0.0-rc4

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

One more update to the MySQL/MariaDB client lib, hopefully the last 
before v1.0.0 final.


This one actually includes quite a few more changes I wanted to get in 
as long as it's making the big leap up to v1.0.0 (see below).


For now, this still lives in a separate fork:
https://github.com/Abscissa/mysql-native-experimental

To use it:
$ git clone https://github.com/Abscissa/mysql-native-experimental.git
$ dub add-local path/to/mysql-native-experimental

And then, when you're doing using this preview:
$ dub remove-local path/to/mysql-native-experimental

Docs here:
http://semitwist.com/mysql-native-docs/v1.0.0-rc4/

I'm going to give this a week. If no fundamental, release-delaying 
issues/objections come up, and nobody speaks up that they could use more 
time to evaluate it, then on Feb 26 I'll merge this branch back over to 
the official mysql-native repo, and tag it as v1.0.0.




Changes in 'v1.0.0-rc4' since the previous preview, 'v0.2.0-preview3':

- Much more documentation improvement.

- Added a Prepared.sql getter, to retrieve the sql for a prepared 
statement. (Previously it was inaccessible.)


- ResultSet.asAA and ResultRange.asAA now return Variant[string] instead
of DBValue[string]. DBValue is no longer needed and now deprecated (as 
it was only used by `asAA` and Variant now handles null properly.)


- Fixed: Row.isNull(index) isn't a setter, so don't mark it @property 
(confuses the doc generator).


- Rename MySqlPool to MySQLPool to be consistent with other parts of the 
API.


- MySQLPool now supports vibe.d's ConnectionPool.maxConcurrency feature.

- Improved separation between internal ("mysql.protocol") and external 
interfaces.

  - No longer publicly imports internal-only symbols by default.
  - Renamed module `mysql.protocol.commands` to `mysql.commands`.
  - Renamed module `mysql.protocol.prepared` to `mysql.prepared`.
  - Moved `ParameterSpecialization` into `mysql.prepared` (was in 
`mysql.protocol.extra_types`).
  - Moved `ColumnSpecialization` into `mysql.commands` (was in 
`mysql.protocol.extra_types`).
  - Moved the other public-API members of `mysql.protocol.extra_types` 
into new modules `mysql.metadata` and `mysql.types`.
  - Split module "mysql.common" into two different modules: 
"mysql.exceptions" and "mysql.protocol.socket"


I also reorganized/rewrote the v1.0.0 changelog entry to be a bit more 
readable, so take a look at the overall changes from the previous 
release, v0.1.7, to this latest release candidate, v1.0.0-rc4


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

Re: Android LDC in a Container

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

On 01/15/2017 12:40 PM, Andre Pany wrote:

Hi,

on Dockerhub I published a repository which makes it really easy to
develop Android
applications using LDC and Joakims work. The repository contains Android
1.1.0 beta from
https://github.com/joakim-noah/android/releases and also the NDK from
google.



I haven't actually had a chance to try either this or Joakims's stuff by 
itself, although I am interested. Can you describe how this repo 
simplifies things?


Also, using this stuff, is there a way for the D application to call 
into Android's API?

scriptlike v0.9.7: Minor update

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

Minor update to scriptlike (Utility library to help you write 
script-like programs in D)


Aside from a few doc updates, this just fixes deprecation warnings when 
compiling with DMD 2.072 and up.


https://github.com/Abscissa/scriptlike

scriptlike v0.10.1 - Another minor update

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

Another minor, but this time slightly breaking update to Scriptlike 
(Utility library to help you write script-like programs in D).


https://github.com/Abscissa/scriptlike

v0.10.1 (changes since v0.9.7):

- Change: Issue #33: Rename Path.toRawString to Path.raw.

- Change: Deprecated Ext.toRawString. It didn't do anything different 
from Ext.toString and thus wasn't needed.


- Fixed: #19: Compile error with DMDFE 2.065. Note, Scriptlike still 
*officially* requires at least DMDFE 2.066, mainly because of a bugfix 
for Windows, but DMDFE 2.065 appears to still be important for Debian's GDC.


- Fixed: Excess blank lines and malformed  in this changelog.

Full changelog: http://semitwist.com/scriptlike/changelog.html

mysql-native v1.0.0: Big refresh

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

mysql-native is now officially at v1.0.0!

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

mysql-native is a native D client driver for MySQL and MariaDB, usable 
either with or without vibe.d. It does not rely on the official C 
libraries, instead communicating directly with the server via the 
published MySQL client/server protocol.


This release is equal to rc4, but compared to the last official release, 
v0.1.7, this is a big update.


Summary of changes since v0.1.7:
- API overhauled for better safety, reliability and ease-of-use.
- Deprecated and replaced entire Command struct with better design.
- Better handling of null.
- Improved/expanded docs.
- Various bugs fixed.
- More rigorous test suite.

Users of v0.1.7 should find that most, if not all, of their code still 
works, albiet with many deprecation messages directing them to the newer 
equivalents. The old, deprecated APIs will be removed in a future 
release, but are still usable in v1.0.0.


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

Overview and example code:
https://github.com/mysql-d/mysql-native/blob/master/README.md

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

Usage in dub:
dependency "mysql-native" version="~>1.0.0"

scriptlike v0.10.2

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

Scriptlike is a utility library to help you write script-like programs in D.

https://github.com/Abscissa/scriptlike

Changes in v0.10.2:

- Enhancement: Added trace functions as debugging aid. Outputs file/line 
info and optionally a variable name/value. 



- Enhancement: Added isUserExec, isGroupExec and isWorldExec to check a 
file's executable bits on Posix. 



- Fixed: #34: Unable to build docs of own project with DUB.

- Fixed: Make sure the example tests, when run in travis-ci, always use 
the current scriptlike commit, instead of using a scriptlike release 
from the published dub repos.


- Fixed: Docs weren't being correctly built for symlink, readLink, 
getTimesWin and trySymlink.


- Change: Removed outdated, messy and problematic "plain script" example.

Full changelog:
http://semitwist.com/scriptlike/changelog.html

Re: Introducing Diskuto - an embeddable comment system

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

Nice. The only example code uses diet templates though, how would one 
embed this when not using diet?

Re: Introducing Diskuto - an embeddable comment system

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

On 03/16/2017 06:23 AM, Sönke Ludwig wrote:


The latest version now offers three embedding modes:
https://github.com/rejectedsoftware/diskuto/tree/master/examples

User accounts and simple moderation are also supported now. The
embed-diet example shows how this can be plugged in.


Nice. Very cool lib!

Re: dmd Backend converted to Boost License

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

On 04/07/2017 05:44 PM, Walter Bright wrote:



2. It's on all of the "Accepted OSS Licenses" lists that major corps have
because of Boost itself being used in those companies. If your license
isn't on
the list, your project isn't being used.


Yup. We figured every corporation that uses C++ has accepted Boost, so
this would be a no-brainer for them to accept D's license.



Anyone "in the know" have a any "inside scoop" regarding the such 
organization's perspective on the "zlib/libpng" license? I tend to favor 
it for my own OSS projects, since it's (in my perspective) at least as 
liberal as Boost, but very, very, ultra-easy to read/understand even for 
an everyday layman. But I would love to hear from anyone with more 
in-the-trenches experience how realistic that really plays out in the 
"real world".


I wonder if maybe it would be worth my while to dual-license my OSS 
dlang projects under both Boost and zlib/libpng. Anyone with real-world 
expertise in the area have any ("number five alive!") nput?

Re: dmd Backend converted to Boost License

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

On 04/07/2017 11:14 AM, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to relicense
it. Thank you, Symantec!


Wow! This is HUGE news for D, and may I say, I think some *major* 
respect (and "props, j00!") are *well-deserved* here not only from 
Walter's work, but also by Symantec themselves.


AFAIK, Symantec were under no particular obligation here, but 
none-the-less chose the consumer/developer-friendly route, and I for one 
couldn't be more appreciative. I'm one who can be very critical of, 
well, everything, but the fine folks at Symantec have earned an enormous 
amount of respect from me, and dare I say, the whole D language 
community as well, in this one much-appreciated move. Major kudos, and 
eternal thanks to all involved :)

Re: Release vibe.d 0.7.31

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

On 04/10/2017 04:48 PM, Sönke Ludwig wrote:

The 0.7.x branch will continue to be maintained for a short
while, but only bug fixes will be included from now on. Applications
should switch to the 0.8.x branch as soon as possible.



If a library depends on vibe, but wants to allow its users to use either 
0.7.x or 0.8.x, is there a recommended way to do that?


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

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

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

On 04/24/2017 11:17 AM, Timon Gehr wrote:

Also, Java's type system is
unsound.



Not doubting you, but this sounds interesting. Further info or links?

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

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

On 04/28/2017 04:26 PM, Atila Neves wrote:

The other day I was reminded that in
C++ land one has to manually write `operator<<` to print things out and
`operator==` to compare things.


What, seriously?!?

That's the thing about C++: The right way is the obscure way, and the 
straightforward way is the wrong way. And yesterday's right way is 
today's wrong way. And apparently (it would seem), the only way NOT to 
completely fuck *everything* up is to become an expert on every corner 
of the language, and STAY an expert on all the latest changes. In the 
immortal words (and voice) of Duke Nukem: "What a mess!"


Seriously, I don't care about the political incorrectness of bashing or 
comparing to other languages, this right here is and always was D's 
killer feature, the whole reason I got into it in the first place and 
have stayed: D takes all the current (and former!) application domains 
of C/C++, and brings to it basic programmer sanity. 'Nuff said.

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

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

On 04/28/2017 08:04 PM, Ali Çehreli wrote:

On 04/28/2017 02:11 PM, Nick Sabalausky (Abscissa) wrote:

 > D takes all the current (and former!) application domains
 > of C/C++, and brings to it basic programmer sanity.

When I had asked Luís Marques what the title of the talk should be, he
had said

   import sanity;

:)



Ok, now I seriously want to create a lib with that name, but the trick 
is to come up with something *worthy* of it :)

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

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

On 04/28/2017 06:11 PM, H. S. Teoh via Digitalmars-d-announce wrote:


That's the thing about C++: The right way is the obscure way, and the
straightforward way is the wrong way. And yesterday's right way is
today's wrong way. And apparently (it would seem), the only way NOT to
completely fuck *everything* up is to become an expert on every corner
of the language, and STAY an expert on all the latest changes. In the
immortal words (and voice) of Duke Nukem: "What a mess!"


Yep, this always reminds me of:

https://bartoszmilewski.com/2013/09/19/edward-chands/



That is *awesome*!

Although, I always saw Eddie Scissors as more of a retelling of 
Frankenstein.




D is not without its own flaws and WAT-worthy dark corners, mind you,
but in spite it its warts, I still prefer D any day over the masochistic
labyrinth of 99 wrong ways to do the same thing (and only 1 "right" way
-- until next year) that is C++.



Yea, I really think it's more important than many of us realize to heed 
Herb Sutter's warning and not allow too much worrying about backwards 
compatibility thus leading D down the same path. When I see people here 
fret over "Yea, but it may cause breakage", on one hand I understand 
that can be the responsible stance, but OTOH it also makes me cringe 
because it's one more "cat" nibbling us to death - I don't want to see 
it follow in C++'s footsteps and allow these unfixed mistakes build up 
and damage what made D great in the first place. Especially since "small 
things that add up to more than the sum of their parts" is a big part of 
what makes D good in the first place.




The latest WAT I found in D is this one, see if you can figure it out:
How an alternation between two character types ends up being int is
beyond me, but even more inscrutible is why ch : wch produces int but
wch : dch produces uint.


Ouch. Although yea, guess that's another good reason to just decide 
Unicode == UTF-8 and be done with it ;) (I don't even care about UTF-8's 
supposed bloat in eastern alphabets - it's freaking *text* either way. 
Tale of Genji would be what, some tens of MB in UTF-8? Bah, trim down a 
few images and overengineered file formats and multimedia clutter if you 
need a shave a few measly MB so badly. If UTF-32'd won out, the complete 
works of Shakespeare would in the same boat, some tens of MB in the 
"wrong" format and we *still* wouldn't have the ASCII-simplicity of code 
points being equal to graphemes anyway. It's *text*. If your software's 
footprint or bandwidth is dominated by the size of a bloated text 
format, then *congratulations*, you officially have one of the smallest, 
most succinct software footprints in the world, so smile and be happy!)

Re: Faster Command Line Tools in D

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

On 05/25/2017 08:30 AM, xtreak wrote:


There are repeated references over usage of D at Netflix for machine 
learning. It will be a very helpful boost if someone comes up with any 
reference or a post regarding how D is used at Netflix and addition of 
Netflix to https://dlang.org/orgs-using-d.html will be amazing.




I've used netflix. If its "suggestion" features are any indication, I'm 
not sure such a thing would be a feather in D's cap ;)

mysql-native v1.1.0 - small bugfix update

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

mysql-native is a native D client driver for MySQL/MariaDB. It works 
with or without Vibe.d.


Small bugfix update:

- Fixed: #99: Update dub.sdl to allow vibe-d 0.8.* releases.

- Fixed: #111: NEWDECIMAL type returns the wrong value. Since this type 
is intended as arbitrary precision, the server itself sends it as a 
string. In order to avoid unexpected loss of precision, mysql-native 
does not attempt to convert the string to a floating-point type. If 
conversion to floating point is required, users can simply pass the 
string to Phobos's to!real.

Re: D now available on Codefights.com

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

Very cool

I've never heard of codefights.com before but I'm giving it as try right 
now (with D, of course) and I'm really enjoying it! :) Kudos to all 
involved!! :)

Re: Boston D Meetup: Strawman Structs

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

On 07/21/2017 05:55 PM, Steven Schveighoffer wrote:

On 7/2/17 6:35 AM, Steven Schveighoffer wrote:
I'll have a short presentation on a weird trick I discovered while 
writing some MySQL serialization code. Hope you can attend!


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



Very cool.

mysqln - tagged bugfix release v1.1.1

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

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

Native D client driver for MySQL/MariaDB, works with or without Vibe.d

Tagged bugfix release v1.1.1:

- Fixed: #116: Prevent segfault on copying ResultRange. (@schveiguy)
- Fixed: #120: Fix typos / grammars in documentation (@Marenz)
- Fixed: #124: Fix deprecations: Change deprecated std.string.munch to 
std.algorithm.skipOver. (@Kozzi11)

Re: mysqln - tagged bugfix release v1.1.1

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

BTW, I'm going to re-post something I posted to github:

FWIW, to any any all who may see: If you need something (even just a 
tagged release), don't hesitate to ping me, or re-ping, or even straight 
up harass me about it. I forget things easily, and the squeaky wheel 
really does get the grease. I have a bad habit of getting caught up in 
"real life"tm, so if something's really important, make sure to let me 
know: the worst thing I could possibly do is be busy with other things, 
so by all means, lemme-have-it.


Github pinging is probably the most reliable way to get my attention (in 
a positive way), so if you need something, don't hesitate: My github id 
is Abscissa

mysqln - v1.1.2

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

On 09/20/2017 01:24 AM, Nick Sabalausky (Abscissa) wrote:

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

Native D client driver for MySQL/MariaDB, works with or without Vibe.d

Tagged bugfix release v1.1.1:

- Fixed: #116: Prevent segfault on copying ResultRange. (@schveiguy)
- Fixed: #120: Fix typos / grammars in documentation (@Marenz)
- Fixed: #124: Fix deprecations: Change deprecated std.string.munch to 
std.algorithm.skipOver. (@Kozzi11)


Followup: v1.1.2

- Fixed: #130 Compilation error when compiling in singleFile mode. (@Marenz)

Re: mysqln - tagged bugfix release v1.1.1

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

On 09/21/2017 08:17 PM, Andrej Mitrovic wrote:
On Wednesday, 20 September 2017 at 05:24:14 UTC, Nick Sabalausky 
(Abscissa) wrote:

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

Native D client driver for MySQL/MariaDB, works with or without Vibe.d


Hey Nick,

Can this also work with Percona MySQL? Or perhaps maybe in the future.. :)

Cheers!


I'm not familiar with Percona. If it's fully MySQL-compatible like 
MariaDB, then it should. (Other than telling travis-ci to test on both 
MariaDB and MySQL, mysql-native doesn't actually have even one line of 
MariaDB-specific code.)

Re: mysqln - tagged bugfix release v1.1.1

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

On 09/25/2017 11:31 PM, Nick Sabalausky (Abscissa) wrote:

On 09/21/2017 08:17 PM, Andrej Mitrovic wrote:
On Wednesday, 20 September 2017 at 05:24:14 UTC, Nick Sabalausky 
(Abscissa) wrote:

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

Native D client driver for MySQL/MariaDB, works with or without Vibe.d


Hey Nick,

Can this also work with Percona MySQL? Or perhaps maybe in the 
future.. :)


Cheers!


I'm not familiar with Percona. If it's fully MySQL-compatible like 
MariaDB, then it should. (Other than telling travis-ci to test on both 
MariaDB and MySQL, mysql-native doesn't actually have even one line of 
MariaDB-specific code.)


Just checked their website. They claim:

"Percona Server for MySQL® is a free, fully compatible, enhanced, open 
source drop-in replacement for MySQL that provides superior performance, 
scalability and instrumentation."


So yes, it should work, although it hasn't been tested.

I'd say go ahead and try it out, and post bug reports to mysql-native if 
you run into any problems:

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

Re: Release D 2.077.0

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

On 11/02/2017 06:35 PM, Martin Nowak wrote:

reproducible dmd builds,


Curiosity: What exactly was preventing this before? Order of source 
files altering the order of output? Something else?


Also, just musing...Regarding the matter of __TIME__(etc) breaking this 
guarantee (breaking it for obvious reasons). Seems to me it would be 
helpful to have compiler switches to force lexer symbols to specific 
values in order to bring at least some level of reproducablity even to 
projects that do use such symbols.

Re: remake of remake of Konami's Knightmare

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

On 11/24/2017 08:28 PM, ketmar wrote:

quickfix. forgot to properly set requested OpenGL version.

http://files.catbox.moe/lx02hz.7z



Very cool! Works under wine for me. Not a game I was familiar with, so 
it's cool learning hands-on about more of Konami's back catalog from one 
of the best gaming eras.

mysql-native v1.1.3

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

An all-D MySQL/MariaDB client library:

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

In v1.1.3:

- Fixed: #138: Prepared: Prevent mem allocs during cleanup. (@Marenz)
- Fixed: #135: Now works on DMD 2.076 and up. (@SingingBush)
- New: #135: Add travis-ci testing for OSX. (@SingingBush)
- Fixed: DMD 2.074.x gives compile error when building tests. (@Abscissa)

mysql-native v1.1.4: Introduced auto-purge to fix a few problems

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

An all-D MySQL/MariaDB client library:

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


In v1.1.4:

Introduced auto-purge to fix a few problems.

- Fixed: #117: ResultRange cannot be copied. (@Abscissa)

- Fixed: #119: Is a defensive Connection.purgeResult call necessary 
before executing another statement? (As of this release, the answer 
changed from "sometimes" to "no") (@Abscissa)


- Fixed: #139: Server packet out of order when Prepared is destroyed too 
early. (@Abscissa)


- Change: MySQLDataPendingException (aka, MYXDataPending) is no longer 
necessary, and no longer thrown. When issuing a command that 
communicates with the server while a ResultRange still has data pending, 
instead of throwing, mysql-native now automatically purges the range and 
safely marks it as invalid and no longer usable. This was changed in 
order to fix #117, #119, and #139. This change should neither break user 
code nor require any changes. (@Abscissa)


- Change: Manually releasing a prepared statement is no longer 
guaranteed to notify the server immediately. In order to facilitate the 
above fixes, and avoid any nasty surprise with struct dtors triggering 
results purges implicitly, any release of prepared statements from the 
server is now queued until mysql-native can be certain no data is 
already pending. This change should neither break user code nor require 
any changes. (@Abscissa)


- Change: Prepared statements are no longer released automatically, due 
to the fix for #117. However, prepared statements and their lifetimes 
are tied to individual connections, and thus will die along with their 
connection, so manual release is not strictly necessary either. 
Accordingly, this change should neither break user code nor require any 
changes. (@Abscissa)


- Fixed: #143: Keep travis-ci build times under control by limiting the 
number of compiler versions tested on OSX. (@SingingBush)



Tentative plans for the next release (probably v1.2.0) include, among 
other things, removing the old deprecated APIs from pre-1.0, deprecating 
a few no-longer-needed things and some misc doc improvements.


Aside from those housekeeping details, my other next big priority is to 
finally tackle the awkwardness of combining prepared statements with 
connection pools. MySQL itself ties prepared statements to the 
individual connection that created them, and that's caused difficulties 
for connection pool users. So I'm thinking a connection-independent 
abstraction is warranted for prepared statements.


Mysql-native is made for its users, so if an issue is particularly 
pressing for you that you feel has been neglected, vote for your biggest 
bug-a-boo by pinging it:

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

(Or better yet, contribute!)

Re: D User Survey

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

On 12/08/2017 05:53 AM, Chris wrote:


Yep. D seems to be quite popular in Europe. I wonder why that is, given 
that it originated in the USA and people in the States are more open to 
new technologies. What were the technical and social factors at work 
here? Maybe D wasn't fancy enough to be taken seriously in the USA and 
maybe people from outside the USA (not only in Europe) looked at it and 
said "Hold on, that's something interesting...and we can contribute to 
it." D certainly struck a chord with many programmers around the globe, 
but what is it exactly? (Please no jokes about D major or D minor chords 
now ;)


Speaking as a US citizen, it's long been my observation that americans 
(and I only mean collectively, of course, it's difficult to generalize 
down to individuals since that varies greatly) tend to be far more 
conservative than one would assume them to be.


Just as one example: The various genres of electronic music. Always 
succeeded far better in europe than they ever did the US. Americans 
would hear it and just bitch about "soulless", "doesn't require musical 
talent" and other such [nonsence]. But turn on (for example) BBC's Top 
Gear and they had recognizable Prodigy, Crystal Method, etc all over the 
place. And heck, most of Fluke's catalog isn't even available in the US. 
That sort of stuff just doesn't sell very well over here. Americans like 
their "three main acoustic cords" and steady simple 4/4 beats.


Even "silicon vally" isn't quite so much "open to new technology" as it 
is driven primarily by buzz and popularity.


And then there's the last presidential election, which, and I don't mean 
this to be snarky, just honest observation: it clearly demonstrated 
there's far more white tra...*cough*...umm..."ultra-conservatives" here 
than anyone ever thought.


From what I hear, we're one of the few remaining industrialized nations 
that has capital punishment. Whether that's good/bad is completely 
beside the point here, the point being: Either way, it's undeniably 
conservative.


Despite perhaps tipping my hand a bit, I really don't mean any of that 
as ranting at all, just illustrating that it DOES make sense that europe 
would be more open to D than the US:


Because the US *is* paradoxically much more conservative than one would 
expect from a relatively young country that produces as much software 
and electronics as it does. Whether that conservativeness is 
good/bad/other is open to opinion, but either way, it is what it is, and 
I think D's higher rate of success elsewhere can be traced to that.

Re: D User Survey

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

On 12/08/2017 08:00 PM, SomeRandomUser wrote:


Isn't that just culture (music) how popular is American Country music in 
Europe?  I have met one person that liked it.  Trump is hardly an 
ultra-conservative (not to mention the various groups of conservatism 
social, fiscal, neo, etc..).  Alot of the whites u mentioned voted for 
Obama last time around and are just scared of globalism and knew the 
alternative would push further down that path.  Not all D users look at 
forums and while I do agree their are far more users visible in Europe 
that doesn't mean it's not used here as well.


All the details are certainly debatable, and I won't claim to be 
well-versed enough in sociology, politics, etc to get into such details 
(nor would I really want to in a D.announce sub-thread - apologies if 
that sounds like back-peddling), but it's just a certain theme I've 
noticed that, from this insider at least, in my personal observation the 
country doesn't seem to be quite as progressive as it may appear to be 
(or claim to be), or as one might assume it to be (the super bowl nipple 
thing is another example), and my hypothesis is that could account for 
the US vs Europe D-uptake discrepency. But, of course one thing that 
*is* certain is that the US has a lot of both ulta-liberal, 
ultra-conservative, and everythintg in-between (and probably plenty of 
extremes on some other axes as well!). So grain of salt in hand, in any 
case, it's just a thought.

Re: D User Survey

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

On 12/09/2017 07:58 AM, wobbles wrote:

On Thursday, 7 December 2017 at 14:31:01 UTC, Chris wrote:
  I didn't know Ireland was so

unknown, unless, of course, I'm supposed to choose "Great Britain".


I also hated myself for clicking Great Britain :-)


As an outsider, I'm curious about this. My (perhaps innacurate?) 
understanding was that "Great Britain" was more a geographical term 
referring to everything on the islands rather than a political boundary 
(as opposed to "UK" which is purely a political concept and includes 
some, but not all, of the countries on the same islands). Is that not 
enitrely correct? Or is that exactly the the part that's uncomfortable - 
that it's a "Country" field which lacks the actual country name and only 
offers a geographic collection in its place?

mysql-native v1.2.0: Housekeeping: Deprecations, Cleanup and Doc Improvements

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

An all-D MySQL/MariaDB client library:

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


In v1.2.0:

There's also a few bugfixes, but aside from that, this is mainly a 
housekeeping release:


- The deperecated symbols have been removed (ie, the the outdated 
pre-v1.0.0 interfaces).


- Some unnecessary symbols have now become deprecated (with recommended 
alternatives). Mainly the redundant set of verbose exception names and 
querySet/ResultSet (just call std.array.array() on the input range 
returned by query() instead).


- Various documentation improvements.

- And some other miscellany.

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


For the next release, slated as v1.3.0, the plan is to remove the 
symbols deprecated in this release, and take care of as much of this 
list as I can (it probably won't be all of it though):


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

Re: mysql-native v1.2.0: Housekeeping: Deprecations, Cleanup and Doc Improvements

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

On 12/15/2017 04:45 AM, Jacob Carlborg wrote:

On 2017-12-15 08:31, Nick Sabalausky (Abscissa) wrote:

- The deperecated symbols have been removed (ie, the the outdated 
pre-v1.0.0 interfaces).


If you have removed symbols that's a breaking API changes which should 
bump the right most digit in the version according to Semantic 
Versioning [1].


[1] https://semver.org/



Oh, I'd thought it was the middle one for that. Right-most for 
non-breaking changes, Middle for all breaking changes, and Left-most for 
major changes. Guess I remembered it wrong :/

mysql-native v1.2.1 (Was: mysql-native v1.2.0: Housekeeping: Deprecations, Cleanup and Doc Improvements)

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

On 12/15/2017 04:45 AM, Jacob Carlborg wrote:

On 2017-12-15 08:31, Nick Sabalausky (Abscissa) wrote:

- The deperecated symbols have been removed (ie, the the outdated 
pre-v1.0.0 interfaces).


If you have removed symbols that's a breaking API changes which should 
bump the right most digit in the version according to Semantic 
Versioning [1].


[1] https://semver.org/



Fixed by releasing a v1.2.1 with the deleted symbols added back in. They 
will be re-deleted in the next version, v2.0.0, along with the symbols 
that were newly-depecated in v1.2.0.


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

mysql-native: Prepared statements: Direction and future

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

I've posted (what basically amounts to an article) about my current 
thoughts on addressing Prepared's current downsides in the next release 
(v2.0.0), as well as a little bit of future direction of the lib.


Anyone interested in mysql-native's prepared statements (especially 
their interplay with connection pools) is encouraged to take a look and 
share any thoughts:


https://github.com/mysql-d/mysql-native/issues/95#issuecomment-357757013

Re: NES emulator written in D

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

Very cool!

mysql-native v2.0.0-rc1: Release Candidate: Redesigned Prepared

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

An all-D MySQL/MariaDB client library:

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

--

I've tagged a release candidate ("v2.0.0-rc1") which, among other 
various enhancements and cleanups, includes a redesign of prepared 
statements which are now connection-independent (among other benefits).


If you use prepared statements, this *does* involve some small breaking 
changes. A migration guide is provided here:


https://github.com/mysql-d/mysql-native/blob/master/MIGRATING_TO_V2.md


Motivations and the specific changes for prepared statements are 
explained here:


https://github.com/mysql-d/mysql-native/blob/master/ABOUT_PREPARED_V2.md

--

Full list of all other changes in this release in the changelog:

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

--

Please give it a try and let me know how it works out. Please file any 
issues here: https://github.com/mysql-d/mysql-native/issues

Re: mysql-native v2.0.0-rc1: Release Candidate: Redesigned Prepared

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

On 02/06/2018 03:42 AM, aberba wrote:


I really want to thank you for putting much time into documentation. 
Very much appreciated. This library is very necessary for the stuff I do.


Glad to hear! Boring as documenting can be, my viewpoint is that it's 
every bit as integral to a tool as the code itself: If people don't know 
how to use something, then what good does it do for it to exist at all? 
(Plus it helps me remember later on just what the heck I was doing :) )

mysql-native v2.0.0-rc2

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

Second release candidate: Tagged v2.0.0-rc2

Changes since RC1 listed in changelog:
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md

These changes are needed to help prepare for the eventual v2.1.0

Re: Official Dub package for DWT

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

Very cool, will have to give it a try. I'm very interested in cross 
platform native-UI GUI libs for D.

mysql-native v2.0.0-rc3: Third release candidate

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

Hopefully the last.

Changes since RC2 listed in changelog:
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md

--

Incidentally, when you're sticking to semantic versioning, utilizing 
release candidates and git branches REALLY comes in handy ;)  Highly 
recommend. Work on v2.1.0 is progressing while v2.0.0 is stabilizing. 
Plus, some of the work on v2.1.0 has revealed needs that are best 
included in v2.0.0 to avoid an imminent bump to v3+. Nice.

Re: dxml 0.2.0 released

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

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

On Mon, Feb 12, 2018 at 02:54:48PM +, rikki cattermole via 
Digitalmars-d-announce wrote:
[...]

Everything you have mentioned is not in Phobos. Just because something
is 'good enough' does not make it 'good enough' for Phobos. In the
words of Andrei "Good enough is not good enough", we need to aim
higher to show what we actually can do.


And thus Phobos continues to let the perfect be the enemy of the good,
and 10 years later std.xml will still be around, and we will still be
arguing over how to replace it.


+Several billion.

Like the improved assert messages we would've had since many years ago 
and was implemented, done and ready to go, but it was instead thrown 
away because...(and here's the real kicker, considering current D 
climate)...because it was a fully in-library solution instead of a new 
compiler feature. Go figure ::eyeroll::



Seriously, I would have thought something like this would be obvious to
programmers of the calibre found on these forums.  I'm a little
astonished that this would even be such a point of contention in the
first place, since the solution is so simple.


I would've expected so too, if it weren't that one of the top favorite 
activities 'round these parts is nitpicking reasonable ideas to death 
for stupid reasons. And, generally letting the perfect be the enemy of 
the good.

Re: dxml 0.2.0 released

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

On 02/12/2018 11:15 AM, rikki cattermole wrote:


dxml 7.5k LOC
std.xml 3k LOC

dxml would make the situation a lot worse.


4.5k LOC == "a lot worse"?

Uuuuhhh...WAT?

Re: dxml 0.2.0 released

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

On 02/12/2018 10:49 PM, Jonathan M Davis wrote:


Andrei used to complain periodically about how large std.datetime was,
thinking that it was way too much code, and then someone actually went to
the effort of stripping out all of the comments and unit tests and whatnot
to count the actual lines of code in the implementation, and it was a _way_
smaller number than the lines in the file (IIRC, it might have even been
something like only 10% of the file, if that). That's what happens when you
write documentation and unit tests that are thorough.



Yea, totally. Another example: mysql-native used to be one (!!) source 
file. It was maybe a bit on the large size for a single module, but it 
was still workable. In the last several years, that library has grown 
many times its old size. But now, I'd say that easily the majority of 
lines are either comments or tests. The *actual* implementation and API 
isn't really all that much more LOC than it used to be. The original 
one-module version, by contrast, was less documented and had...I don't 
think it even had a single test (IIRC, the 
now-old-and-probably-bitrotted "app.d" wasn't even there.)

mysql-native v2.0.0: Redesign Prepared

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

An all-D MySQL/MariaDB client library:

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



This new v2.0.0, among other various enhancements and cleanups, includes 
a redesign of prepared statements which are now connection-independent 
(among other benefits).


If you use prepared statements, this *does* involve some small breaking 
changes. A migration guide is provided here:


https://github.com/mysql-d/mysql-native/blob/master/MIGRATING_TO_V2.md

Motivations and the specific changes for prepared statements are 
explained here:


https://github.com/mysql-d/mysql-native/blob/master/ABOUT_PREPARED_V2.md



Full list of all other changes in this release in the changelog:
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md



Coming up: Version 2.1.0 in on the way.
Progress so far:
https://github.com/mysql-d/mysql-native/milestone/3?closed=1

Re: D compiler daily downloads at an all-time high

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

On 02/13/2018 01:15 PM, Dmitry Olshansky wrote:

On Monday, 12 February 2018 at 15:20:29 UTC, Martin Tschierschke wrote:

On Monday, 16 November 2015 at 15:20:51 UTC, Andrei

Congratulations to everybody who co

Andrei

Old post but new numbers!

http://erdani.com/d/downloads.daily.png

Would be nice to know what caused the recent spike to >8000?
Are there any other usage stats available? For dlang.org or 
code.dlang.org ?


Regards mt.


When I see spikes like that out of nowhere that it’s usually some 
automation kicking in. Could it be a new CI that we didn’t account for yet?


Secretly hope it’s a fresh wave of D users though ;)


A totally botched DoS attempt? ;) I'll assume no ;)

Re: Beta 2.079.0

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

On 02/19/2018 05:49 AM, Martin Nowak wrote:

http://dlang.org/changelog/2.079.0.html


...WOW O_o

This release is seriously, just...wow!

One question though: I'm unclear on the "include imports". Do those 
basically obviate the original purpose of rdmd? Ie, so dmd doesn't need 
to be passed a list of every individual file to be compiled? Just do 
this and be done?:


$ dmd -offoobar -Isource -i=foobar source/foobar/main.d
$ ./foobar

Or do I misunderstand it?

mysql-native v2.1.0-rc1: New features

[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-rc1', release candidate for v2.1.0, which mainly adds a 
few new features, inlcuding 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.


Full changelog for this release is in the 'v2.1.x' branch:
https://github.com/mysql-d/mysql-native/blob/v2.1.x/CHANGELOG.md

Final v2.1.0 release is tentatively scheduled for one week from today.

Re: mysql-native v2.1.0-rc1: New features

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

Minor second release candidate, 'v2.1.0-rc2'. Only thing this changes is 
to update the example in the readme to include the new simplified 
prepared statement interface.

Re: mysql-native v2.1.0-rc1: New features

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

On 02/25/2018 02:01 AM, Suliman wrote:

What about string interpolation like:

conn.exec("INSERT INTO table_name VALUES ({i}, {s})"); ?

Instead of:
conn.exec("INSERT INTO table_name VALUES (?, ?)", i, s);


The syntax is purely, 100% server-side. Mysql-native just passes the 
whole string, question marks and all, straight off to the server. So 
whatever syntax the server supports, mysql-native supports. Whatever the 
server doesn't, mysql-native doesn't.


I've heard about a MySQL (I think) syntax like this:
"INSERT INTO table_name VALUES (:i, :s)"

But I haven't given it a try, and I don't know about its compatability.

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

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

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.)

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.

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: 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/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 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" ;)\