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",
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"
],
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
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
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
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
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
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.
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
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?
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
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
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
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
Which one would you recommended for working with browser socket
client and D-based client (abstracted aoi)?
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.
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,
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.
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,
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
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
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
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
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)
{
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)
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
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
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
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) {
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.
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
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)
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,
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)`.
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,
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
36 matches
Mail list logo
