Re: DMD Symbol Reference Analysis Pass
On Thursday, 28 May 2015 at 21:27:06 UTC, Per Nordlöw wrote: Speed-up varies between 2.0 and 2.7 according to recent experiments done using new unittest at The test file http://downloads.dbpedia.org/3.9/en/instance_types_en.nt.bz2 contains 15.9 Mlines :) /Per
strange bug with unions?
I don't know why but when using a template union with a static
ubyte array i get bizarre results!
module main;
import std.stdio;
private union ByteConverter(T)
{
ubyte[T.sizeof] bytes;
T value;
}
ubyte[] toBytes(T)(T from) if (!is(T == const))
{
ByteConverter!T converter;
converter.value = from;
return converter.bytes;
}
T fromBytes(T)(in ubyte[] bytes)
{
ByteConverter!T converter;
converter.bytes = bytes;
return converter.value;
}
void main(string[] args)
{
writeln(fromBytes!uint(toBytes(34u)));// should print 32 but
prints 1244564
}
why dose it print 1244564 the array is static size so why is it
acting like bytes is a pointer not a static array?
Re: strange bug with unions?
On Friday, 29 May 2015 at 07:55:55 UTC, seen wrote:
I don't know why but when using a template union with a static
ubyte array i get bizarre results!
module main;
import std.stdio;
private union ByteConverter(T)
{
ubyte[T.sizeof] bytes;
T value;
}
ubyte[] toBytes(T)(T from) if (!is(T == const))
{
ByteConverter!T converter;
converter.value = from;
return converter.bytes;
}
T fromBytes(T)(in ubyte[] bytes)
{
ByteConverter!T converter;
converter.bytes = bytes;
return converter.value;
}
void main(string[] args)
{
writeln(fromBytes!uint(toBytes(34u)));// should print 32 but
prints 1244564
}
why dose it print 1244564 the array is static size so why is it
acting like bytes is a pointer not a static array?
http://fr.wikipedia.org/wiki/Endianness#Little_endian
Re: strange bug with unions?
On Friday, 29 May 2015 at 08:00:54 UTC, deadalnix wrote:
On Friday, 29 May 2015 at 07:55:55 UTC, seen wrote:
I don't know why but when using a template union with a static
ubyte array i get bizarre results!
module main;
import std.stdio;
private union ByteConverter(T)
{
ubyte[T.sizeof] bytes;
T value;
}
ubyte[] toBytes(T)(T from) if (!is(T == const))
{
ByteConverter!T converter;
converter.value = from;
return converter.bytes;
}
T fromBytes(T)(in ubyte[] bytes)
{
ByteConverter!T converter;
converter.bytes = bytes;
return converter.value;
}
void main(string[] args)
{
writeln(fromBytes!uint(toBytes(34u)));// should print 32 but
prints 1244564
}
why dose it print 1244564 the array is static size so why is
it acting like bytes is a pointer not a static array?
http://fr.wikipedia.org/wiki/Endianness#Little_endian
endianness should not be an issue since I'm not changing machines
and using static array unions is a common way to convert to bytes
in D.
Re: strange bug with unions?
On 05/29/2015 12:55 AM, seen wrote:
I don't know why but when using a template union with a static ubyte
array i get bizarre results!
module main;
import std.stdio;
private union ByteConverter(T)
{
ubyte[T.sizeof] bytes;
That's a fixed-length array (aka static array), which has value semantics.
T value;
}
ubyte[] toBytes(T)(T from) if (!is(T == const))
That function returns a slice to a...
{
ByteConverter!T converter;
converter.value = from;
return converter.bytes;
... local static array. :(
Replace the return type with
a) auto
b) ubyte[T.sizeof]
}
T fromBytes(T)(in ubyte[] bytes)
{
ByteConverter!T converter;
converter.bytes = bytes;
return converter.value;
}
void main(string[] args)
{
writeln(fromBytes!uint(toBytes(34u)));// should print 32 but prints
1244564
}
why dose it print 1244564 the array is static size so why is it acting
like bytes is a pointer not a static array?
Now it prints 34. :)
Ali
Re: strange bug with unions?
On Friday, 29 May 2015 at 07:55:55 UTC, seen wrote:
ubyte[] toBytes(T)(T from) if (!is(T == const))
{
ByteConverter!T converter;
converter.value = from;
return converter.bytes;
}
This function is incorrect: it is returning a slice (dynamic
array) of a static array, which is located on the stack. The fact
that it compiles without error is bug 9279
(https://issues.dlang.org/show_bug.cgi?id=9279).
Re: DMD Symbol Reference Analysis Pass
On Thursday, 28 May 2015 at 21:23:59 UTC, Per Nordlöw wrote: https://github.com/nordlow/justd/blob/79cc8bf0766282368f05314d00566e7d234988bd/bylinefast.d#L207 which is currently deactivated. It has worked flawlessly in my applications, so none AFAIK. Could this replace the stuck https://github.com/D-Programming-Language/phobos/pull/2794?
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 17:22:21 UTC, Andrei Alexandrescu wrote: On 5/28/15 8:38 AM, Manu via Digitalmars-d wrote: * Forceinline. Thanks for initiating this! The lack of a means to force inlining has been unpleasant at Facebook as well. It would be great if we got this (and of course other items on the list) rolling. -- Andrei Yes, likely, unlikely, forceinline, and noinline are important tools. You should already be able to use PGO which gives the compiler real statistics about your program and is good for a 5-10% speedup. https://github.com/D-Programming-Language/dmd/pull/4651
Re: DMD Symbol Reference Analysis Pass
On Friday, 29 May 2015 at 08:48:59 UTC, Martin Nowak wrote: https://github.com/D-Programming-Language/phobos/pull/2794? That's a massive discussion. Is it possible to describe in shorter terms what the problem is and how it relates to byLine? Please.
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? - Quality of ecosystem. It's relatively simple to run into an issue, that requires one to be a D expert to resolve (codegen bugs, ICEs, CTFE bugs, undecipherable error messages). Fairly problematic for learning the language, especially for people without C++ background. - Lack of libraries. We're missing too many components and the fact that I'd have to write 3 libraries to realize a tiny project makes it particularly hard to get a foot in the door. - Learning material. To much knowledge about D is implicitly shared among contributors and heavy users (e.g. local imports should be selective, or they might shadow symbols) making it harder to learn the language. Outdated information on dlang.org doesn't help either.
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote: - lack of a decimal data type - you cannot perform monetary calculation using floating point. http://dlang.org/phobos/std_bigint.html? - lack of a chinese or japanese calendar in the std.datetime module; - missing of overflow checks for integral data types; http://dlang.org/phobos/core_checkedint.html
Re: DMD Symbol Reference Analysis Pass
On Friday, 29 May 2015 at 09:17:17 UTC, Per Nordlöw wrote: That's a massive discussion. Is it possible to describe in shorter terms what the problem is and how it relates to byLine? Would the problem be solved if `byLine` was changed to not use `readln()`?
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? If you're interested in enterprise point of view, our ecosystem is build around .net technologies, it gets the job done, so it's usually hard to come up with a case for D. There is a small utility, which updates database in a multithreaded fashion and doesn't share code with the rest of the project, but it needs database connectivity for mssql and oracle and again D can't show any advantage in such use case.
Re: is there any reason to use SuperFastHash in druntime? (except speed)
On Thursday, 28 May 2015 at 03:09:07 UTC, ketmar wrote: i think that there is some sense in trading some speed for better distribution. what do you think? We discussed most part of this already. http://forum.dlang.org/post/mff4id$hj8$1...@digitalmars.com And we're already using MurmurHash3 for the new CTFEable hash function. https://github.com/D-Programming-Language/druntime/blob/master/src/core/internal/hash.d Though I don't get any feedback for the library AA. http://forum.dlang.org/post/mjsma6$196h$1...@digitalmars.com and i believe that people that care about performance will roll their own hash functions anyway Anyone will use the built-in hash, performance is of utmost importance. [2] http://code.google.com/p/fast-hash/ It's called fast hash, but how fast is it?
RE: Why aren't you using D at work?
We use D in our work a little. And we dont using it more because we do not need to ;). We have a quite big php codebase and bacause od facebook(hhvm) our code is fast enought. - Původní zpráva - Od:"Manu via Digitalmars-d" Odesláno:28. 5. 2015 16:40 Komu:"digitalmars.D" Předmět:Why aren't you using D at work? I've been using D in all my personal projects for years now, but I lament coding C at work every day, and I pine for salvation. I seem to have reasonable influence in my workplaces, and I suspect I could have my workplace adopt D, but when considering the notion with other staff, we always seem to encounter hard blockers to migration that stop us in our tracks. I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? Every place I work has a slightly different set of blockers. I have potential opportunity to involve D in my workplace in multiple key areas, but blockers exist along every path, as follows: Web: * We need NaCl + Emscripten support in LDC. Doesn't need to be comprehensive, just successfully compile code. Emscripten alone may satisfy; probably a much easier target. Core engine/applications: * Android+iOS. (plus also the web targets above in the future) Desktop utilities: * Workable Qt bindings. General friction/resistance from colleagues: * Forceinline. We have SO MUCH CODE that simply must inline. It's non-negotiable, nobody is comfortable to write ranges or properties without forceinline. I can't sell "just trust that the optimiser might maybe hopefully do what you want" to low-level engineers, I've been trying for years. * Debugging experience; it's come a long way, but there's still significant usability inhibitors. I often wonder if others share the importance of mobile cross-compilers? They seem to be getting lots of love recently, which is very exciting! I'd like to encourage those working on the Android/iOS toolchains to publish regular binary builds of the toolchains so we with little allocated working time can grab the latest toolchains and try our stuff from time to time. Who maintains the CI solutions for the various compilers? How hard is it to add CI for the common cross-compilers and publish them? The interesting observation I make from that list above, is that barring Qt bindings, everything I list is a problem for LDC. It would seem to that LDC is the most important point of focus for my company at this time. How many contributors does LDC have these days out of curiosity? GDC could give Android, but all the other points depend on LLVM. The trick is getting something (anything) to shift to D in the office, giving other programmers some exposure, and give us a context to experiment with D in application to our particular workload; that is, realtime processing and rendering of geospatial data, an ideal workload for D in my mind! http://udserver.euclideon.com/demo (demo is NaCl + Emscripten, we'd love to have written it in D!)
RE: is there any reason to use SuperFastHash in druntime? (exceptspeed)
A little bit faster than murnurhash3 in my scenerio. But I prefer farmhash. http://code.google.com/p/farmhash/ - Původní zpráva - Od:"Martin Nowak via Digitalmars-d" Odesláno:29. 5. 2015 11:41 Komu:"digitalmars-d@puremagic.com" Předmět:Re: is there any reason to use SuperFastHash in druntime? (exceptspeed) On Thursday, 28 May 2015 at 03:09:07 UTC, ketmar wrote: > i think > that there is some sense in trading some speed for better > distribution. > what do you think? We discussed most part of this already. http://forum.dlang.org/post/mff4id$hj8$1...@digitalmars.com And we're already using MurmurHash3 for the new CTFEable hash function. https://github.com/D-Programming-Language/druntime/blob/master/src/core/internal/hash.d Though I don't get any feedback for the library AA. http://forum.dlang.org/post/mjsma6$196h$1...@digitalmars.com > and i believe that people that care about performance will roll > their own > hash functions anyway Anyone will use the built-in hash, performance is of utmost importance. > [2] http://code.google.com/p/fast-hash/ It's called fast hash, but how fast is it?
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 08:57:46 UTC, Martin Nowak wrote: On Thursday, 28 May 2015 at 17:22:21 UTC, Andrei Alexandrescu wrote: On 5/28/15 8:38 AM, Manu via Digitalmars-d wrote: * Forceinline. Thanks for initiating this! The lack of a means to force inlining has been unpleasant at Facebook as well. It would be great if we got this (and of course other items on the list) rolling. -- Andrei Yes, likely, unlikely, forceinline, and noinline are important tools. You should already be able to use PGO which gives the compiler real statistics about your program and is good for a 5-10% speedup. https://github.com/D-Programming-Language/dmd/pull/4651 Walter said likely/unlikely won't be implemented as the compiler already assumes the first condition is the more likely one the last time this was brought up. I'm not sure if this is still true.
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 09:33:25 UTC, Kagamin wrote: On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? If you're interested in enterprise point of view, our ecosystem is build around .net technologies, it gets the job done, so it's usually hard to come up with a case for D. There is a small utility, which updates database in a multithreaded fashion and doesn't share code with the rest of the project, but it needs database connectivity for mssql and oracle and again D can't show any advantage in such use case. Same here. Our customers live in Java and .NET world. They also tend to choose the technology stack themselves. C++ only appears into the scene when there is the need for some OS integration or performance boost. So just as JNI, P/Invoke, COM component. Also there are native compilers for both eco-systems around the corner. .NET Native on one side and the AOT support is being discussed for Java 10 (ignoring the commercial options). For the customers doing mobile projects, we tend to go with a mix of platform SDKs and some web help. Overall, for the amount of C++ code that gets written, D would hardly make any difference and cannot compete with the eco-systems being used from business case point of view.
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 09:50:29 UTC, weaselcat wrote: Walter said likely/unlikely won't be implemented as the compiler already assumes the first condition is the more likely one the last time this was brought up. That is not what he said http://forum.dlang.org/post/m8739b$an$1...@digitalmars.com.
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: The trick is getting something (anything) to shift to D in the office, giving other programmers some exposure, and give us a context to experiment with D in application to our particular workload; that is, realtime processing and rendering of geospatial data, an ideal workload for D in my mind! http://udserver.euclideon.com/demo (demo is NaCl + Emscripten, we'd love to have written it in D!) Are you working with Euclideon / Bruce Dell? Sounds fun! I am not using D for anything serious: 1. Partially because C++/clang is more mature and does a better job for real time audio. I am using my own libraries that provides the features D has, but C++ lacks. 2. Since not using C++ at all is not an option, I've had to spend more time than I've enjoyed figuring out how to do C++14 style meta programming, which is annoying and somewhat time consuming. D is better, in some areas, but lacking in others. So metaprograming is not a good enough reason to switch. 3. D's memory model is up in the blue, C++ has locked down on one model, Rust on another. I am currently starting to think that Rust is a more likely option than D given the direction D might be taking towards reference counting etc. But I am not using Rust either… just watching how it develops.
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 17:22:21 UTC, Andrei Alexandrescu wrote: On 5/28/15 8:38 AM, Manu via Digitalmars-d wrote: * Forceinline. Thanks for initiating this! The lack of a means to force inlining has been unpleasant at Facebook as well. It would be great if we got this (and of course other items on the list) rolling. -- Andrei I understand the position you and Walter are in that you are nagged regularly for wrong-headed or pet features but I do think a lesson needs to be taken from forceinline that standard features like this need to go in. Poor Manu has been beating that drum for so long. If multiple members of the community keep coming back to a thing over time then it needs to be seriously reexamined and not enter the state I see in some communities where it because almost a religious commandment as the community is sick of discussing it and there has been a command from on high that it will not be that way. It's very much like generics in Go. The problem is that people forget what the arguments actually were and take away a possibly wrongheaded sense of conclusion which fossilizes. Perhaps the issue re-openner should be responsible for a detailed summary of the arguments previously given before and against and any new additions rather than people making references to disparate and sometimes private threads.
Re: shared libs for OSX
On Wednesday, 27 May 2015 at 21:24:25 UTC, bitwise wrote: Basically, I've gone back to the idea of using the dylib ctor/dtors. I don't think we really even need the image-added callback, at least not for dylibs. Looks good. The compiler could add a simple ctor/dtor to any D object.
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 10:05:08 UTC, Paulo Pinto wrote:
On Friday, 29 May 2015 at 09:33:25 UTC, Kagamin wrote:
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
I expect I'm not alone. Please share the absolute blockers
preventing
you from adopting D in your offices. I wonder if there will
be common
themes emerge?
If you're interested in enterprise point of view, our
ecosystem is build around .net technologies, it gets the job
done, so it's usually hard to come up with a case for D. There
is a small utility, which updates database in a multithreaded
fashion and doesn't share code with the rest of the project,
but it needs database connectivity for mssql and oracle and
again D can't show any advantage in such use case.
Same here.
Our customers live in Java and .NET world. They also tend to
choose the technology stack themselves.
C++ only appears into the scene when there is the need for some
OS integration or performance boost. So just as JNI, P/Invoke,
COM component.
Also there are native compilers for both eco-systems around the
corner. .NET Native on one side and the AOT support is being
discussed for Java 10 (ignoring the commercial options).
For the customers doing mobile projects, we tend to go with a
mix of platform SDKs and some web help.
Overall, for the amount of C++ code that gets written, D would
hardly make any difference and cannot compete with the
eco-systems being used from business case point of view.
I'm using D at work successfully. However, what is lacking that
makes it hard to convince others:
1. [medium priority]
No standard GUI ("Look Ma, there's a button that says 'Hello,
world!', if I press it!"). You can work around that, because you
can still call D from any GUI either as an executable, a socket
or interface to D (via C). Still, people love GUIs. I hope
dlangui can help here.
2. [high priority]
Uncertainty regarding ARM (iOS/Android). Deal breaker, show
stopper. Was worrying a few years ago, but is just bad now in
2015.
3. [constant priority]
Learning resources, learning curve. As mentioned in a comment
above: you have to know D well to be able to make sense of error
messages etc. You need to know D "low-level" or D's internals in
order to take full advantage of it. A lot of concepts are
unfamiliar to people and/or not yet common ground (ranges,
templates, component programming), especially as inbuilt
features. The other day I needed startswith and ctypes in Python
and immediately got this:
https://docs.python.org/2/library/stdtypes.html
https://docs.python.org/2/library/ctypes.html
For D I get:
==> http://dlang.org/phobos/std_string.html
==> http://dlang.org/phobos/std_algorithm.html#startsWith
==>
http://dlang.org/phobos/std_algorithm_searching.html#.startsWith
uint startsWith(alias pred = "a == b", Range, Needles...)(Range
doesThisStart, Needles withOneOfThese) if (isInputRange!Range &&
Needles.length > 1 && is(typeof(.startsWith!pred(doesThisStart,
withOneOfThese[0])) : bool) &&
is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[1..$]))
: uint));
bool startsWith(alias pred = "a == b", R1, R2)(R1 doesThisStart,
R2 withThis) if (isInputRange!R1 && isInputRange!R2 &&
is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) :
bool));
bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E
withThis) if (isInputRange!R &&
is(typeof(binaryFun!pred(doesThisStart.front, withThis)) : bool));
WTF? :-)
I know, we all know that, but still it puts people off, a simple
psychological issue. D smells of elitism and hackeritis. Python
and Java are more like "Hey, I can do it too. Look Ma, it prints
'Hello, world!'!!!" In other words, it doesn't make people feel
good about themselves, there's no immediate reward. This is
purely a marketing issue and has nothing to do with the language
itself. But even if people are free to chose a language, they shy
away from D.
And since we're talking about psychology, I think D is a language
you only come to appreciate after years of programming in other
languages. People won't adopt it as long as they feel comfortable
- or secure - in other languages, as long as they don't see an
immediate benefit in using D. I'm not sure if there's anything
the D community can do about this except for keeping on keeping
on.
Re: Proof of concept - library AA
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote: Would be interesting to get some opinions on this. https://github.com/D-Programming-Language/druntime/pull/1282 For my own reasons, a library AA is most welcome: * separating library features from language features * making features optional and opt-in instead of opt-out * modularizing the language and runtime for pay-as-you-go implementations But, if you'll forgive my ignorance, what is the primary motivation for migrating to a library AA? Mike
Re: Proof of concept - library AA
On Wednesday, 27 May 2015 at 17:16:53 UTC, IgorStepanov wrote: Foo f; f[5][3] = Foo(42); translates to f.opIndex!(true)(5).opIndex!(true)(3) = Foo(42); auto x = f[5][4]; translates to auto x = f.opIndex!(false)(5).opIndex!(false)(3); We shouldn't replace opIndexAssign though, b/c default construction + assignment is more expensive than constructing in-place.
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 11:17:00 UTC, Martin Nowak wrote: On Wednesday, 27 May 2015 at 17:16:53 UTC, IgorStepanov wrote: Foo f; f[5][3] = Foo(42); translates to f.opIndex!(true)(5).opIndex!(true)(3) = Foo(42); auto x = f[5][4]; translates to auto x = f.opIndex!(false)(5).opIndex!(false)(3); We shouldn't replace opIndexAssign though, b/c default construction + assignment is more expensive than constructing in-place. Sorry, I meant f.opIndex!(true)(5).opIndexAssign(Foo(42), 3);
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 11:16:27 UTC, Mike wrote: But, if you'll forgive my ignorance, what is the primary motivation for migrating to a library AA? - The current implementation uses runtime type information (TypeInfo) to compute hashes and compare keys. That's at least 2 virtual non-inlineable calls to lookup a value by an int key. Speedup is likely in the 1.5x-2x range. - The runtime interface is incorrectly attributed. - Small-key/value optimizations are hardly possible without statically knowing the types.
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 10:40:22 UTC, Ola Fosheim Grøstad wrote: On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: The trick is getting something (anything) to shift to D in the office, giving other programmers some exposure, and give us a context to experiment with D in application to our particular workload; that is, realtime processing and rendering of geospatial data, an ideal workload for D in my mind! http://udserver.euclideon.com/demo (demo is NaCl + Emscripten, we'd love to have written it in D!) Are you working with Euclideon / Bruce Dell? Sounds fun! I am not using D for anything serious: 1. Partially because C++/clang is more mature and does a better job for real time audio. I am using my own libraries that provides the features D has, but C++ lacks. 2. Since not using C++ at all is not an option, I've had to spend more time than I've enjoyed figuring out how to do C++14 style meta programming, which is annoying and somewhat time consuming. D is better, in some areas, but lacking in others. So metaprograming is not a good enough reason to switch. This is very interesting. It kinda defeats the "D is too complicated" argument I often hear. 3. D's memory model is up in the blue, C++ has locked down on one model, Rust on another. I am currently starting to think that Rust is a more likely option than D given the direction D might be taking towards reference counting etc. But I am not using Rust either… just watching how it develops. And if D offered various models (cf. std.allocator), would you still prefer languages with just one model for the sake of simplicity and not having to worry about which model to choose?
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 09:22:56 UTC, Martin Nowak wrote: On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote: - lack of a decimal data type - you cannot perform monetary calculation using floating point. http://dlang.org/phobos/std_bigint.html? No. There is no scale in BigInt. 1 / 2 will result in 0 not in 0.5. If BigInt in D was inspired from java BigInt, the direct equivalent should be java BigDecimal, but this does not exist in phobos. Even if I keep a scale myself, there are missing features like rounding. Anyway, I implemented my own decimal type : https://github.com/rumbu13/sharp/blob/master/src/system/package.d#L2512, but I would prefer that D will provide such types built in the language, at least this was the intention many years ago: http://dlang.org/d-floating-point.html - lack of a chinese or japanese calendar in the std.datetime module; - missing of overflow checks for integral data types; http://dlang.org/phobos/core_checkedint.html Division overflow is not implemented (int.min / -1) and using a linear syntax instead of a simple expression is not the best way to convince people to switch sides.
Re: As discussed in DConf2015: Python-like keyword arguments
On 2015-05-29 00:35, Atila Neves wrote:
I might do a blog post on this, but here's some POC code:
import std.stdio;
import std.range;
import std.typetuple;
import std.traits;
import std.conv;
struct Foo { int i; }
struct Bar { int i; }
struct Baz { int i; }
void func(Foo foo, Bar bar, Baz baz) {
writeln("foo is ", foo);
writeln("bar is ", bar);
writeln("baz is ", baz);
}
auto getStrArgs(alias F, T...)() {
string[] strArgs;
foreach(i, ParamType; ParameterTypeTuple!F) {
enum index = staticIndexOf!(ParamType, T);
static if(index != -1) {
strArgs ~= "args[" ~ index.to!string ~ "]";
} else {
strArgs ~= ParamType.stringof ~ ".init";
}
}
return strArgs;
}
auto kwargs(alias F, T...)(T args) {
enum strArgs = getStrArgs!(F, T);
mixin("return F(" ~ strArgs.join(",") ~ ");");
}
void main() {
kwargs!func(Bar(2), Baz(3), Foo(1));
kwargs!func(Baz(3), Foo(1));
}
Here's another solution [1].
And here's an implementation with language support which allows named
arguments but not reordering the arguments [2]. Originally implemented
by Michel Fortin.
[1]
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135
[2] https://github.com/jacob-carlborg/dmd/tree/named_parameters
--
/Jacob Carlborg
Re: Why aren't you using D at work?
On 2015-05-29 11:48, Daniel Kozák via Digitalmars-d wrote: We use D in our work a little. And we dont using it more because we do not need to ;). We have a quite big php codebase and bacause od facebook(hhvm) our code is fast enought. You're using PHP? Then that's reason enough to switch :) -- /Jacob Carlborg
Re: shared libs for OSX
On 2015-05-27 23:24, bitwise wrote: Good point. I've come up another solution and posted it here: http://dpaste.com/0DXBSNQ Will "dladdr" return different values (mach_header) for different dynamic libraries? Won't there only be one "init" function, as you said earlier. Or does it work somehow anyway? -- /Jacob Carlborg
Re: Why aren't you using D at work?
On 2015-05-28 22:22, rumbu wrote: - lack of a chinese or japanese calendar in the std.datetime module; What about Tango [1]? [1] http://dsource.org/projects/tango/docs/current/tango.time.chrono.Japanese.html -- /Jacob Carlborg
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 11:22:53 UTC, IgorStepanov wrote: Sorry, I meant f.opIndex!(true)(5).opIndexAssign(Foo(42), 3); Added to the ER. https://issues.dlang.org/show_bug.cgi?id=7753#c6
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 12:23:14 UTC, rumbu wrote: On Friday, 29 May 2015 at 09:22:56 UTC, Martin Nowak wrote: On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote: - lack of a decimal data type - you cannot perform monetary calculation using floating point. http://dlang.org/phobos/std_bigint.html? No. There is no scale in BigInt. 1 / 2 will result in 0 not in 0.5. If BigInt in D was inspired from java BigInt, the direct equivalent should be java BigDecimal, but this does not exist in phobos. Even if I keep a scale myself, there are missing features like rounding. Anyway, I implemented my own decimal type : https://github.com/rumbu13/sharp/blob/master/src/system/package.d#L2512, Fair play to you! We should bundle these efforts. What about a page where we collect all this stuff like "I miss this feature in D, and here's my own library for it." We all have stuff like this in the attic somewhere. but I would prefer that D will provide such types built in the language, at least this was the intention many years ago: http://dlang.org/d-floating-point.html - lack of a chinese or japanese calendar in the std.datetime module; - missing of overflow checks for integral data types; http://dlang.org/phobos/core_checkedint.html Division overflow is not implemented (int.min / -1) and using a linear syntax instead of a simple expression is not the best way to convince people to switch sides.
Re: As discussed in DConf2015: Python-like keyword arguments
I know some people don't like abusing opDollar, but here's my
implementation:
import std.traits, std.algorithm, std.conv;
private struct Named(string n, T) {
enum name = n;
T value;
}
private auto makeNameIndex(NamedList...)(string[] names) {
auto indices = new size_t[](names.length);
foreach(i, n ; NamedList) {
auto x = names.countUntil(n.name);
assert(x >= 0, "Keyword Parameter \"" ~ n.name ~ "\" does
not exist in " ~ text(names));
indices[x] = i;
}
return indices;
}
private immutable struct KeyWordDollar {
@property
auto opDispatch(string param, T)(T t) {
return Named!(param,T)(t);
}
}
private struct KeyWordManager(alias f) {
private enum paramNames = [ParameterIdentifierTuple!f];
auto opDollar(size_t pos = 0)() const {
return immutable KeyWordDollar();
}
auto opIndex(NamedArgs...)(NamedArgs namedArgs) {
enum ordering = makeNameIndex!NamedArgs(paramNames);
ParameterTypeTuple!f args;
foreach(i, ref a; args) {
a = namedArgs[ ordering[i] ].value;
}
return f(args);
}
}
auto kw(alias f)() {
return KeyWordManager!f();
}
int foo(int x, int y) {
return x+y;
}
unittest {
assert(8 == kw!foo[$.y = 5, $.x = 3]);
}
Re: sockaddr_in and InternetAddress
On 2015-05-28 11:10 PM, Vladimir Panteleev wrote: On Friday, 29 May 2015 at 00:08:10 UTC, Andre Kostur wrote: I'm looking for one of two things: 1) If I have a sockaddr_in, how do I get it into an InternetAddress? First of all, you may not actually need an InternetAddress. Modern code working with addresses should be address-agnostic, so it should take an Address instead. Ideally, you should avoid doing anything address-family-specific - then, it will work with any address family, incl. any introduced in the future. Generally speaking, sure. But I live down at the protocol layers of networking where I do need to be aware of whether I'm using IPv4 or IPv6. You could: - Create an UnknownAddressReference which uses a pointer to your sockaddr_in. - Create an InternetAddress, then copy the address over its "name" property. Seems inconvenient to construct then copy over an object when I have the data ready at the time of construction. 2) If it is agreed that there should be a shorter way, I'm willing to write the code, but would need a little guidance as to where would be the appropriate place to put the code (New overload to parseAddress? New constructor for InternetAddress?) A new constructor for InternetAddress won't hurt. Done (for both InternetAddress and Internet6Address), pull request is in progress. Thanks for the input! (And to Adam too...)
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 12:52:29 UTC, Martin Nowak wrote: On Friday, 29 May 2015 at 11:22:53 UTC, IgorStepanov wrote: Sorry, I meant f.opIndex!(true)(5).opIndexAssign(Foo(42), 3); Added to the ER. https://issues.dlang.org/show_bug.cgi?id=7753#c6 Thanks, but unfortunately, writing enhacement request to bugzilla is equals to writing to /dev/null :) I'll create a DIP about this, when I'll have a free time. What do you want about this syntax? Maybe you may suggest a better solution?
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 12:52:12 UTC, Jacob Carlborg wrote: On 2015-05-28 22:22, rumbu wrote: - lack of a chinese or japanese calendar in the std.datetime module; What about Tango [1]? [1] http://dsource.org/projects/tango/docs/current/tango.time.chrono.Japanese.html The Japanese Calendar is Gregorian, so there are no major differences. On the contrary the Chinese one is very different with floating month sizes. If someone is wondering why a calendar is needed in a payroll calculation, it's used to determine the number of working days in a month :) Tahngo was nice but not supported anymore, I expect these features in phobos.
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 11:29:13 UTC, Chris wrote: This is very interesting. It kinda defeats the "D is too complicated" argument I often hear. I don't know what is typical, but I am dealing with Python, Javascript, Dart, C++ and Objective-C for commercial use, and plan on adding Swift. C++14 is by far the most taxing, due to not enough rigour in the language design (complications with no benefits!). Dart you can master in a week, and is more productive than C++. So I have a lower threshold for adding a "Dart-like" language with an IDE than a "C++-like" language for commercial use. My threshold for adding Swift is very low due to the perceived simplicity and decent tooling. 3. D's memory model is up in the blue, C++ has locked down on one model, Rust on another. I am currently starting to think that Rust is a more likely option than D given the direction D might be taking towards reference counting etc. But I am not using Rust either… just watching how it develops. And if D offered various models (cf. std.allocator), would you still prefer languages with just one model for the sake of simplicity and not having to worry about which model to choose? I would prefer one clean heap-model that the compiler can optimize easily + compiler backed stack allocation, and that most third party libraries are written for. Almost all my performance oriented allocations are on the stack or are preallocated in big blocks, so I'd put more emphasis on things like VLA (which is available as a C++ extension in clang/gcc). There is no way a generic solution can beat a tailored solution when it comes to abstract datatypes and memory management, so having lots of options in a standard library sounds useful. But interoperability matters more. Like, I am likely to use Swift for ios/osx GUI, but need a companion language for the core application engine. C++ is most likely today. If Rust or D makes integration with Swift easy then I would consider a switch. The bottom line is overall productivity, long term maintenance and risk for hitting an issue that requires "ugly unsupported hacks". It is much more difficult to find a place for a "middle ground" solution than a very focused heavy duty solution or a very light solution that is easy to get on with. I don't think people look for "middle ground" solutions when the try to solve a problem.
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 12:39:20 UTC, Jacob Carlborg wrote: On 2015-05-29 11:48, Daniel Kozák via Digitalmars-d wrote: We use D in our work a little. And we dont using it more because we do not need to ;). We have a quite big php codebase and bacause od facebook(hhvm) our code is fast enought. You're using PHP? Then that's reason enough to switch :) +1 :)
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 14:03:19 UTC, Ola Fosheim Grøstad wrote: On Friday, 29 May 2015 at 11:29:13 UTC, Chris wrote: This is very interesting. It kinda defeats the "D is too complicated" argument I often hear. I don't know what is typical, but I am dealing with Python, Javascript, Dart, C++ and Objective-C for commercial use, and plan on adding Swift. C++14 is by far the most taxing, due to not enough rigour in the language design (complications with no benefits!). Dart you can master in a week, and is more productive than C++. So I have a lower threshold for adding a "Dart-like" language with an IDE than a "C++-like" language for commercial use. My threshold for adding Swift is very low due to the perceived simplicity and decent tooling. D is not perceived as a simple language, although it can be trivial to use sometimes. To simply get things done the languages mentioned above are certainly a good choice and if you develop for mobile phones, D is certainly not a good choice _at the moment_. However, for a constantly growing long-term code base, D is my language of choice. It's clean (i.e. maintainable), flexible (many ways to tackle new problems), easily unit-testable and, of course, compiles to native machine code. It also interfaces to C(++) which is very important. 3. D's memory model is up in the blue, C++ has locked down on one model, Rust on another. I am currently starting to think that Rust is a more likely option than D given the direction D might be taking towards reference counting etc. But I am not using Rust either… just watching how it develops. And if D offered various models (cf. std.allocator), would you still prefer languages with just one model for the sake of simplicity and not having to worry about which model to choose? I would prefer one clean heap-model that the compiler can optimize easily + compiler backed stack allocation, and that most third party libraries are written for. Almost all my performance oriented allocations are on the stack or are preallocated in big blocks, so I'd put more emphasis on things like VLA (which is available as a C++ extension in clang/gcc). There is no way a generic solution can beat a tailored solution when it comes to abstract datatypes and memory management, so having lots of options in a standard library sounds useful. But interoperability matters more. Like, I am likely to use Swift for ios/osx GUI, but need a companion language for the core application engine. C++ is most likely today. If Rust or D makes integration with Swift easy then I would consider a switch. The bottom line is overall productivity, long term maintenance and risk for hitting an issue that requires "ugly unsupported hacks". It is much more difficult to find a place for a "middle ground" solution than a very focused heavy duty solution or a very light solution that is easy to get on with. I don't think people look for "middle ground" solutions when the try to solve a problem. My approach has been similar. The GUI could be anything, the core is D. I don't want to rewrite core functionality in various languages, and with other languages I always hit a wall that says "Thus far shalt thou go and no further!"
Re: RE: Why aren't you using D at work?
On Friday, 29 May 2015 at 09:49:17 UTC, Daniel Kozák wrote: I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? Strong blockers are C/C++ coders who do not wish to learn a new language because they are already accustomed to C/C++. Usually they say that in D there is no fundamental and significant differences from C++, so they believe that to change something makes no sense. With this need to fight! :)
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 14:22:58 UTC, Chris wrote: However, for a constantly growing long-term code base, D is my language of choice. It's clean (i.e. maintainable), flexible (many ways to tackle new problems), easily unit-testable and, of course, compiles to native machine code. It also interfaces to C(++) which is very important. Yes, C++ interfacing could prove important, if it can cover >95% of C++ library interfaces. Are you using D for a constantly growing long-term code base, or planning to? There is no way a generic solution can beat a tailored solution when it comes to abstract datatypes and memory management, so having lots of options in a standard library sounds useful. Ugh, I said the opposite of what I meant. I don't think having lots of allocation options in a standard library sounds all that useful, since I will most likely roll my own when hitting a serious performance problem. Rolling your own is often the same amount of work as "searching for a narrow solution" unless you are doing something really complicated. I think many standard libraries could be cut down to the most generally useful functionality. In C++ I use std::array or my own data structures, I only occasionally use std::vector… In Python I use no more than 5% of the standard library. Generally useful solutions (like comprehensions) beats narrow solutions 99% of the time, because when you need something narrow then the pre-canned narrow solutions often require hacks to serve the purpose (the wrong kind of narrowness or "fits perfectly except it doesn't work when…X…").
Re: As discussed in DConf2015: Python-like keyword arguments
Two other ways to implement the concept. The first works with optional
arguments and the other requires all arguments.
/**
* Optional arguments and no default values; might not compile if all args
* not passed.
*/
---
/**
* A templated function useful for creating aliases for naming function
* parameters.
*/
auto namedArguments(string name, T)(T arguments)
{
static struct Args
{
enum string argName = name;
T argValue;
alias argValue this;
}
return Args(cast(Unqual!T)arguments);
}
///
unittest
{
alias arg1 = namedArguments!("arg1", string);
alias arg2 = namedArguments!("arg2", int);
void namedArgsFunc(T...)(T arguments)
{
const vars = parseArguments!()(arguments);
const string one = vars.arg1;
const int two = vars.arg2;
}
namedArgsFunc(arg1(""), arg2(42));
namedArgsFunc(arg2(56), arg1("fred"));
}
private enum isNamedArgument(T) = hasMember!(T, "argName") && hasMember!
(T, "argValue");
/**
* Parse parameters of the type returned from $(D namedArguments) into a
* named tuple usable in a function.
*/
auto parseArguments(T...)(T inputs) if (allSatisfy!(isNamedArgument, T))
{
template GetTypeAndName(ArgT)
{
alias Type = typeof(ArgT.argValue);
enum string Name = ArgT.argName;
alias GetTypeAndName = TypeTuple!(Type, Name);
}
auto ret = Tuple!(staticMap!(GetTypeAndName, T))();
foreach (arg; inputs)
{
mixin(`ret.` ~ arg.argName) = arg.argValue;
}
return ret;
}
unittest
{
alias arg1 = namedArguments!("arg1", string);
alias arg2 = namedArguments!("arg2", int);
const test1 = parseArguments(arg1("string"), arg2(42));
assert(test1.arg1 == "string");
assert(test1.arg2 == 42);
const test2 = parseArguments(arg2(42), arg1("string"));
assert(test2.arg1 == "string");
assert(test2.arg2 == 42);
}
--
///All required arguments
--
/**
* A templated function useful for creating aliases for naming function
* parameters.
*
* Params:
* ArgTypesT = The enum type for all named parameters in a group.
*
* Returns: A voldemort type that can be handled by $(D parseArguments).
*/
template namedArguments(ArgTypesT) if (is(ArgTypesT == enum))
{
auto namedArguments(ArgTypesT type, T)(T arguments)
{
static struct Args
{
alias ArgType = ArgTypesT;
enum ArgType argsType = type;
T args;
alias args this;
}
return Args(cast(Unqual!T)arguments);
}
}
///
unittest
{
enum ArgTypes
{
Arg1,
Arg2
}
alias FuncArgsT = namedArguments!ArgTypes;
alias arg1 = FuncArgsT!(ArgTypes.Arg1, string);
alias arg2 = FuncArgsT!(ArgTypes.Arg2, int);
void namedArgsFunc(T...)(T arguments)
{
const vars = parseArguments(arguments);
const string one = vars.Arg1;
const int two = vars.Arg2;
}
namedArgsFunc(arg1(""), arg2(42));
namedArgsFunc(arg2(56), arg1("fred"));
}
private enum isNamedArgument(T) = hasMember!(T, "argsType") && hasMember!
(T, "args");
/**
* Parse parameters of the type returned from $(D namedArguments) into a
* named tuple usable in a function.
*/
auto parseArguments(T...)(T inputs) if (allSatisfy!(isNamedArgument, T))
{
template GetTypeAndName(ArgT)
{
import std.conv : to;
alias Type = typeof(ArgT.args);
enum string Name = ArgT.argsType.to!string();
alias GetTypeAndName = TypeTuple!(Type, Name);
}
auto ret = Tuple!(staticMap!(GetTypeAndName, T))();
foreach (I, arg; inputs)
{
ret[I] = arg.args;
}
return ret;
}
unittest
{
enum ArgTypes
{
Arg1,
Arg2
}
alias FuncArgsT = namedArguments!ArgTypes;
alias arg1 = FuncArgsT!(ArgTypes.Arg1, string);
alias arg2 = FuncArgsT!(ArgTypes.Arg2, int);
const test1 = parseArguments(arg1("string"), arg2(42));
assert(test1.Arg1 == "string");
assert(test1.Arg2 == 42);
const test2 = parseArguments(arg2(42), arg1("string"));
assert(test2.Arg1 == "string");
assert(test2.Arg2 == 42);
}
--
Jonathan
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. If awareness of its existence weren't a problem, it wouldn't be a long list. Mostly SPARC/Solaris and Politics (including inertia of the current approach). -Wyatt
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 13:45:56 UTC, rumbu wrote: Tahngo was nice but not supported anymore Two months ago it had an update that bumped tested version to 2.067.
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 14:46:06 UTC, Ola Fosheim Grøstad wrote: On Friday, 29 May 2015 at 14:22:58 UTC, Chris wrote: However, for a constantly growing long-term code base, D is my language of choice. It's clean (i.e. maintainable), flexible (many ways to tackle new problems), easily unit-testable and, of course, compiles to native machine code. It also interfaces to C(++) which is very important. Yes, C++ interfacing could prove important, if it can cover >95% of C++ library interfaces. Are you using D for a constantly growing long-term code base, or planning to? I've been using D for a long-term project for quite a while now. There is no way a generic solution can beat a tailored solution when it comes to abstract datatypes and memory management, so having lots of options in a standard library sounds useful. Ugh, I said the opposite of what I meant. I don't think having lots of allocation options in a standard library sounds all that useful, since I will most likely roll my own when hitting a serious performance problem. Rolling your own is often the same amount of work as "searching for a narrow solution" unless you are doing something really complicated. I think many standard libraries could be cut down to the most generally useful functionality. In C++ I use std::array or my own data structures, I only occasionally use std::vector… In Python I use no more than 5% of the standard library. Generally useful solutions (like comprehensions) beats narrow solutions 99% of the time, because when you need something narrow then the pre-canned narrow solutions often require hacks to serve the purpose (the wrong kind of narrowness or "fits perfectly except it doesn't work when…X…").
Re: DIP78 - macros without syntax extensions
On Thursday, 28 May 2015 at 13:34:24 UTC, Steven Schveighoffer wrote: Quote from dconf W&A ask me anything: Q: "Will we get a macro system" Both Walter and Andrei: "no" It's safe to close the corresponding DIPs?
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 12:39:20 UTC, Jacob Carlborg wrote: On 2015-05-29 11:48, Daniel Kozák via Digitalmars-d wrote: We use D in our work a little. And we dont using it more because we do not need to ;). We have a quite big php codebase and bacause od facebook(hhvm) our code is fast enought. You're using PHP? Then that's reason enough to switch :) Yes it is :). This is why I always works on thinks at work, where I can avoid PHP. czech translate of PHP acronym is: Prasečí Hromádka Písmenek (Swine pile of letters)
Re: shared libs for OSX
On Friday, 29 May 2015 at 12:46:43 UTC, Jacob Carlborg wrote:
On 2015-05-27 23:24, bitwise wrote:
Good point.
I've come up another solution and posted it here:
http://dpaste.com/0DXBSNQ
Will "dladdr" return different values (mach_header) for
different dynamic libraries? Won't there only be one "init"
function, as you said earlier. Or does it work somehow anyway?
I'm going to test it out this weekend, but if I do get the wrong
address, I think I can add a symbol with "__attribute__
((visibility ("hidden")))" and use dladdr on that instead. I
don't think hidden symbols should collide.
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? I do use it at work, but I also don't really have a collaborative codebase. These are usually assistant programs/scripts, our primary product is web-based and runs on IIS. I do QA work so not involved in the Android/iOS work. I've had complaints that I was using D and others wouldn't want to learn it to help contribute, switching to our company language (C#) didn't help in getting on-board to contribute to my projects. I'm back to writing whatever I can in D.
Re: As discussed in DConf2015: Python-like keyword arguments
On Thursday, 28 May 2015 at 22:35:14 UTC, Atila Neves wrote:
I might do a blog post on this, but here's some POC code:
Now with default values!
import std.stdio;
import std.range;
import std.typetuple;
import std.traits;
import std.conv;
struct Foo { int i; }
struct Bar { int i; }
struct Baz { int i; }
void func(Foo foo = Foo(11), Bar bar = Bar(22), Baz baz =
Baz(33)) {
writeln("foo is ", foo);
writeln("bar is ", bar);
writeln("baz is ", baz);
}
void main() {
kwargs!func(Bar(2), Baz(3), Foo(1)); //1, 2, 3
kwargs!func(Baz(3), Foo(1)); //1, 22, 3
}
auto getStrArgs(alias F, T...)() {
string[] strArgs;
foreach(i, ParamType; ParameterTypeTuple!F) {
enum index = staticIndexOf!(ParamType, T);
static if(index != -1) {
strArgs ~= "args[" ~ index.to!string ~ "]";
} else {
alias defaultValue = ParameterDefaultValueTuple!F[i];
static if(is(defaultValue == void)) {
strArgs ~= ParamType.stringof ~ ".init";
} else {
strArgs ~= defaultValue.stringof;
}
}
}
return strArgs;
}
auto kwargs(alias F, T...)(T args) {
enum strArgs = getStrArgs!(F, T);
mixin("return F(" ~ strArgs.join(",") ~ ");");
}
Re: As discussed in DConf2015: Python-like keyword arguments
On Friday, 29 May 2015 at 15:16:56 UTC, Jonathan Crapuchettes
wrote:
Two other ways to implement the concept. The first works with
optional
arguments and the other requires all arguments.
unittest
{
alias arg1 = namedArguments!("arg1", string);
alias arg2 = namedArguments!("arg2", int);
void namedArgsFunc(T...)(T arguments)
{
const vars = parseArguments!()(arguments);
const string one = vars.arg1;
const int two = vars.arg2;
}
namedArgsFunc(arg1(""), arg2(42));
namedArgsFunc(arg2(56), arg1("fred"));
}
...
Jonathan
This is a very interesting approach, but the problem is that the
person writing the function has to work to give support.
I think we should try to create a wrapper function taking the
original function as (alias F) that leverages
ParameterIdentifierTuple , ParameterTypeTuple and
ParameterDefaultValueTuple to generate the namedArguments
automatically.
Also, we could actually make this a Functor/Callback object that
has already created members that give you easy access to the
types of the named arguments. This way, we can even conceive a
way to return a "partial" function with enough arguments, and
only really call it when all the keyword arguments were actually
provided (or enough of them were provided and the rest have
provided a default value).
This will allow us to create a concise API that is convenient,
and strong.
Liran
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote: Thanks, but unfortunately, writing enhacement request to bugzilla is equals to writing to /dev/null :) No it's not, it keeps us from rediscussing the same stuff over and over. I'll create a DIP about this, when I'll have a free time. As the amount of DIPs grows, DIPs become the new ER. The problem is that this enhancement is of low priority and there is nothing you can do to change that, except for making a convincing case and a backward compatible implementation. What do you want about this syntax? Maybe you may suggest a better solution? A separate opIndexCreate might be better, b/c it allows you to have a ref return for one and an rvalue return for the other function. It also allows to use those operands as polymorphic functions in classes.
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 10:32:50 UTC, Martin Nowak wrote: On Friday, 29 May 2015 at 09:50:29 UTC, weaselcat wrote: Walter said likely/unlikely won't be implemented as the compiler already assumes the first condition is the more likely one the last time this was brought up. That is not what he said http://forum.dlang.org/post/m8739b$an$1...@digitalmars.com. Wow, I shouldn't post before going to bed. My apologies, remembered it way differently. Sorry for the noise.
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote: What do you want about this syntax? Maybe you may suggest a better solution? The discussion drifts a little OT, if we have opIndexCreate, then the library AA can be more compatible, but it still won't be a drop-in replacement.
Re: shared libs for OSX
On 2015-05-29 18:45, bitwise wrote:
I'm going to test it out this weekend, but if I do get the wrong
address, I think I can add a symbol with "__attribute__ ((visibility
("hidden")))" and use dladdr on that instead. I don't think hidden
symbols should collide.
Doesn't "dlopen" open the current image if "null" is passed? And that
void* which is returned is actually a "mach_header*", if I recall correctly.
--
/Jacob Carlborg
dmd makes D appear slow
In nearly every benchmark I see D in, the default compiler used is dmd which runs computationally intense tasks 4-5x+ slower than GDC/LDC example of a random blog post I found: http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html D is up to 10x(!) slower than Rust. Well... dmd is. Under LDC: MD5 is 5x faster, SHA1 is about the same, SHA256 is 10x faster, SHA512 is 10x faster. The kicker? _all_ of these were faster than the Rust timings(albeit by 5-10%) when using LDC. This isn't the first time I've seen this, in basically every benchmark featuring D I have to submit a patch/make a comment that dmd shouldn't be used. Make no mistake, this is damaging to D's reputation - how well does D's "native efficiency" go over when people are saying it's slower than Scala and F#(mono)? LDC and GDC need promoted more. Bye,
Re: dmd makes D appear slow
On Fri, May 29, 2015 at 06:13:02PM +, weaselcat via Digitalmars-d wrote: > In nearly every benchmark I see D in, the default compiler used is dmd > which runs computationally intense tasks 4-5x+ slower than GDC/LDC As I keep saying, in my own compute-intensive projects I have consistently found that dmd-generated code (dmd -O -inline -release) is about 20-30% slower on average, sometimes even up to 50% slower, compared to gdc-generated code (gdc -O3 -finline -frelease). This is measured by actual running time in an actual application, not benchmark-specific code. I have looked at the generated assembly before, and it's clear that the gdc optimizer is way ahead of dmd's. The dmd optimizer starts failing to inline inner loop code after about 1-2 levels of function call nesting, not to mention it's unable to factor out a lot of loop boilerplate code. The gdc optimizer, by contrast, not only factors out almost all loop boilerplate code and inlines inner loop function calls several levels deep, it also unrolls loops in a CPU-specific way, does major loop restructuring, compounded with much more linear code optimization than dmd does, instruction reordering and then refactoring after that, etc., in some cases reducing the size of inner loop code (as in, the amount of code that runs per iteration) by up to 90%. I don't know the internal workings of the dmd optimizer, but it's clear that at present, with almost nobody working on it except Walter, it's never going to catch up. (Maybe this statement will provoke Walter into working his magic? :-P) [...] > This isn't the first time I've seen this, in basically every benchmark > featuring D I have to submit a patch/make a comment that dmd shouldn't > be used. Make no mistake, this is damaging to D's reputation - how > well does D's "native efficiency" go over when people are saying it's > slower than Scala and F#(mono)? > > LDC and GDC need promoted more. [...] This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. T -- Marketing: the art of convincing people to pay for what they didn't need before which you fail to deliver after.
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. I did make LDC default compiler used in Arch but now people are unhappy with increased compile times so I may need to revert it back :)
Re: dmd makes D appear slow
On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d wrote: > On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: > >This will probably offend some people, but I think LDC/GDC should be > >the default download on dlang.org, and dmd should be provided as an > >alternative for those who want the latest language version and don't > >mind the speed compromise. > > I did make LDC default compiler used in Arch but now people are > unhappy with increased compile times so I may need to revert it back > :) Can't please 'em all... According to Walter, many D users want fast compile times, and aren't as concerned about performance of the generated code. But from this thread's OP, it seems there's another group of users who don't care about fast compile times but want the generated code to squeeze every last drop of performance from their CPUs. So I guess we should be equally recommending all 3 compilers, with a note to help people choose their compiler depending on their needs. T -- Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N
Re: dmd makes D appear slow
On 29 May 2015 20:15, "weaselcat via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > In nearly every benchmark I see D in, the default compiler used is dmd which runs computationally intense tasks 4-5x+ slower than GDC/LDC > > example of a random blog post I found: > http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html > > D is up to 10x(!) slower than Rust. > > Well... dmd is. Under LDC: > MD5 is 5x faster, > SHA1 is about the same, > SHA256 is 10x faster, > SHA512 is 10x faster. > > The kicker? > _all_ of these were faster than the Rust timings(albeit by 5-10%) when using LDC. > > This isn't the first time I've seen this, in basically every benchmark featuring D I have to submit a patch/make a comment that dmd shouldn't be used. Make no mistake, this is damaging to D's reputation - how well does D's "native efficiency" go over when people are saying it's slower than Scala and F#(mono)? > > LDC and GDC need promoted more. > > Bye, It's also hurting in a lot of recent pull requests I've been seeing. People are going out their way to micro optimise code for DMD, but ultimately their intention ends up being rejected because of GDC/LDC providing said optimisations for free. It's not just PR, but also a waste/drain on resource for people who could be better focusing their limited free time.
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: On Fri, May 29, 2015 at 06:13:02PM +, weaselcat via Digitalmars-d wrote: In nearly every benchmark I see D in, the default compiler used is dmd which runs computationally intense tasks 4-5x+ slower than GDC/LDC As I keep saying, in my own compute-intensive projects I have consistently found that dmd-generated code (dmd -O -inline -release) is about 20-30% slower on average, sometimes even up to 50% slower, compared to gdc-generated code (gdc -O3 -finline -frelease). This is measured by actual running time in an actual application, not benchmark-specific code. I have looked at the generated assembly before, and it's clear that the gdc optimizer is way ahead of dmd's. The dmd optimizer starts failing to inline inner loop code after about 1-2 levels of function call nesting, not to mention it's unable to factor out a lot of loop boilerplate code. The gdc optimizer, by contrast, not only factors out almost all loop boilerplate code and inlines inner loop function calls several levels deep, it also unrolls loops in a CPU-specific way, does major loop restructuring, compounded with much more linear code optimization than dmd does, instruction reordering and then refactoring after that, etc., in some cases reducing the size of inner loop code (as in, the amount of code that runs per iteration) by up to 90%. I don't know the internal workings of the dmd optimizer, but it's clear that at present, with almost nobody working on it except Walter, it's never going to catch up. (Maybe this statement will provoke Walter into working his magic? :-P) [...] This isn't the first time I've seen this, in basically every benchmark featuring D I have to submit a patch/make a comment that dmd shouldn't be used. Make no mistake, this is damaging to D's reputation - how well does D's "native efficiency" go over when people are saying it's slower than Scala and F#(mono)? LDC and GDC need promoted more. [...] This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. T LDC can work wonders, indeed. I've seen it. Drawback: GDC and LDC lag behind. D doesn't like legacy code, so I always update my code. Maybe we could synchronize dmd, ldc and gdc faster? Dmd is the only way to update your code.
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: On Fri, May 29, 2015 at 06:13:02PM +, weaselcat via Digitalmars-d wrote: In nearly every benchmark I see D in, the default compiler used is dmd which runs computationally intense tasks 4-5x+ slower than GDC/LDC As I keep saying, in my own compute-intensive projects I have consistently found that dmd-generated code (dmd -O -inline -release) is about 20-30% slower on average, sometimes even up to 50% slower, compared to gdc-generated code (gdc -O3 -finline -frelease). This is measured by actual running time in an actual application, not benchmark-specific code. I have looked at the generated assembly before, and it's clear that the gdc optimizer is way ahead of dmd's. The dmd optimizer starts failing to inline inner loop code after about 1-2 levels of function call nesting, not to mention it's unable to factor out a lot of loop boilerplate code. The gdc optimizer, by contrast, not only factors out almost all loop boilerplate code and inlines inner loop function calls several levels deep, it also unrolls loops in a CPU-specific way, does major loop restructuring, compounded with much more linear code optimization than dmd does, instruction reordering and then refactoring after that, etc., in some cases reducing the size of inner loop code (as in, the amount of code that runs per iteration) by up to 90%. I don't know the internal workings of the dmd optimizer, but it's clear that at present, with almost nobody working on it except Walter, it's never going to catch up. (Maybe this statement will provoke Walter into working his magic? :-P) dmd's backend is also under a proprietary license reducing the amount of people willing to contribute. Not to mention that GDC and LDC benefit heavily from GCC and LLVM respectively, these aren't exactly one man projects(e.g, Google, Redhat, Intel, AMD etc contribute heavily to GCC and LLVM is basically Apple's baby.) [...] This isn't the first time I've seen this, in basically every benchmark featuring D I have to submit a patch/make a comment that dmd shouldn't be used. Make no mistake, this is damaging to D's reputation - how well does D's "native efficiency" go over when people are saying it's slower than Scala and F#(mono)? LDC and GDC need promoted more. [...] This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. T I think they probably should be if only for the licensing issues, dmd can't even be redistributed - AFAIK it's in very, very few D repositories on Linux. re dicebot: I did make LDC default compiler used in Arch but now people are unhappy with increased compile times so I may need to revert it back :) Maybe this should be brought up on LDC's issue tracker(that is, slower compilation times compared to dmd.) Although it might have already been discussed.
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 19:01:18 UTC, H. S. Teoh wrote: On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d wrote: On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: >This will probably offend some people, but I think LDC/GDC >should be >the default download on dlang.org, and dmd should be provided >as an >alternative for those who want the latest language version >and don't >mind the speed compromise. I did make LDC default compiler used in Arch but now people are unhappy with increased compile times so I may need to revert it back :) Can't please 'em all... According to Walter, many D users want fast compile times, and aren't as concerned about performance of the generated code. But from this thread's OP, it seems there's another group of users who don't care about fast compile times but want the generated code to squeeze every last drop of performance from their CPUs. So I guess we should be equally recommending all 3 compilers, with a note to help people choose their compiler depending on their needs. T I think it might be worth investigating why LDC/GDC are slower than dmd when compiling non-optimized builds. This seems like something that would be easier to solve than getting dmd up to the same performance level as LDC/GDC. Bye,
Re: dmd makes D appear slow
On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d wrote: On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. I did make LDC default compiler used in Arch but now people are unhappy with increased compile times so I may need to revert it back :) Can't please 'em all... According to Walter, many D users want fast compile times, and aren't as concerned about performance of the generated code. But from this thread's OP, it seems there's another group of users who don't care about fast compile times but want the generated code to squeeze every last drop of performance from their CPUs. So I guess we should be equally recommending all 3 compilers, with a note to help people choose their compiler depending on their needs. myOpinion = (fastCompileTimes * 1 < fastCode); -Steve
Re: dmd makes D appear slow
On 5/29/15 12:13 PM, weaselcat wrote: In nearly every benchmark I see D in, the default compiler used is dmd which runs computationally intense tasks 4-5x+ slower than GDC/LDC example of a random blog post I found: http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html One problem here is pointed by the blogger: "I tried to compile with LDC2 and failed (windows 7 x64): ..." Can he be helped? Andrei
Re: dmd makes D appear slow
IMHO all what is needed is to update the download page with some description of deferences between the compilers, like: dmd - reference compiler, Digital Mars backend - best for latest dlang features, fast compile times gdc - GNU gcc backend based compiler - best for portability and compatibility with gnu tools ldc - LLVM backend based compiler - best for optimized builds, best runtime speed Note to benchmark users: please use ldc compiler with -inline -O -boundscheck=off (or whatever is correct for LDC) options for best results
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 20:02:49 UTC, Martin Krejcirik wrote: IMHO all what is needed is to update the download page with some description of deferences between the compilers, like: +1
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 19:17:14 UTC, Andrei Alexandrescu wrote: On 5/29/15 12:13 PM, weaselcat wrote: In nearly every benchmark I see D in, the default compiler used is dmd which runs computationally intense tasks 4-5x+ slower than GDC/LDC example of a random blog post I found: http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html One problem here is pointed by the blogger: "I tried to compile with LDC2 and failed (windows 7 x64): ..." Can he be helped? http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html?showComment=1432925658409#c6228383399074019471
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 20:23:13 UTC, Vladimir Panteleev wrote: On Friday, 29 May 2015 at 19:17:14 UTC, Andrei Alexandrescu wrote: On 5/29/15 12:13 PM, weaselcat wrote: In nearly every benchmark I see D in, the default compiler used is dmd which runs computationally intense tasks 4-5x+ slower than GDC/LDC example of a random blog post I found: http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html One problem here is pointed by the blogger: "I tried to compile with LDC2 and failed (windows 7 x64): ..." Can he be helped? http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html?showComment=1432925658409#c6228383399074019471 Thanks, he updated the results. DMD MD5 - 16.05s (470% slower) SHA1 - 2.35s (19% faster) SHA256 - 47.96s (690% slower (!)) SHA512 - 61.47s (1375% slower (!)) LDC2 MD5 - 2,18s (55% faster) SHA1 - 2.88s (same) SHA256 - 6,79s (3% faster) SHA512 - 4,6s (3% slower) % is compared to Rust.
Re: Why aren't you using D at work?
On Friday, 29 May 2015 at 12:55:13 UTC, Chris wrote: Fair play to you! We should bundle these efforts. What about a page where we collect all this stuff like "I miss this feature in D, and here's my own library for it." We all have stuff like this in the attic somewhere. http://code.dlang.org/
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 20:02:49 UTC, Martin Krejcirik wrote: Note to benchmark users: please use ldc compiler with -inline -O -boundscheck=off (or whatever is correct for LDC) options for best results AFAIK you shouldn't use the -inline flag with LDC, as it tells LDC to run the inline LLVM pass. LDC's inlining is enabled with -enable-inlining and is enabled at -O2 and higher. I believe these are similar except LDC's -enable-inlining has better cost analysis configured for the pass(?) -inline should probably be renamed because this is confusing due to dmd's usage of it. But yes, a simple blurb on which compiler flags to use for optimization would probably help as there seems to be some confusion about this due to differing compiler flags. I imagine Iain, Kai, Nadlinger, etc would know which ones to use.
Re: DIP66 1.2 (Multiple) alias this. Continuation of work.
On Tuesday, 26 May 2015 at 00:03:43 UTC, Andrei Alexandrescu wrote: On 5/25/15 3:01 PM, IgorStepanov wrote: Ok, I've applied your changes to the DIP page, and I'm starting to rework my github PR. Sorry for the slow work (I'm very busy last time). However I still working. Stay on line=) Thanks. Please get this done and let's pull it in for 068. -- Andrei I've finished preparing of the github PR. Now it is ready for review.
dlang.org build broken
Folks, looks like there are multiple breakages in the Phobos documentation build for dlang.org. Could someone look into this pronto? -- Andrei
Re: DIP66 1.2 (Multiple) alias this. Continuation of work.
On 5/29/15 3:37 PM, IgorStepanov wrote: On Tuesday, 26 May 2015 at 00:03:43 UTC, Andrei Alexandrescu wrote: On 5/25/15 3:01 PM, IgorStepanov wrote: Ok, I've applied your changes to the DIP page, and I'm starting to rework my github PR. Sorry for the slow work (I'm very busy last time). However I still working. Stay on line=) Thanks. Please get this done and let's pull it in for 068. -- Andrei I've finished preparing of the github PR. Now it is ready for review. So https://github.com/D-Programming-Language/dmd/pull/3998 is the one? -- Andrei
Re: dlang.org build broken
On 5/29/15 3:35 PM, Andrei Alexandrescu wrote: Folks, looks like there are multiple breakages in the Phobos documentation build for dlang.org. Could someone look into this pronto? -- Andrei I'm working on the UnixAddress issues, will have a PR after I verify it passes the normal tests. -Steve
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 17:52:58 UTC, Martin Nowak wrote: On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote: What do you want about this syntax? Maybe you may suggest a better solution? The discussion drifts a little OT, if we have opIndexCreate, then the library AA can be more compatible, but it still won't be a drop-in replacement. We went a long way in this direction and if we don't come to the result yet, that, I think, we haven't thought-out plan. I suggest you to answer to the following two question: 1. What way to transit to the new AA would be acceptable? You rejects my way (and I could not continue to work in the winter), and AFAIR you principial objection was: "aaLiteral is non-@safe for the unsafe code and it is breakage". However, aaLiteral attributes hasn't checked by compiler, because it was used in e2ir. _d_assocarrayliteralTX is not @safe or pure, but aa can be used in @safe pure code. We may insert additional checks, see aaLiteral attributes, and raise deprecation message, if attributes are inacceptable. If it is the last objection, we may repeat compiler-side part for the new AA template. Othrewice, lets invent another way. 2. What issues disallows us to implement full library AA? Except .stringof, .mangleof, and other compiler magic. I see only two issues: opIndexCreate and building aa from literals.
Re: dlang.org build broken
On 5/29/15 3:47 PM, Steven Schveighoffer wrote: On 5/29/15 3:35 PM, Andrei Alexandrescu wrote: Folks, looks like there are multiple breakages in the Phobos documentation build for dlang.org. Could someone look into this pronto? -- Andrei I'm working on the UnixAddress issues, will have a PR after I verify it passes the normal tests. PR: https://github.com/D-Programming-Language/phobos/pull/3344 And BTW, how can we get the ddoc build to be part of the auto tester? It's kind of important. Luckily, it's only built on one platform, we can pick the fastest. If at all possible, if the auto generated ddocs could be available for the PR, that would be hugely helpful. Right now, when ddoc changes are made, you have to build them locally to see the changes. -Steve
Re: dlang.org build broken
On 5/29/15 3:56 PM, Steven Schveighoffer wrote: On 5/29/15 3:47 PM, Steven Schveighoffer wrote: On 5/29/15 3:35 PM, Andrei Alexandrescu wrote: Folks, looks like there are multiple breakages in the Phobos documentation build for dlang.org. Could someone look into this pronto? -- Andrei I'm working on the UnixAddress issues, will have a PR after I verify it passes the normal tests. PR: https://github.com/D-Programming-Language/phobos/pull/3344 And BTW, how can we get the ddoc build to be part of the auto tester? It's kind of important. Luckily, it's only built on one platform, we can pick the fastest. If at all possible, if the auto generated ddocs could be available for the PR, that would be hugely helpful. Right now, when ddoc changes are made, you have to build them locally to see the changes. -Steve cc Brad Roberts -- Andrei
Re: dlang.org build broken
On Friday, 29 May 2015 at 21:35:23 UTC, Andrei Alexandrescu wrote: Folks, looks like there are multiple breakages in the Phobos documentation build for dlang.org. Could someone look into this pronto? -- Andrei https://github.com/D-Programming-Language/druntime/pull/1289/files https://github.com/D-Programming-Language/phobos/pull/3346
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 19:16:45 UTC, Steven Schveighoffer wrote: On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d wrote: On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. I did make LDC default compiler used in Arch but now people are unhappy with increased compile times so I may need to revert it back :) Can't please 'em all... According to Walter, many D users want fast compile times, and aren't as concerned about performance of the generated code. But from this thread's OP, it seems there's another group of users who don't care about fast compile times but want the generated code to squeeze every last drop of performance from their CPUs. So I guess we should be equally recommending all 3 compilers, with a note to help people choose their compiler depending on their needs. myOpinion = (fastCompileTimes * 1 < fastCode); -Steve For the development cycle too?
Re: dlang.org build broken
On Fri, May 29, 2015 at 03:56:43PM -0600, Steven Schveighoffer via Digitalmars-d wrote: > On 5/29/15 3:47 PM, Steven Schveighoffer wrote: > >On 5/29/15 3:35 PM, Andrei Alexandrescu wrote: > >>Folks, looks like there are multiple breakages in the Phobos > >>documentation build for dlang.org. Could someone look into this pronto? > >>-- Andrei > > > >I'm working on the UnixAddress issues, will have a PR after I verify > >it passes the normal tests. > > PR: https://github.com/D-Programming-Language/phobos/pull/3344 > > And BTW, how can we get the ddoc build to be part of the auto tester? > It's kind of important. Luckily, it's only built on one platform, we > can pick the fastest. There's a problem with building it on just one platform: platform-specific docs don't get built. For example, std.windows.* isn't getting built at all. Even if we added it to the makefile, it still wouldn't work, since it's version'd out by platform. > If at all possible, if the auto generated ddocs could be available for > the PR, that would be hugely helpful. Right now, when ddoc changes are > made, you have to build them locally to see the changes. [...] +1. This would be an incredibly useful addition to the autotester. T -- Designer clothes: how to cover less by paying more.
Re: DIP66 1.2 (Multiple) alias this. Continuation of work.
On Friday, 29 May 2015 at 21:41:12 UTC, Andrei Alexandrescu wrote: On 5/29/15 3:37 PM, IgorStepanov wrote: On Tuesday, 26 May 2015 at 00:03:43 UTC, Andrei Alexandrescu wrote: On 5/25/15 3:01 PM, IgorStepanov wrote: Ok, I've applied your changes to the DIP page, and I'm starting to rework my github PR. Sorry for the slow work (I'm very busy last time). However I still working. Stay on line=) Thanks. Please get this done and let's pull it in for 068. -- Andrei I've finished preparing of the github PR. Now it is ready for review. So https://github.com/D-Programming-Language/dmd/pull/3998 is the one? -- Andrei Yep.
Re: dlang.org build broken
On 5/29/15 4:02 PM, Andrei Alexandrescu via Digitalmars-d wrote: On 5/29/15 3:56 PM, Steven Schveighoffer wrote: PR: https://github.com/D-Programming-Language/phobos/pull/3344 And BTW, how can we get the ddoc build to be part of the auto tester? It's kind of important. Luckily, it's only built on one platform, we can pick the fastest. If at all possible, if the auto generated ddocs could be available for the PR, that would be hugely helpful. Right now, when ddoc changes are made, you have to build them locally to see the changes. -Steve cc Brad Roberts -- Andrei I agree that some sort of testing infrastructure should be built for documentation build, review, and testing. I don't believe that the needs overlap sufficiently with code building and testing and can be made generic enough (the d doc tooling is _very_ specific to d) to fit into a generic CI tool that it fits within the current auto-tester. There's certainly some very high level overlaps, but ultimately, I believe that something dedicated to documentation build/review/testing would be a better path.
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote: I suggest you to answer to the following two question: 1. What way to transit to the new AA would be acceptable? One that doesn't break any code, carefully deprecates necessary semantic changes, and provides an improved implementation. You rejects my way (and I could not continue to work in the winter), and AFAIR you principial objection was: "aaLiteral is non-@safe for the unsafe code and it is breakage". The objection was too much code breakage for an inferior implementation. https://github.com/D-Programming-Language/druntime/pull/934#issuecomment-66888409 We may insert additional checks, see aaLiteral attributes, and raise deprecation message, if attributes are inacceptable. Maybe we can hack around the attribute incompatibilities in the compiler, we'll have to add deprecations at some point anyhow. 2. What issues disallows us to implement full library AA? Except .stringof, .mangleof, and other compiler magic. I see only two issues: opIndexCreate and building aa from literals. - error messages - attributes - literals (especially polysemous initializers, i.e. ubyte[ubyte] aa = [0:1, 1:2]) - implicit tail const conversion Val[Key] -> const(Val)[Key] - lots of magic around making Key const - delete aa[key] - lots of other small details (grep for Taarray in src/expression.c) This is a heavily used built-in type, we can't risk a rewrite that breaks lots of code.
Re: shared libs for OSX
On Fri, 29 May 2015 14:05:10 -0400, Jacob Carlborg wrote:
On 2015-05-29 18:45, bitwise wrote:
I'm going to test it out this weekend, but if I do get the wrong
address, I think I can add a symbol with "__attribute__ ((visibility
("hidden")))" and use dladdr on that instead. I don't think hidden
symbols should collide.
Doesn't "dlopen" open the current image if "null" is passed?
No, it opens the image for the main program, even if called from a shared
lib.
And that void* which is returned is actually a "mach_header*", if I
recall correctly.
Not sure if this is true.
This works for sure in terms of getting "a" mach_header*, but I still have
to check if visibility(hidden) allows each shared lib to have it's own
copy of "_symbol":
__attribute__ ((visibility("hidden"))) static int _symbol = 1;
Dl_info info;
if(dladdr(&symbol, &info))
const struct mach_header* myHeader = cast(const struct
mach_header*)info.dli_fbase
https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dladdr.3.html
Bit
Re: is there any reason to use SuperFastHash in druntime? (except speed)
On Fri, 29 May 2015 09:36:22 +, Martin Nowak wrote: > On Thursday, 28 May 2015 at 03:09:07 UTC, ketmar wrote: >> i think that there is some sense in trading some speed for better >> distribution. >> what do you think? > We discussed most part of this already. > http://forum.dlang.org/post/mff4id$hj8$1...@digitalmars.com i was more interested in reasons behind choosing SFH, yet worded my question poorly. sorry. > Though I don't get any feedback for the library AA. > http://forum.dlang.org/post/mjsma6$196h$1...@digitalmars.com me has nothing valuable to say. ;-) sadly, i can see things done wrong only after they were done, not in the design stage. >> and i believe that people that care about performance will roll their >> own hash functions anyway > Anyone will use the built-in hash, performance is of utmost importance. i believe that it should be "acceptable", not "fastest possible". i like to trade some speed for better output, for example. what is the reason of having superfast, but not good hash function? code will spend alot of time resolving collisions then. ;-) >> [2] http://code.google.com/p/fast-hash/ > It's called fast hash, but how fast is it? i didn't do any serious measurement, but for me it's slightly faster than Murmur3 (which is seen even in code, as it uses one multiplication where Murmur3 is using two), and the quality of output is comparable. signature.asc Description: PGP signature
Re: is there any reason to use SuperFastHash in druntime? (exceptspeed)
On Fri, 29 May 2015 11:52:58 +0200, Daniel Kozák via Digitalmars-d wrote: > A little bit faster than murnurhash3 in my scenerio. But I prefer > farmhash. http://code.google.com/p/farmhash/ thank you, i didn't hit that one before. signature.asc Description: PGP signature
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 22:05:27 UTC, Idan Arye wrote: For the development cycle too? I've had LDC edge out dmd in compilation times during development cycle. dmd sees zero boost from separate object compilation. Using DCD as an example(because it has not-long not-short build times,) initial non-optimized build took 3.10 elapsed with dmd, 5.11 with ldc. Changing one file and building took the same amount for dmd but only 0.43 seconds(430 milliseconds) for ldc. Bye,
Re: dmd makes D appear slow
On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote: > On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d > wrote: >> On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: >> >This will probably offend some people, but I think LDC/GDC should be >> >the default download on dlang.org, and dmd should be provided as an >> >alternative for those who want the latest language version and don't >> >mind the speed compromise. >> >> I did make LDC default compiler used in Arch but now people are unhappy >> with increased compile times so I may need to revert it back :) > > Can't please 'em all... According to Walter, many D users want fast > compile times, and aren't as concerned about performance of the > generated code. But from this thread's OP, it seems there's another > group of users who don't care about fast compile times but want the > generated code to squeeze every last drop of performance from their > CPUs. > > So I guess we should be equally recommending all 3 compilers, with a > note to help people choose their compiler depending on their needs. the thing is that benchmarks are measuring execution time, not compiling time. that's why D is failing benchmarks. making LDC or GDC a "reference" compiler, and stating that if someone is ready to trade codegen quality for compilation speed, he can use DMD instead, is the way to start being "benchmark friendly". people doing benchmarks usually downloading what official site gives 'em. so they taking DMD and assuming that it's the best *execution* speed D can offer. i.e. developers can continue using DMD as their base, but offering it as "experimental compiler not recommended to use in production" on the offsite, replacing "download D compiler" links with LDC/GDC. this way people will not get Hot New Features right away, but "D is slw" rants will go down. ;-) signature.asc Description: PGP signature
Re: dmd makes D appear slow
On Fri, 29 May 2015 20:02:47 +, Martin Krejcirik wrote: > dmd >- reference compiler, Digital Mars backend - best for latest dlang >features, fast compile times > > gdc >- GNU gcc backend based compiler - best for portability and >compatibility with gnu tools > > ldc >- LLVM backend based compiler - best for optimized builds, best >runtime speed does LDC really surpasses GDC in generated code speed? signature.asc Description: PGP signature
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 23:19:36 UTC, ketmar wrote: On Fri, 29 May 2015 20:02:47 +, Martin Krejcirik wrote: dmd - reference compiler, Digital Mars backend - best for latest dlang features, fast compile times gdc - GNU gcc backend based compiler - best for portability and compatibility with gnu tools ldc - LLVM backend based compiler - best for optimized builds, best runtime speed does LDC really surpasses GDC in generated code speed? yes GDC is 2-3x slower than LDC on this bench for example. I think it's because of a lack of cross module inlining.
Re: dmd makes D appear slow
On Fri, 29 May 2015 23:29:39 +, weaselcat wrote: > On Friday, 29 May 2015 at 23:19:36 UTC, ketmar wrote: >> On Fri, 29 May 2015 20:02:47 +, Martin Krejcirik wrote: >> >>> dmd >>>- reference compiler, Digital Mars backend - best for >>> latest dlang >>>features, fast compile times >>> >>> gdc >>>- GNU gcc backend based compiler - best for portability and >>>compatibility with gnu tools >>> >>> ldc >>>- LLVM backend based compiler - best for optimized builds, >>> best >>>runtime speed >> >> does LDC really surpasses GDC in generated code speed? > > yes GDC is 2-3x slower than LDC on this bench for example. I think it's > because of a lack of cross module inlining. thanks for the info. signature.asc Description: PGP signature
Re: Proof of concept - library AA
On 5/29/15 4:41 PM, Martin Nowak wrote: On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote: I suggest you to answer to the following two question: 1. What way to transit to the new AA would be acceptable? One that doesn't break any code, carefully deprecates necessary semantic changes, and provides an improved implementation. I suggest first we build a library AA that sits beside real AA, even if it doesn't . Then we create a test suite to prove that the library AA can be a drop in replacement. Then replace it :) Put it in code.dlang or std.experimental. It's better to have code to play with and test than it is to do everything at once. -Steve
Re: dmd makes D appear slow
On 5/29/15 4:05 PM, Idan Arye wrote: On Friday, 29 May 2015 at 19:16:45 UTC, Steven Schveighoffer wrote: On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d wrote: On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. I did make LDC default compiler used in Arch but now people are unhappy with increased compile times so I may need to revert it back :) Can't please 'em all... According to Walter, many D users want fast compile times, and aren't as concerned about performance of the generated code. But from this thread's OP, it seems there's another group of users who don't care about fast compile times but want the generated code to squeeze every last drop of performance from their CPUs. So I guess we should be equally recommending all 3 compilers, with a note to help people choose their compiler depending on their needs. myOpinion = (fastCompileTimes * 1 < fastCode); For the development cycle too? I saw the slide from Liran that shows your compiler requirements :) I can see why it's important to you. But compiled code outlives the compiler execution. It's the wart that persists. But techniques (for most projects) are available to speed compile time, and even in that case, compile time for whole project is quite low. For very large projects, toolchain performance is definitely important. We need to work on that. But I don't see how speed of compiler should sacrifice runtime performance. -Steve
ddox no longer part of dlang.org?
In Andrei's presentation last night, he mentioned that the new ddox documentation coincided with a surge in visits to dlang.org. However, I just noticed, the link to them is gone. How long has that been the case, and can we put them back up? Also, does anyone know how often the "prerelease" linked docs are updated? -Steve
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 22:41:13 UTC, Martin Nowak wrote:
On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote:
I suggest you to answer to the following two question:
1. What way to transit to the new AA would be acceptable?
One that doesn't break any code, carefully deprecates necessary
semantic changes, and provides an improved implementation.
You rejects my way (and I could not continue to work in the
winter), and AFAIR you principial objection was: "aaLiteral is
non-@safe for the unsafe code and it is breakage".
The objection was too much code breakage for an inferior
implementation.
https://github.com/D-Programming-Language/druntime/pull/934#issuecomment-66888409
We may insert additional checks, see aaLiteral attributes, and
raise deprecation message, if attributes are inacceptable.
I recall a list of your demands.
1. open addressing
2. efficient construction, insertion and assignment (no extra
copies or postblits)
3. fully CTFEable (includes storing literals in the data segment)
4. type and attribute correctness
5. get's rid of TypeInfo methods (toHash, opEquals, tsize)
6. GC NO_SCAN for values
1. It depends only on library AA implementation, not on
dmd-druntime interaction.
2. This goal was achieved in my last AA version. Open addressing
edition may get us troubles with it, but I think this troubles
are solvable.
3. Storing CTFE literals was implemented in that implementation.
Maybe not quite right, but the problem is also solvable.
4. This solution follows directly from template implementation.
5. Was done.
6. This problem is also solvable.
Now about backward compatibility:
AFAIR you pointed to the one breakage: the forced checking of
attribute correctness.
I then entered into an argument with you, but I forgot, that the
forced attribute checking was disabled in the last edition:
Yes, aaLiteral gets attributes from the underlying code, and if
AA constructor was unsafe, aaLiteral was unsafe too.
However, AssocArrayLiteralExp::toElem doesn't check the attribute
correctness and constructing of unsafe or non-throwable AA from
safe or throwable code was allowed.
Or I forgot about some other breakage cases?
2. What issues disallows us to implement full library AA?
Except .stringof, .mangleof, and other compiler magic.
I see only two issues: opIndexCreate and building aa from
literals.
- error messages
- attributes
- literals (especially polysemous initializers, i.e.
ubyte[ubyte] aa = [0:1, 1:2])
- implicit tail const conversion Val[Key] -> const(Val)[Key]
- lots of magic around making Key const
- delete aa[key]
- lots of other small details (grep for Taarray in
src/expression.c)
This is a heavily used built-in type, we can't risk a rewrite
that breaks lots of code.
- error messages
Is it a significant problem? If compiler allows correct code,
disallows incorrect code and gets a clear error messages there
there is no problem, I think. Of cource, we will need to write
pretty error messages, implement correct .stringof in dmd (to
writting type name as V[K], not as AA!(K, V).
- attributes
We will able to deprecate attribute violations in transitional
version (with vtbl).
- literals (especially polysemous initializers, i.e.
ubyte[ubyte] aa = [0:1, 1:2])
Yes, this is the first main trouble.
- implicit tail const conversion Val[Key] -> const(Val)[Key]
May be we may add "alias this"-es for all all those variants?
Something like ...
struct AA(K, V)
{
alias getCKeyMval this;
alias getMKeyCval this;
alias getCKeyCval this;
@property {
ref AA!(const(K), V) getCKeyMval() { return
*cast(typeof(return)*)&this; }
ref AA!(K, const(V)) getMKeyCval() { return
*cast(typeof(return)*)&this; }
ref AA!(const(K), const(V)) getCKeyCval() { return
*cast(typeof(return)*)&this; }
}
}
- lots of magic around making Key const
The most count of them may be solved without language modifying.
- delete aa[key]
This case has gone one or two years ago.
Now for the following code...
int[int] aa;
delete aa[5];
... compiler writes me "Error: cannot delete type int"
- lots of other small details (grep for Taarray in
src/expression.c)
We should start to try to find and solve them.
As I see, we now we need only two language change requirements:
opIndexCreate and AA literal overloading.
The rest of the problems can be identified at the stage of
parallel operation of both implementations.
Re: dmd makes D appear slow
On 30 May 2015 at 09:14, ketmar via Digitalmars-d wrote: > On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote: > >> On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d >> wrote: >>> On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote: >>> >This will probably offend some people, but I think LDC/GDC should be >>> >the default download on dlang.org, and dmd should be provided as an >>> >alternative for those who want the latest language version and don't >>> >mind the speed compromise. >>> >>> I did make LDC default compiler used in Arch but now people are unhappy >>> with increased compile times so I may need to revert it back :) >> >> Can't please 'em all... According to Walter, many D users want fast >> compile times, and aren't as concerned about performance of the >> generated code. But from this thread's OP, it seems there's another >> group of users who don't care about fast compile times but want the >> generated code to squeeze every last drop of performance from their >> CPUs. >> >> So I guess we should be equally recommending all 3 compilers, with a >> note to help people choose their compiler depending on their needs. > > the thing is that benchmarks are measuring execution time, not compiling > time. that's why D is failing benchmarks. making LDC or GDC a "reference" > compiler, and stating that if someone is ready to trade codegen quality > for compilation speed, he can use DMD instead, is the way to start being > "benchmark friendly". > > people doing benchmarks usually downloading what official site gives 'em. > so they taking DMD and assuming that it's the best *execution* speed D > can offer. > > i.e. developers can continue using DMD as their base, but offering it as > "experimental compiler not recommended to use in production" on the > offsite, replacing "download D compiler" links with LDC/GDC. this way > people will not get Hot New Features right away, but "D is slw" rants > will go down. ;-) I actually think this is a really good idea. I don't think it's right that random people should encounter DMD as a first impression, they should encounter GDC or LDC, since those are the toolsets they will be making direct comparisons against during their evaluation. At the point that they're not yet a D enthusiast, access to cutting edge language features should mean practically nothing to them. That said, it would be nice if the DMD developer community at large were able to work closer with GDC/LDC. Is there some changes in workflow that may keep GDC/LDC up to date beside DMD as PR's are added? Possible to produce 'nightlies' for those compilers, so that developers following mainline DMD can easily update their respective compilers to reflect? Perhaps DMD developers could even develop language features against LDC instead of DMD, and backport to DMD? For my work, and what I noticed in my other thread, is that LDC is central to expansion of the D ecosystem, and I think it needs to be taken more seriously by the entire DMD community; it can't be a little thing off to the side. LDC gives us portability; iOS, Android, Windows, Emscripten, NativeClient, and plenty of other platforms. It's 2015; the fact that we still don't support Android and iOS is just not unacceptable. Most computers in the world run those operating systems. LDC is also the only performant way to target Windows, the overwhelmingly largest desktop platform... but we lose the debugger! >_< How can we release products created with D if we still don't have a way to build and run on modern computers? So, LDC: Windows, Android, iOS... this must be 99.% of computers on the planet! LDC needs to be first-class. Ideally, even more polished than DMD, and it should probably be the first contact people have with D. * I don't mean to down-play GDC, but it can't give us Windows or iOS, which are critical targets. I want to use D in my work, right now. I could... if I could actually target the computers we run code on.
