Re: DLL loading behaviors and pragma(lib)

[rikki cattermole via Digitalmars-d-learn]

On 11/08/2017 12:18 AM, David Zhang wrote:
I've been working on getting OpenGL to load on windows without a 
library, and encountered something curious;


Context creation fails when I try to use the function pointer retrieved 
through GetProcAddress, but works just fine with the statically linked 
version provided through core.sys.windows.wingdi.d.


This may be a stupid question, but why is this?

Thanks.


Odd.

Just to confirm your wglGetProcAddress, is extern(Windows/System)?
And it is non-null after being loaded?

Re: Bug in D?!

[ketmar via Digitalmars-d-learn]

Mr. Pib wrote:


string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}


mixin(Q!(`x`, 100)());

outputs, at compile time,

x
100
x = d;

there is no lowercase d. I did initially define Q as

string Q(alias T, D)(D d)

and one might think it is remnants left over from I cleaned the project 
so it shouldn't be happening. Seems like a bug.


(I realized that I'd probably only ever pass compile time values)

Of course, using D.stringof gives the value.

The problem is the case of D.


nope. the problem is the *value* of D. `char(100)` == 'd'.

string s = "<"~100~">";

yes, this works. weither this bug or not is questionable, but this is how D 
works regerding to implicit type conversions: small ints (in the range of 
[0..char.max]) will be implicitly converted to `char` if necessary.

Bug in D?!

[Mr. Pib via Digitalmars-d-learn]

string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}


mixin(Q!(`x`, 100)());

outputs, at compile time,

x
100
x = d;

there is no lowercase d. I did initially define Q as

string Q(alias T, D)(D d)

and one might think it is remnants left over from I cleaned the 
project so it shouldn't be happening. Seems like a bug.


(I realized that I'd probably only ever pass compile time values)

Of course, using D.stringof gives the value.

The problem is the case of D.

Re: GTKD resources

[Mr. Pib via Digitalmars-d-learn]

On Friday, 11 August 2017 at 02:27:21 UTC, captaindet wrote:

On 2017-08-11 13:00, Mr. Pib wrote:
How can one include external files such as glade, icons, 
images that are
static in nature in to the binary but not require extraction 
on program

run to be used?

gtk's builder doesn't seem to take an in memory representation 
of glade
files and building a pixbuf seems quite over the top to do 
such simple

things?



including the glade UI/XML defs to the executable is simple, 
compile with -J. switch and:



immutable string UIdefs = import("myuidefs.glade");
...
main(){
...
builder.addFromString( UIdefs );
...


Thanks. It one can use pixbuf to do something similar, albeit 
more complicated.


https://stackoverflow.com/questions/14121166/gdk-pixbuf-load-image-from-memory

Re: Jetbrains announce support for rust plugin, show them we want one too!

[Dmitry via Digitalmars-d]

On Thursday, 10 August 2017 at 19:44:35 UTC, 12345swordy wrote:

On Thursday, 10 August 2017 at 05:55:59 UTC, Dmitry wrote:

On Wednesday, 9 August 2017 at 20:29:07 UTC, 12345swordy wrote:
You edit the json file of course. That how DUB generates 
solution files for visual D and other IDE's.


This breaks changes that was done in the VS project.


What changes are talking about? You typically make changes in 
the json file.


https://forum.dlang.org/thread/olfrkycsfukvipeoh...@forum.dlang.org

Re: GTKD resources

[captaindet via Digitalmars-d-learn]

On 2017-08-11 13:00, Mr. Pib wrote:

How can one include external files such as glade, icons, images that are
static in nature in to the binary but not require extraction on program
run to be used?

gtk's builder doesn't seem to take an in memory representation of glade
files and building a pixbuf seems quite over the top to do such simple
things?



including the glade UI/XML defs to the executable is simple, compile 
with -J. switch and:



immutable string UIdefs = import("myuidefs.glade");
...
main(){
...
builder.addFromString( UIdefs );
...

Re: DlangUI Error

[Mike Parker via Digitalmars-d-learn]

On Thursday, 10 August 2017 at 23:38:42 UTC, Jiyan wrote:



So the strange thing is i had an older compiler (v2.074.1), so
i started running the 2.075 version - with which it worked!
The thing is i can start the 2.075 version only over the 
activate.sh
script in a shell. Can you tell me how i can really use the 
2.075 version
(without having to run the script each time i open a shell, and 
why do

i have to do that).


Sounds like you used the script from the download page that 
installs the compiler per user. It's designed to allow you to 
have multiple versions installed in your user directory and 
requires you to specify which version you want to activate. You 
could probably configure your bash shell to activate dmd when you 
launch it, or you could install dmd via the .deb or .rpm, 
assuming you're on a Linux flavor.

Re: Beta D 2.075.1

[Walter Bright via Digitalmars-d-announce]

On 8/10/2017 6:03 PM, Vladimir Panteleev wrote:

On Thursday, 10 August 2017 at 20:15:12 UTC, Walter Bright wrote:
It could use all of the runtime library functions added to the index, instead 
of just a smattering.


This should be the case as of a few years. Is there anything missing 
specifically that you can point out?




No. Guess I haven't been keeping up!

Re: Beta D 2.075.1

[Vladimir Panteleev via Digitalmars-d-announce]

On Thursday, 10 August 2017 at 20:15:12 UTC, Walter Bright wrote:
It could use all of the runtime library functions added to the 
index, instead of just a smattering.


This should be the case as of a few years. Is there anything 
missing specifically that you can point out?

GTKD resources

[Mr. Pib via Digitalmars-d-learn]

How can one include external files such as glade, icons, images 
that are static in nature in to the binary but not require 
extraction on program run to be used?


gtk's builder doesn't seem to take an in memory representation of 
glade files and building a pixbuf seems quite over the top to do 
such simple things?

Re: DlangUI Error

[HyperParrow via Digitalmars-d-learn]

On Thursday, 10 August 2017 at 23:38:42 UTC, Jiyan wrote:

On Thursday, 10 August 2017 at 22:27:44 UTC, HyperParrow wrote:

On Thursday, 10 August 2017 at 20:48:23 UTC, Jiyan wrote:

Hey,
i get the following errors when i try to use dlangui, by just 
importing the package i get a lot of errors which look like:
function std.xml.Item.opEquals does not override any 
function, did you mean to override 'object.Object.opEquals'?


What is happening there?


The error message is correct but the error is only recognized 
by the compiler since the latest release. To fix it requires 
intervention of the author: either "override" must be removed 
from the opEquals that's indicated or the opEquals parameters 
must be changed o match exactly the signature used on 
Object.opEquals.


Until this is done in libdlangui you can use an older 
compiler, e.g last 2.074.x release should make the error 
disappearing (since it wasn't detected yet).


Hey thank you for your reply :)

So the strange thing is i had an older compiler (v2.074.1), so
i started running the 2.075 version - with which it worked!


Small confusion from my part.

The thing is i can start the 2.075 version only over the 
activate.sh
script in a shell. Can you tell me how i can really use the 
2.075 version
(without having to run the script each time i open a shell, and 
why do

i have to do that).


I have no idea of what is this script. Actually i don't use 
dlangui at all.

I stop here.

Re: DlangUI Error

[Jiyan via Digitalmars-d-learn]

On Thursday, 10 August 2017 at 22:27:44 UTC, HyperParrow wrote:

On Thursday, 10 August 2017 at 20:48:23 UTC, Jiyan wrote:

Hey,
i get the following errors when i try to use dlangui, by just 
importing the package i get a lot of errors which look like:
function std.xml.Item.opEquals does not override any function, 
did you mean to override 'object.Object.opEquals'?


What is happening there?


The error message is correct but the error is only recognized 
by the compiler since the latest release. To fix it requires 
intervention of the author: either "override" must be removed 
from the opEquals that's indicated or the opEquals parameters 
must be changed o match exactly the signature used on 
Object.opEquals.


Until this is done in libdlangui you can use an older compiler, 
e.g last 2.074.x release should make the error disappearing 
(since it wasn't detected yet).


Hey thank you for your reply :)

So the strange thing is i had an older compiler (v2.074.1), so
i started running the 2.075 version - with which it worked!
The thing is i can start the 2.075 version only over the 
activate.sh
script in a shell. Can you tell me how i can really use the 2.075 
version
(without having to run the script each time i open a shell, and 
why do

i have to do that).

[Issue 17742] New: std.range.transposed does not have opIndex

[via Digitalmars-d-bugs]

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

  Issue ID: 17742
   Summary: std.range.transposed does not have opIndex
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

auto ror = 5.iota.map!(y => 5.iota.map!(x => x * y).array).array;
assert(ror[3][2] == 6); // OK
auto result = ror.transposed;
assert(result[3][2] == 6); // Error

--

[Issue 17741] New: std.range.transposed does not work with Map

[via Digitalmars-d-bugs]

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

  Issue ID: 17741
   Summary: std.range.transposed does not work with Map
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

auto ror = 5.iota.map!(y => 5.iota.map!(x => x * y));
auto result = ror.transposed;

Error: template std.range.transposed cannot deduce function from argument types
!()(MapResult!(__lambda1, Result)), candidates are:

--

DLL loading behaviors and pragma(lib)

[David Zhang via Digitalmars-d-learn]

I've been working on getting OpenGL to load on windows without a 
library, and encountered something curious;


Context creation fails when I try to use the function pointer 
retrieved through GetProcAddress, but works just fine with the 
statically linked version provided through 
core.sys.windows.wingdi.d.


This may be a stupid question, but why is this?

Thanks.

Re: string hash significant speedup

[HyperParrow via Digitalmars-d-learn]

On Thursday, 10 August 2017 at 20:07:35 UTC, Steven Schveighoffer 
wrote:

On 8/10/17 3:36 PM, Johnson Jones wrote:
when using T[string], hashing is used. Computing the hash is 
slow(relatively speaking).


Does D cache the hashes? Strings are immutable so there is 
absolutely no reason why the hash ever need to be computed 
more than once.


It computes them on insertion, and caches the result in the 
structure of the hash table.


-Steve


But i think he speaks about the strings that are tested for 
inclusion (i.e opIn RHS), not those who are inserted, for which 
obviously the hash is known.

Re: DlangUI Error

[HyperParrow via Digitalmars-d-learn]

On Thursday, 10 August 2017 at 20:48:23 UTC, Jiyan wrote:

Hey,
i get the following errors when i try to use dlangui, by just 
importing the package i get a lot of errors which look like:
function std.xml.Item.opEquals does not override any function, 
did you mean to override 'object.Object.opEquals'?


What is happening there?


The error message is correct but the error is only recognized by 
the compiler since the latest release. To fix it requires 
intervention of the author: either "override" must be removed 
from the opEquals that's indicated or the opEquals parameters 
must be changed o match exactly the signature used on 
Object.opEquals.


Until this is done in libdlangui you can use an older compiler, 
e.g last 2.074.x release should make the error disappearing 
(since it wasn't detected yet).

Re: How do I compile a program with curl lib on Windows?

[Neto via Digitalmars-d-learn]

UPDATE 2:

Managed to do it! Got the precompiled binaries from here:


https://github.com/HazeProductions/libcurl


(thank @frk1 very much for his repo)

downloaded them then extracted the release folder to proper curl 
folder on my machine then



dmd -L-libcurl app.d -I"C:\libcrl"


worked just fine. Topic closed.

Re: string hash significant speedup

[Johnson Jones via Digitalmars-d-learn]

On Thursday, 10 August 2017 at 20:07:35 UTC, Steven Schveighoffer 
wrote:

On 8/10/17 3:36 PM, Johnson Jones wrote:
when using T[string], hashing is used. Computing the hash is 
slow(relatively speaking).


Does D cache the hashes? Strings are immutable so there is 
absolutely no reason why the hash ever need to be computed 
more than once.


It computes them on insertion, and caches the result in the 
structure of the hash table.


-S


Thanks. What is the cache size?

Re: How do I compile a program with curl lib on Windows?

[Neto via Digitalmars-d-learn]

On Thursday, 10 August 2017 at 20:29:53 UTC, Neto wrote:
Could someone give me an example to how do I compile a program 
with support to curl on Windows? Where do I find the .lib for 
link against my D programa under Windows or do I need to 
compile it myself? I downloaded the lib versions at curl's 
official web site but I find either .a files or .h in the lib 
folder


UPDATE:

Found the links right here:


https://github.com/HazeProductions/libcurl


Compiling as:

dmd  -dw -m32 -L-lcurl app.d 
-I"C:\Users\neto\Desktop\static-debug-x86"


I get the following error:


OPTLINK: Warning 9: Unknow option: LCURL


What am I missing? is the library name wrong/couldn't be found or 
what else?

DlangUI Error

[Jiyan via Digitalmars-d-learn]

Hey,
i get the following errors when i try to use dlangui, by just 
importing the package i get a lot of errors which look like:
function std.xml.Item.opEquals does not override any function, 
did you mean to override 'object.Object.opEquals'?


What is happening there?

How do I compile a program with curl lib on Windows?

[Neto via Digitalmars-d-learn]

Could someone give me an example to how do I compile a program 
with support to curl on Windows? Where do I find the .lib for 
link against my D programa under Windows or do I need to compile 
it myself? I downloaded the lib versions at curl's official web 
site but I find either .a files or .h in the lib folder

[Issue 17569] Rename dman in the Debian .deb package to prevent conflict with Debian package debian-goodies

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
Just rename it to dmanual

--

Re: Beta D 2.075.1

[Walter Bright via Digitalmars-d-announce]

On 8/8/2017 1:32 PM, Martin Nowak wrote:

On Tuesday, 8 August 2017 at 15:45:45 UTC, Vladimir Panteleev wrote:

On Tuesday, 8 August 2017 at 14:57:58 UTC, Daniel Kozak wrote:

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


Thanks. I've submitted a fix.


Thanks, considering https://issues.dlang.org/show_bug.cgi?id=17569 I'd still say 
we should evaluate whether we want to continue maintaining and shipping a tool 
with unclear usefulness and userbase.


Just rename it to dmanual.

Re: Beta D 2.075.1

[Walter Bright via Digitalmars-d-announce]

On 8/10/2017 10:24 AM, Martin Nowak wrote:

Does it provide enough value over the website search?


I use it all the time, because it gets me where I want to go from the command 
line. Opening a browser, browsing to dlang.org, clickety-clicking around takes 
much longer.


Worse, the site search rarely gets me where I want to go.


While I personally find the tool nice, I never ended up using it much, because 
it requires you to know what you're searching for.


It could use all of the runtime library functions added to the index, instead of 
just a smattering.

Re: string hash significant speedup

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/10/17 3:36 PM, Johnson Jones wrote:
when using T[string], hashing is used. Computing the hash is 
slow(relatively speaking).


Does D cache the hashes? Strings are immutable so there is absolutely no 
reason why the hash ever need to be computed more than once.


It computes them on insertion, and caches the result in the structure of 
the hash table.


-Steve

Re: Jetbrains announce support for rust plugin, show them we want one too!

[12345swordy via Digitalmars-d]

On Thursday, 10 August 2017 at 05:55:59 UTC, Dmitry wrote:

On Wednesday, 9 August 2017 at 20:29:07 UTC, 12345swordy wrote:
You edit the json file of course. That how DUB generates 
solution files for visual D and other IDE's.


This breaks changes that was done in the VS project.


What changes are talking about? You typically make changes in the 
json file.


Alex

string hash significant speedup

[Johnson Jones via Digitalmars-d-learn]

when using T[string], hashing is used. Computing the hash is 
slow(relatively speaking).


Does D cache the hashes? Strings are immutable so there is 
absolutely no reason why the hash ever need to be computed more 
than once.


Essentially the hash should be attached to strings like their 
length and address.


Does D compute the hash of a string every time it is looked up? 
If so, any way to optimize that it?

Vectorflow noob

[Jiyan via Digitalmars-d-learn]

Hey,
wanted to the following simple thing with vectorflow:

I want to develop a simple MLP, which has 2 input neurons and one 
output neuron.
The network should simply add the input values together, so [1,2] 
predicts [3] i guess.

I started in a newbish way to build the following code:

import vectorflow;


struct Obs // The represeneted data
{
	float label; // Did i get that right that label would be the 
DESIRED output (3=1+2)
	float []features; // The features are the input i guess, so 
features = f.e. [1,2]

}

void main()
{

auto net = NeuralNet()
.stack(DenseData(2))
	.stack(Linear(10));   // Is this the right way to construct 
the Net?


// The training data
Obs []data;


data.length = 10;

import std.random;
import std.algorithm;
foreach(ref Obs n; data)
{
		// The features are getting fille with random numbers between 
0.5 and 5

// The label becomes the sum of feature[0] and feature[1]
n.features.length = 2;
n.features[0] = uniform(0.5, 5);
n.features[1] = uniform(0.5, 5);

n.label = n.features.sum;
writeln(n.features[0], " ", n.features[1], " ", n.label);
assert (n.label == n.features[0] + n.features[1]);
}

net.learn(data, "logistic", AdaGrad(10, 0.1, 500), true, 3);

auto val = net.predict(data[0]); // is this wrong?
val.writeln;
}

Thanks :)

[Issue 17740] ghost "internal" symbols show up sometimes

[via Digitalmars-d-bugs]

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

--- Comment #2 from Jonathan M Davis  ---
Well, it looks like it relates to directly assigning a non-null value to the
_timezone member at compile time. The new TimeZone class declaration is not
required. All you have to do to trigger it is to change line # 8996 at the
bottom of std.datetime.systime from

Rebindable!(immutable TimeZone) _timezone;
to

Rebindable!(immutable TimeZone) _timezone = UTC();

Unfortunately, declaring a struct like

struct S
{
Rebindable!(immutable TimeZone) _timezone = UTC();
}

does not exhibit the problem. So, I don't know how to create a small test case
that doesn't require the std.datetime code. But assigning UTC() like this
before used to work. A backend bug on Windows prevened me from getting a
similar PR merged where it added a new TimeZone class, and assigning UTC() in
that case had exactly the same problem as I recall (certainly, assigning the
new time zone class did, because that's what blocked the PR). But it worked
perfectly fine on other OSes, and I'm fairly certain that I tried those changes
again at some point, and the backend bug was gone - I just wanted to rework the
changes, so they weren't committed. Regardless, it worked perfectly fine on
non-Windows OSes previously. So, something about this broke in the last several
releases. I'd have to do some research to figure out when it broke though.

--

[Issue 17740] ghost "internal" symbols show up sometimes

[via Digitalmars-d-bugs]

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

--- Comment #1 from Steven Schveighoffer  ---
(In reply to Steven Schveighoffer from comment #0)
> Another example:

Wrong link, here it is:
https://forum.dlang.org/post/exinpcxvpdsbazyaw...@forum.dlang.org

--

Re: Beta D 2.075.1

[Vladimir Panteleev via Digitalmars-d-announce]

On Thursday, 10 August 2017 at 17:24:41 UTC, Martin Nowak wrote:
Try dman 2.074.0, opens 
http://dlang.org/changelog/2.019.html#2.074.0.


That would be a bug. It extends to the generated CHM's index as 
well, so we should fix it.



So in the end the search bar works much better for me.


If dman doesn't find the exact thing you're looking for, it falls 
back to a Google search, which is what the website search uses as 
well.

Re: Beta D 2.075.1

[Martin Nowak via Digitalmars-d-announce]

On Wednesday, 9 August 2017 at 15:35:12 UTC, Ulrich Küttler wrote:

On Tuesday, 8 August 2017 at 20:32:34 UTC, Martin Nowak wrote:
Thanks, considering 
https://issues.dlang.org/show_bug.cgi?id=17569 I'd still say 
we should evaluate whether we want to continue maintaining and 
shipping a tool with unclear usefulness and userbase.


dman is awesome! I did not use it because I did not know!


I guessed that would happen, doesn't resolve the name conflicts 
though.

Does it provide enough value over the website search?
Try dman 2.074.0, opens 
http://dlang.org/changelog/2.019.html#2.074.0.

Also not a good replacement for DCD like docs-in-IDE integration.

What about dman as dub package? For sure we could upload 
d.tag/d-tags.json to the website.


While I personally find the tool nice, I never ended up using it 
much, because it requires you to know what you're searching for. 
No fuzzy search, no overview, etc.


So in the end the search bar works much better for me.

Re: Why does stringof not like functions with arguments?

[Meta via Digitalmars-d-learn]

On Thursday, 10 August 2017 at 15:55:41 UTC, Jason Brady wrote:
Wow. That makes perfect sense. I forgot stringof works only 
with expressions


It works with symbols too. See the following:

template test(){}
pragma(msg, test.stringof);

[Issue 17740] New: ghost "internal" symbols show up sometimes

[via Digitalmars-d-bugs]

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

  Issue ID: 17740
   Summary: ghost "internal" symbols show up sometimes
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

In unknown circumstances, CTFE initializations can cause a symbol "internal" to
be emitted to the object file. I'm pretty sure this isn't supposed to happen.

When it does happen, you get linker errors that "internal" isn't defined.

A current example where it is blocking a PR:
https://github.com/dlang/phobos/pull/5683

Note the error from the builds:
generated/freebsd/release/32/libphobos2.a(file_5f5_798.o)(.text._D3std4file28__T17statTimeToStdTimeVai97Z17statTimeToStdTimeFNaNbNfKS4core3sys5posix3sys4stat6stat_tZS3std8datetime7systime7SysTime+0x61):
In function
`_D3std4file28__T17statTimeToStdTimeVai97Z17statTimeToStdTimeFNaNbNfKS4core3sys5posix3sys4stat6stat_tZS3std8datetime7systime7SysTime':
: undefined reference to `internal'
generated/freebsd/release/32/libphobos2.a(file_5f6_7a4.o)(.text._D3std4file29__T17statTimeToStdTimeVai109Z17statTimeToStdTimeFNaNbNfKS4core3sys5posix3sys4stat6stat_tZS3std8datetime7systime7SysTime+0x61):
In function
`_D3std4file29__T17statTimeToStdTimeVai109Z17statTimeToStdTimeFNaNbNfKS4core3sys5posix3sys4stat6stat_tZS3std8datetime7systime7SysTime':
: undefined reference to `internal'
generated/freebsd/release/32/libphobos2.a(systime_31a9_2ce.o)(.data+0x0):
undefined reference to `internal'
generated/freebsd/release/32/libphobos2.a(systime_31a9_2ce.o)(.rodata+0x8):
undefined reference to `internal'
generated/freebsd/release/32/libphobos2.a(systime_31a9_2ce.o)(.text._D3std8datetime7systime7SysTime11toLocalTimeMxFNaNbNfZS3std8datetime7systime7SysTime+0x18):
In function
`_D3std8datetime7systime7SysTime11toLocalTimeMxFNaNbNfZS3std8datetime7systime7SysTime':
: undefined reference to `internal'
generated/freebsd/release/32/libphobos2.a(systime_31a9_2ce.o)(.text._D3std8datetime7systime7SysTime5toUTCMxFNaNbNfZS3std8datetime7systime7SysTime+0x18):
more undefined references to `internal' follow

Another example:
https://github.com/dlang/dmd/blob/master/src/ddmd/tocsym.d#L681

I found in the compiler these lines:
https://github.com/dlang/dmd/blob/master/src/ddmd/tocsym.d#L662
https://github.com/dlang/dmd/blob/master/src/ddmd/tocsym.d#L681

Which explain how the symbol name is generated. Those are in a section titled
"CTFE stuff".

Just recording this bug here so it's not forgotten. I have no idea how to
reduce it.

--

Re: ModuleInfo Error

[Johan via Digitalmars-d]

On Thursday, 10 August 2017 at 14:32:04 UTC, Adam D. Ruppe wrote:
On Wednesday, 9 August 2017 at 22:43:03 UTC, Johnson Jones 
wrote:


because people cannot cut ties with the past and learn from 
their mistakes.  Do we even need to separate the linker and 
compiler?


Like I said though, a lot of D's corporate users see this as 
being a major feature for their productivity. So it isn't quite 
as clear cut that one way is better than the other.


Separating compilation and linking is helpful for example for 
reducing the build time of incremental builds and parallelizing 
builds. A number of language semantics I personally understand in 
terms of separate codegen and linking, but I am not sure if 
that's strictly needed (D being a systems language, probably it 
is). Separate compilation is also needed for cross-language 
interop (e.g. for a mixed C++/D codebase).


But Walter has said he is interested in doing an integrated 
linker and getting benefits from it, just that's a lot more 
work than it sounds like and he has a lot of other things to 
do...


Kinke has added LLD to LDC for MSVC, and for other platforms it 
is a WIP. See https://github.com/ldc-developers/ldc/pull/2142 , 
https://github.com/ldc-developers/ldc/pull/2203 . So already LDC 
running on Linux can generate a Windows executable.


-Johan

[Issue 17736] bigint opunary should be better performing

[via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer  ---
Either way, this is not a "simple" enhancement. But feel free to take over this
enhancement request if you want to write it up.

--

[Issue 17736] bigint opunary should be better performing

[via Digitalmars-d-bugs]

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

--- Comment #3 from hst...@quickfur.ath.cx ---
IMO, the refcounting idea is still valid, if a bit more complicated to
implement. It would be important for reducing GC load on BigInt-heavy code, I
think.

--

Re: Why does stringof not like functions with arguments?

[Jason Brady via Digitalmars-d-learn]

On Thursday, 10 August 2017 at 14:51:22 UTC, Meta wrote:


Welcome to optional parentheses hell. Please enjoy your stay.

Because function calls in D can optionally omit the parens, 
`FunctionWithArguments.stringof` is actually attempting to call 
`FunctionWithArguments` without any arguments, and then call 
`stringof` on the result. In other words, it's actually trying 
to do this:


writeln(FunctionWithArguments().stringof);

And the D compiler is rightly telling you that you can't call 
the function with no arguments. The easiest solution is to use 
__traits(identifier) instead:


writeln(__traits(identifier, FunctionWithArguments));

You can make a handy template helper to do this for you:

enum stringOf(alias symbol) = __traits(identifier, symbol);
writeln(stringOf!FunctionWithArguments);


Wow. That makes perfect sense. I forgot stringof works only with 
expressions and that a function name is a valid expression in the 
case of UCF.


I already found the __traits as a workaround, but the template 
helper is a great idea. Thanks!

Re: I'm the new package maintainer for D on ArchLinux

[Dicebot via Digitalmars-d-announce]

On Thursday, 10 August 2017 at 15:36:54 UTC, Wild wrote:

And of course congratulations for becoming a TU! :)
Thanks, and while I have you here, is there any reason why all 
the dtools programs have 'dtools-' as a prefix?


Some of them have very common names (like "detab") and I was 
concerned that it may eventually clash with binary name of some 
other totally unrelated utility from a different package. And for 
convenience more commonly used / uniquely named ones like rdmd 
also provide shorter symlink.

Re: Who here uses vibe-s3 from code.dlang.org?

[Andres Clari via Digitalmars-d]

On Monday, 7 August 2017 at 22:46:57 UTC, aberba wrote:
vibe-s3 (https://code.dlang.org/packages/vibe-s3) is an Amazon 
s3 object storage API for D.


Has anyone here used or tested it? What was your experiences? 
It has the tagline "this library is highly alpha and mostly 
untested. use at your own risk".


Last time I tested it around Nov, 2016, it was very buggy. I'm 
using an in-house deimos wrapper for "libs3".


I would be awesome to have some native library for S3, and other 
AWS stuff, but I'm very thrown back by having it depend on 
vibe.d. Nothing against it, but say you just want to make a 
simple upload utility specialized, having to depend on vibe.d for 
that really is something unacceptable.


Ideally we'd wanna have a library for the whole Amazon auth stuff 
wrapped, and libraries for the specific services you want to use, 
being as standalone as possible.

Re: I'm the new package maintainer for D on ArchLinux

[Wild via Digitalmars-d-announce]

On Thursday, 10 August 2017 at 15:18:31 UTC, Dicebot wrote:
Thanks for bringing my attention to it, I have disowned both it 
and dstep-git. Note though that you could take it over anyway 
if you intend to move it to [community] as a TU - contacting 
original author is only matter of politeness.

I didn't want to take it over if you still wanted to maintain it


And of course congratulations for becoming a TU! :)
Thanks, and while I have you here, is there any reason why all 
the dtools programs have 'dtools-' as a prefix?

Re: I'm the new package maintainer for D on ArchLinux

[Dicebot via Digitalmars-d-announce]

On Thursday, 10 August 2017 at 14:42:43 UTC, Wild wrote:
On Thursday, 10 August 2017 at 14:26:41 UTC, Jacob Carlborg 
wrote:
That's great. Do you want to maintain the package for DStep as 
well as Dicebot did?


I could do that, but what I can see Dicebot still maintains it
https://aur.archlinux.org/packages/dstep/
But it could just be that he has forgot to orphan it.


Thanks for bringing my attention to it, I have disowned both it 
and dstep-git. Note though that you could take it over anyway if 
you intend to move it to [community] as a TU - contacting 
original author is only matter of politeness.


And of course congratulations for becoming a TU! :)

Re: Documentation licence

[ANtlord via Digitalmars-d]

On Saturday, 15 July 2017 at 01:49:24 UTC, Seb wrote:

On Friday, 30 June 2017 at 10:10:14 UTC, ANtlord wrote:
Hello! I use service devdocs.io for some technologies. And I 
think that I able to add D to this service.


Hi,

Did you manage to make progress on this issue? As mentioned 
this is in my focus as well and I will be able to allocate some 
time to help.


Btw @ others there is an open Trello card at the devdocs.io 
board which allows voting:


https://trello.com/c/bCgqhZ4s/123-d


I created the PR [1]. But is not approved. It is not discussed 
even.


https://github.com/Thibaut/devdocs/pull/661 [1]

Re: delegates/lambas do not pick up calling convention

[Timon Gehr via Digitalmars-d-learn]

On 10.08.2017 15:22, Adam D. Ruppe wrote:

On Wednesday, 9 August 2017 at 23:52:00 UTC, Johnson Jones wrote:

extern(C) delegate(void*) {}


You should very rarely use extern(C) delegate... delegate is a D type, 
so the C function is almost certainly not actually receiving it.


Only time you'd want an extern(C) using D types like delegates, arrays, 
strings, etc., is if the receiver is actually also written in D.


idk if this would fix your problem, but it should be changed regardless.


gdk is actually using a function with arguments of type (extern(C) int 
function(void*),void*).


Anyway, I think there are use cases for extern(C) delegates too, along 
the following lines:


alias D=extern(C) int delegate(int);

struct F(S,T...){ // this struct is compatible with C
void* ptr;
extern(C) S function(void*,T) funptr;
auto opCall(T args){
return funptr(ptr,args);
}
}

void main(){
int y=2;
D dg=(x)=>x+y;
auto f=*cast(F!(int,int)*)
import std.stdio;
writeln(f(3));
}

Re: Fix gtkD api display

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

On Thursday, 10 August 2017 at 14:55:06 UTC, Mike Wey wrote:
The problem was that there are a few large classes at the start 
of the hierarchy, and with the old version of ddox the function 
pages would not only be generated for the base class, but also 
for all the derived classes.


Oh, I see. My generator lists them on the index, but doesn't 
recreate it each time, it just links. For example:


http://dpldocs.info/experimental-docs/gtk.ApplicationWindow.ApplicationWindow.html

it lists inherited members again, but not all their docs.


That would be great.


kewl

I don't use the documentation myself so this isn't really a 
problem.


It is a lot easier to link to individual pages from the outside 
which means search is more reliable, the back button works, stuff 
like that.

Re: Fix gtkD api display

[Mike Wey via Digitalmars-d-learn]

On 10-08-17 15:57, Adam D. Ruppe wrote:

On Saturday, 5 August 2017 at 14:02:09 UTC, Mike Wey wrote:
One issue is the shear size of the generated documentation, though the 
current version of ddox no longer generates a ton of unused files 
bringing the size down from 15-20GB to a mere 2GB.


what?! I'm not actually sure how much gtk alone takes, but my entire doc 
folder is 4 GB, including a good chunk of the dub repo, phobos, 
druntime, my stuff, search indexes, archives, etc.


I guess it is possible the gtkd is 2 GB of that, but at least it isn't 20.


The problem was that there are a few large classes at the start of the 
hierarchy, and with the old version of ddox the function pages would not 
only be generated for the base class, but also for all the derived classes.


So when you have a base class with 264 functions, and you have 385 
classes that are directly or indirectly derived from it.
Things start to add up, That is 101_640 html pages just for this one 
case, and there are more.


Luckily this is fixed, especially because ddox never actually linked to 
these pages.


The need to go trough the empty module page when browsing the 
documentation. For a lot / most? functions the complete documentation 
is in the overview defeating the purpose of the one page per artifact.


If you guys are interested, I can do a custom adrdox for gtk that:

* reads more of the gtk syntax 
https://developer.gnome.org/gtk-doc-manual/stable/documenting_syntax.html.en 



* recognizes the one-item-per-module pattern and skips the empty pages

* has a style more like https://gtkd.org/index.html

* Maybe a few other little things?


That would be great.


And im not a big fan of the one page per artifact style of documentation.


Oh, it is so much better in a lot of ways.


I don't use the documentation myself so this isn't really a problem.

--
Mike Wey

Re: Calling C++ "void foo(Klass&)"

[Mengu via Digitalmars-d]

On Thursday, 10 August 2017 at 07:58:55 UTC, Arjan wrote:

On Thursday, 10 August 2017 at 00:32:40 UTC, Mengu wrote:
my second question is: i have no idea what's going on in this 
file: 
https://github.com/whoshuu/cpr/blob/master/include/cpr/body.h 
i'd appreciate some pointers.


A new 'type' named Body which IS-A std::string is defined.


i think we can mimic this with an alias this for a string (or 
const char*) property. is that right?



To construct a Body there are various options:
The ctors 'default': Body(), 'copy': Body(const Body&) and 
'move': Body(Body&&) ctors are using the compiler generated 
default implementation.

The same is true for the assignment operators =


how can i check what compiler generates for default so i can add 
them to my extern C++ clause?


Then a few explicit conversion ctors are defined to construct a 
Body from a const char* string and std::string. Explicit means 
the compiler is not allowed to implicit convert to std::string 
or const char* for provide args not being a const char* or 
std::string but for which a conversion exists.




i'll give these converters a try.


Since the h file also contains the definitions, the compiler 
must inline the code for the Body ctors and assignment 
operator. It also means not C/cpp file is needed since the 
function bodies are already in the h file.


i realized that when i saw the member initialization syntax in 
header files.




HTH


thank you very much for the detailed explanation.

Re: Why does stringof not like functions with arguments?

[Meta via Digitalmars-d-learn]

On Wednesday, 9 August 2017 at 01:39:07 UTC, Jason Brady wrote:

Why does the following code error out with:

app.d(12,10): Error: function app.FunctionWithArguments (uint 
i) is not callable using argument types ()


Code:

import std.stdio;

void FunctionWithoutArguments() {
}

void FunctionWithArguments(uint i) {
}

void main()
{
writeln(FunctionWithoutArguments.stringof);
writeln(FunctionWithArguments.stringof);
}


Welcome to optional parentheses hell. Please enjoy your stay.

Because function calls in D can optionally omit the parens, 
`FunctionWithArguments.stringof` is actually attempting to call 
`FunctionWithArguments` without any arguments, and then call 
`stringof` on the result. In other words, it's actually trying to 
do this:


writeln(FunctionWithArguments().stringof);

And the D compiler is rightly telling you that you can't call the 
function with no arguments. The easiest solution is to use 
__traits(identifier) instead:


writeln(__traits(identifier, FunctionWithArguments));

You can make a handy template helper to do this for you:

enum stringOf(alias symbol) = __traits(identifier, symbol);
writeln(stringOf!FunctionWithArguments);

Re: I'm the new package maintainer for D on ArchLinux

[Wild via Digitalmars-d-announce]

On Thursday, 10 August 2017 at 14:26:41 UTC, Jacob Carlborg wrote:
That's great. Do you want to maintain the package for DStep as 
well as Dicebot did?


I could do that, but what I can see Dicebot still maintains it
https://aur.archlinux.org/packages/dstep/
But it could just be that he has forgot to orphan it.

Re: gtkD window centering message up and no app on taskbar

[Mike Wey via Digitalmars-d-learn]

On 09-08-17 23:54, Johnson Jones wrote:

Ok, I added

 import core.sys.windows.winuser;
 __gshared extern(C) core.sys.windows.winuser.HANDLE 
function(GdkWindow*) gdk_win32_window_get_handle;
 Linker.link(gdk_win32_window_get_handle, 
"gdk_win32_window_get_handle", LIBRARY_GDK);


to GtkD\generated\gtkd\gdk\c\functions.d

and rebuilt and it seems to work. Hopefully that is the right place so 
in the future when I replace GtkD with it won't show up as a bug in my 
code somewhere. I assume master will be updated with this at some point?


That would be the correct place. If it is added to GtkD it won't be in 
functions.d, which is generated. It would be something like: gdk.c.win32.


--
Mike Wey

Re: ModuleInfo Error

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 9 August 2017 at 22:43:03 UTC, Johnson Jones wrote:
Well, I use Visual D and not sure if it can use rdmd(I'm sure 
it can be hacked)


I don't know.

because people cannot cut ties with the past and learn from 
their mistakes.  Do we even need to separate the linker and 
compiler?


Like I said though, a lot of D's corporate users see this as 
being a major feature for their productivity. So it isn't quite 
as clear cut that one way is better than the other.


But Walter has said he is interested in doing an integrated 
linker and getting benefits from it, just that's a lot more work 
than it sounds like and he has a lot of other things to do...

Re: I'm the new package maintainer for D on ArchLinux

[Jacob Carlborg via Digitalmars-d-announce]

On 2017-08-09 22:42, Wild wrote:

Hi everyone,

The D packages for ArchLinux has been orphaned since Dicebot stepped
down as the maintainer and no one else stepped up. So I decided to step
up and apply to become a Trusted User, and I got accepted yesterday[1].


That's great. Do you want to maintain the package for DStep as well as 
Dicebot did?


--
/Jacob Carlborg

Re: Fix gtkD api display

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

On Saturday, 5 August 2017 at 14:02:09 UTC, Mike Wey wrote:
One issue is the shear size of the generated documentation, 
though the current version of ddox no longer generates a ton of 
unused files bringing the size down from 15-20GB to a mere 2GB.


what?! I'm not actually sure how much gtk alone takes, but my 
entire doc folder is 4 GB, including a good chunk of the dub 
repo, phobos, druntime, my stuff, search indexes, archives, etc.


I guess it is possible the gtkd is 2 GB of that, but at least it 
isn't 20.



The need to go trough the empty module page when browsing the 
documentation. For a lot / most? functions the complete 
documentation is in the overview defeating the purpose of the 
one page per artifact.


If you guys are interested, I can do a custom adrdox for gtk that:

* reads more of the gtk syntax 
https://developer.gnome.org/gtk-doc-manual/stable/documenting_syntax.html.en


* recognizes the one-item-per-module pattern and skips the empty 
pages


* has a style more like https://gtkd.org/index.html

* Maybe a few other little things?

And im not a big fan of the one page per artifact style of 
documentation.


Oh, it is so much better in a lot of ways.

Re: new russian Dlang book

[Suliman via Digitalmars-d-announce]

Big update of site layout.

[Issue 2137] Data not compressed on fly when adding to zip archive

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 2137] Data not compressed on fly when adding to zip archive

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/6b151756108f57a1bc472ad121f27a38df2c80f0
Fix Issue 2137 - Data not compressed on fly when adding to zip archive

https://github.com/dlang/phobos/commit/aa8c61f8a20cb1d0dd438bf0959453526663454e
Merge pull request #5679 from RazvanN7/Issue_2137

Fix Issue 2137 - Data not compressed on fly when adding to zip archive
merged-on-behalf-of: MetaLang 

--

Re: Import modules too verbose in some cases

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 9 August 2017 at 23:57:19 UTC, Johnson Jones wrote:
Sometimes one doesn't want to import either the whole module 
nor specify a single function to import.


There was a proposal called "dependency carrying declarations" 
about that, but a library trick was found to beat it:


https://github.com/dlang/druntime/pull/1756

They called it "self-important lookups"...though the PR was never 
actually merged, but as you can see in there, the code was 
actually quite trivial (the PR is about 95% documentation):


template from(string moduleName)
{
mixin("import from = " ~ moduleName ~ ";");
}


So then you can do an inline import and reference right there.

It seems that basically D has all the info to import the 
function implicitly because it usually gives a nice error 
message tells us which module to import for the function.


It is guessing there, giving a hint to users but it doesn't 
actually have enough information to fix it automatically. 
Consider:


struct A {
  static struct B {
  static void C() {}
  }
}

in that case A.B.C() is the struct function, not an import. The 
line between the package+module and the inner symbol is unknown 
without an import.


Sometimes we still need to specify the fully qualified name due 
to conflicts with other modules.


Keep in mind too that you can do renamed imports:

import short = some.long.name;

short.foo(); // refers to some.long.name.foo();

Rather, how about a new feature were we do not have to import 
modules at all by specifying the fully qualified name? Since 
conflicts might occur, how bout using a symbol to express that?


#A.B.C();



This is what the `from!"A.B".C()` trick linked above enables. But 
notice that the module is in quotes - it still doesn't know where 
where the line is drawn between module and inner name without you 
telling it somehow.

Re: delegates/lambas do not pick up calling convention

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

On Wednesday, 9 August 2017 at 23:52:00 UTC, Johnson Jones wrote:

extern(C) delegate(void*) {}


You should very rarely use extern(C) delegate... delegate is a D 
type, so the C function is almost certainly not actually 
receiving it.


Only time you'd want an extern(C) using D types like delegates, 
arrays, strings, etc., is if the receiver is actually also 
written in D.


idk if this would fix your problem, but it should be changed 
regardless.

[Issue 14536] Calling destroy() on a on an extern(C++) class causes a segfault

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
cat > bug.d << CODE
extern(C++) class Bar {}

void main()
{
auto inst = new Bar;
delete inst;
}
CODE

Crashes in rt_finalize2.
Weirdly enough works with `scope` classes. I vaguely remember someone hacked
around that crash for scope classes in dmd.

--

Re: Efficiently streaming data to associative array

[Jon Degenhardt via Digitalmars-d-learn]

On Wednesday, 9 August 2017 at 13:36:46 UTC, Steven Schveighoffer 
wrote:

On 8/8/17 3:43 PM, Anonymouse wrote:
On Tuesday, 8 August 2017 at 16:00:17 UTC, Steven 
Schveighoffer wrote:
I wouldn't use formattedRead, as I think this is going to 
allocate temporaries for a and b.


What would you suggest to use in its stead? My use-case is 
similar to the OP's in that I have a string of tokens that I 
want split into variables.


using splitter(","), and then parsing each field using 
appropriate function (e.g. to!)


For example, the OP's code, I would do:

auto r = line.splitter(",");
a = r.front;
r.popFront;
b = r.front;
r.popFront;
c = r.front.to!int;

It would be nice if formattedRead didn't use appender, and 
instead sliced, but I'm not sure it can be fixed.


Note, one could make a template that does this automatically in 
one line.


-Steve


The blog post Steve referred to has examples of this type 
processing while iterating over lines in a file. A couple 
different ways to access the elements are shown. AA access is 
addressed also: 
https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/


--Jon

[Issue 17388] [scope] e[] should be treated like as far as scope goes

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/fc9c84ba1722c02f0c1877ffa39134c84a5e13e0
fix Issue 17388 - [scope] e[] should be treated like  as far as scope goes

https://github.com/dlang/dmd/commit/09cd19d51b1e000dc81a61d167dc559480958f3e
Merge pull request #7076 from WalterBright/fix17388

fix Issue 17388 - [scope] e[] should be treated like  as far as sco…
merged-on-behalf-of: Martin Nowak 

--

Re: delegates/lambas do not pick up calling convention

[Timon Gehr via Digitalmars-d-learn]

On 10.08.2017 01:52, Johnson Jones wrote:

given somethign like Threads.threadsAddIdle

which takes an extern(C) int (void*)

we can't seem to do

threadsAddIdle((void*) { }, null);


I think this is a compiler bug. Try:

threadsAddIdle((x){ }, null);

It seems that the calling convention is deduced only if the parameter 
type needs to be deduced too.


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

[Issue 17739] New: Calling convention of not deduced for delegate function arguments with explicit parameter types

[via Digitalmars-d-bugs]

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

  Issue ID: 17739
   Summary: Calling convention of not deduced for delegate
function arguments with explicit parameter types
   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 v2.075.0:

alias F=extern(C) int delegate(int);
void foo(F dg){ }
void main(){
F dg=(int a)=>a; // ok
foo((int a)=>a); // error
}

the error message is:

bug.d(5): Error: function bug.foo (extern (C) int delegate(int) dg) is not
callable using argument types (int function(int a) pure nothrow @nogc @safe)

The code compiles if the explicit parameter type is removed from the delegate.

The code should compile.

--

[Issue 17198] rdmd does not recompile when --extra-file is added

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to newCTFE at https://github.com/dlang/tools

https://github.com/dlang/tools/commit/5ffca7b0e097644fbcffbee8ba755e4ae48c9d9f
fix issue 17198 - rdmd does not recompile when --extra-file is added

https://github.com/dlang/tools/commit/790b223fd22193c7c7ef4d65bd3db226da800450
Merge pull request #219 from aG0aep6G/17198

--

[Issue 17262] Better docs for rdmd

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to newCTFE at https://github.com/dlang/tools

https://github.com/dlang/tools/commit/e11129de676d9c563476f44f60cc71c793dcb3ef
Issue 17262 - Better docs for rdmd

https://github.com/dlang/tools/commit/f01bcafa8cd8d6102cabc4f4aa9deca037e0231c
Merge pull request #232 from wilzbach/fix-17262

--

[Issue 11997] rdmd should search its binary path for the compiler

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to newCTFE at https://github.com/dlang/tools

https://github.com/dlang/tools/commit/f7e6f4ed925f6a8f97b4c0f02cfce2620489357a
Fix Issue 11997 - rdmd should search it's binary path for the compiler

https://github.com/dlang/tools/commit/ee59ec92912cf98f4167a6802383804cb8d7aa9a
Merge pull request #250 from joakim-noah/rdmd

--

[Issue 17731] dman fails to build due to more than 32767 symbols

[via Digitalmars-d-bugs]

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

--- Comment #8 from github-bugzi...@puremagic.com ---
Commit pushed to newCTFE at https://github.com/dlang/tools

https://github.com/dlang/tools/commit/72ab90ceadd6a421126643cef6780b8be96f5d17
dman: Use d-tags.json instead of d.tag

--

[Issue 17731] dman fails to build due to more than 32767 symbols

[via Digitalmars-d-bugs]

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to newCTFE at https://github.com/dlang/installer

https://github.com/dlang/installer/commit/ef720edff651d8d2c2c20d39940f9162f73d2f3e
disable dman to workaround Issue 17731

https://github.com/dlang/installer/commit/17c6c70a931329c0bce2442fcb121ec0733ea1a4
Merge pull request #240 from MartinNowak/workaround_17731

https://github.com/dlang/installer/commit/e356e3710410dde59c5707b903c3f913a41e2925
remove dman from installers to workaround Issue 17731

https://github.com/dlang/installer/commit/7c7006ef85833155db5c6af6c0cc377d3ca8
Merge pull request #241 from MartinNowak/workaround_17731

--

[Issue 17317] 2.074.0 release candidate does not have updated backend license

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to newCTFE at https://github.com/dlang/installer

https://github.com/dlang/installer/commit/b3fcff745fd8234140d57c49a6d21eae91e6f785
Fix Issue 17317 - 2.074.0 release candidate does not have updated backend
license

https://github.com/dlang/installer/commit/6a2ac3ccb0754ae0c541d531c5a7f8ab093ef30d
Merge pull request #229 from wilzbach/update-dmd-license

--

[Issue 17614] [REG2.075.0-b2] __VERSION__ has the wrong value

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to newCTFE at https://github.com/dlang/installer

https://github.com/dlang/installer/commit/5a92cda46371382ff03276970dd970d1a9718851
fix Issue 17614 - __VERSION__ has the wrong value

https://github.com/dlang/installer/commit/500302cdddb8c7b7ab656b565b7144ab7ac39dbf
Merge pull request #237 from MartinNowak/fix17614

--

Re: I'm the new package maintainer for D on ArchLinux

[Guillaume Piolat via Digitalmars-d-announce]

On Wednesday, 9 August 2017 at 20:42:48 UTC, Wild wrote:

- Discord: https://discordapp.com/invite/bMZk9Q4


Just wanted to say that this Discord server is a very nice D 
sub-community, and Discord itself is more impressive than your 
typical IRC alternative.

Re: GC operates in LIFO sequence?

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 9 August 2017 at 17:38:15 UTC, Swoorup Joshi wrote:


Is garbage collection even useful besides managing memory?


GC has the unique advantage of being a global owner, hence 
avoiding to encode ownership into types for memory (when you can 
use it).

Re: Import modules too verbose in some cases

[Rene Zwanenburg via Digitalmars-d]

On Wednesday, 9 August 2017 at 23:57:19 UTC, Johnson Jones wrote:
Sometimes one doesn't want to import either the whole module 
nor specify a single function to import. It seems that 
basically D has all the info to import the function implicitly 
because it usually gives a nice error message tells us which 
module to import for the function.


It doesn't have that information available, and that's unlikely 
to change due to the compilation model. Rather, a few very common 
cases have been hardcoded in the compiler:


https://github.com/dlang/dmd/blob/4d86fcba2fd2ef86cc85738cd2ac2b059dbb5800/src/ddmd/imphint.d

[Issue 17738] New: access to local alias from outside compiles but execution hangs

[via Digitalmars-d-bugs]

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

  Issue ID: 17738
   Summary: access to local alias from outside compiles but
execution hangs
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: domini...@scherkl.de

import std.traits;

foo.C foo(T, U)(const(T) a, const(U) b)
{
   alias C = CommonType!(T, U);
   return cast(C)a + cast(C)b;
}
// compiles, but execution hangs (programm uses 100% CPU and only ends after
stack overflow is reached some time later)

CommonType!(T, U) foo2(T, U)(const(T) a, const(U) b)
{
   alias C = CommonType!(T, U);
   return cast(C)a + cast(C)b;
}
// compiles and runs fine

--

Re: delegates/lambas do not pick up calling convention

[ag0aep6g via Digitalmars-d-learn]

On 08/10/2017 01:52 AM, Johnson Jones wrote:

I've tried

 import gdk.Threads;
 alias DD = static 
extern(C) int delegate(void*);

 auto x = (void*)
 {
 return 1;
 };
 
gdk.Threads.threadsAddIdle(x, null);


1) You probably meant to apply `DD` to `x`.
2) `x` must be a `function`, not a `delegate`.
3) (optional) `static` is not needed.

So:


import gdk.Threads;
alias DD = extern(C) int function(void*);
DD x = (void*)
{
return 1;
};
gdk.Threads.threadsAddIdle(x, null);

[Issue 17737] New: Empty of -e option for MSVC

[via Digitalmars-d-bugs]

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

  Issue ID: 17737
   Summary: Empty of -e option for MSVC
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: daewon4...@gmail.com

The -e is thought to be transformed to /E or /EP in MSVC, but it seems the
command option is not processed
properly.(https://github.com/dlang/dmd/blob/master/src/vcbuild/msvc-dmc.d)

Is it deliberately omitted? or should be added as follows?



case "-e": // "show results of preprocessor"
newArgs ~= "/E";
break;


--

Re: Calling C++ "void foo(Klass&)"

[Arjan via Digitalmars-d]

On Thursday, 10 August 2017 at 00:32:40 UTC, Mengu wrote:
my second question is: i have no idea what's going on in this 
file: 
https://github.com/whoshuu/cpr/blob/master/include/cpr/body.h 
i'd appreciate some pointers.


A new 'type' named Body which IS-A std::string is defined.
To construct a Body there are various options:
The ctors 'default': Body(), 'copy': Body(const Body&) and 
'move': Body(Body&&) ctors are using the compiler generated 
default implementation.

The same is true for the assignment operators =
Then a few explicit conversion ctors are defined to construct a 
Body from a const char* string and std::string. Explicit means 
the compiler is not allowed to implicit convert to std::string or 
const char* for provide args not being a const char* or 
std::string but for which a conversion exists.


Since the h file also contains the definitions, the compiler must 
inline the code for the Body ctors and assignment operator. It 
also means not C/cpp file is needed since the function bodies are 
already in the h file.


HTH

Re: long strings seem to only display ""

[Rainer Schuetze via Digitalmars-d-debugger]

On 06.08.2017 20:32, Rainer Schuetze wrote:



On 06.08.2017 05:34, FoxyBrown wrote:
Was having a strange debug issue until I checked the visualizer on the 
string and realized it was just a long string ;/


mago is showing long strings as "" making one think they are empty.

instead, the first n chars should be shown with an ellipse is

e.g.,

"This is a very long str"...


I noticed this recently, too, but didn't get around to fixing it. 
wstring and dstring are ok, but string is limited to 200 characters.


Should be fixed in the next release.


Released now in https://github.com/dlang/visuald/releases/tag/v0.45.1-rc2

Re: D on AArch64 CPU

[David J Kordsmeier via Digitalmars-d-learn]

On Wednesday, 9 August 2017 at 08:37:53 UTC, Johannes Pfau wrote:


Iain recently updated GDC & phobos up to 2.074 and we have a 
pull request for 2.075. So don't worry about fixing old GDC 
phobos/druntime versions, recent gdc git branches should 
already have AArch64 phobos changes.


We have a test runner for AArch and GDC master here: 
https://buildbot.dgnu.org/#/builders/2/builds/29


There are still some failing test suite tests though and AFAICS 
we currently don't build phobos on that CI at all.


(We can run ARM/AArch tests without special hardware, thanks to
QEMU's user mode emulation)

-- Johannes


Thanks both for the reply.   I'll be interested to try both gdc 
and the ldc cross compiler options.

Re: Visual Studio Code code-d serve-d beta release

[Dmitry via Digitalmars-d-announce]

On Wednesday, 9 August 2017 at 14:39:12 UTC, WebFreak001 wrote:
try using the C/C++ Extension in vscode which uses the visual 
studio debugger, that one works great on windows for D


OMG, it's really works. Thank you alot!
I'll try to use VSCode as main IDE for D code.

Re: VisualD: ModuleInfo Errors

[Rainer Schuetze via Digitalmars-d-debugger]

On 09.08.2017 23:24, Johnson Jones wrote:
I routinely get this error when I forget to add a module that I import 
to the project. It throughs me for a loop because the error doesn't 
really make sense for what is actually wrong(or does it?):



  Error 42: Symbol Undefined _D9DLLImport12__ModuleInfoZ 
(DLLImport.__ModuleInfo)


Adding DLLImport.d to the project solves the problem.

I guess this is due to the fact that the module does not have a library 
backing and the __ModuleInfo function isn't generated for it so it 
doesn't exist anywhere? (Just guessing)


The symbol reference to the ModuleInfo is usually caused by an import. 
It is added to the ModuleInfo of the importing module to ensure properly 
ordered execution of (shared) static constructors. Only modules that 
have "static this()" or that import modules that have it are affected.




Is there any way Visual D can help with this? Either watch out for the 
error(I guess this is a dmd problem) and rename it or add a hint about 
adding it to the project or somehow detect the modules and add them 
silently to the command line or even auto add them to the project?





Visual D already helps a bit by demangling the symbol and adding it to 
the error message (the part in parenthesis is not emitted by the linker).


I don't think silently trying to add modules to the command line is a 
good idea (follow-up errors can cause even more confusion). Making 
suggestions regarding missing symbols could be helpful, though. dmd 
already does that on Posix systems if no "main" is defined.

Re: Visual D Map Files

[Rainer Schuetze via Digitalmars-d-debugger]

On 09.08.2017 22:16, Johnson wrote:
Do generating these at all help with anything? e.g., what does full 
and/or cross-references do as far as the debugging experience is 
concerned? Does it add anything that none does as far as dmd, mago, and 
visual D is concerned?


The map files are a human digestible log of what the linker did. It 
shows you what has ended up in the binary and how much space it takes 
up. It is not used/needed for the debugger.


A machine can do nice things with it, too. Try feeding it into 
http://thecybershadow.net/d/mapview/

Re: Jetbrains announce support for rust plugin, show them we want one too!

[Dmitry via Digitalmars-d]

On Wednesday, 9 August 2017 at 20:29:07 UTC, 12345swordy wrote:
You edit the json file of course. That how DUB generates 
solution files for visual D and other IDE's.


This breaks changes that was done in the VS project.