Re: DWT API Documentation now on dpldocs.info

[Patrick Schluter via Digitalmars-d-announce]

On Thursday, 8 March 2018 at 01:21:44 UTC, Adam D. Ruppe wrote:
As some of you might know, DWT is a D port of Java's SWT. It is 
as thus nearly identical and you can use Java's documentation 
with very little effort - copy/paste of Java examples almost 
just work as D too.


[...]


Thank you, Adam. You made my day!

Re: mysql-native v2.1.0

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

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


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


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


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


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


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




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

Re: Lobst.rs now has a "D" tag

[Bauss via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 16:34:31 UTC, Pradeep Gowda wrote:

https://lobste.rs/t/d

Please do not forget to tag your D related submissions with the 
"D" tag.


Can someone invite me at baussproje...@gmail.com

Re: mysql-native v2.1.0

[Bauss via Digitalmars-d-announce]

On Thursday, 8 March 2018 at 07:03:15 UTC, Nick Sabalausky 
(Abscissa) wrote:

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


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


I had similar issues returning a raw connection created.


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


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


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


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


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

Re: mysql-native v2.1.0

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

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


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


I had similar issues returning a raw connection created.


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


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


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

Re: mysql-native v2.1.0

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

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


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


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




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


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


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




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

However I still have this issue:

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

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


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


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


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


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



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


private static __gshared MySQLPool[string] _pools;

And then I retrieve a connection with the function below.

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


private static shared globalPoolLock = new Object;

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

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

   _pools[connectionString] = pool;
     }
   }

   return pool.lockConnection();
}

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


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


MySQLPool pool;

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


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


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

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

Re: Gtk-D API Documentation now on dpldocs.info

[ANtlord via Digitalmars-d-announce]

On Thursday, 8 March 2018 at 01:27:07 UTC, Adam D. Ruppe wrote:
GtkD is a D wrapper to the GTK library. It has plenty of doc 
comments attached... but they are in a special GTK syntax and 
all the cross references refer to C structs and functions 
instead of to D classes and methods.


Well, adrdox got some special-case code to handle this and do 
the translations for us! I'd say I got it about 95% handled 
automatically... and I like the result a lot more than the 
official docs for either D or C.


Take a look!

http://gtk-d.dpldocs.info/index.html


Great job! Thanks a lot!

4 types of applications that can be created using java programming

[mia avery via Digitalmars-d-announce]

 Hello Guys,

  Having more than 3 years experience at MindMajix.com in IT 
professional with expertise in providing Enterprise Performance 
Engineering solutions & Integrated end to end IT monitoring 
solutions to clients from various industries.


1) Standalone Application

It is also known as a desktop application or window-based 
application. An application that we need to install on every 
machine such as media player, antivirus etc. AWT and Swing are 
used in java for creating standalone applications.


2) Web Application

An application that runs on the server side and creates a dynamic 
page, is called web application. Currently, servlet, JSP, Struts, 
JSF etc. technologies are used for creating web applications in 
Java.


3) Enterprise Application

An application that is distributed in nature, such as banking 
applications etc. It has the advantage of the high-level 
security, load balancing, and clustering. In Java, EJB is used 
for creating enterprise applications.


4) Mobile Application

An application that is created for mobile devices. Currently, 
Android and Java ME are used for creating mobile applications.

Release: nanovega.d rendering lib like html5 canvas

[Adam D. Ruppe via Digitalmars-d-announce]

https://github.com/adamdruppe/arsd

nanovega.d

depends on: simpledisplay.d, color.d, and ttf.d (latter only on 
Windows)


Should also be present in v1.3 of the dub package 
http://code.dlang.org/packages/arsd-official


API docs (includes an example to get you started)
http://dpldocs.info/experimental-docs/arsd.nanovega.html

This module's primary author is ketmar. What follows is his 
description:



NanoVega is a fork of the famous NanoVG rendering library. it was 
ported to D, and then updgraded with various features.


NanoVega is using OpenGL for rendering (i.e. no intermediate 
rasterize-to-picture step), and its API modelled after HTML5 
canvas API.


most interesting *new* features are:

 * clipping to paths

 * support for non-zero and even-odd fill rules. original NanoVG 
only

supported non-zero (despite what it's README says).

 * fontconfig support on Posix systems.

 * full-featured picking API: you can check if your mouse cursor 
is inside of a filled path, or on the border of a stroked path. 
you don't need to render your pathes for this, and you can do 
your tests *before* rendering (to change colors of UI elements on 
mouse hover, for example). it is quite fast,  and is using 
quad-tree to further speed up the tests.


 * NanoVega is completely @nogc!

 * easy to use and powerful text API: accepts `char`, `wchar`, 
and `dchar` strings, so you don't need to convert your text back 
and forth! provides iterators and callback-based API to get 
various text metrics.


 * doesn't require any dependencies besides ARSD modules.

 * extensive DDoc documentation and sample code.

 * comes with Blendish port to make your UI rendering easy and 
fun.  
(see blendish.d in the arsd repo)


there is also standalone SVG parser and rasterizer, based on 
NanoSVG project. it was forked, ported to D, and made even better 
than the original! 



 * completely standalone, doesn't require any other modules.

 * converts your SVGs to drawing commands or cubic bezier curves.

 * supports standalone "style" tag.

 * has better and faster XML parser.

 * has builtin rasterizer, so you can convert your icons to 
images for speed.


 * can be used with NanoVega to render SVGs without prior 
rasterizing.


 * FAST! and @nogc!


enjoy, and happy hacking. ;-)

Re: DWT API Documentation now on dpldocs.info

[Adam D. Ruppe via Digitalmars-d-announce]

On Thursday, 8 March 2018 at 01:34:12 UTC, Bill Baxter wrote:
The logo in the corner - http://dwt.dpldocs.info/d-logo.png is 
a 404 btw.


Yeah, I realized after generating the files that I used the wrong 
header source. The search is a broken link too...


All fixed now via some hacky redirects :)

Re: Diamond Full-stack MVC / Template Engine - v2.7.0 Released!

[Mike Parker via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 22:37:36 UTC, bauss wrote:

I finally got around and fixed the last corners here and there.

If you wonder what Diamond is, then it's a library for 
developing full-stack MVC web-applications based on vibe.d.


It contains a lot of features (Which you can see in the READ ME)


And you can read more about the project in the Project Highlight 
bauss did on the D Blog a while back:


https://dlang.org/blog/2017/11/20/project-highlight-diamond-mvc-framework/

Re: DWT API Documentation now on dpldocs.info

[Bill Baxter via Digitalmars-d-announce]

The logo in the corner - http://dwt.dpldocs.info/d-logo.png -- is a 404 btw.

On Wed, Mar 7, 2018 at 5:32 PM, Bill Baxter  wrote:

> Cool!  I used to love using DWT back in the day.
>
> Yeh the Eclipse ones look like they were written by someone trying very
> hard to make you think you were using a native app on some platform with a
> horrible UI from the 90s.
>
> --bb
>
> On Wed, Mar 7, 2018 at 5:28 PM, Adam D. Ruppe via Digitalmars-d-announce <
> digitalmars-d-announce@puremagic.com> wrote:
>
>> Compare and contrast with the official Java dox:
>>
>> http://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.pl
>> atform.doc.isv/reference/api/org/eclipse/swt/package-summary.html
>>
>> both are generated from basically the same doc comments, but I like mine
>> better :)
>>
>
>

Re: DWT API Documentation now on dpldocs.info

[Bill Baxter via Digitalmars-d-announce]

Cool!  I used to love using DWT back in the day.

Yeh the Eclipse ones look like they were written by someone trying very
hard to make you think you were using a native app on some platform with a
horrible UI from the 90s.

--bb

On Wed, Mar 7, 2018 at 5:28 PM, Adam D. Ruppe via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Compare and contrast with the official Java dox:
>
> http://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.pl
> atform.doc.isv/reference/api/org/eclipse/swt/package-summary.html
>
> both are generated from basically the same doc comments, but I like mine
> better :)
>

Gtk-D API Documentation now on dpldocs.info

[Adam D. Ruppe via Digitalmars-d-announce]

GtkD is a D wrapper to the GTK library. It has plenty of doc 
comments attached... but they are in a special GTK syntax and all 
the cross references refer to C structs and functions instead of 
to D classes and methods.


Well, adrdox got some special-case code to handle this and do the 
translations for us! I'd say I got it about 95% handled 
automatically... and I like the result a lot more than the 
official docs for either D or C.


Take a look!

http://gtk-d.dpldocs.info/index.html

Well, I made a mistake generating these and there's a broken 
image and link in the header... but the text body looks pretty 
good!


You can navigate around there and even go to the root and see all 
the various packages included in gtkd:


http://gtk-d.dpldocs.info/gtk.html


Any Gtk-D users here who can give me some practical feedback? 
Unlike most dub packages, gtkd is just too big to automatically 
generate on the server, so I have to do it on my computer and 
copy the (almost 26,000!!!) files up to the 'net. So I won't 
update it frequently, but I will keep improving if I hear good 
ideas.

Re: Gtk-D API Documentation now on dpldocs.info

[Adam D. Ruppe via Digitalmars-d-announce]

Compare and contrast to the official gtk-d docs:

https://api.gtkd.org/gtkd/gtk/AboutDialog.html

and the C gtk docs:

https://developer.gnome.org/gtk3/stable/GtkApplication.html


You can see they are all generated from the same source doc 
comments, but I think mine is nicest - just translating the links 
into the D names helps. Even if you can do it in your head once 
you get to know the pattern, having clicks just work to get you 
there are nice.

Re: DWT API Documentation now on dpldocs.info

[Adam D. Ruppe via Digitalmars-d-announce]

Compare and contrast with the official Java dox:

http://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/package-summary.html

both are generated from basically the same doc comments, but I 
like mine better :)

DWT API Documentation now on dpldocs.info

[Adam D. Ruppe via Digitalmars-d-announce]

As some of you might know, DWT is a D port of Java's SWT. It is 
as thus nearly identical and you can use Java's documentation 
with very little effort - copy/paste of Java examples almost just 
work as D too.


But, the eclipse docs are meh and besides, it is nice to have the 
D docs anyway.


Thankfully, there's plenty of documentation comments in the dwt 
source. Alas, they are javadoc comments. Well, now adrdox knows 
how to read javadoc (if specifically told to).


I don't have a great entry point to the docs, so it will just go 
to the Display class... but take a look:


http://dwt.dpldocs.info/index.html

As you click around, you can navigate, see the inheritance trees, 
and might even notice some of the java.lang namespace in there!


http://dwt.dpldocs.info/java.lang.String.html

Well, I made a mistake generating these and there's a broken 
image and link in the header... but the text body looks pretty 
good!



Any DWT users who can give me feedback on the quality?

Re: Diamond Full-stack MVC / Template Engine - v2.7.0 Released!

[Adam D. Ruppe via Digitalmars-d-announce]

And api documentation for the new version!

http://diamond.dpldocs.info/v2.7.0/index.html

Re: LDC 1.8.0

[Stephan via Digitalmars-d-announce]

On Sunday, 4 March 2018 at 22:37:21 UTC, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to announce LDC 1.8. The 
highlights of this version in a nutshell:


* Based on D 2.078.3.
* New switch `-link-defaultlib-shared` to link against shared 
druntime/Phobos.

* Plugins support, compatible with existing Clang plugins.
* Support for LLVM IR-based PGO as alternative to existing 
(AST-based) PGO.

* Basic support for LLVM XRay instrumentation.

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.8.0


Thanks to all contributors!


Awesome! Thanks!

When is it available on homebrew?

Cheers,
Stephan

Re: Documentation for any* dub package, any version

[Adam D. Ruppe via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 22:47:48 UTC, bauss wrote:

How would you go about updating docs?


Either go to the url for the specific version you want like 
http://diamond.dpldocs.info/v2.7.0/index.html and it will 
download (once dub scrapes it anyway)


or ping me and I'll manually update the master branch. so this is 
good now too http://diamond.dpldocs.info/diamond.html



I still haven't decided when I want to automatically update 
master so it is manual at this point.

Re: Documentation for any* dub package, any version

[bauss via Digitalmars-d-announce]

On Friday, 2 March 2018 at 00:04:10 UTC, Adam D. Ruppe wrote:

On Thursday, 1 March 2018 at 11:00:15 UTC, Jonas Drewsen wrote:
Would be cool if you could add support for creating docs from 
any dub project stored on github and not only the ones on 
code.dlang.org.


That might be possible too.


BTW I just put the server code up on github
https://github.com/adamdruppe/dpldocs


there's actually not that much to it right now.


How would you go about updating docs?

I'd like to have http://diamond.dpldocs.info/diamond.html updated

Thank you!

llvm-mca: a static performance analysis tool

[Johan Engelen via Digitalmars-d-announce]

I find this such great LLVM news that I'd share it here:

llvm-mca: a static performance analysis tool
http://lists.llvm.org/pipermail/llvm-dev/2018-March/121490.html

cheers,
  Johan

Diamond Full-stack MVC / Template Engine - v2.7.0 Released!

[bauss via Digitalmars-d-announce]

I finally got around and fixed the last corners here and there.

If you wonder what Diamond is, then it's a library for developing 
full-stack MVC web-applications based on vibe.d.


It contains a lot of features (Which you can see in the READ ME)

To name a few of the key features:

* Full control over requests / responses when wanted.
* "Websettings" file that lets you control requests / responses 
for:

  * Before a request is handled.
  * After a request has been handled.
  * When an error occurres.
  * When a page or controller action wasn't found.
  * When a static file has been requested.
* Multiple static file paths
* Let's you bind to multiple ip addresses and ports.
* Let's you control default headers for each type of request 
(default, static files, errors, not found etc.)
* Uses vibe.d for backend, so it's very powerful and all vibe.d 
features can be used with Diamond
* Easy control over the application's type using *static if* 
constructs.

  * isWeb (true for both web-servers and web-apis.)
  * isWebServer (true for web-servers)
  * isWebApi (true for web-apis)
  * isWeb, isWebServer and isWebApi will be false for standalone.
* ACL & Authentication tied to it
* Separate authentication that can be used either with or without 
the ACL

* CSRF Protection
* Easy integrated cookie/session API.
* The network can be restricted to specific ips.
* Transactions
* Unittesting
* Logging
* i18n
* Version-control
* Route rewriting
* Database Integration & Object Relational Mapping
* Websockets
* Specialized Routes (Can fetch resources external internal or 
local)
* Views are parsed at compile-time, thus rendering of views are 
super fast

* Views can have layout views
* Views have a metadata section that lets you change view 
configurations such as its controller, model, layout, route and 
placeholders.
* Views have placeholders and layout view's can access the render 
view's placeholders.

* Views can encode their data
* Has a rich syntax that allows for complex and innovative 
rendering.
* Easy access to the current request / response using the 
properties: *httpRequest* and *httpResponse*

* Can render other views within itself
* Any type of D code can be written within views.
* Allows for sections, which is useful to only render a part of 
the view. (Very useful for responsive designs)

* Can be passed to controllers by their base view
* Layout views can be changed dynamically
* Expensive views can be cached.
* Flash-messages
* Controller actions are mapped through attributes. (By default 
the route name will be the name of the function.)
  * If wanted actions can be mapped manually, but that's a legacy 
feature.
* Controller actions can easily control how the response is 
handled, as they require a status returned

  * Status.success (Will continue to handle the request.)
  * Status.end (Will end the request; useful for json responses 
etc. *Note: using the json() function already does it for you.)*

  * Status.notFound (Will issue a 404 status for the response.)
* Can map mandatory actions that are executed on every requests. 
(Useful for authentication etc.)

* Easy integrated authentication (Can be combined with ACL)
* RESTful
* Specific actions can be restricted to specific ips.

After 2.7.0 I have decided to drop backward compatibility as 
2.7.0 barely introduces any major breaking changes, but it fixes 
a lot of issues and now works with vibe.d 0.8.2 and mysql-native 
2.1.0!!


Since last announced update the following has been added:

* i18n messages can now be added dynamically.
* Support for mysql-native 2.1.0
* Support for vibe.d 0.8.2
* Removed backward compatibility with older vibe.d versions
* Slowly moving away from shared static constructors. (Currently 
Diamond implements a main function for a start.)
* Better internal usage of placeholders (They now append to the 
view's content, instead of using std.array.replace.)
* Removed the rootPath property from the View class, because it 
was expensive and kind of useless.

* You can now retrieve placeholder values from views
* Route creation was made public
* Added new view functionality such as the ability to delay view 
render for layouts etc.

* Added the ability to use a single view for routing
* Added a view constructor extension type

Other than that minor optimizations and bug fixes has also taken 
place.


Github: https://github.com/DiamondMVC/Diamond
Dub: https://code.dlang.org/packages/diamond (Currently waiting 
for dub to update the package!)


In the last announcement for Diamond I said I'd implement a SEO 
API and SOAP support and it's still planned, but it wasn't 
prioritized like updating to vibe.d 0.8.2 and mysql-native 2.1.0


I still plan to implement it within the near future!

I think Diamond has reached a stable phase, which means I can 
focus on adding tutorials, examples etc.


I also need to pick up working on the official Diamond website, 
but I have a lot of actual paid work that I can't just put away 
at the mome

Re: mysql-native v2.1.0

[bauss via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 19:36:57 UTC, bauss wrote:
On Wednesday, 7 March 2018 at 11:04:10 UTC, Nick Sabalausky 
(Abscissa) wrote:

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


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




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


I was all the way down at 1.1.2, because of other issues that I 
can't remember on top of my head, but they have since been 
resolved. There were only one issue back for which was the 
locked connection thing, which my post above has a link to.


So I changed my code to do this with retrieving the pool and 
creating it:


/// Collection of connection pools.
private static __gshared MySQLPool[string] _pools;

/// Global pool lock to ensure we don't attempt to create a 
connection pool twice on same connection string.

private static shared globalPoolLock = new Object;

/**
* Gets a new mysql connection from the pool.
* Params:
*   connectionString = The connection string for the connection.
* Returns:
*   The mysql connection.
*/
private MySQLPool getPool(string connectionString)
{
  auto pool = _pools.get(connectionString, null);

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

  _pools[connectionString] = pool;
}

return getPool(connectionString);
  }

  return pool;
}

And when using it:

  auto pool = getPool(useDbConnectionString);
  auto connection = pool.lockConnection();

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

Rather than just returning the connection from it.

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


I had similar issues returning a raw connection created.

Advent of D

[greentea via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 16:34:31 UTC, Pradeep Gowda wrote:

https://lobste.rs/t/d

Please do not forget to tag your D related submissions with the 
"D" tag.


and a blog post:

https://lobste.rs/s/b4qki7/advent_d

Re: mysql-native v2.1.0

[bauss via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 11:04:10 UTC, Nick Sabalausky 
(Abscissa) wrote:

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


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




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


I was all the way down at 1.1.2, because of other issues that I 
can't remember on top of my head, but they have since been 
resolved. There were only one issue back for which was the locked 
connection thing, which my post above has a link to.

Re: mysql-native v2.1.0

[bauss via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 10:14:08 UTC, Nick Sabalausky 
(Abscissa) wrote:

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.


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


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


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

However I still have this issue:

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

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


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


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


private static __gshared MySQLPool[string] _pools;

And then I retrieve a connection with the function below.

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


private static shared globalPoolLock = new Object;

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

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

  _pools[connectionString] = pool;
}
  }

  return pool.lockConnection();
}

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

Re: Release D 2.079.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/7/18 12:02 PM, H. S. Teoh wrote:

On Wed, Mar 07, 2018 at 02:53:17PM +, Mike Parker via 
Digitalmars-d-announce wrote:

On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:

It will force everyone who compiles dmd from source to use dub. It's
not the end of the world, but I for one will not be too happy about
it.


IMO, much better than forcing everyone to compile with make, which I'm
not too happy about :-)


Touché. :-D  The good thing is that make is pretty much guaranteed to
exist in all OS installations (except Windows perhaps? But pretty much
anywhere a compiler toolchain is installed), whereas dub isn't.


You need a D compiler to build D. So dub is probably there too.

Note that I'm against having phobos being a separate dependency from the 
compiler, but I'm not against switching to dub for the build.


-Steve

Re: Release D 2.079.0

[H. S. Teoh via Digitalmars-d-announce]

On Wed, Mar 07, 2018 at 02:53:17PM +, Mike Parker via 
Digitalmars-d-announce wrote:
> On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:
> > It will force everyone who compiles dmd from source to use dub. It's
> > not the end of the world, but I for one will not be too happy about
> > it.
> 
> IMO, much better than forcing everyone to compile with make, which I'm
> not too happy about :-)

Touché. :-D  The good thing is that make is pretty much guaranteed to
exist in all OS installations (except Windows perhaps? But pretty much
anywhere a compiler toolchain is installed), whereas dub isn't.

Seriously, I would be much happier with a D build tool. Dub is not a bad
package manager, though it could be better, but IMO it does a poor job
at being a general build system.  If it were only made more configurable
and less insistent about everything being required to be done its way or
the highway, having Phobos distributed as a dub package wouldn't be so
bad. 

But who knows. Maybe being forced to use dub to build Phobos would
finally provide the motivation for people to improve dub as a build
tool. But AIUI there are some fundamental design assumptions built into
dub that basically makes it impossible to fix some of these issues
without pretty much rewriting it from ground up.  Because of this, I
have not found myself particularly inclined to actually look at its
code.


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.

Lobst.rs now has a "D" tag

[Pradeep Gowda via Digitalmars-d-announce]

https://lobste.rs/t/d

Please do not forget to tag your D related submissions with the 
"D" tag.

Re: Release D 2.079.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 07.03.2018 um 17:01 schrieb Paolo Invernizzi:

On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote:

But why wouldn't it be possible to make a quick bugfix release with 
the current scheme? It has happened in the past. Granted, if a 
0.8.5-beta.1 is already tagged, then using 0.8.5 for a quick 
intermediate release would be bad, but at that point the beta could 
likely also be turned into a full release pretty quickly.


Well, I don't know why, but quick is more than 30 days right now using 
the current release procedure...


https://github.com/vibe-d/vibe.d/issues/2058
https://github.com/vibe-d/vibe.d/releases

Anyway, never mind!

/Paolo


What I mean are releases like these:

https://vibed.org/blog/posts/vibe-release-0.7.11 (3 days)
https://vibed.org/blog/posts/vibe-release-0.7.28 (16 days)

There are also releases such as 0.7.29 that actually got branched out 
and was stabilized while 0.7.30 was already pushed further along on master.


But such releases were only done if really necessary, because a release, 
despite many things being automated, always has quite some overhead, 
just like maintaining parallel branches has. Depending on the work force 
and the general development speed that may be okay, but currently 
development time unfortunately is a premium.

Re: Release D 2.079.0

[Paolo Invernizzi via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote:

But why wouldn't it be possible to make a quick bugfix release 
with the current scheme? It has happened in the past. Granted, 
if a 0.8.5-beta.1 is already tagged, then using 0.8.5 for a 
quick intermediate release would be bad, but at that point the 
beta could likely also be turned into a full release pretty 
quickly.


Well, I don't know why, but quick is more than 30 days right now 
using the current release procedure...


https://github.com/vibe-d/vibe.d/issues/2058
https://github.com/vibe-d/vibe.d/releases

Anyway, never mind!

/Paolo

Re: Release D 2.079.0

[Mike Parker via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 14:20:54 UTC, H. S. Teoh wrote:



It will force everyone who compiles dmd from source to use dub. 
It's not the end of the world, but I for one will not be too 
happy about it.


IMO, much better than forcing everyone to compile with make, 
which I'm not too happy about :-)

Re: Release D 2.079.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 07.03.2018 um 13:57 schrieb Paolo Invernizzi:

On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:

Well, for all of the recent releases we made sure that there was no 
breakage for new compiler versions. This release was an exception, 
because I didn't manage to put out the fixed release in time. The plan 
is to have all future releases go back to the normal mode where the 
new compiler version always works.


Since std.experimental isn't involved from now on, it shouldn't even 
be necessary anymore to put out new vibe.d releases for new DMD 
versions, because DMD/Phobos already checks for regressions against 
vibe.d and all breaking changes should simply result in a deprecation 
warning.


That's fine, thanks.

As for the versioning scheme, currently almost all new releases have 
some small breaking change or deprecation. If I'd use the "minor" 
version for that, then there would be no way to signal that a release 
makes broad and more disruptive changes, such as the 0.8.0 release. 
But all of this will change, as the remaining parts get pushed to 
separate repositories one-by-one, with their own version starting at 
1.0.0.


I understand your reasoning, but there's value in being able to just 
rapidly fix something with a new release, or just port some master 
bug-fixes into a released version branch.


DMD is experiencing a very enjoyable release process of patch versions, 
thanks to Martin and the team.


It your concern is only related to the best way to inform the users 
about a broad and disruptive change in vibe-d, I suggest to simply use 
the usual channels for that, change logs and announce forum.


My impression is that there's a lot of value in using patch for patch, 
instead of using patch for development, also in a zero major, so I maybe 
you should consider that change, or at least, investigate a little about 
that opportunity.


/Paolo


But why wouldn't it be possible to make a quick bugfix release with the 
current scheme? It has happened in the past. Granted, if a 0.8.5-beta.1 
is already tagged, then using 0.8.5 for a quick intermediate release 
would be bad, but at that point the beta could likely also be turned 
into a full release pretty quickly.


But the point is that the development mode is currently still happening 
in a linear fashion. Starting to have (a) stable branch(es) with 
additional point releases would increase the overhead to a point where 
there wouldn't be any meaningful progress anymore, at least at this time.


Then there is the fact that 0.8.0 was developed in a parallel branch for 
quite a while. If the minor version would have been used to denote 
regular small updates, it would not have been possible to tag alpha/beta 
releases on the 0.8.x branch at all.

Re: Release D 2.079.0

[H. S. Teoh via Digitalmars-d-announce]

On Wed, Mar 07, 2018 at 03:58:38PM +1300, rikki cattermole via 
Digitalmars-d-announce wrote:
> On 07/03/2018 2:54 PM, psychoticRabbit wrote:
> > On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:
> > > 
> > > Also, if you'll allow me to have crazy ideas for a moment, one
> > > wonders why we shouldn't just release Phobos itself through dub?
> > > Rust makes people use their build tool, why not us?
> > 
> > That's the day I stop using D.
> > 
> > I do not, and will not, use dub. Full stop.
> > 
> > Same goes for Rust ;-)
> 
> Under such arrangement nobody is forcing you to use dub.
> We wouldn't break distribution or usage of dmd just because of
> changing a make file to dub. That's just silly.

It will force everyone who compiles dmd from source to use dub. It's not
the end of the world, but I for one will not be too happy about it. Not
to mention, it will introduce bootstrapping issues to Phobos, since dub
itself depends on Phobos (again, solvable, but can be a potential source
of trouble).


T

-- 
Don't get stuck in a closet---wear yourself out.

Re: mysql-native v2.1.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/7/18 5: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


Hm.. I've wanted to do the same thing, yet for redis (as redis is super 
unsecure when using a network socket, but can have fine-grained 
permissions when using a unix socket). Will that be possible?


-Steve

Re: Release D 2.079.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/6/18 3:50 PM, Jack Stouffer wrote:

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
That being said, I'm wondering if it wouldn't be better to have 
std.experimental be in its own repository. This allows selection of 
the dependency on std.experimental separate from phobos. It still 
would be an "official" dlang package, and might even be included in 
the distribution (the latest version anyway), and docs included on the 
website. But if needed, you could have your dub package depend on a 
prior version.


The entire concept needs a reexamination IMO. I just checked the git 
history, and not one module has graduated from std.experimental to 
mainline Phobos since the idea's inception in 2014. While it's possible 
that none of the modules are ready, logger has been there for four years 
now. I was against changing how experimental is handled in the past, but 
I recently have started to rethink how we promote modules.


Promotion of modules is a different discussion. I think std.experimental 
is fine as a project, but just needs to be decoupled with needed 
compiler and stable library fixes.


To put it in terms of Atila's reference, it's like we coupled the 
breaking changes of boost-experimental with critical clang fixes.


Also, if you'll allow me to have crazy ideas for a moment, one wonders 
why we shouldn't just release Phobos itself through dub? Rust makes 
people use their build tool, why not us?


No. Phobos has a reasonably stable API, and we need to keep it that way. 
There are too many coupled changes with Phobos and DMD that I think we 
would be asking for a mountain of "Why is this version of Phobos not 
compatible with this version of DMD?" bugs.


-Steve

Re: Release D 2.079.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/6/18 11:02 PM, Seb wrote:

On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:

On 3/6/18 2:30 PM, Martin Nowak wrote:

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:


But if needed, you could have your dub package depend on a prior 
version.


http://code.dlang.org/packages/stdx-allocator ;)



This is the answer, vibe.d should depend on stdx-allocator.

-Steve


Vibe.d (and a lot of other projects) do depend on this package, see e.g.

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

Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm 
and not released as the latest stable tag yet, which is the reason for 
Atila's justified complaint.


Hm... so basically this was fixed back in December, but just hadn't been 
released? I think then this seems like an unfortunate, but temporary 
problem that should be OK for the future.


In any case, I think this shows we need to move our proving grounds to 
an external package. Much better to do it that way than to couple 
breaking changes on an experimental package with dmd/phobos fixes.


-Steve

Re: Release D 2.079.0

[Paolo Invernizzi via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:

Well, for all of the recent releases we made sure that there 
was no breakage for new compiler versions. This release was an 
exception, because I didn't manage to put out the fixed release 
in time. The plan is to have all future releases go back to the 
normal mode where the new compiler version always works.


Since std.experimental isn't involved from now on, it shouldn't 
even be necessary anymore to put out new vibe.d releases for 
new DMD versions, because DMD/Phobos already checks for 
regressions against vibe.d and all breaking changes should 
simply result in a deprecation warning.


That's fine, thanks.

As for the versioning scheme, currently almost all new releases 
have some small breaking change or deprecation. If I'd use the 
"minor" version for that, then there would be no way to signal 
that a release makes broad and more disruptive changes, such as 
the 0.8.0 release. But all of this will change, as the 
remaining parts get pushed to separate repositories one-by-one, 
with their own version starting at 1.0.0.


I understand your reasoning, but there's value in being able to 
just rapidly fix something with a new release, or just port some 
master bug-fixes into a released version branch.


DMD is experiencing a very enjoyable release process of patch 
versions, thanks to Martin and the team.


It your concern is only related to the best way to inform the 
users about a broad and disruptive change in vibe-d, I suggest to 
simply use the usual channels for that, change logs and announce 
forum.


My impression is that there's a lot of value in using patch for 
patch, instead of using patch for development, also in a zero 
major, so I maybe you should consider that change, or at least, 
investigate a little about that opportunity.


/Paolo

Re: mysql-native v2.1.0

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

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


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




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

Re: mysql-native v2.1.0

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

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

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


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


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


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

Re: mysql-native v2.1.0

[Sönke Ludwig via Digitalmars-d-announce]

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

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: Release D 2.079.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 07.03.2018 um 10:17 schrieb Paolo Invernizzi:

On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:

On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:

On 3/6/18 2:30 PM, Martin Nowak wrote:

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:


But if needed, you could have your dub package depend on a prior 
version.


http://code.dlang.org/packages/stdx-allocator ;)



This is the answer, vibe.d should depend on stdx-allocator.

-Steve


Vibe.d (and a lot of other projects) do depend on this package, see e.g.

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

Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm 
and not released as the latest stable tag yet, which is the reason for 
Atila's justified complaint.


The point is just to persuade Sonke to do his development in the minor 
version and increase it during every vibe-d release, and keep the patch 
version for fast fixes of the latest released vibe-d when a new version 
of the compiler is being released.


The actual policy is just an ask for problems...

It's not a big deal to fix the breakage on the latest released vibe-d 
code, it's a fast process. But it's a problem in just coordinating the 
next release of vibe-d with the release of the compiler, if you need to 
do this, like in this case.


/Paolo



Well, for all of the recent releases we made sure that there was no 
breakage for new compiler versions. This release was an exception, 
because I didn't manage to put out the fixed release in time. The plan 
is to have all future releases go back to the normal mode where the new 
compiler version always works.


Since std.experimental isn't involved from now on, it shouldn't even be 
necessary anymore to put out new vibe.d releases for new DMD versions, 
because DMD/Phobos already checks for regressions against vibe.d and all 
breaking changes should simply result in a deprecation warning.


As for the versioning scheme, currently almost all new releases have 
some small breaking change or deprecation. If I'd use the "minor" 
version for that, then there would be no way to signal that a release 
makes broad and more disruptive changes, such as the 0.8.0 release. But 
all of this will change, as the remaining parts get pushed to separate 
repositories one-by-one, with their own version starting at 1.0.0.

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

[Martin Tschierschke via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 09:16:42 UTC, aberba wrote:
On Tuesday, 6 March 2018 at 10:15:30 UTC, Martin Tschierschke 
wrote:

[...]

[...]

[...]


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

OK, so, no useful hint from me

Re: mysql-native v2.1.0

[aberba via Digitalmars-d-announce]

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:
On Tuesday, 6 March 2018 at 04:31:42 UTC, Nick Sabalausky 
(Abscissa) 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".

Re: Release D 2.079.0

[Paolo Invernizzi via Digitalmars-d-announce]

On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:
On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer 
wrote:

On 3/6/18 2:30 PM, Martin Nowak wrote:
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven 
Schveighoffer wrote:


But if needed, you could have your dub package depend on a 
prior version.


http://code.dlang.org/packages/stdx-allocator ;)



This is the answer, vibe.d should depend on stdx-allocator.

-Steve


Vibe.d (and a lot of other projects) do depend on this package, 
see e.g.


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

Also many packages already depend on vibe.d-0.8.3, but it's in 
rc1 atm and not released as the latest stable tag yet, which is 
the reason for Atila's justified complaint.


The point is just to persuade Sonke to do his development in the 
minor version and increase it during every vibe-d release, and 
keep the patch version for fast fixes of the latest released 
vibe-d when a new version of the compiler is being released.


The actual policy is just an ask for problems...

It's not a big deal to fix the breakage on the latest released 
vibe-d code, it's a fast process. But it's a problem in just 
coordinating the next release of vibe-d with the release of the 
compiler, if you need to do this, like in this case.


/Paolo

Re: Article: Why Const Sucks

[Simen Kjærås via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 17:41:42 UTC, H. S. Teoh wrote:
Yeah, Andrei has admitted before that this is probably what he 
would do today, if he were given a second chance to design 
ranges.  But at the time, the landscape of D was rather 
different, and certain language features didn't exist yet 
(sorry, can't recall exactly which off the top of my head), so 
he settled with the compromise that we have today.


As they say, hindsight is always 20/20.  But it wasn't so easy 
to foresee the consequences at the time when the very concept 
of ranges was still brand new.


Andrei's 'On Iteration'[0] was published 2009-11-09. Postblits 
had been in the language for about a year and a half[1], and 
@disable arrived early 2010[2]. Both features were probably too 
new to warrant being an integral part of the design of ranges.


--
  Simen

[0]: http://www.informit.com/articles/printerfriendly/1407357
[1]: https://dlang.org/changelog/2.012.html
[2]: https://dlang.org/changelog/2.040.html