Re: D for microservices

[Jacob Carlborg via Digitalmars-d]

On Thursday, 8 March 2018 at 07:20:53 UTC, Radu wrote:

This guys says that vide.d works 
https://forum.dlang.org/thread/gikoeutmdyvolfshp...@forum.dlang.org


Yes, it's pretty straightforward:

1. Build on Ubuntu, or some other dist
2. Statically link the whole binary with LDC, then you don't need 
to use Musl

3. Run it on Alpine

--
/Jacob Carlborg

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: D for microservices

[Radu via Digitalmars-d]

On Thursday, 8 March 2018 at 06:49:07 UTC, Andrew Benton wrote:

On Monday, 5 March 2018 at 17:58:25 UTC, Joakim wrote:

[...]


I took a shot at dockerizing dub-registry with the alpine build 
using multistage builds.  I got ldc installed and dub built.  
Unfortunately when I tried to build dub-registry, I found that 
vibe-d's vibe-core, libevent, and libasync configurations can't 
run under musl due to some of the networking dependencies in 
druntime core, e.g. `core.sys.linux.netinet.in_`.


I realize that's something that you can't really prevent as the 
packager, but it's still relevant to the status of D for 
microservices.


Bad news: not being able to build vibe.d is a pretty big hit 
for this objective.
Good news: there are other libraries we can try and we know how 
to fix this problem.


This guys says that vide.d works 
https://forum.dlang.org/thread/gikoeutmdyvolfshp...@forum.dlang.org

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: D for microservices

[Andrew Benton via Digitalmars-d]

On Monday, 5 March 2018 at 17:58:25 UTC, Joakim wrote:

On Monday, 5 March 2018 at 14:34:44 UTC, aberba wrote:

[snip]


The Alpine build is up, let me know if you have any problems.  
Note the changelog entry that says you'll need to install llvm 
and maybe other packages from the Alpine package manager first.


I took a shot at dockerizing dub-registry with the alpine build 
using multistage builds.  I got ldc installed and dub built.  
Unfortunately when I tried to build dub-registry, I found that 
vibe-d's vibe-core, libevent, and libasync configurations can't 
run under musl due to some of the networking dependencies in 
druntime core, e.g. `core.sys.linux.netinet.in_`.


I realize that's something that you can't really prevent as the 
packager, but it's still relevant to the status of D for 
microservices.


Bad news: not being able to build vibe.d is a pretty big hit for 
this objective.
Good news: there are other libraries we can try and we know how 
to fix this problem.

[Issue 18573] std.algorithm each does not function correctly for assignment under x86

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18573

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com

--

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!

Re: Can't "is null" an interface?!?! Incompatible types???

[Nicholas Wilson via Digitalmars-d-learn]

On Thursday, 8 March 2018 at 04:48:08 UTC, Nick Sabalausky 
(Abscissa) wrote:

-
import vibe.core.net;
TCPConnection mySocket;

void main() {
auto b = mySocket is null;
}
-

That's giving me:

-
Error: incompatible types for (mySocket) is (null): 
TCPConnection and typeof(null)

-

WTF?!?!

The type in question (vibe.core.net.TCPConnection) is an 
interface:

http://vibed.org/api/vibe.core.net/TCPConnection
https://github.com/vibe-d/vibe.d/blob/master/core/vibe/core/net.d#L344

The following works just fine:
-
interface IFoo {}

void main() {
IFoo i;
auto b = i is null;
}
-


That does seem odd.
---
/+dub.sdl:
dependency "vibe-d" version="~>0.8.3-alpha.1"
+/
import vibe.core.net;
import std.stdio;
TCPConnection mySocket;

void main() {
auto b = mySocket is null;
writeln(b);
}
---
works fine on run.dlang.io

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.

Re: docs/definition: !object

[ketmar via Digitalmars-d-learn]

Nick Sabalausky (Abscissa) wrote:

(Or does  return the address of the *reference* to the object 
rather than the address of the object?...You can see just how often I do 
OO in D ;) )


exactly. if you want to convert object to a pointer safely, do this:

MyObject o;
void* p = *cast(void**)

this magic construct guarantees that you won't hit `opCast()` in 
`MyObject` (yes, somebody *can* write weird `opCast` for `void*`! ;-).


doing just `` gives you the address of a variable (on a stack, or in a 
tls), which is, obviously, never `null`. ;-)

Re: docs/definition: !object

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

On 03/08/2018 12:05 AM, ketmar wrote:

Nick Sabalausky (Abscissa) wrote:

I'm having trouble finding the documentation for what exactly the 
unary "not" operator does when applied to a class/interface object. 
Does this documentation exist somewhere?


I know at least part of it involves "is null", but I seem to remember 
hearing there was more to it than just that.


https://dlang.org/spec/operatoroverloading.html#boolean_operators

"Class references are converted to bool by checking to see if the class 
reference is null or not."


Ah, thanks.

But are we CERTAIN that's all there is to it? I have a non-reduced 
situation right now where outputting the address of a class reveals a 
non-null address, and yet assert(!!theObjectInQuestion) is failing. 
(this is occurring during stack unwinding, if that makes a difference)


(Or does  return the address of the *reference* to the object 
rather than the address of the object?...You can see just how often I do 
OO in D ;) )

[Issue 18579] New: No group separators for floating point number formatted with zero decimal digits

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18579

  Issue ID: 18579
   Summary: No group separators for floating point number
formatted with zero decimal digits
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: lluce...@gmail.com

Format string "%,3.0f" used with a non-decimal double (e.g. 16887662) does not
group the output digits with a group separator (,). The same applies for
floating point numbers with decimal part formatted with zero decimal precision.
The expected formatting: e.g. 16,887,662.

--

Re: docs/definition: !object

[ketmar via Digitalmars-d-learn]

Nick Sabalausky (Abscissa) wrote:

I'm having trouble finding the documentation for what exactly the unary 
"not" operator does when applied to a class/interface object. Does this 
documentation exist somewhere?


I know at least part of it involves "is null", but I seem to remember 
hearing there was more to it than just that.


https://dlang.org/spec/operatoroverloading.html#boolean_operators

"Class references are converted to bool by checking to see if the class reference is 
null or not."

[Issue 18578] New: First enum value assigned 0 instead of EnumBaseType.init

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18578

  Issue ID: 18578
   Summary: First enum value assigned 0 instead of
EnumBaseType.init
   Product: D
   Version: D2
  Hardware: All
   URL: https://dlang.org/spec/enum.html
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

The following example does not compile:

enum Foo { foo1 }
enum Bar : Foo { bar1 }

It fails with the message:

Error: cannot implicitly convert expression 0 of type int to Foo

We can fix it by changing the definition of Bar to this:

enum Bar : Foo { bar1 = Foo.init }

However, the spec (https://dlang.org/spec/enum.html) indicates that the value
of `bar` should already have been `Foo.init`. 

> 6. The value of an EnumMember is given by its AssignExpression. If there is 
> no AssignExpression and it is the first EnumMember, its value is 
> EnumBaseType.init.

It looks like the implementation is assigning the value `0` to the first enum
value instead of EnumBaseType.init.  Either the spec is wrong or this is a bug.

--

Re: VsCode tutorial

[Mike Franklin via Digitalmars-d-learn]

On Wednesday, 7 March 2018 at 21:39:09 UTC, Apocalypto wrote:

Are there any tutorials about D in vscode?


No that I know of.

Which are the minimal plugins to install to have code 
completion, syntax highlighting and code formatting?


I've been getting by with 
https://marketplace.visualstudio.com/items?itemName=webfreak.code-d-beta


Are there any app templates that i can invoke to not start 
every project from scratch?


See the usage of `dub init` here: 
https://code.dlang.org/getting_started



How can I debug my app?


See 
https://marketplace.visualstudio.com/items?itemName=webfreak.debug


Mike

docs/definition: !object

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

I'm having trouble finding the documentation for what exactly the unary 
"not" operator does when applied to a class/interface object. Does this 
documentation exist somewhere?


I know at least part of it involves "is null", but I seem to remember 
hearing there was more to it than just that.

Can't "is null" an interface?!?! Incompatible types???

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

-
import vibe.core.net;
TCPConnection mySocket;

void main() {
auto b = mySocket is null;
}
-

That's giving me:

-
Error: incompatible types for (mySocket) is (null): TCPConnection and 
typeof(null)

-

WTF?!?!

The type in question (vibe.core.net.TCPConnection) is an interface:
http://vibed.org/api/vibe.core.net/TCPConnection
https://github.com/vibe-d/vibe.d/blob/master/core/vibe/core/net.d#L344

The following works just fine:
-
interface IFoo {}

void main() {
IFoo i;
auto b = i is null;
}
-

Re: Vtable for virtual functions in D

[Mike Franklin via Digitalmars-d]

On Wednesday, 7 March 2018 at 22:02:17 UTC, sarn wrote:

When I wrote Xanthe a year ago, I rolled my own classes using 
alias this and explicit vtables:

https://gitlab.com/sarneaud/xanthe/blob/master/src/game/rigid_body.d#L15
(I did this because normal D classes use the druntime library, 
and Xanthe was an experiment in not using the D runtime at all.)


Nice!  I was thinking about something almost exactly like this 
recently since 2.079.0 has features to further decouple the 
language from the runtime.  It would be nice to read a blog post 
about this technique.


Mike

[Issue 18221] DMD64 2.078.0 compile time explodes with -inline (>4X)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18221

Илья Ярошенко  changed:

   What|Removed |Added

   Keywords||performance

--

[Issue 18221] DMD64 2.078.0 compile time explodes with -inline (>4X)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18221

--- Comment #2 from Илья Ярошенко  ---
Mir Algorithm tests are a huge chunk of a super generic code. The same problem
exists for a ultra Phobos-idiomatic code based on std.range and std.algorithm.

--

[Issue 18221] DMD64 2.078.0 compile time explodes with -inline (>4X)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18221

Илья Ярошенко  changed:

   What|Removed |Added

Summary|DMD64 2.078.0 compile time  |DMD64 2.078.0 compile time
   |explodes with -inline for   |explodes with -inline (>4X)
   |mir-algorithm (>4X) |

--

Re: Fact check: when did D add static if?

[Meta via Digitalmars-d]

On Thursday, 8 March 2018 at 04:12:12 UTC, Adam D. Ruppe wrote:

On Thursday, 8 March 2018 at 04:09:17 UTC, Meta wrote:
Has D had static if since its inception, or was it added 
somewhere along the way?


https://digitalmars.com/d/1.0/changelog1.html

What's New for D 0.124
May 19, 2005
New/Changed Features
*snip*
Added static if.


That's before my time! But by looking at the changelog, static 
if was pretty weak early on and expanded over time.


Thanks Adam, that was exactly what I was looking for.

Re: Fact check: when did D add static if?

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 8 March 2018 at 04:09:17 UTC, Meta wrote:
Has D had static if since its inception, or was it added 
somewhere along the way?


https://digitalmars.com/d/1.0/changelog1.html

What's New for D 0.124
May 19, 2005
New/Changed Features
*snip*
Added static if.


That's before my time! But by looking at the changelog, static if 
was pretty weak early on and expanded over time.

Fact check: when did D add static if?

[Meta via Digitalmars-d]

Has D had static if since its inception, or was it added 
somewhere along the way?

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

[Issue 18577] New: Loose isForwardRange

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18577

  Issue ID: 18577
   Summary: Loose isForwardRange
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: yshu...@gmail.com

Loose isForwardRange to something like:

isInputRange!R && is(Unqual!(ReturnType!((R r) => r.save)) == Unqual!R)

I'm writing functions that takes a range and produce another range, with the
guarantee that the origin range is not changed. So I need save() to produce a
non-const range from a const one, which does not meet the current
isForwardRange criteria.

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17448

--- Comment #31 from Shachar Shemesh  ---
Here goes:

(In reply to Andrei Alexandrescu from comment #30)
> Indeed it seems we are not supporting registration by address with ease for
> D value types.

Make that: at all. I understand that there are cases where it is safe to do,
but I don't think we have a good guarantee about those cases. Without them, it
is simply impossible.

> That C++ ... still has a variety of safety,
> correctness, and efficiency issues (I am not exaggerating; all three
> problems are present)

In the interest of better understanding the trade-offs, can you please
elaborate? I'm asking because D's insistence on moving things around is one of
the language features I understand less. I don't see what the huge gains are,
and some of the actual compiler behaviors I've seen are downright
counter-productive. I've seen cases where the same object gets moved around so
much, and for no apparent good reason, that I seriously worry for the
performance bleed from this feature.

> (It should be noted that C++ has its own, distinct issues with
> self-registering objects, to which I dedicate several slides in
> http://erdani.com/index.php/training/mc1xd.)

Unless I've missed where in that link the actual slides are, not helping.

> 
> Allow me to make a few suggestions for workarounds:
> 
> * Avoid automatic/stack allocation and also return by value

This is a HUGE increase in the cost of allocating the struct. There are
efficient mechanisms for dynamic allocations (e.g. - maintaining a pool), but
they cost in other overheads (e.g. - predetermining the number of instances,
adding an initialization stage).

> As a perk, you avoid the
> creation, copying, and destruction of spurious objects - which comes along
> with calls to register/unregister, which I assume has a significant cost.

I don't think registering an object with a linked list is as big a cost as
dynamic allocation.

> * Use a "cookie", not an address, in the registration. A classic
> registration pattern returns a cookie/handle, usually an integer, which the
> object stores.

No, that's not correct. There is indeed a classic pattern where the registrar
returns a cookie, but it *stores* the pointer internally (or, in the Windows
way, obfuscates it into the handle). I don't think you can come up with a
scheme where the Linux kernel cannot translate an integer FD into a file
pointer without user-space's help.

Someone outside of the struct has to know the pointer, or the struct is
unlocatable without already knowing where it is. Needless to say, this would
defeat the purpose of registering it.

> If after exploring these and other solutions you come to the conclusion they
> are not satisfactory, I encourage you to create a DIP. Two possible lines of
> attack are:
> 
> (1) Allow specifying that an object can't be moved
> (2) Allow a type to intercept its move by means of a nothrow hook

(2) is what we've been asking for all along (e.g. - comment #15). Give us a way
to update the external reference when the address changes.

I'll try to phrase a DIP. It would be my first one, so help would be
appreciated.

--

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: #dbugfix: Unclear error message when trying to inherit from multiple classes

[Mike Parker via Digitalmars-d]

On Wednesday, 7 March 2018 at 22:23:59 UTC, Meta wrote:



https://issues.dlang.org/show_bug.cgi?id=18574


Noted!

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: why not use git rebase instead of git merge in dlang repos?

[timotheecour via Digitalmars-d]

On Wednesday, 7 March 2018 at 22:28:26 UTC, ketmar wrote:

H. S. Teoh wrote:

I've pestered Brad about it before, but the real trouble is 
the Mailman
software.  If you feel motivated enough, pestering the 
upstream Mailman
authors about it might actually get us closer to fixing this 
problem, as
it really isn't a problem on Brad's end either. It's not 
unfixable, it
just requires a change to the Mailman software to process 
headers

correctly.


yeah, that is what i meant when i wrote "current arch". ;-)


can we move this side-discussion to 
https://github.com/CyberShadow/DFeed/issues/99 (root cause of 
split threads?) => see my last post in particular which mentions 
'Changing the setting of anonymous_list to no has resulted in the 
correct

Message-Id'

Re: #dbugfix: Unclear error message when trying to inherit from multiple classes

[Nicholas Wilson via Digitalmars-d]

On Wednesday, 7 March 2018 at 22:23:59 UTC, Meta wrote:

class Test: Foo, Bar, Baz
{
}

class Foo {}
class Bar {}
class Baz {}

Error: class `Test` base type must be interface, not Bar
Error: class `Test` base type must be interface, not Baz

I thought this error message used to be a lot better; along the 
lines of "D does not support multiple inheritance. Use 
interfaces instead." It'd be nice if it was changed to be 
clearer about what the error is.


https://issues.dlang.org/show_bug.cgi?id=18574


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

[Issue 18221] DMD64 2.078.0 compile time explodes with -inline for mir-algorithm (>4X)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18221

Timothee Cour  changed:

   What|Removed |Added

Summary|DMD64 2.078.0 compile time  |DMD64 2.078.0 compile time
   |explodes with -inline for   |explodes with -inline for
   |mir-algorithm   |mir-algorithm (>4X)

--

[Issue 18221] DMD64 2.078.0 compile time explodes with -inline for mir-algorithm

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18221

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #1 from Timothee Cour  ---
ping.

from previous posts above the OP it seems it gets a factor 4X slower.

here's the OP to make it easier:
```
On Wednesday, 10 January 2018 at 21:32:55 UTC, Nathan S. wrote:
> On my mac laptop running DMD 2.078.0, building and running the mir-algorithm 
> unittests takes 8 seconds normally but takes ~3 minutes 49 seconds with dub 
> options "releaseMode", "optimize", "inline", "noBoundsCheck".

When I remove the "inline" option the build + test time becomes <10 seconds. So
the weirdly slow part is related to inlining.
```

and:

```
DMD 2.077.1 for linux32: 3 min 20 sec
DMD 2.077.1 for linux64: 3 min 16 sec
DMD 2.077.1 for mac64: 5 min 4 sec

DMD 2.078.0-rc.1 for linux32: 13 min 30 sec
DMD 2.078.0-rc.1 for linux64: 9 min 39 sec
DMD 2.078.0-rc.1 for mac64: 10 min 56 sec, then the job was aborted
```

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17448

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18576

--

[Issue 18576] Compiler not doing RVO with auto returns

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18576

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17448

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17448

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18575

--

[Issue 18575] making delegate from member function can lead to unsafe code

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18575

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17448

--

[Issue 18576] New: Compiler not doing RVO with auto returns

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18576

  Issue ID: 18576
   Summary: Compiler not doing RVO with auto returns
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

As reported by Tomer Filiba:

void delegate() callback;

struct S {
int x;
@disable this(this);

this(int x) {
this.x = x;
callback = 
}
void inc() {
x++;
}
}

auto f() {
return g();   // RVO not done
}
auto g() {
return h();  // RVO not done
}
auto h() {
return S(100);
}

void main() {
auto s = f();
writeln(, " ", callback.ptr);// 7FFF0C838400 7FFF0C8383A0
callback();
writeln(s.x);  // 100 instead of 101
}

--

[Issue 18573] std.algorithm each does not function correctly for assignment under x86

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18573

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--

[Issue 18575] making delegate from member function can lead to unsafe code

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18575

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe

--

[Issue 18575] New: making delegate from member function can lead to unsafe code

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18575

  Issue ID: 18575
   Summary: making delegate from member function can lead to
unsafe code
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

As reported by Tomer Filiba:

@safe:

struct S {
@safe:
int x;

auto foo() {return }
void bar() {x = 999;}
}

auto f() {
auto s = S(100);
return s.foo();
}

void main() {
auto dg = f();
dg(); // i now have a delegate that will write 999 to some random
stack location
}

--

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 

Re: why not use git rebase instead of git merge in dlang repos?

[ketmar via Digitalmars-d]

H. S. Teoh wrote:


I've pestered Brad about it before, but the real trouble is the Mailman
software.  If you feel motivated enough, pestering the upstream Mailman
authors about it might actually get us closer to fixing this problem, as
it really isn't a problem on Brad's end either. It's not unfixable, it
just requires a change to the Mailman software to process headers
correctly.


yeah, that is what i meant when i wrote "current arch". ;-)

#dbugfix: Unclear error message when trying to inherit from multiple classes

[Meta via Digitalmars-d]

class Test: Foo, Bar, Baz
{
}

class Foo {}
class Bar {}
class Baz {}

Error: class `Test` base type must be interface, not Bar
Error: class `Test` base type must be interface, not Baz

I thought this error message used to be a lot better; along the 
lines of "D does not support multiple inheritance. Use interfaces 
instead." It'd be nice if it was changed to be clearer about what 
the error is.


https://issues.dlang.org/show_bug.cgi?id=18574

Re: why not use git rebase instead of git merge in dlang repos?

[H. S. Teoh via Digitalmars-d]

On Thu, Mar 08, 2018 at 12:10:28AM +0200, ketmar via Digitalmars-d wrote:
> Seb wrote:
> 
> > OT: I don't know what you are doing, but you seem to be the only one
> > who always creates new threads when replying. I assume you use nntp?
> > Maybe something wrong with your client?
> 
> it was already discussed several times: this is the issue with mailing
> list processor: it cannot properly link replies. it is unfixable with
> the current nntp/mlist arch, though.

Yeah, the trouble is that I'm using the mailing list interface, and
Mailman, the software behind that, is munging my outgoing mail headers.
Nothing much I can do from my end, unfortunately.

I've pestered Brad about it before, but the real trouble is the Mailman
software.  If you feel motivated enough, pestering the upstream Mailman
authors about it might actually get us closer to fixing this problem, as
it really isn't a problem on Brad's end either. It's not unfixable, it
just requires a change to the Mailman software to process headers
correctly.


T

-- 
People demand freedom of speech to make up for the freedom of thought which 
they avoid. -- Soren Aabye Kierkegaard (1813-1855)

[Issue 18574] New: Unclear error message when trying to inherit from multiple classes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18574

  Issue ID: 18574
   Summary: Unclear error message when trying to inherit from
multiple classes
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: monkeywork...@hotmail.com

class Test: Foo, Bar, Baz
{
}

class Foo {}
class Bar {}
class Baz {}

Error: class `Test` base type must be interface, not Bar
Error: class `Test` base type must be interface, not Baz

I thought this error message used to be a lot better; along the lines of "D
does not support multiple inheritance. Use interfaces instead." It'd be nice if
it was changed to be clearer about what the error is.

--

Re: Vtable for virtual functions in D

[H. S. Teoh via Digitalmars-d]

On Wed, Mar 07, 2018 at 09:14:12PM +, Henrik via Digitalmars-d wrote:
[...]
> The direct support of C headers would be very convenient in migrating
> parts of C/C++ projects to D. It would also open up POSIX which is
> used extensively in our work.
[...]

There's already core.sys.posix.*, which are POSIX headers translated
into D, and which you can import and use right away. E.g.:

import core.sys.posix.unistd;
char[1024] buf;
int fd = open("/tmp/file", O_RDONLY);
auto len = read(fd, buf.ptr, buf.length);
...
close(fd);

Similarly, C standard library functions are directly available via
core.stdc.*:

import core.stdc.stdlib;
void* buf = malloc(1024);
... // use buf here
free(buf);

In principle, although direct support of C headers is not supported
(yet?), it's pretty easy to declare C functions in D and then just call
it directly, e.g.:

// Declare C function here
extern(C) size_t strlen(const(char)* s);

void main()
{
import std.string : toStringz;

// Call here
auto len = strlen("blah blah".toStringz);
}

In the above example I purposely used std.string to showcase how easy it
is to interoperate with C API functions, with toStringz and fromStringz
providing convenient conversions to/from C's char* strings.  The only
wrinkle here is that toStringz may allocate (because D strings are not
null-terminated in general), so cannot be used in @nogc code.

However, D string *literals* are always null-terminated, so the above
code could actually be replaced with just:

auto len = strlen("blah blah".ptr);

and it will work in @nogc as well. Just be careful not to do that with
non-literal strings (or append a null manually and then it should be
safe).

The trouble with general C headers is that sometimes complicated macros
are used, and D does not come with a C macro processor, so it is tricky
to interface with those kinds of headers.  Still, if your code is not
directly dependent on the macros, you could just run the header through
a C preprocessor and then translate the C prototypes into D.  (There are
some cases for which this may not be so straightforward, but generally
you should be able to get quite far this way.)


T

-- 
Caffeine underflow. Brain dumped.

Re: why not use git rebase instead of git merge in dlang repos?

[ketmar via Digitalmars-d]

Seb wrote:

OT: I don't know what you are doing, but you seem to be the only one who 
always creates new threads when replying. I assume you use nntp? Maybe 
something wrong with your client?


it was already discussed several times: this is the issue with mailing list 
processor: it cannot properly link replies. it is unfixable with the 
current nntp/mlist arch, though.

Re: issue with each specifically for x86

[ketmar via Digitalmars-d-learn]

Matt Gamble wrote:

Ok, this has been submitted as a bug. 
https://issues.dlang.org/show_bug.cgi?id=18573


thank you.

[Issue 18573] std.algorithm each does not function correctly for assignment under x86

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18573

Ketmar Dark  changed:

   What|Removed |Added

  Component|phobos  |dmd
   Hardware|x86 |All
 OS|Windows |All

--- Comment #2 from Ketmar Dark  ---
p.s.: as this bug affects x86_64 too (albeit only with `real`s), i changed arch
to all.

--

Re: Vtable for virtual functions in D

[sarn via Digitalmars-d]

On Wednesday, 7 March 2018 at 12:49:40 UTC, Guillaume Piolat 
wrote:
If you know enough D maybe you can implement your own virtual 
functions on top of D structs. It seems no one has made it yet.


When I wrote Xanthe a year ago, I rolled my own classes using 
alias this and explicit vtables:

https://gitlab.com/sarneaud/xanthe/blob/master/src/game/rigid_body.d#L15
(I did this because normal D classes use the druntime library, 
and Xanthe was an experiment in not using the D runtime at all.)


Henrik: you might be interested in this post I wrote about making 
that:

https://theartofmachinery.com/2017/02/28/bare_metal_d.html
NB: things are moving fast and some things have already improved 
since then.

[Issue 18573] std.algorithm each does not function correctly for assignment under x86

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18573

--- Comment #1 from Ketmar Dark  ---
some clarification: basically, this boils down to codegen bug: if we have
function that returns some floating point value, and FPU is involved, and
caller does `cast(void)myfunc()`, result is not popped from FPU stack.

note that `cast(void)` is vital here: everything is ok without it. also, as
X86_64 doesn't use FPU for floats and doubled, you need to use `real` there to
trigger the bug.

minified sample by ag0aep6g:

double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();

double b = 2;
assert(b == 2); /* fails; should pass */
}

--

[Issue 18573] std.algorithm each does not function correctly for assignment under x86

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18573

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: why not use git rebase instead of git merge in dlang repos?

[Seb via Digitalmars-d]

On Wednesday, 7 March 2018 at 21:03:52 UTC, H. S. Teoh wrote:
On Wed, Mar 07, 2018 at 12:42:52PM -0800, Timothee Cour via 
Digitalmars-d wrote:

[...]


On the contrary, I find using merge is easier to understand, 
because it shows clearly individual commits within a single PR, 
and also a linear series of merged PRs if you traverse down 
master.  In fact, in my own projects I sometimes purposely use 
`git merge --no-ff` to force a merge commit, because it shows 
distinct lines of development more clearly.


But I suppose this is one of the things reasonable people will 
disagree on.



T


OT: I don't know what you are doing, but you seem to be the only 
one who always creates new threads when replying. I assume you 
use nntp? Maybe something wrong with your client?

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.

Re: issue with each specifically for x86

[Matt Gamble via Digitalmars-d-learn]

On Wednesday, 7 March 2018 at 21:39:58 UTC, ketmar wrote:

Matt Gamble wrote:


On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:

On 03/07/2018 09:09 PM, ag0aep6g wrote:

[...]


With `real` instead of `double` x86_64 is also affected.


Wow. Good to know I'm not crazy. I was afk for a bit, sorry. I 
guess I'm glad I found it and posted. The conversation has 
gone beyond my realm of understanding. Has anyone tested on 
2.079 like Ali wanted. I have not had a chance to install. I 
was going to wait to post the bug till that was tried.


sure, it is still there in git HEAD. it is not the bug that can 
be fixed "accidentally". %-)


Ok, this has been submitted as a bug. 
https://issues.dlang.org/show_bug.cgi?id=18573
Thanks for the quick responses. Don't know what I'd do with out 
the community.

[Issue 18573] std.algorithm each does not function correctly for assignment under x86

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18573

Matthew Gamble  changed:

   What|Removed |Added

   Severity|enhancement |normal

--

[Issue 18573] New: std.algorithm each does not function correctly for assignment under x86

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18573

  Issue ID: 18573
   Summary: std.algorithm each does not function correctly for
assignment under x86
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: gambl...@gmail.com

Seems to be a problem with using "each" under 32bit which can be fixed by using
foreach or switching to x64. 

Let to a long discussion on the learn forum that went past my pay grade:
https://forum.dlang.org/post/hjqqqmlhkjrqaisbh...@forum.dlang.org

Below is a silly case, that replicates the error. (i.e. I know I could use
iota(0,9,2).array), but that does not demonstrate the potential bug and would
not fix my actual program.)

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

unittest
{
auto a = new double[9];
a[0] = 0;
iota(1,a.length).each!(i => a[i] = a[i-1] + 2);
writeln(a);
}

//x86, wrong, error
//[-nan, 2, 4, 6, 8, 10, 12, 14, 16]
//First-chance exception: std.format.FormatException Unterminated format
specifier: "%" at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(1175)

//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]

unittest
{
auto a = new double[9];
a[0] = 0;
foreach(i; 1..a.length) a[i] = a[i - 1] + 2;
writeln(a);
}

//x86, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]

//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]

Originally found on windows 10, DMD v2.076.1, but now confirmed by others on
linux and current version.

--

Re: issue with each specifically for x86

[ketmar via Digitalmars-d-learn]

Matt Gamble wrote:


On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:

On 03/07/2018 09:09 PM, ag0aep6g wrote:


double f() { return 1; }
void main()
{
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
    double b = 2;
     assert(b == 2); /* fails; should pass */
}



With `real` instead of `double` x86_64 is also affected.


Wow. Good to know I'm not crazy. I was afk for a bit, sorry. I guess I'm 
glad I found it and posted. The conversation has gone beyond my realm of 
understanding. Has anyone tested on 2.079 like Ali wanted. I have not had 
a chance to install. I was going to wait to post the bug till that was 
tried.


sure, it is still there in git HEAD. it is not the bug that can be fixed 
"accidentally". %-)

VsCode tutorial

[Apocalypto via Digitalmars-d-learn]

Are there any tutorials about D in vscode?

Which are the minimal plugins to install to have code completion, 
syntax highlighting and code formatting?


Are there any app templates that i can invoke to not start every 
project from scratch?

How can I debug my app?

Re: issue with each specifically for x86

[Matt Gamble via Digitalmars-d-learn]

On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:

On 03/07/2018 09:09 PM, ag0aep6g wrote:


double f() { return 1; }

void main()
{
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();

     double b = 2;
     assert(b == 2); /* fails; should pass */
}



With `real` instead of `double` x86_64 is also affected.


Wow. Good to know I'm not crazy. I was afk for a bit, sorry. I 
guess I'm glad I found it and posted. The conversation has gone 
beyond my realm of understanding. Has anyone tested on 2.079 like 
Ali wanted. I have not had a chance to install. I was going to 
wait to post the bug till that was tried.

Re: Advent of D

[Russel Winder via Digitalmars-d]

On Tue, 2018-03-06 at 18:09 +, Jordi Gutiérrez Hermoso via
Digitalmars-d wrote:
> I wrote a blog post about working on Advent of Code in D. You can 
> read it here:
> 
> http://jordi.inversethought.com/blog/advent-of-d/

Another blog post deserving of formal publication in an ACCU journal.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: Vtable for virtual functions in D

[Henrik via Digitalmars-d]

Hi everyone,

thank you all for your great answers. I'm playing around with 
@nogc right now, and it looks really promising. Strings and 
static arrays all seem to be located on the stack, which is so 
much better compared to std::string and std::vector in C++. The 
double indirection for virtual functions bother me, and it isn't 
getting better with all methods being virtual by default - I 
guess I'll be writing the keyword "final" very intensively in all 
my programs. I would also gladly pay some bytes in pointer bloat 
to have my virtual functions speed up. Strange that D kept the 
vtable approach when breaking with C++.


I know that D concentrated much on C++ compatibility a while ago. 
Are there any plans to support the direct inclusion on C header 
files? Many important libraries like ICU have C interfaces even 
when written in C++. The direct support of C headers would be 
very convenient in migrating parts of C/C++ projects to D. It 
would also open up POSIX which is used extensively in our work.


This looks great:
https://github.com/D-Programming-Deimos/
but it must be tedious to keep such files up to date.

Despite the point where I'm complaining, I must say that D looks 
very impressive. Beautiful syntax, large standard library, and 
standardized inline assembler (Thank you!). I'll definitely try 
to find a suitable project to try out D under serious conditions.

Re: issue with each specifically for x86

[ketmar via Digitalmars-d-learn]

ag0aep6g wrote:


On 03/07/2018 09:09 PM, ag0aep6g wrote:


double f() { return 1; }
void main()
{
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
    double b = 2;
     assert(b == 2); /* fails; should pass */
}



With `real` instead of `double` x86_64 is also affected.


yeah. that is 'cause SSE cannot do math with 80-bit floats, and compiler 
falls back to FPU in this case.

Re: issue with each specifically for x86

[ag0aep6g via Digitalmars-d-learn]

On 03/07/2018 09:09 PM, ag0aep6g wrote:


double f() { return 1; }

void main()
{
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();

     double b = 2;
     assert(b == 2); /* fails; should pass */
}



With `real` instead of `double` x86_64 is also affected.

Re: why not use git rebase instead of git merge in dlang repos?

[H. S. Teoh via Digitalmars-d]

On Wed, Mar 07, 2018 at 12:42:52PM -0800, Timothee Cour via Digitalmars-d wrote:
> There are lots of articles on this topic, eg:
> https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/
> (note that squashing down to 1 commit shouldn't be necessary but at
> least rebasing should be done)
> 
> github UI also allows to rebase (instead of merge)
> 
> would really simplify things like visualization / understanding
> history, git bisect. It shouldn't matter at what commit was a feature
> started, only thing that matter should be when it was incorporated
> into master.

On the contrary, I find using merge is easier to understand, because it
shows clearly individual commits within a single PR, and also a linear
series of merged PRs if you traverse down master.  In fact, in my own
projects I sometimes purposely use `git merge --no-ff` to force a merge
commit, because it shows distinct lines of development more clearly.

But I suppose this is one of the things reasonable people will disagree
on.


T

-- 
Customer support: the art of getting your clients to pay for your own 
incompetence.

Re: issue with each specifically for x86

[ketmar via Digitalmars-d-learn]

H. S. Teoh wrote:

On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn 
wrote:

[...]

it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it doesn't matter, 'cause no FPU is used there.
the fix prolly should be easy: just emit "FPU pop" if function result
is ignored. codegen should have this info at hand, i believe.


Nice catch!  Is there a bug filed for this yet?  If not, it should be.


btw, this is specific to `cast(void)`. if you'll remove the cast, or do 
something like `cast(void)(pred(i)+42);`, the bug won't be there. so it 
looks like it is not a codegen bug after all, but glue layer. the codegen 
is correctly dropping the result without `cast(void)` (`fstp   %st(0)` is 
inserted in `main`), but cannot do that if return type information is stripped.


so it looks that glue layer should not strip return type info.

[Issue 18161] std.algorithm.iteration.chunkBy should be usable in @safe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18161

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Jack Stouffer  ---
This is due to chunkBy using RefCounted for its origin range, which I can't see
any good reason to do.

--

Re: issue with each specifically for x86

[ketmar via Digitalmars-d-learn]

H. S. Teoh wrote:

On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn 
wrote:

[...]

it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it doesn't matter, 'cause no FPU is used there.
the fix prolly should be easy: just emit "FPU pop" if function result
is ignored. codegen should have this info at hand, i believe.


Nice catch!  Is there a bug filed for this yet?  If not, it should be.


it seems that no bug is filled yet. feel free to do so. ;-) or maybe OP 
should better do it, dunno. definitely not me. ;-)

why not use git rebase instead of git merge in dlang repos?

[Timothee Cour via Digitalmars-d]

There are lots of articles on this topic, eg:
https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/
(note that squashing down to 1 commit shouldn't be necessary but at
least rebasing should be done)

github UI also allows to rebase (instead of merge)

would really simplify things like visualization / understanding
history, git bisect. It shouldn't matter at what commit was a feature
started, only thing that matter should be when it was incorporated
into master.

Re: issue with each specifically for x86

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

On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn wrote:
[...]
> it looks like ignoring `double` result causes FPU stack imbalance
> ('cause compiler doesn't insert "FPU pop" instruction), and that
> affects the computations.
> 
> on 64 bit it doesn't matter, 'cause no FPU is used there.
> 
> the fix prolly should be easy: just emit "FPU pop" if function result
> is ignored. codegen should have this info at hand, i believe.

Nice catch!  Is there a bug filed for this yet?  If not, it should be.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs

Re: Two things I thought would be simple

[Timon Gehr via Digitalmars-d]

On 07.03.2018 18:23, Jonathan M Davis wrote:

However, even doing something like

auto func2(Parameters!func args = AliasSeq!(1, 2, 3))
{
  return func(args);
}

doesn't work properly. If that version of the function is used, then the
call which passes all three arguments compiles, but the others don't, which
means that it's acting like the AliasSeq isn't even there (though it's
clearly doing_something_  with it, since you get a compilation error if one
of its values is void). I'd argue that either the values in the AliasSeq
should be being assigned, or they shouldn't be legal. Having them be there
but ignored just plain seems like a bug, but I have no idea what the
compiler is thinking here.


https://issues.dlang.org/show_bug.cgi?id=18572

[Issue 18572] New: AliasSeq default arguments are broken

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18572

  Issue ID: 18572
   Summary: AliasSeq default arguments are broken
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

DMD 2.079.0:

alias Seq(T...)=T;
void func(Seq!(int,int,int) args=Seq!(1,2,3)){ // ok
}
void main(){
Seq!(int,int,int) args=Seq!(1,2,3); // ok
func(); // error
func(args); // ok
}

The code should compile.

--

Re: issue with each specifically for x86

[ketmar via Digitalmars-d-learn]

Steven Schveighoffer wrote:

it seems that the only difference between `void` and `double` lambda is one 
asm instruction: `fldl   (%edi)`. it is presend in `double` labmda, and 
absent in `void` lambda.


it looks like ignoring `double` result causes FPU stack imbalance ('cause 
compiler doesn't insert "FPU pop" instruction), and that affects the computations.


on 64 bit it doesn't matter, 'cause no FPU is used there.

the fix prolly should be easy: just emit "FPU pop" if function result is 
ignored. codegen should have this info at hand, i believe.

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: issue with each specifically for x86

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/7/18 3:09 PM, ag0aep6g wrote:

On 03/07/2018 08:54 PM, Steven Schveighoffer wrote:

Clearly there is some codegen issue here.


It's beautiful:


double f() { return 1; }

void main()
{
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();
     cast(void) f();

     double b = 2;
     assert(b == 2); /* fails; should pass */
}



Are all those calls required? That's one crazy bug.

-Steve

Re: How can I get notified when an process created by spawnShell() has exit?

[Basile B. via Digitalmars-d-learn]

On Wednesday, 7 March 2018 at 15:03:28 UTC, Marc wrote:
I do need to start (up to 4 a time) processes in parallel but 
I'd like to get notified (similar to C#'s Process.Exited Event) 
when the process exits. How can I do that in D?


You can use pipeShell and a control loop to check when the 
ProcessPipes it returns is done.


example:

```d
void main()
{
import std.stdio, std.process, std.conv, std.random, 
core.thread,

std.algorithm, std.range;

ProcessPipes[4] pp;
iota(0,4).each!(a => pp[a] = pipeShell("sleep " ~ 
uniform(1,20).to!string));

while (pp[].any!(a => !tryWait(a.pid).terminated))
Thread.sleep(dur!"msecs"(50));

writeln("done");
}
```

You can wrap in a struct to hide the ugly bits.

Re: issue with each specifically for x86

[ag0aep6g via Digitalmars-d-learn]

On 03/07/2018 08:54 PM, Steven Schveighoffer wrote:

Looking at each, it looks like it does this:

cast(void) unaryFun!pred(r.front);

So I tried this:

auto pred = i => a[i] = a[i-1] + 2;
foreach(i; 1 .. a.length)
    cast(void)pred(i);

And I see the -nan value. Remove the cast(void) and I don't see it.

Clearly there is some codegen issue here.


It's beautiful:


double f() { return 1; }

void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();

double b = 2;
assert(b == 2); /* fails; should pass */
}

Re: issue with each specifically for x86

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/7/18 1:57 PM, Matt Gamble wrote:
This is a record for me with two 32bit vs 64bit issues in one day. Seems 
to be a problem with using "each" under 32bit which can be fixed by 
using foreach or switching to x64. Am I doing something wrong or is this 
the second bug I've found today?


Below is a silly case, that replicates an error. (i.e. I know I could 
use iota(0,9,2).array), but that does not demonstrate the potential bug 
and would not fix my actual program.)


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

unittest
{
 auto a = new double[9];
 a[0] = 0;
 iota(1,a.length).each!(i => a[i] = a[i-1] + 2);
 writeln(a);
}

//x86, wrong, error
//[-nan, 2, 4, 6, 8, 10, 12, 14, 16]
//First-chance exception: std.format.FormatException Unterminated format 
specifier: "%" at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(1175)


//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]

unittest
{
 auto a = new double[9];
 a[0] = 0;
 foreach(i; 1..a.length) a[i] = a[i - 1] + 2;
 writeln(a);
}

//x86, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]

//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]

This is windows 10, DMD v2.076.1



It has something to do with the fact that you are returning the value:

iota(1, a.length).each!((i) {a[i] = a[i - 1] + 2;}); // ok
iota(1, a.length).each!((i) {return a[i] = a[i - 1] + 2;}); // shows error


Which is odd to say the least, I don't think each is supposed to do 
anything with the return value.


I don't get the exception BTW (2.078.1 Windows 10).

Looking at each, it looks like it does this:

cast(void) unaryFun!pred(r.front);

So I tried this:

auto pred = i => a[i] = a[i-1] + 2;
foreach(i; 1 .. a.length)
   cast(void)pred(i);

And I see the -nan value. Remove the cast(void) and I don't see it.

Clearly there is some codegen issue here.

-Steve

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?

[Issue 9297] Formatting of floating point values in std.format truncates reals to double

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=9297

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||gambl...@gmail.com

--- Comment #3 from Steven Schveighoffer  ---
*** Issue 18570 has been marked as a duplicate of this issue. ***

--

[Issue 18570] exp function does not work correctly for real in 64bit Windows

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18570

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Steven Schveighoffer  ---
Thanks, seems like this is a duplicate then.

*** This issue has been marked as a duplicate of issue 9297 ***

--

Re: issue with each specifically for x86

[Ali Çehreli via Digitalmars-d-learn]

On 03/07/2018 10:57 AM, Matt Gamble wrote:
This is a record for me with two 32bit vs 64bit issues in one day. Seems 
to be a problem with using "each" under 32bit which can be fixed by 
using foreach or switching to x64. Am I doing something wrong or is this 
the second bug I've found today?


Below is a silly case, that replicates an error. (i.e. I know I could 
use iota(0,9,2).array), but that does not demonstrate the potential bug 
and would not fix my actual program.)


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

unittest
{
 auto a = new double[9];
 a[0] = 0;
 iota(1,a.length).each!(i => a[i] = a[i-1] + 2);
 writeln(a);
}

//x86, wrong, error
//[-nan, 2, 4, 6, 8, 10, 12, 14, 16]
//First-chance exception: std.format.FormatException Unterminated format 
specifier: "%" at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(1175)


//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]

unittest
{
 auto a = new double[9];
 a[0] = 0;
 foreach(i; 1..a.length) a[i] = a[i - 1] + 2;
 writeln(a);
}

//x86, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]

//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]

This is windows 10, DMD v2.076.1



Confirmed on Linux with dmd 2.078.1

It's somehow related to the unused return value of the lambda. The 
following code has the same error:


iota(1,a.length).each!((i) {
a[i] = a[i-1] + 2;
return a[i];
});

The error disappears when that return statement is commented-out.

Please file a dmd bug after making sure that 2.079 still has it. (Too 
lazy to install right now.)


An ldc that I have handy does not have this bug:

  based on DMD v2.073.2 and LLVM 4.0.0

Ali