Re: GDC generate wrong .exe ("not a valid win32 application")
On Wednesday, 21 June 2017 at 15:55:27 UTC, David Nadlinger wrote: On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer wrote: Fresh install of GDC. (tried with 32x ad 32_64x) Where did you get the GDC executable from? The GDC project doesn't currently offer any official builds that target Windows; the 6.3.0 builds from https://gdcproject.org/downloads in fact generate Linux binaries. — David Oh, ops. I looked at the title "x86_64-w64-mingw32" not at the (target) x86_64-linux-gnu. Thanks :)
Re: GDC generate wrong .exe ("not a valid win32 application")
On Monday, 19 June 2017 at 23:55:54 UTC, rjframe wrote: On Mon, 19 Jun 2017 14:08:56 +, Patric Dexheimer wrote: Fresh install of GDC. (tried with 32x ad 32_64x) GDC: 6.3.0 DUB: 1.3.0 dub run --build=release --arch=x86 --compiler=gdc (...) Running .\main Failed to spawn new process (%1 is not a valid win32 application) If you try compiling a single file directly (gdc app.d -o app), does it work? If it does, what's the output of `dub run -v ...`? Same problem compiling directly. dub verbose output: C:\Users\User\Desktop\d_test>dub run --build=debug --arch=x86 --compiler=gdc -v Using dub registry url 'http://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at C:\ProgramData\dub\packages\local-packages.json Looking for local package map at C:\Users\User\AppData\Roaming\dub\packages\local-packages.json Note: Failed to determine version of package d_test at .. Assuming ~master. Refreshing local packages (refresh existing: false)... Looking for local package map at C:\ProgramData\dub\packages\local-packages.json Looking for local package map at C:\Users\User\AppData\Roaming\dub\packages\local-packages.json Refreshing local packages (refresh existing: false)... Looking for local package map at C:\ProgramData\dub\packages\local-packages.json Looking for local package map at C:\Users\User\AppData\Roaming\dub\packages\local-packages.json Checking for upgrades. Using cached upgrade results... Generating using build Generate target d_test (executable C:\Users\User\Desktop\d_test d_test) Performing "debug" build using gdc for x86. d_test ~master: target for configuration "application" is up to date. Using existing build in C:\Users\User\Desktop\d_test\.dub\build\application-debug-linux.posix-x86-gdc_2068-413C114DFC17AD06F727410485B0042A\. Copying target from C:\Users\User\Desktop\d_test\.dub\build\application-debug-linux.posix-x86-gdc_2068-413C114DFC17AD06F727410485B0042A\d_test to C:\Users\User\Desktop\d_test To force a rebuild of up-to-date targets, run again with --force. Running .\d_test Failed to spawn new process (%1 n├úo ├® um aplicativo Win32 v├ílido.)
GDC generate wrong .exe ("not a valid win32 application")
Fresh install of GDC. (tried with 32x ad 32_64x) GDC: 6.3.0 DUB: 1.3.0 dub run --build=release --arch=x86 --compiler=gdc (...) Running .\main Failed to spawn new process (%1 is not a valid win32 application)
Re: Label as Values in D ?
On Monday, 5 June 2017 at 13:16:43 UTC, ketmar wrote: Patric Dexheimer wrote: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html Is possible to use Label as Values in D? Or there is a way to do dynamic goto statements? Ps: This is out of curiosity / performance reasons. I know the potential of bad design / ugly code ;) as we have nested functions, you can just initialize a table with function pointers, and use it instead of computed goto. this is way more powerful trick, as you can actually use any selector you want, in any way you want, and still have the speed of computed goto (most of the time). That´s nice, I take a look with compiler explorer and it indeed create a jump instead of a call. Not sure if fast as goto, w´ll have to benchmark it :)
Label as Values in D ?
https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html Is possible to use Label as Values in D? Or there is a way to do dynamic goto statements? Ps: This is out of curiosity / performance reasons. I know the potential of bad design / ugly code ;)
Re: function overload with mixin template bug?
On Wednesday, 17 May 2017 at 13:26:36 UTC, Adam D. Ruppe wrote:
On Wednesday, 17 May 2017 at 13:13:06 UTC, Patric Dexheimer
wrote:
Function overloads coming from mixin templates are not being
detected ?
A name being present in the struct means that name is NOT
pulled from the mixin template. This is a feature, not a bug.
It allows overriding of mixin template individual behavior.
see: http://arsdnet.net/this-week-in-d/sep-27.html
To bring in the mixin overloads in addition to your current
ones instead of overriding, use alias:
mixin Foo some_name;
alias foo = some_name.foo;
void foo() {} // now they are all combined
Oh, thank you, didn´t know about it.
didn´t know about this syntax also "mixin Foo some_name;"
function overload with mixin template bug?
1)
struct T{
void f1(){writeln("default f1");}
void f1(int x){writeln("overload f1");}
}
//main
T().f1();
T().f1(1);
//compiles and output as expected.
2)
mixin template add_function(){
void f1(){writeln("default f1");}
}
struct T{
mixin add_function;
void f1(int x){writeln("overload f1");}
}
//main
T().f1();
T().f1(1);
//Error: function f355.T.f1 (int x) is not callable using
argument types ()
/* What? i´m missing something here? */
3)
mixin template add_function(){
void f1(){writeln("default f1");}
}
struct T{
mixin add_function;
}
//main
T().f1();
//compiles and output as expected.
Function overloads coming from mixin templates are not being
detected ?
Re: opCall with struct alias this
On Friday, 5 May 2017 at 13:19:03 UTC, Adam D. Ruppe wrote: On Friday, 5 May 2017 at 13:05:35 UTC, Patric Dexheimer wrote: [...] You should never use static opCall. They are ambiguous with non-static opCall as well as with constructors. It is a buggy mess that should never have been in the language in the first place. [...] It make sense. Even liking of the possibilities of static opCall. But I believe that somethings must exist to evade opCall usages now like empty params ctor on structs.
opCall with struct alias this
struct Base(T){
static T opCall(Args...)( Args args ){
writeln(args);
writeln("opCall");
T t;
return t;
}
}
struct Data{
Base!Data b;
alias b this;
}
void main()
{
// Expected: opCall of Base!Data, but get error
// auto x = Data(10);
// opCall called. What just happened here?
// never saw anything about init as function.
auto y = Data.init(10);
}
Re: Garbage Collector?
GC it´s not only about some performance issues that some people may encounter on D, but it its a marketing problem as well. "D is a systems programming language with..." GC(!?). Most people that are interest in D came from c/c++ or other backgrounds without GC or hearing their entire life that GC "may be bad". Its not a question of "how bad it is" or if it is bad at all. People know how to program without GC. So this is just something in the way. Anyway D is awesome.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 09:35:39 UTC, Joseph Rushton Wakeling wrote: And the simple clarity of the syntax really helps compared to, say, C++. It's much easier to write and much easier to read and understand. So, once again, it's easier to move fast. As a D beginner I have to say that this one was very visible for me. I´m able to look at any D project read it and undertand it with ease. Very few times I was able to do it that easy looking on c++ sources.
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 12:10:55 UTC, Andrey wrote: On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote: what can be done, tho, is article (or series of articles) describing what exactly druntime is, how it is compared to libc and libc++, why it doesn't hurt at all, how to do "bare metal" with custom runtime, why GC is handy (and how to limit GC impact if that is necessary), and so on. that is something D Foundation should do, i believe. +1 +1
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote: On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote: Please don't post non-d. it slipped accidentally, sorry. ;-) for OP: `uint[2] a = [42, 69];` is the correct syntax. "uint[$] a = [42, 69];" haha for a moment I thought that this was the way of D to create a fixed-size array without explicit setting the size (like what u can do in c++ :))
DLang Youtube channel
There isn't a official D youtube channel right? Would be be nice to have all the D related videos spread on youtube centralized in one place :)
Re: Fun: Shooting yourself in the foot in D
On Friday, 28 October 2016 at 09:29:41 UTC, Chris wrote: On Friday, 28 October 2016 at 01:25:55 UTC, Kirill Kryukov wrote: You shoot yourself in a tuple containing your foot, boot and sock. Cannot implicitly convert expression (map(shoot(foot))) of type MapResult to std.ouch.InputRange!limb You create the bullet in your foot for efficiency (CTFE).
Re: D Uniform initialization {}
S[] s = [{ 1, 2 }];
Nice, did´n knew that it worked.
On Friday, 21 October 2016 at 21:41:16 UTC, Daniel Kozak wrote:
Because there is no need. In c++ it is disaster because there
is milion way how to initialize something, it is really hard to
understand and inconsistent
I never really felt lost about it with c++, but the argument
holds true anyway :)
Re: D Uniform initialization {}
On Friday, 21 October 2016 at 19:20:25 UTC, Daniel Kozak wrote:
Dne 21.10.2016 v 20:49 Patric Dexheimer via Digitalmars-d
napsal(a):
Quite sure that this was already discussed, but.. any chance
of this on D?
No (I hope so)
There are a lot of places where it should make the code clear.
Can you elaborate on this?
I always have to create shorter aliases for the most used
structs. (which i think is awkward sometimes)
Why? (I do not see any relation to Uniform initialization)
egs:
//D
alias vec3 = Tuple!(float, "x", float, "y", float, "z");
vec3[] vectors = [
vec3(1.0,0.0,1.0),
vec3(2.0,1.0,1.0),
vec3(3.0,2.0,1.0)
];
//C++ equivalent
vec3 vectors[] = {
{1.0,0.0,1.0},
{2.0,1.0,1.0},
{3.0,2.0,1.0}
};
//D
auto return_value = get_struct(); //don´t need to write the
return type
set_struct( StructName(value1, value2) );
//C++
set_struct( {value1, value2} ); //don´t need to write the
argument type
//D in case of large struct names
alias v = VeryLargeStructName; //not cool
v[] vectors = [
v(1.0,0.0,1.0),
v(2.0,1.0,1.0),
v(3.0,2.0,1.0)
];
I find myself falling with frequency on examples that will
benefit from the c++ uniform initialization.
"No (I hope so)"
Can you explain why you think is a bad idea?
D Uniform initialization {}
Quite sure that this was already discussed, but.. any chance of this on D? (one of the few things that i miss from c++) There are a lot of places where it should make the code clear. I always have to create shorter aliases for the most used structs. (which i think is awkward sometimes) I know there is the case of being ambiguous with lambdas, but after reading this thread https://forum.dlang.org/thread/nud21i$o29$1...@digitalmars.com uniform initialization comes to my mind again :)
Re: ReturnType and Parameters of Templated function/method
On Thursday, 13 October 2016 at 21:07:17 UTC, ketmar wrote: On Thursday, 13 October 2016 at 20:52:09 UTC, Patric Dexheimer wrote: So for now my idea is to brute force the numbers of arguments with 'compiles' trait or trying to get the sourcecode somehow. depending on source code form (even if you can get it) is highly error-prone. consider it UB. also, i think that you'd better not guess, but ask the user to explicitly instantiate the methods with `alias` -- this way you have to write less hacky code, and the user will have more control over what is bound. you may provide helper mixin templates to instantiate n-ary functions with given set of types too. this is slightly more work on the user side, but it doesn't depend on hacks and undocumented things. Yes, but i like the idea of "automagically" bind everything with little user effort. Sometimes you have a lot of code to expose to lua (and templated code as well with lots of templated argument combinations), so I think is nice to have some automated work on this. But you are right about the "highly error-prone" part. I´ll try to avoid that path :)
Re: ReturnType and Parameters of Templated function/method
On Thursday, 13 October 2016 at 18:01:25 UTC, Ali Çehreli wrote:
On 10/13/2016 07:19 AM, Patric Dexheimer wrote:
There is a way to capture the return type/parameters of a
templated
function like:
void add(T)(T t){}
Parameters!add;
Yes, i know that the template don´t have any type until
explicitly coded
like:
Parameters!(add!int);
Or another solution like getting the string function
declaration will be
enough:
"void add(T)(T t)"
Like what happens with:
void other_add(int x){}
writeln( typeof(__traits(getMember, Module,
"other_add")).stringof );
//output: void(int x)
There are several related options in std.traits. What exactly
are you trying to achieve? Perhaps there is a better way.
Ali
I´m working on a Lua binding for D.
One of my ideas is to try to make automatic binding for structs,
even if some method have templated arguments. My idea is to at
least try to bind templated functions with basic types
automatically (in the example, bind then add!int, add!float,
add!string etc..)
I tried arity!add which should resolve my problem too, but did´nt
compile too.
So for now my idea is to brute force the numbers of arguments
with 'compiles' trait or trying to get the sourcecode somehow.
ReturnType and Parameters of Templated function/method
There is a way to capture the return type/parameters of a
templated function like:
void add(T)(T t){}
Parameters!add;
Yes, i know that the template don´t have any type until
explicitly coded like:
Parameters!(add!int);
Or another solution like getting the string function declaration
will be enough:
"void add(T)(T t)"
Like what happens with:
void other_add(int x){}
writeln( typeof(__traits(getMember, Module,
"other_add")).stringof ); //output: void(int x)
Re: code-d 0.12.0 - The user friendly release (code-d for noobs)
On Wednesday, 5 October 2016 at 05:53:06 UTC, Suliman wrote: Please, add Sublime support +1 for Sublime Support :)
Re: Struct immutable data and dict
On Thursday, 6 October 2016 at 03:48:22 UTC, Mike Parker wrote: On Thursday, 6 October 2016 at 03:05:18 UTC, Patric Dexheimer wrote: [...] There's a difference between initialization and assignment. [...] On Thursday, 6 October 2016 at 03:48:22 UTC, Mike Parker wrote: On Thursday, 6 October 2016 at 03:05:18 UTC, Patric Dexheimer wrote: [...] Hm, so in dict they are always assuming that i´m doing assignments.. Ok, more clear now. thanks.
Re: Struct immutable data and dict
On Thursday, 6 October 2016 at 02:09:44 UTC, Adam D. Ruppe wrote: On Thursday, 6 October 2016 at 01:23:35 UTC, Patric Dexheimer wrote: Why? Because you'd be overwriting that immutable member. Structs just put structure around their contents, but it doesn't change their nature. That struct is no different than if you wrote `immutable size_t` as the value - and of course, overwriting that; changing that violates that promise that you won't change it. You could store pointers to those structs though, and overwrite the pointer. But why i´m overwriting the struct if its the first time i´m putting it there? (like on the array).
Struct immutable data and dict
struct Test{
immutable size_t id;
}
Test[string] dict;
Test[] array;
void main(){
array~=Test(1);//work
dict["teste"] = Test(1); //fail ??
}
"Error: cannot modify struct dict["teste"] Test with immutable
members"
Why?
Window x64, LDC, Derelict : unable to compile
LLVM D compiler (1a7070): based on DMD v2.071.2-b2 and LLVM 3.9.0git-fbbabf3 command: dub run --build=release --arch=x86_64 --compiler=D:/ldc/bin/ldc2.exe Output: Performing "release" build using D:/ldc/bin/ldc2.exe for x86_64. derelict-util 2.0.6: building configuration "library"... Error: failed to create path to file: .dub\obj\..\..\AppData\Roaming\dub\packages\derelict-util-2.0.6\derelict-util\.dub\build\library-release-windows-x86_64-ldc_0-E1A9179AF0D6E609F102DF89BE3F74F1\DerelictUtil.lib no such file or directory D:/ldc/bin/ldc2.exe failed with exit code 1. changing to DMD compiler works properly.
Re: Fibers, what for?
On Monday, 13 June 2016 at 00:57:11 UTC, Alex Parrill wrote: Also note that Vibe.d, the largest fiber-based framework D has to offer, is capable of running several coroutines in parallel on multiple threads, meaning you must use the same level of synchronization as if you were using threads. Vibe.d framework share the same fibers between threads? Or each thread have his own fibers? I was trying this(shared fibers) but it didnt work.
Fibers, what for?
I learned about Fibers on D, and now i´m starting to read about it (Threads/Fibers/Coroutines) etc. But when i try to make something usefull with it i just fail to see the real advantage over a normal structured programming without it. Can someone show some code with usefull/unique/advantageous use of fibers? Thanks in advance!
