Re: Getting DUB to work with VS 2017

On Monday, 22 May 2017 at 01:49:48 UTC, Enjoys Math wrote: I did `dub generate visuald project_name`. VS 2017 loads the .sln file except for red 'x's on the dub.json files. My dub.json file looks like (if it matters): { "name": "pegparser", "targetName": "PEGparser",

Getting DUB to work with VS 2017

I did `dub generate visuald project_name`. VS 2017 loads the .sln file except for red 'x's on the dub.json files. My dub.json file looks like (if it matters): { "name": "pegparser", "targetName": "PEGparser", "authors": [ "Fruitful Approach" ],

Re: C++ binding issues with C++ function returning a simple POD struct.

On Monday, 22 May 2017 at 01:27:22 UTC, Nicholas Wilson wrote: On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote: I am statically linking to ImGui [1] on Win 10 x64, quite successfully till this issue came up. The noticed error so far comes when an ImGui function returns an ImVec2, a

Re: DMD VS2017 Support

On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote: On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227 I really like this

Re: C++ binding issues with C++ function returning a simple POD struct.

On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote: I am statically linking to ImGui [1] on Win 10 x64, quite successfully till this issue came up. The noticed error so far comes when an ImGui function returns an ImVec2, a simple POD struct of two float members. I can use this struct

Re: Non-x86 targets for DMD

On Wednesday, 17 May 2017 at 22:16:35 UTC, Kagamin wrote: Can't you run it in qemu? Probably I could, might even work parallel with other stuff, especially stuff that are mainly lexical (register naming, etc). So far I studied the ARM assembly language, and it seems less scary than the x86

Re: Why would an initialised struct pointer field be null in the struct's destructor?

On Monday, 22 May 2017 at 00:45:27 UTC, Adam D. Ruppe wrote: On Monday, 22 May 2017 at 00:36:24 UTC, Stanislav Blinov wrote: I can't think of any case where you'd want preconditions on destructor when the object is in .init state. I think we're actually saying the same thing: I mean the

Re: Why would an initialised struct pointer field be null in the struct's destructor?

On Monday, 22 May 2017 at 00:36:24 UTC, Stanislav Blinov wrote: I can't think of any case where you'd want preconditions on destructor when the object is in .init state. I think we're actually saying the same thing: I mean the destructor must be callable on .init so you might do like struct

Re: Why would an initialised struct pointer field be null in the struct's destructor?

On Monday, 22 May 2017 at 00:23:26 UTC, Adam D. Ruppe wrote: On Sunday, 21 May 2017 at 14:13:20 UTC, Stanislav Blinov wrote: Not if you either emplace() or blit Foo.init into all of the array elements. You especially need to be safe calling ~this on Foo.init. How so? .init is supposed to be

Re: Why would an initialised struct pointer field be null in the struct's destructor?

On Sunday, 21 May 2017 at 14:13:20 UTC, Stanislav Blinov wrote: Not if you either emplace() or blit Foo.init into all of the array elements. You especially need to be safe calling ~this on Foo.init.

Re: Why would an initialised struct pointer field be null in the struct's destructor?

On Sunday, 21 May 2017 at 23:59:08 UTC, Guillaume Piolat wrote: On Sunday, 21 May 2017 at 12:48:10 UTC, Adam D. Ruppe wrote: Any struct should be able to have its destructor called Does this rule also applies to class objects? Yes. If your destructor does modify the state, you should expect

Re: Why would an initialised struct pointer field be null in the struct's destructor?

On Sunday, 21 May 2017 at 12:48:10 UTC, Adam D. Ruppe wrote: Any struct should be able to have its destructor called Does this rule also applies to class objects?

Re: [WEKA] Calling fork() and D runtime

On Monday, 15 May 2017 at 11:33:29 UTC, Jonathan Shamir wrote: Hey, This is my first time writing in the D forums! I have an application written in D that runs as a linux daemon (some python service script is in charge of running and daemonizing it). This "agent" works similar to docker - a

Re: DMD VS2017 Support

On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227 I really like this philosophy: "It does not work, a fix is available, but it

Re: Socket missing option: SO_REUSEPORT

On Wednesday, 21 December 2016 at 16:49:53 UTC, Damian wrote: SO_REUSEPORT is not supported on Windows. Is is supported on linux. On Windows the behavior of SO_REUSEPORT is included in SO_REUSEADDR. I submitted an issue to get this fixed for Linux.

[Issue 17416] New: SocketOption.REUSEPORT not available on linux

https://issues.dlang.org/show_bug.cgi?id=17416 Issue ID: 17416 Summary: SocketOption.REUSEPORT not available on linux Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: normal

Re: Value closures (no GC allocation)

On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote: Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat. :)

Re: C++ binding issues with C++ function returning a simple POD struct.

On Sunday, 21 May 2017 at 19:58:32 UTC, Stefan Koch wrote: On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote: I am statically linking to ImGui [1] on Win 10 x64, quite successfully till this issue came up. The noticed error so far comes when an ImGui function returns an ImVec2, a

Re: Value closures (no GC allocation)

On Sunday, 21 May 2017 at 20:09:14 UTC, Stanislav Blinov wrote: is a function that is generated by the template. It accesses the frame of create(). Am I missing something? It does access the frame, but only long enough to copy the values into the struct there's no reason for that to

Re: Value closures (no GC allocation)

On Sunday, 21 May 2017 at 19:43:32 UTC, Adam D. Ruppe wrote: On Sunday, 21 May 2017 at 19:11:46 UTC, Stanislav Blinov wrote: Looks cool, but it'd still want a GC closure, won't it? No, it just generates the same struct you'd write manually. That should work fine with @nogc now. auto

Re: C++ binding issues with C++ function returning a simple POD struct.

On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote: I am statically linking to ImGui [1] on Win 10 x64, quite successfully till this issue came up. The noticed error so far comes when an ImGui function returns an ImVec2, a simple POD struct of two float members. I can use this struct

Re: Value closures (no GC allocation)

On Sunday, 21 May 2017 at 19:11:46 UTC, Stanislav Blinov wrote: Looks cool, but it'd still want a GC closure, won't it? No, it just generates the same struct you'd write manually. That should work fine with @nogc now.

Re: My two cents on what D needs to be more successful...

On Sunday, 21 May 2017 at 18:29:46 UTC, Adam D. Ruppe wrote: On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote: * the following *standard* libraries : Suppose I made a dmd distribution with my libraries pre-packaged (I already have libraries for most the stuff you listed)...

C++ binding issues with C++ function returning a simple POD struct.

I am statically linking to ImGui [1] on Win 10 x64, quite successfully till this issue came up. The noticed error so far comes when an ImGui function returns an ImVec2, a simple POD struct of two float members. I can use this struct as argument to functions but when it is returned from a

Re: Value closures (no GC allocation)

On Sunday, 21 May 2017 at 18:17:57 UTC, Adam D. Ruppe wrote: But, using the struct stuff, we can add some artificial sweetener now: return bar(lambda!(x, q{ (int y) => x + y })); You pass the captures first, then a q{} string literal of the lambda. Here's the implementation of that lambda

Re: My two cents on what D needs to be more successful...

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote: * the following *standard* libraries : Suppose I made a dmd distribution with my libraries pre-packaged (I already have libraries for most the stuff you listed)... would that work for you? Or must it come from the dlang.org site

Re: Value closures (no GC allocation)

On Sunday, 21 May 2017 at 04:08:04 UTC, Vittorio Romeo wrote: This exact statement applied to C++ before C++11, but the introduction of lambda expression significantly changed the way people write and think about C++. Sometimes syntactic sugar can have huge impact on a language. Oh

Re: Why: error("multiple ! arguments are not allowed");

On Sunday, 21 May 2017 at 14:11:00 UTC, Stanislav Blinov wrote: On Sunday, 21 May 2017 at 13:42:50 UTC, Vladimir Panteleev wrote: On Sunday, 21 May 2017 at 13:08:18 UTC, Adam D. Ruppe wrote: foo!(x)!y I think it's the same as foo!x!y. As for the reason - I think because the order is

[Issue 15740] Indexing a std.typecons.Tuple with names doesn't work in ctfe

https://issues.dlang.org/show_bug.cgi?id=15740 bastien penavayre changed: What|Removed |Added CC|

Re: Value closures (no GC allocation)

Hi Vittorio, wonderful to see you here after C++Now! :) On 05/20/2017 09:08 PM, Vittorio Romeo wrote: >consider this code: > > void delegate()[] arr; > > foreach(i; 0..5) > { > arr ~= () => writeln(i); > } > > foreach(f; arr) > { > f(); > } > > This

Re: Is there websocket client implementation for D

On Wednesday, 25 March 2015 at 15:46:31 UTC, Adam D. Ruppe wrote: On Wednesday, 25 March 2015 at 07:12:56 UTC, thedeemon wrote: It's for server side, but probably contains stuff you need for client too. Yeah, I've been meaning to write a client for a while but haven't gotten around to it

WebSocket lib

Which one would you recommended for working with browser socket client and D-based client (abstracted aoi)?

Re: Multiple template variadic list not working

On Sunday, 21 May 2017 at 15:30:38 UTC, Stanislav Blinov wrote: In this case, eponymous template should do the trick: template func(UserArgs...) { void func(Arguments...)(Arguments args) {} } Ah I see, I didn't know of this technique. Thanks.

Re: Multiple template variadic list not working

On Sunday, 21 May 2017 at 15:13:55 UTC, bastien penavayre wrote: I've been trying to translate the following idea expressed here in c++: template void func(Arguments... args) {} so I tried void func(UserArgs..., Arguments...)(Arguments args) {} and then void func(Args...)(Filter!(isType,

Re: Multiple template variadic list not working

On Sunday, 21 May 2017 at 15:16:55 UTC, Stefan Koch wrote: How would that work ? How would I know where UserArgs end, and Arguments begin ? func!(UserArgs here)(Arguments values here); C++ does it without any problem. I don't see what prevent D from doing it.

Re: Multiple template variadic list not working

On Sunday, 21 May 2017 at 15:13:55 UTC, bastien penavayre wrote: I've been trying to translate the following idea expressed here in c++: template void func(Arguments... args) {} so I tried void func(UserArgs..., Arguments...)(Arguments args) {} and then void func(Args...)(Filter!(isType,

Multiple template variadic list not working

I've been trying to translate the following idea expressed here in c++: template void func(Arguments... args) {} so I tried void func(UserArgs..., Arguments...)(Arguments args) {} and then void func(Args...)(Filter!(isType, Args) args) {} but nothing works. This seems like something

Re: CTFE Status 2

On Tuesday, 16 May 2017 at 13:44:27 UTC, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] So ... I just encountered more ABI issues; related to slices which are part of structures. struct R { uint[] s1; uint[] s2; } like this. R

Re: Why: error("multiple ! arguments are not allowed");

On Sunday, 21 May 2017 at 13:42:50 UTC, Vladimir Panteleev wrote: On Sunday, 21 May 2017 at 13:08:18 UTC, Adam D. Ruppe wrote: foo!(x)!y I think it's the same as foo!x!y. As for the reason - I think because the order is possibly ambiguous or something? You could interpret it as either

Re: Why would an initialised struct pointer field be null in the struct's destructor?

On Sunday, 21 May 2017 at 12:48:10 UTC, Adam D. Ruppe wrote: On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote: // Why is this._foo null here??? The others have answered why and what to do, but note that according to the spec, that any struct should be able to

Re: My two cents on what D needs to be more successful...

Ok :) Thanks for the quick answer !

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

https://issues.dlang.org/show_bug.cgi?id=15246 Stanislav Blinov changed: What|Removed |Added CC|

Re: Why: error("multiple ! arguments are not allowed");

On Sunday, 21 May 2017 at 13:08:18 UTC, Adam D. Ruppe wrote: foo!(x)!y I think it's the same as foo!x!y. As for the reason - I think because the order is possibly ambiguous or something? You could interpret it as either (foo!x)!y or foo!(x!y).

Re: Why: error("multiple ! arguments are not allowed");

On Sunday, 21 May 2017 at 13:08:18 UTC, Adam D. Ruppe wrote: If I comment that line and use the hacked dmd, it seems to work. Well, not exactly work, it didn't actually instantiate the inner template like it probably should have. So is it just not implemented correctly and became an error

Why: error("multiple ! arguments are not allowed");

Why is that prohibited? I just wrote template foo(x) { template foo(y) {}} and did foo!(x)!y and it triggered that error. If I comment that line and use the hacked dmd, it seems to work. So why is that error there?

Re: Why would an initialised struct pointer field be null in the struct's destructor?

On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote: // Why is this._foo null here??? The others have answered why and what to do, but note that according to the spec, that any struct should be able to have its destructor called, so you should do a null check in

Re: Please provide DMD as 64 executable

On Sunday, 21 May 2017 at 01:29:58 UTC, Laeeth Isharc wrote: There a Visual D script, but I do not know how to use that using msbuild. We had some trickiness at work regarding this. You essentially need to invoke devenv instead of msbuild if you want to script the process. Of course, now

Re: Why is DUB not passing dll.def file to linker

On Sunday, 21 May 2017 at 11:47:15 UTC, Mike Parker wrote: So what I would try in your situation is to add three new configurations to the exeProject's dub.json. Use the "platforms" directive to limit one to "windows-x86", another to "windows-x86_64", and leave the other one empty. List the

Re: Why would an initialised struct pointer field be null in the struct's destructor?

On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote: Looks like you would want to use emplace [0] here. public this(int n) { this._data = (cast(Foo*) calloc(n, Foo.sizeof))[0 .. n]; foreach(ref element; this._data) {

Re: My two cents on what D needs to be more successful...

On Sunday, 21 May 2017 at 11:27:19 UTC, Ecstatic Coder wrote: Coedit is actually by far my favorite IDE for D testing and debugging. I liked it immediately after I saw that it doesn't need to create a project if all you need it compile and test a small D script. I know I can create a

Re: Why is DUB not passing dll.def file to linker

On Sunday, 21 May 2017 at 11:42:02 UTC, Mike Parker wrote: On Sunday, 21 May 2017 at 10:53:42 UTC, Igor wrote: Dynamic libraries are not yet supported as dependencies - building as static library. I see. And I'm not surprised. DLL support on Windows (at least in DMD, not sure about LDC)

Re: Why is DUB not passing dll.def file to linker

On Sunday, 21 May 2017 at 10:53:42 UTC, Igor wrote: Dynamic libraries are not yet supported as dependencies - building as static library. I see. And I'm not surprised. DLL support on Windows (at least in DMD, not sure about LDC) is still not where it needs to be. I don't know how much has

Re: Please provide DMD as 64 executable

On Sunday, 21 May 2017 at 01:29:58 UTC, Laeeth Isharc wrote: On Friday, 19 May 2017 at 10:38:56 UTC, Andre Pany wrote: Should I file an issue for providing the 64 build of dmd on windows? As 64 bit is the default on the other platforms it should be available for windows too by default. Kind

Re: My two cents on what D needs to be more successful...

On Sunday, 21 May 2017 at 06:55:19 UTC, rikki cattermole wrote: On 21/05/2017 7:51 AM, Ecstatic Coder wrote: Exactly what I was talking about :D Thanks for your efforts !!! I'll download and test them right away. Keep in mind that they are not on code.dlang.org for a reason, they are not

Re: My two cents on what D needs to be more successful...

Coedit is actually by far my favorite IDE for D testing and debugging. I liked it immediately after I saw that it doesn't need to create a project if all you need it compile and test a small D script. I know I can create a project, but for tiny projects I don't use it on purpose, despite I

Re: Why is DUB not passing dll.def file to linker

On Sunday, 21 May 2017 at 10:15:40 UTC, Mike Parker wrote: Then you can add the following to exeProject/dub.json: "dependencies": { "dllProjectName": {"path" : "../dllProject" } } I would expect the import lib to be linked automatically. This should ensure the dll is compiled with the

Re: Why is DUB not passing dll.def file to linker

On Sunday, 21 May 2017 at 09:37:56 UTC, Igor wrote: If I now run dub build in main project both projects compile and work together, but if I run dub build -ax86_64 only main project is built as 64bit while dll project is still being built as 32bit. Does anyone have a suggestion how can I make

Re: My two cents on what D needs to be more successful...

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote: Since a few months, I'm using D for all my command-line tools. For that use case, the language and its standard libraries are really perfect, making it the best scripting language I know, completely exploding JavaScript, Python,

Re: Implicit conversion from 'Ok' to 'Result' type when returning functions

On Sunday, 21 May 2017 at 09:55:41 UTC, David Zhang wrote: On Sunday, 21 May 2017 at 09:37:46 UTC, Nicholas Wilson wrote: On Sunday, 21 May 2017 at 09:29:40 UTC, David Zhang wrote: Well then it becomes Result!(T, E) ok(T,E) (T t) { return Result(t); } Result!(T, E) error(T,E)(E e) {

Re: Implicit conversion from 'Ok' to 'Result' type when returning functions

On Sunday, 21 May 2017 at 09:37:46 UTC, Nicholas Wilson wrote: On Sunday, 21 May 2017 at 09:29:40 UTC, David Zhang wrote: Well then it becomes Result!(T, E) ok(T,E) (T t) { return Result(t); } Result!(T, E) error(T,E)(E e) { return Result(e); } and then provided it can be inferred (e.g.

Re: Why is DUB not passing dll.def file to linker

On Saturday, 20 May 2017 at 21:36:42 UTC, Mike Parker wrote: On Saturday, 20 May 2017 at 20:26:29 UTC, Igor wrote: So my question is if the fix is so simple what are the reasons it isn't implemented? Am I missing something? I don't know, but you could always submit a PR or an enhancement

Re: Implicit conversion from 'Ok' to 'Result' type when returning functions

On Sunday, 21 May 2017 at 09:29:40 UTC, David Zhang wrote: On Sunday, 21 May 2017 at 09:15:56 UTC, Nicholas Wilson wrote: have free functions Result!(T, ErrorEnum) ok(T)(T t) { return Result(t); } Result!(T, ErrorEnum) error(T)(ErrorEnum e) { return Result(e); } then go if (!foo)

Re: Implicit conversion from 'Ok' to 'Result' type when returning functions

On Sunday, 21 May 2017 at 09:15:56 UTC, Nicholas Wilson wrote: have free functions Result!(T, ErrorEnum) ok(T)(T t) { return Result(t); } Result!(T, ErrorEnum) error(T)(ErrorEnum e) { return Result(e); } then go if (!foo) return ok(42); else return error(Error.fooHappened); Ah,

Re: Implicit conversion from 'Ok' to 'Result' type when returning functions

On Sunday, 21 May 2017 at 08:44:31 UTC, David Zhang wrote: Hi, I was reading a bit about this in Rust, and their enum type. I was wondering if this is replicate-able in D. What I've got right now is rather clunky, and involves using `typeof(return).ok` and `typeof(return).error)`.

Implicit conversion from 'Ok' to 'Result' type when returning functions

Hi, I was reading a bit about this in Rust, and their enum type. I was wondering if this is replicate-able in D. What I've got right now is rather clunky, and involves using `typeof(return).ok` and `typeof(return).error)`. While that's not too bad, it does involve a lot more typing,

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

https://issues.dlang.org/show_bug.cgi?id=16856 --- Comment #7 from Nemanja Boric <4bur...@gmail.com> --- Ha, that's a bummer. I'm on a holiday right now with limited access to workstation, but I'll give it a look in early June. --

Re: My two cents on what D needs to be more successful...

On 21/05/2017 7:51 AM, Ecstatic Coder wrote: Exactly what I was talking about :D Thanks for your efforts !!! I'll download and test them right away. Keep in mind that they are not on code.dlang.org for a reason, they are not ready for general use. So take a developers mindset if you use

Re: My two cents on what D needs to be more successful...

Exactly what I was talking about :D Thanks for your efforts !!! I'll download and test them right away.

Islyf;dh

testdasdas

Re: Fluent APIs

On Sunday, 21 May 2017 at 05:18:33 UTC, Russel Winder wrote: I am having a crisis of confidence. In two places I have structurally: datum.action() .map!(…) and then the fun starts as I need to actually do a flatMap. In one of the two places I have to: .array .joiner; but

Islyf;dh

test

Re: My two cents on what D needs to be more successful...

This is the work I am related to or created myself. - std.ui.windowing[0] - std.ui.gui - std.graphics.image[1] - std.graphics.color[2] - std.events[0] - std.events.loop[0] - std.audio - std.sockets[0] Any assistance to improving my work including[3] would be appreciated as I am slow. [0]