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",
"authors": [
"Fruitful Approach"
],
"description": "A parser for LED UX Designer using pegged.",
"copyright": "Copyright 2017, fruitfulappro...@gmail.co",
"license": "proprietary",
"dependencies": {
"pegged": "~>0.4.2",
"pyd": "~>0.9.9",
}
}
Building gives errors although doing `dub build` at the command
line works.
Shouldn't the build command be `dub build` instead of `$(CC)
-c` ?
How do I make this work. Otherwise, I will just make calls to
a D app from python over the command line or something...
Build Errors:
---
-- Build started: Project: pegparser, Configuration: debug
Win32 --
Building
C:\Users\Gabe\Dropbox\MyProjects\___SOUND_UNITED\LED_UX_Designer\lang\PEGparser\PEGparser.exe...
Microsoft (R) Incremental Linker Version 14.10.25019.0
Copyright (C) Microsoft Corporation. All rights reserved.
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\source\led_ux_grammar.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\source\main.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\abstract_.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\ast.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\boolobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\bufferobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\bytearrayobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\bytesobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\cellobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\ceval.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\classobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\cobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\code.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\codecs.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\compile.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\complexobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\cStringIO.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\datetime.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\descrobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\dictobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\enumobject.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\errcode.obj+
obj\debug\dummy\dummy\dummy\dummy\dummy\dummy\dummy\pegparser\..\..\..\..\..\..\..\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\eval.obj+
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"
],
"description": "A parser for LED UX Designer using pegged.",
"copyright": "Copyright 2017, fruitfulappro...@gmail.co",
"license": "proprietary",
"dependencies": {
"pegged": "~>0.4.2",
"pyd": "~>0.9.9",
}
}
Building gives errors although doing `dub build` at the command
line works.
Shouldn't the build command be `dub build` instead of `$(CC) -c` ?
How do I make this work. Otherwise, I will just make calls to a
D app from python over the command line or something...
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 simple POD
struct of two float members. I can use this struct as argument
to functions but when it is returned from a function I get a
0xC005: Access violation reading location
0x. I can even debug the process with Visual
Studion, mixed d and c++ sources. The functions I tested
return data from some internal global ImGui data, which I can
fully examine, the crash happens on the return statement.
Moreover, some functions have variations which return only one
component from that ImVec2 POD, which do work as expected,
e.g.:
ImVec2 GetCursorPos(); // crash
float GetCursorPosX(); // works
float GetCursorPosY(); // works
The latter do basically the same as the first one, but return
ImVec.x or .y respectively.
How could I further debug this?
If somebody would be willing to look at the source, the
binding is here [2].
[1] https://github.com/ocornut/imgui
[2] https://github.com/ParticlePeter/imgui_lib
Probably because the D side is expecting to have the struct
returned in a pointer allocated by the callee and then the C++
puts it in regs and BOOM.
If you wrap the C++ side to return the struct by a pointer then
use that in D, then it should work.
And this is actually D problem. In fact first bug report on this
thing was dated back to 2014. Still not fixed.
There is possible hacky workaround to try - put struct as pointer
arg instead of return and make helper method to use it, like this
HACK ---
// extern(C++) of course
void GetCursorPos(ImVec2* v);
// helper
ImVec2 GetCursorPos()
{
ImVec2 temp;
GetCursorPos();
return temp;
}
--
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 as argument to functions but when it is returned from a function I get a 0xC005: Access violation reading location 0x. I can even debug the process with Visual Studion, mixed d and c++ sources. The functions I tested return data from some internal global ImGui data, which I can fully examine, the crash happens on the return statement. Moreover, some functions have variations which return only one component from that ImVec2 POD, which do work as expected, e.g.: ImVec2 GetCursorPos(); // crash float GetCursorPosX(); // works float GetCursorPosY(); // works The latter do basically the same as the first one, but return ImVec.x or .y respectively. How could I further debug this? If somebody would be willing to look at the source, the binding is here [2]. [1] https://github.com/ocornut/imgui [2] https://github.com/ParticlePeter/imgui_lib Probably because the D side is expecting to have the struct returned in a pointer allocated by the callee and then the C++ puts it in regs and BOOM. If you wrap the C++ side to return the struct by a pointer then use that in D, then it should work.
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
destructor must be callable on .init so you might do like
struct Foo {
int* ptr;
~this() {
// might be called with ptr is null cuz of .init
// so wanna check
if(ptr !is null) free(ptr);
}
}
Ah, yes, exactly. The page is indeed the same one.
P.S. Though it's fine to call free with a null pointer :P
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 Foo {
int* ptr;
~this() {
// might be called with ptr is null cuz of .init
// so wanna check
if(ptr !is null) free(ptr);
}
}
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 destructible without question. destroy() calls in the runtime also blit the initializer back over the destructed objects. std.algorithm.move et al. specifically take advantage of .init (blit it over the moved-from object, so it can either be destructed or assigned something else). I can't think of any case where you'd want preconditions on destructor when the object is in .init state.
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 it to be called and have the state ready for it. When you're using the GC, destructors *may* not be called under certain conditions: http://dlang.org/spec/class.html#destructors But there's no stopping you from destructing manually (via destroy() call), or by allocating classes manually via malloc or on the stack.
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: 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 simple POD struct of two float members. I can use this struct as argument to functions but when it is returned from a function I get a 0xC005: Access violation reading location 0x. I can even debug the process with Visual Studion, mixed d and c++ sources. The functions I tested return data from some internal global ImGui data, which I can fully examine, the crash happens on the return statement. Moreover, some functions have variations which return only one component from that ImVec2 POD, which do work as expected, e.g.: [...] are you aware of https://github.com/Extrawurst/DerelictImgui ? Yes I am, its (understandably) not being updated too regularly, it goes the route of creating a C binding, and a D binding on top, lot of work. We should be able to bind the C++ variant directly by now I think.
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 as argument to functions but when it is returned from a function I get a 0xC005: Access violation reading location 0x. I can even debug the process with Visual Studion, mixed d and c++ sources. The functions I tested return data from some internal global ImGui data, which I can fully examine, the crash happens on the return statement. Moreover, some functions have variations which return only one component from that ImVec2 POD, which do work as expected, e.g.: [...] are you aware of https://github.com/Extrawurst/DerelictImgui ?
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 function I get a 0xC005: Access violation reading location 0x. I can even debug the process with Visual Studion, mixed d and c++ sources. The functions I tested return data from some internal global ImGui data, which I can fully examine, the crash happens on the return statement. Moreover, some functions have variations which return only one component from that ImVec2 POD, which do work as expected, e.g.: ImVec2 GetCursorPos(); // crash float GetCursorPosX(); // works float GetCursorPosY(); // works The latter do basically the same as the first one, but return ImVec.x or .y respectively. How could I further debug this? If somebody would be willing to look at the source, the binding is here [2]. [1] https://github.com/ocornut/imgui [2] https://github.com/ParticlePeter/imgui_lib
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 yet. What you do is make a HTTP request with a particular header, and if the server likes it, you're OK and can send messages. If not, the failure should be gracefully reported. Could probably write it up in a couple hours if I had a couple hours :( How about now?
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, Args) args) {}
but nothing works.
This seems like something simple to handle, why is it not then ?
In this case, eponymous template should do the trick:
template func(UserArgs...) {
void func(Arguments...)(Arguments args) {}
}
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, Args) args) {}
but nothing works.
This seems like something simple to handle, why is it not then ?
How would that work ?
How would I know where UserArgs end, and Arguments begin ?
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 simple to handle, why is it not then ?
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 have its destructor called, so you should do a null check in there anyway. Not if you either emplace() or blit Foo.init into all of the array elements.
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 there anyway.
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 empty one last and it should become the default on non-Windows platforms. Move your preBuildCommands directive to the windows-x86 configuration, and copy it to the windows-x86_64 configuration with the addition of "-ax86_64" to the "dub build" command. Thanks for the suggestion Mike. I just added this for now and it works: "preBuildCommands-x86_64": ["cd game & dub build -ax86_64"], "preBuildCommands-x86": ["cd game & dub build"],
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)
{
auto tmp = Foo(1);
element = tmp;
}
}
Cheers,
Eduard
[0] - https://dlang.org/phobos/std_conv.html#.emplace.3
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) is still not where it needs to be. I don't know how much has changed since Benjiman Thaut's DConf talk last year [1], but I don't recall any major announcements. I expect there aren't a whole lot of people actively developing shared libraries in D. [1] http://dconf.org/2016/talks/thaut.html 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 empty one last and it should become the default on non-Windows platforms. Move your preBuildCommands directive to the windows-x86 configuration, and copy it to the windows-x86_64 configuration with the addition of "-ax86_64" to the "dub build" command.
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 changed since Benjiman Thaut's DConf talk last year [1], but I don't recall any major announcements. I expect there aren't a whole lot of people actively developing shared libraries in D. [1] http://dconf.org/2016/talks/thaut.html
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 same architecture as
the exe.
DUB reports:
Dynamic libraries are not yet supported as dependencies -
building as static library.
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
this work for both architectures?
You'll need to pass -ax86_64 in your preBuildCommands. You could
set up separate configurations.
What's the issue with using the DLL project as a dependency?
Assuming the following layout:
-project
-- dllProject
-- exeProject
You should be able to add a copyFiles directive to the dllProject
configuration that will copy the DLL to the output directory of
anything that depends on it.
"copyFiles" : ["dllProject.dll"]
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 same architecture as
the exe.
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) { return Result(e); }
and then provided it can be inferred (e.g. from the function
signature)
it will still work.
But how would it be inferred? Like the `ok` function, `T` could
be inferred, but E? I'm not sure I understand. If you have to
specify the types every time, it kinda defeats the purpose.
With the function signature as it is, you'd have to specify the
type of the other type (e.g. you'd need to specify E for
`ok()`).
As in the function signature of the function you call `ok` or
`error` in.
Result!(int, SomeEnum) myfunc(bool foo)
{
if(!foo)
return ok(42);
else
return error(SomeEnum.fooHappened);
}
should work.
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. from the function
signature)
it will still work.
But how would it be inferred? Like the `ok` function, `T` could
be inferred, but E? I'm not sure I understand. If you have to
specify the types every time, it kinda defeats the purpose. With
the function signature as it is, you'd have to specify the type
of the other type (e.g. you'd need to specify E for `ok()`).
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 request. Actually, it turned out since 32bit def file needs additional settings in it compared to 64bit version it is handy to be able to have separate def files and use: "sourceFiles-windows-x86_64" : ["dll64.def"], "sourceFiles-windows-x86" : ["dll32.def"], to only pass appropriate one. Now since dll project can't be built as a dependency I added this to my main project dub.json: "preBuildCommands": ["cd game & dub build"], 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 this work for both architectures?
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)
return ok(42);
else
return error(Error.fooHappened);
Ah, I think you misread. ErrorEnum is a template type, like
`T`. There's no ErrorEnum enum specified.
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. from the function
signature)
it will still work.
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, I think you misread. ErrorEnum is a template type, like `T`.
There's no ErrorEnum enum specified.
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)`.
While that's not too bad, it does involve a lot more typing,
and thus more area for human error.
If you're not familiar with the Result and Option types, it
allows you to do something like this:
---
Result!(string, ErrorEnum) someFunction(...)
{
return Ok("Hello!");
}
Result!(string, ErrorEnum) someFunction2(...)
{
return Error(ErrorEnum.dummyError);
}
---
I'm not entirely sure it's possible... but I figured I might
give it a try.
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);
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, and
thus more area for human error.
If you're not familiar with the Result and Option types, it
allows you to do something like this:
---
Result!(string, ErrorEnum) someFunction(...)
{
return Ok("Hello!");
}
Result!(string, ErrorEnum) someFunction2(...)
{
return Error(ErrorEnum.dummyError);
}
---
I'm not entirely sure it's possible... but I figured I might give
it a try.
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 in the other place I have to:
.joiner
.array;
in order to stop the compiler spewing out a mass of (to me
anyway) incomprehensible messages with types I have no
knowledge of. So why does the fluent API chain break in
different ways in the two cases. A Priori this seems like a
breakage of the abstraction.
Full code is at
https://github.com/russel/ApproxGC/blob/master/source/main.d
The comparison is between the functions
createGenerationsDeleteList and
createListOfPlaces.
Any help rebuilding my knowledge would be good.
Also error message comprehensible to programmers rather than
compiler writers might help.
For this kind of errors I find that it helps to break the
pipeline into individual stages and reason about the type
separately.
Function createGenerationsDeleteList returns auto.
{
groups.byPair() // This gives a range of Tuple!(string, string[])
.map!(func) // this gives a sorted range of string[]
.array // this gives a string[][]
.joiner; // this gives a range of string[]
}
all is good. If we swap the array and joiner we get
{
.map!(func) // this gives a sorted range of string[]
.joiner // range of range of string(?)
.array; // array of range of string
}
return type is auto, no problems.
Function createListOfPlaces return string[] <--
{
path.dirEntries(SpanMode.shallow) // range of DirEntries
.map!(p => p.name) // range of strings
.map!(p => // range of
p.dirEntries("*.deb", SpanMode.depth). // range of dir
entires
map!(a => a.dirName).uniq) // goes to a
range of strings
// have a range of range of strings here
.joiner // range of string
.array // string[]
}
all is good.
swap the array and joiner and we have
{
// have a range of range of strings here
.array // array of range of string
.joiner // range of string
}
range of string is NOT string[], hence you get an error.
TL;DR you specified the return type in the second case, changing
the order of the operations yields a different type -> type error.
