Re: Rant after trying Rust a bit
On 7/25/2015 3:28 PM, deadalnix wrote:
Also, argument from ignorance is hard to maintain when the thread is an actual
feedback from experience.
You say that interfaces do the same thing. So please show how it's done with the
example I gave:
int foo(T: hasPrefix)(T t) {
t.prefix();// ok
bar(t);// error, hasColor was not specified for T
}
void bar(T: hasColor)(T t) {
t.color();
}
Re: Rant after trying Rust a bit
On Sunday, 26 July 2015 at 00:31:48 UTC, Jonathan M Davis wrote:
auto foo(T)(T t)
if(cond1!T cond2!T cond3!T cond4!T cond5!T
cond6!T cond7!T)
{
...
auto b = bar(t);
...
auto c = baz(t);
...
}
auto bar(T)(T t)
if(cond2!T cond3!T)
{
...
auto l = lark(t);
...
}
auto baz(T)(T t)
if(cond1!T cond4!T)
{
...
auto s = stork(t);
...
}
auto lark(T)(T t)
if(cond5!T cond6!T)
{
...
}
auto stork(T)(T)
if(cond2!T cond3!T cond7!T)
{
auto w = wolf(t);
}
auto wolf(T)(T)
if(cond7!T)
{
...
}
Regardless of this debate, it would be great if template
constraints could be inferred. It seems rather trivial.
Although I understand that a lot of times the compiler doesn't
have the function's body at hand.
Run D on AWS Lambda
https://aws.amazon.com/lambda/ https://github.com/Laeeth/awslambda_d http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/ No proper docs yet, but you can figure it out from the go example.
Re: D Web Services Application Potential?
On Sunday, 26 July 2015 at 03:04:21 UTC, Brandon Ragland wrote: On Sunday, 26 July 2015 at 02:53:12 UTC, Etienne Cimon wrote: On 2015-07-25 22:35, Brandon Ragland wrote: On Sunday, 26 July 2015 at 00:46:58 UTC, Etienne Cimon wrote: [...] In relation to DDB: Have you seen: https://github.com/buggins/ddbc It's most similar to the JDBC driver in Java. Currently supports MySQL, PostgreSQL and SQLite. That might be a good starting point to expand the SQL driver support for a web framework. I dug around some of your repos, too early to comment but I'll sift through more of it as time allows, see if I can't offer anything towards your current goals in the near future. I fully agree that D would be a great fit for web development. Thanks for the reply. Yes, the goal is to avoid libpq. A typical Vibe.d TCP Connection is based on what you know as Green Threads, it's called Tasks/Fibers in D. It means you have to avoid any library that uses thread-blocking I/O because you're using 1 thread to handle all requests. That would make sense then. Was unaware vibe.d was using green threading. The JVM dropped green threads circa 1.2, a long time ago. I suppose the complexity of asynchronous I/O was never implemented to avoid these blocking issues with fibers/tasks? There's a way to avoid the blocking by spawning more threads (through worker tasks), but it's so much more efficient to use native protocol implementations. After all, this is how D and vibe.d can get the most req/s compared to the other native frameworks. Somebody took the time to write a very elaborate standoff and it shows a pretty accurate picture of it: https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/
[Issue 14742] Changing function signatures breaks code
https://issues.dlang.org/show_bug.cgi?id=14742 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Walter Bright bugzi...@digitalmars.com --- I'm going to resolve this as wontfix. I know I come down hard on breaking changes, but in my mind I thought it was good enough if calling the function with the same arguments continues to work. For example, adding a parameter with a default value will enable the calls to work, but of course anything using ParameterTypeTupe or relying on the particular mangled name is going to break. I'm going to say that the latter two cases are a little too restrictive to say we won't break them. --
Re: Rant after trying Rust a bit
On Sunday, 26 July 2015 at 01:56:29 UTC, Tofu Ninja wrote: Key point is opt-in. Opt-in doesn't really fix the problem. It just allows you to choose whether you're going to break more code by requiring that all template constraints be updated because a function being called inside somewhere had its constraint updated. So, you're choosing whether to opt-in to that problem or not, but if you opt-in, you're still screwed by it. That's not going to change just because it's optional. And my point about template constraint condition proliferation holds even with the current implementation. Anyone choosing to try and put all of the sub-constraints in the top-level constraint has a maintenance problem. Sure, you can choose not to do that and let the user see errors from within the template when they use a type that fails the template constraint of a function being called and thus avoid the constraint proliferation (which then causes its own problems due to how that's more annoying to deal with when you run into it), but the problem is still there. If you opt-in to putting everything in the top-level template constraints, you will have a maintenance issue. The fact that you can choose what you do or don't put in your template constraints (or that you could choose whether to use the new paradigm/feature that you're proposing) doesn't fix the problem that going that route causes maintenance issues. That fundamental problem still remains. All it means is that you can choose whether you want to cause yourself problems by going that route, not that they're necessarily a good idea. - Jonathan M Davis
Re: Run D on AWS Lambda
On 26/07/2015 3:55 p.m., Laeeth Isharc wrote: https://aws.amazon.com/lambda/ https://github.com/Laeeth/awslambda_d http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/ No proper docs yet, but you can figure it out from the go example. FYI, based upon what I could find, it is using Amazon Linux[0] x64. So because right now we cannot cross compile really, linux has to be host OS to build these with D, locally atleast. [0] http://aws.amazon.com/amazon-linux-ami/
Re: Rant after trying Rust a bit
On Sunday, 26 July 2015 at 02:15:20 UTC, jmh530 wrote:
On Sunday, 26 July 2015 at 00:31:48 UTC, Jonathan M Davis wrote:
On Friday, 24 July 2015 at 01:09:19 UTC, H. S. Teoh wrote:
The second issue that I see with your suggestion is basically
what Walter is saying the problem is. Even if we assume that
we _do_ want to put all of the requirements for foo - direct
or indirect - in its template constraint, this causes a
maintenance problem. For instance, if foo were updated to call
another function
I think from your post I finally understand what Walter was
getting at.
Not sure if this simplifies things, but what if instead you do
something like
void foo(T)(T t)
if (__traits(compiles, bar(t) __traits(compiles, baz(t)))
{
...
auto b = bar(t);
...
auto c = baz(t);
...
}
This only really works in the case where it's obvious that you
are calling some bar(t). It might not work more generally...
Anyway, in your next example, you have additional layers with
some more condn!T constraints. If instead you just have more
__traits(compiles, x) for whatever templates they are calling,
then checking that bar compiles necessarily also tests whether
those other functions can compile as well. In this way, you're
testing all the constraints at lower levels. So I guess you
would still be checking that each constraint works, but at the
highest level you only have to specify that the templates you
are calling compile.
In my opinion this is superior (for this case) because if you
change bar and baz then you don't have to make changes to foo.
Am I wrong? Is this just another way of doing the same thing?
I suggested the same in response to Walter earlier. It is one way
to combat the problem. However, it's really only going to work in
basic cases (at least, without getting ugly). What if what you
passed to bar wasn't t but was a result from calling a function
on t? Or maybe it was a result of calling a function on the
return value of a function that was called on t? Or perhaps you
passed t through a chain of free functions and ended up with some
other type from that, and it doesn't pass bar's template
constraint? In order to deal with that sort of thing, pretty
soon, you have to put most of the function inside its own
constraint. It's _far_ cleaner in general to just be putting the
sub-constraints in the top-level constraint - e.g. maybe all that
it means is using isForwardRange and hasLength instead of just
isInputRange rather than putting a whole chain of function calls
inside of __traits(compiles, ...) test in the template
constraint. It just gets ugly quickly to try and get it to work
for you automatically by putting the calls you're making in the
constraint so that the actual constraint conditions are inferred.
The other problem is that if you're putting all of those
__traits(compiles, ...) tests in template constraints rather than
putting the sub-constraints in there, it makes it a lot more of a
pain for the user to figure out why they're failing the
constraint. The constraint for what's failing in
__traits(compiles, ...) isn't shown, whereas it would be if you
just let it get past the template constraint and fail the
sub-constraint at the point where that function is being called,
you'd see the actual condition that's failing. So, as annoying as
it would be, it would actually be easier to figure out what you
were doing wrong. Also, if you really didn't put the
sub-constraint in the top-level constraint at all, then the
constraint is split out so that when you get a failure at the
top-level, you see only the stuff that the function requires
directly, and when you get a failure internally, you see it the
condition that that function requires and can see that
separately. So, instead of having to figure out which part of
condition1 condition2 is failing, you know which it is,
because the conditions are tested in separate places.
I suspect that the best way to go with this is that a template
constraint only require the stuff that a function uses directly
and let the constraints on any functions being called internally
report their own errors and then have the compiler provide really
good error messages to make that sane. Then it can be a lot
clearer what condition you're failing when you call the function
with a bad argument. But we need to improve the error messages
further if we want to go that way.
The other alternative would be to just make a best faith effort
to put all of the sub-constraints in the top-level constraint
initially and then have better error messages for when the
constraint is incomplete due to a change to a function being
called. But that would still require better error messages (which
is the main problem with the other suggestion), and it actually
has the problem that if a function being called has its
constraint lessened (rather than made more strict) such that your
outer function could
Re: D Web Services Application Potential?
On 26/07/2015 10:47 a.m., Brandon Ragland wrote: Hi All, Not entirely certain if there is a decent D web applications server implementation as of yet, but if there is a project going on, I'd love to have a gander. On the off-chance there isn't one, who would be interested in going at it, call it, a 'group' project. I've been yearning for a D web app server for a while, as most of my day to day work is done on Java EE containers (think Glassfish, Weblogic, etc. Java Beans, lalala) and the insane system usage has bothered me from day one. There's Wt for C++, although I don't see much coming from that, though the concept is grand. Rust has a few up and coming web server frameworks as well. D could really excel here. -Thoughts? Am I crazy (probably)? I wrote Cmsed[0], web service framework which uses Vibe.d and Dvorm (ORM)[1]. They are both sunsetted. I'm currently working on a web server[2] that will ultimately replace a good bit of what Vibe.d is currently being used for. Which will be using libasync[3] (backend for vibe.d but purely in D) instead of Vibe.d. Of course progress is slow and my current set of code is not up in the repository as I wrote it on stream[4]. My intention is there, is once std.experimental.image gets more boring again / can't do much on stream I'll start work on it again. Once it comparable to what I've got on repo, I'll update it. In terms of what the web server will be like, Apache httpd config syntax[5] but a LOT more dynamic ala JSP style. Once web server is done then I'll continue with my web service framework based upon Cmsed. Most of that code is ready to go. It's just things like reloading and templates that need rewriting. [0] https://github.com/rikkimax/cmsed [1] https://github.com/rikkimax/dvorm [2] https://github.com/DNetDev/webserver [3] https://github.com/etcimon/libasync [4] https://www.livecoding.tv/alphaglosined/ [5] https://github.com/DNetDev/apache_httpd_format
Re: static linking
On Saturday, 25 July 2015 at 18:02:48 UTC, Laeeth Isharc wrote: I am trying to compile a D binary to run on AWS lambda. If I cannot link statically, which files should I include in the zip upload - libphobos2.so, libdruntime-linux64so.o ? I think dicebot who maitains the arch linux package change dmd to dynamically link with phobos by default (we don't yet do that on any other platform). You should be able to link statically using -L-l:libphobos2.a or -defaultlib=libphobos2.a.
[Issue 14801] OS X installer not compatible with OS X 10.11
https://issues.dlang.org/show_bug.cgi?id=14801 --- Comment #2 from Martin Nowak c...@dawg.eu --- I build an installer that creates links in /usr/local/bin, can you please check whether that resolves the issue. https://dlang.dawg.eu/downloads/dmd.2.068.0-b2~fix14801/ https://github.com/MartinNowak/installer/commit/833a78085c680e92381d56c31349a3981c8c7318 --
Re: Run D on AWS Lambda
On Sunday, 26 July 2015 at 03:55:17 UTC, Laeeth Isharc wrote: https://aws.amazon.com/lambda/ https://github.com/Laeeth/awslambda_d http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/ No proper docs yet, but you can figure it out from the go example. Please take the time to write the damn docs and a small article. If you don't know where to host it, you can write a guest entry on my blog https://code.dawg.eu/.
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 05:29:39 UTC, Jonathan M Davis wrote: Well, even if concepts _were_ where it was at, at least D basically lets you implement them or do something far more lax or ad hoc, because template constraints and static if give you a _lot_ flexibility. We're not tied down in how we go about writing template constraints or even in using the function level to separate out functionality, because we can do that internally with static if where appropriate. So, essentially, we're in a great place regardless. The point of having a type system is to catch as many mistakes at compile time as possible. The primary purpose of a type system is to reduce flexibility.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 03:44:23 UTC, Joakim wrote: No, Swift is already general-purpose because it isn't highly optimized for a single purpose or feature and it's a fairly low-level native language which could be used to write everything from hardware drivers to webapps. Hardware drivers? Why not? If you can get FFT within 10% of C++, you could probably disable ARC, turn off dynamic dispatch, and write something reasonably fast. It is a native language after all, just like D. In fact, I now see that Apple announced that they will be contributing a linux port when they open-source it later this year, so it won't even be tied to Apple's platform soon. GNUStep has existed for decades. And gone nowhere. What does that have to do with Swift getting a linux port? It's a lot easier to port and reuse a programming language than something like GNUStep. As for Apple's subconscious gratifications, considering I bought my first and last Apple product, a Powerbook G4, a decade ago and would never buy any of their products since, because of their crazy patent stance, that certainly doesn't describe me. Ola brought up Swift as some sort of exception to the general-purpose native languages on mobile trend and I'm simply pointing out that's not true. http://www.primatelabs.com/blog/2014/12/swift-performance/ Swift is 24x slower than C++ for FFT… As your subsequent posts show, it can easily be made to be almost as fast as C++, since it's a native language. Standard apps on Android, iOS and in browsers rely heavily upon the builtin rendering/animation engines of their platforms (written in C/C++). The bottleneck for Javascript apps on mobile is the animation engine and emulating the native GUI. For the vast majority of apps Javascript itself performs well enough. For apps that are mostly GUI code, this may be true. Still, google felt Java itself was enough of a bottleneck that they switched it from JIT compilation to AoT. For many mobile apps 80% of the code is GUI code. That means you pay a high price for not using the default language and TOOLING for the platform. As I've pointed out cross platform GUI is no longer a realistic option since the Apple/Google have differentiated their GUIs on purpose in order to make it harder. Even if 80% is GUI code, the remaining 20% can slow you down. You don't have to use the default language and tooling in order to call the native GUI APIs, as you yourself pointed out with your MoSync example. As for cross-platform GUIs, an app's GUI doesn't need to be the _same_ across platforms in order to be cross-platform. Since the native GUIs can always be called from other languages, you could simply design a different GUI for each platform, by calling the native GUI APIs from one non-default language, say D, and use that same non-default language for all non-GUI code. That way, you save some re-implementation time in each default platform language for the non-GUI code, at least. Anyway, your point seems to be that native mobile is only taking off for superficial GUI reasons, but this ignores the fact that every mobile platform moved from higher-level and less efficient languages to lower-level native languages over time, from iOS's initial web sdk that was quickly ditched for Obj-C to the recent move by google to AoT-compile all the Java apps since Android 5. I guess they all did this for no reason at all. From a performance perspective you could probably do most mobile apps in Javascript/V8 with no noticeable impact. Performance? Arguable, for apps that are mostly GUI code. Battery life? No way. Btw, Dart has picked up the null-related-operators from Swift. It also has async syntax sugar over Futures. It might eventually be positioned as a mobile language for Android, through Sky SDK and Material Design widgets. Given the trend towards native/AoT compilation and that Dart doesn't fit in, I don't see it.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 07:18:23 UTC, Joakim wrote: In fact, I now see that Apple announced that they will be contributing a linux port when they open-source it later this year, so it won't even be tied to Apple's platform soon. GNUStep has existed for decades. And gone nowhere. What does that have to do with Swift getting a linux port? It's a lot easier to port and reuse a programming language than something like GNUStep. I somehow doubt that anyone outside those already using Objective-C/Foundation will pick up Swift. Time will show. As your subsequent posts show, it can easily be made to be almost as fast as C++, since it's a native language. Well, those were not obvious tweaks in my book. Maybe Swift will improve in the future, I don't know. For apps that are mostly GUI code, this may be true. Still, google felt Java itself was enough of a bottleneck that they switched it from JIT compilation to AoT. It did at least save them some memory and start up/warm-up time? cross-platform. Since the native GUIs can always be called from other languages, you could simply design a different GUI for each platform, by calling the native GUI APIs from one non-default language, say D, and use that same non-default language for all non-GUI code. Yes, people do that. Anyway, your point seems to be that native mobile is only taking off for superficial GUI reasons, but this ignores the fact that every mobile platform moved from higher-level and less efficient languages to lower-level native languages over time, from iOS's initial web sdk that was quickly ditched for Obj-C to the recent move by google to AoT-compile all the Java apps since Android 5. I guess they all did this for no reason at all. All I really can say is that many scripting languages are fast enough for the typical logic you need in a regular mobile app... But both Google/Apple need a lock-in strategy to get unique apps on their platform. What killed Mosync as a project was IMHO the diverging GUIs and the competing cross platform solutions based on scripting-languages. Performance? Arguable, for apps that are mostly GUI code. Battery life? No way. Few developers care about battery life when the app is actively used. It's not like end users will say When I use the weather app my battery gets drained faster. What matters are things like not doing frequent work when the app is idle. Now, vendors might care and have many reasons for pushing their own platform. Given the trend towards native/AoT compilation and that Dart doesn't fit in, I don't see it. I have no idea, it is all about tooling, ease of development and end user experience. And iOS appears to be moving away from ASM and towards using an intermediate representation that is hardware independent. So not a strict trend towards native. The trend over the past 5 years appears to be going towards vendor specific solutions.
Re: Named parameters
Am Fri, 24 Jul 2015 14:04:17 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 7/24/2015 10:15 AM, tcak wrote: How would this create a problem I can't see. The question is what problem does it solve. At least: 1 Better readable code with literal parameters auto x = window.addNewControl(Title, 20, 50, 100, 50, true); There are some domains which would benefit a lot from this (every OpenGL function call, most graphics/image libraries) 2 If you have many parameters with default values, you can keep default values for all other parameters and overwrite only one. This can sometimes be done with overloads, but what if you've got parameters of the same type: void foo(bool a = function1(x, y), bool b = function2(x, y), bool c = function1(x, y)) foo(function1(x, y), function2(x, y), false); = foo(c = false) 3 One thing that's sometimes annoying in D is that it's not possible to have normal arguments after a variadic argument. Named parameters could solve that: void foo(A, T... args, B) = foo!(int, int, bool, B = bool) Note that there are languages which allow named parameters but do not allow parameter reordering. This still allows 1 and 3 but the implementation is simpler.
Re: Rant after trying Rust a bit
On 7/25/2015 12:08 AM, Jonathan M Davis wrote: I must say that this is a rather odd argument to be having though, since normally I'm having to argue that 100% test coverage isn't enough rather than that code needs to have 100% (e.g. how range-based algorithms need to be tested with both value type ranges and reference type ranges, which doesn't increase the code coverage at all but does catch bugs with how save is used, and without that, those bugs won't be caught). So, having to argue that all code should have 100% code coverage (or as close to it as is possible anyway) is kind of surreal. I would have thought that that was a given at this point. The real question is how far you need to go past that to ensure that your code works correctly. It's still unusual to have 100% coverage in Phobos, and this is not because it is hard. Most of the time, it is easy to do. It's just that nobody checks it. Although we have succeeded in making unit tests part of the culture, the next step is 100% coverage. I know that 100% unit test coverage hardly guarantees code correctness. However, since I started using code coverage analyzers in the 1980s, the results are surprising - code with 100% test coverage has at LEAST an order of magnitude fewer bugs showing up in the field. It's surprisingly effective. I would have had a LOT more trouble shipping the Warp project if I hadn't gone with 100% coverage from the ground up. Nearly all the bugs it had in the field were due to my misunderstandings of the peculiarities of gpp - the code had worked as I designed it. This is a huge reason why I want to switch to ddmd. I want to improve the quality of the compiler with unit tests. The various unit tests schemes I've tried for C++ are all ugly, inconvenient, and simply a bitch. It's like trying to use a slide rule after you've been given a calculator. (I remember the calculator revolution. It happened my freshman year at college. September 1975 had $125 slide rules in the campus bookstore. December they were at $5 cutout prices, and were gone by January. I never saw anyone use a slide rule again. I've never seen a technological switchover happen so fast, before or since.)
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 08:48:40 UTC, Walter Bright wrote:
On 7/24/2015 11:10 PM, Jonathan M Davis wrote:
So, maybe we should look at something along those lines rather
than
proliferating the top-level function overloading like we're
doing now.
Consider the following pattern, which I see often in Phobos:
void foo(T)(T t) if (A) { ... }
void foo(T)(T t) if (!A B) { ... }
from a documentation (i.e. user) perspective. Now consider:
void foo(T)(T t) if (A || B)
{
static if (A) { ... }
else static if (B) { ... }
else static assert(0);
}
Makes a lot more sense to the user, who just sees one function
that needs A or B, and doesn't see the internal logic.
Yeah, though, I believe that Andrei has argued against that every
time that someone suggests doing that. IIRC, he wants ddoc to
that for you somehow rather than requiring that we write code
that way.
And from a test perspective, it's actually a bit ugly to take
function overloads and turn them into static ifs, because instead
of having separate functions that you can put unittest blocks
under, you have to put all of those tests in a single unittest
block or put the unittest blocks in a row with comments on them
to indicate which static if branch they go with. It also has the
problem that the function can get _way_ too long (e.g. putting
all of the overloads of find in one function would be a really
bad idea).
Alternatively, you could do something like
template foo(T)
if(A || B)
{
void foo()(T t)
if(A)
{}
void foo()(T t)
if(B)
{}
}
which gives you the simplified template constraint for the
documentation, though for better or worse, you'd still get the
individual template constraints listed separately for each
overload - though given how often each overload needs an
explanation, that's not necessarily bad.
And in many cases, what you really have is overlapping
constraints rather than truly distinct ones. So, you'd have
something like
auto foo(alias pred, R)(R r)
if(testPred!pred isInputRange!R !isForwardRange!R)
{}
auto foo(alias pred, R)(R r)
if(testPred!pred isForwardRange!R)
{}
and be turning it into something like
template foo(alias pred)
if(testPred!pred)
{
auto foo(R)(R r)
if(isInputRange!R !isForwardRange!R)
{}
auto foo(R)(R r)
if(isForwardRange!R)
{}
}
So, part of the template constraint gets factored out completely.
And if you want to factor it out more than that but still don't
want to use static if because of how it affects the unit tests,
or because you don't want the function to get overly large, then
you can just forward it to another function. e.g.
auto foo(alias pred, R)(R r)
if(testPred!pred isInputRange!R)
{
return _foo(pred, r);
}
auto _foo(alias pred, R)(R r)
if(!isForwardRange!R)
{}
auto _foo(alias pred, R)(R r)
if(isForwardRange!R)
{}
or go for both the outer template and forwarding, and do
template foo(alias pred)
if(testPred!pred)
{
auto foo(R)(R r)
if(isInputRange!R)
{
return _foo(pred, r);
}
auto _foo(R)(R r)
if(!isForwardRange!R)
{}
auto _foo(R)(R r)
if(isForwardRange!R)
{}
}
We've already created wrapper templates for at least some of the
functions in Phobos so that you can partially instantiate them -
e.g.
alias myMap = map!(a = a.func());
So, it we're already partially moving stuff up a level in some
cases. We just haven't used it as a method to simplify the main
template constraint that user sees or to simplify overloads.
I do think that it can make sense to put very similar overloads
in a single function with static if branches like you're
suggesting, but I do think that it's a bit of a maintenance issue
to do it for completely distinct overloads - especially if there
are several of them rather than just a couple. But it's still
possible to combine their template constraints at a higher level
and have overloaded functions rather than simply using static ifs.
- Jonathan M Davis
Re: Rant after trying Rust a bit
On 7/24/2015 11:10 PM, Jonathan M Davis wrote:
So, maybe we should look at something along those lines rather than
proliferating the top-level function overloading like we're doing now.
Consider the following pattern, which I see often in Phobos:
void foo(T)(T t) if (A) { ... }
void foo(T)(T t) if (!A B) { ... }
from a documentation (i.e. user) perspective. Now consider:
void foo(T)(T t) if (A || B)
{
static if (A) { ... }
else static if (B) { ... }
else static assert(0);
}
Makes a lot more sense to the user, who just sees one function that needs A or
B, and doesn't see the internal logic.
Re: Rant after trying Rust a bit
On 7/25/2015 2:14 AM, Jonathan M Davis wrote:
I do think that it can make sense to put very similar overloads in a single
function with static if branches like you're suggesting, but I do think that
it's a bit of a maintenance issue to do it for completely distinct overloads -
especially if there are several of them rather than just a couple. But it's
still possible to combine their template constraints at a higher level and have
overloaded functions rather than simply using static ifs.
I also sometimes see:
void foo(T)(T t) if (A B) { ... }
void foo(T)(T t) if (A !B) { ... }
The user should never have to see the B constraint in the documentation. This
should be handled internally with static if.
Re: Rant after trying Rust a bit
On 7/25/2015 12:19 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: The point of having a type system is to catch as many mistakes at compile time as possible. The primary purpose of a type system is to reduce flexibility. Again, the D constraint system *is* a compile time system, and if the template body uses an interface not present in the type and not checked for in the constraint, you will *still* get a compile time error. The idea that Rust traits check at compile time and D does not is a total misunderstanding. BTW, you might want to remove the UTF-8 characters from your user name. Evidently, NNTP doesn't do well with them.
Re: Named parameters
On 2015-07-24 23:04, Walter Bright wrote: The question is what problem does it solve. For one thing, it avoids the ugly hack which is the Flag template and Yes/No structs. With Flag: string getLine(Flag!keepTerminator keepTerminator); getLine(Flag!keepTerminator.yes); With named parameters: string getLine(bool keepTerminator); getLine(keepTerminator: true); -- /Jacob Carlborg
Re: Rant after trying Rust a bit
On 2015-07-24 21:04, Walter Bright wrote: Dynamic cast is no different from QueryInterface(), which is how it's done, and the reason is the point of all this - avoiding needing to enumerate every interface needed by the leaves at the root of the call tree. I'm not familiar with QueryInterface(): -- /Jacob Carlborg
Re: Rant after trying Rust a bit
Sorry for somewhat delayed answer - not sure if anyone has
answered to your questions in the meanwhile.
On Friday, 24 July 2015 at 00:19:50 UTC, Walter Bright wrote:
On 7/23/2015 2:08 PM, Dicebot wrote:
It does not protect from errors in definition
void foo (R) (Range r)
if (isInputRange!Range)
{ r.save(); }
unittest
{
SomeForwardRange r;
foo(r);
}
This will compile and show 100% test coverage. Yet when user
will try using it
with real input range, it will fail.
That is correct. Some care must be taken that the mock types
used in the unit tests actually match what the constraint is,
rather than being a superset of them.
This is absolutely impractical. I will never even consider such
attitude as a solution for production projects. If test coverage
can't be verified automatically, it is garbage, period. No one
will ever manually verify thousands lines of code after some
trivial refactoring just to make sure compiler does its job.
By your attitude `-cov` is not necessary at all - you can do the
same manually anyway, with some help of 3d party tool. Yet you
advertise it as crucial D feature (and are being totally right
about it).
There is quite a notable difference in clarity between error
message coming from
some arcane part of function body and referring to wrong usage
(or even totally
misleading because of UFCS) and simple and straightforward
Your type X does not
implement method X necessary for trait Y
I believe they are the same. method X does not exist for type
Y.
Well, the difference is that you believe and I actually write
code and read those error messages. They are not the same at all.
In D error message gets evaluated in context of function body and
is likely to be completely misleading in all but most trivial
methods. For example, if there is a global UFCS function
available with the same name but different argument list, you
will get an error about wrong arguments and not about missing
methods.
Coverage does not work with conditional compilation:
void foo (T) ()
{
import std.stdio;
static if (is(T == int))
writeln(1);
else
writeln(2);
}
unittest
{
foo!int();
}
$ dmd -cov=100 -unittest -main ./sample.d
Let's look at the actual coverage report:
===
|void foo (T) ()
|{
|import std.stdio;
|static if (is(T == int))
1|writeln(1);
|else
|writeln(2);
|}
|
|unittest
|{
1|foo!int();
|}
|
foo.d is 100% covered
I look at these all the time. It's pretty obvious that the
second writeln is not being compiled in.
Again, this is impractical. You may be capable of reading with
speed of light but this not the normal industry case. Programs
are huge, changesets are big, time pressure is real. If something
can't be verified in automated way at least for basic sanity, it
is simply not good enough. This is the whole point of CI
revolution.
In practice I will only look into .cov files when working on
adding new tests to improve the coverage and will never be able
to do it more often (unless compiler notifies me to do so). This
is real-world constraint one needs to deal with, not matter what
your personal preferences about good development process are.
Now, if I make a mistake in the second writeln such that it is
syntactically correct yet semantically wrong, and I ship it,
and it blows up when the customer actually instantiates that
line of code,
-- where is the advantage to me? --
How am I, the developer, better off? How does well, it looks
syntactically like D code, so ship it! pass any sort of
professional quality assurance?
?
If compiler would actually show 0 coverage for non-instantiated
lines, than automatic coverage control check in CI would complain
and code would never be shipped unless it gets covered with tests
(which check the semantics). Your are putting it totally
backwards.
Re: Rant after trying Rust a bit
On 7/24/15 9:16 PM, Tofu Ninja wrote: Current template types work like duck typing, which works, but its error prone, and your argument of unittests is obviously bad in the context of duck typing. Could you please make the obvious explicit? We want a real type system for our template types. Every time this (or really any apology of C++ concepts) comes up, the discussion has a similar shape: 1. Concepts are great because they're a type system for the type system! And better error messages! And look at these five-liners! And Look at iterators! And other nice words! 2. I destroy them. 3. But we want concepts because they're a type system for the type system! And ... etc. etc. I have no idea how people can simply ignore the fact that their arguments have been systematically dismantled. Andrei
Re: Rant after trying Rust a bit
On 7/25/15 9:17 AM, Brendan Zabarauskas wrote: On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote: On 7/25/2015 12:19 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: The point of having a type system is to catch as many mistakes at compile time as possible. The primary purpose of a type system is to reduce flexibility. Again, the D constraint system *is* a compile time system, and if the template body uses an interface not present in the type and not checked for in the constraint, you will *still* get a compile time error. The idea that Rust traits check at compile time and D does not is a total misunderstanding. BTW, you might want to remove the UTF-8 characters from your user name. Evidently, NNTP doesn't do well with them. I think the point is that trait based constraints force compilation errors to be raised at the call site, and not potentially from deep within a template expansion. Template errors are stack traces coming from duck typed, compile time programs. Library authors can't rely on the typechecker to pick up on mistakes that may only appear at expansion time in client programs. Understood, but by the same token library authors shouldn't ship untested code. This is basic software engineering. Once we agree on that, we figure that concepts help nobody. -- Andrei
Re: Rant after trying Rust a bit
On 25 July 2015 at 18:48, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/24/2015 11:10 PM, Jonathan M Davis wrote:
So, maybe we should look at something along those lines rather than
proliferating the top-level function overloading like we're doing now.
Consider the following pattern, which I see often in Phobos:
void foo(T)(T t) if (A) { ... }
void foo(T)(T t) if (!A B) { ... }
from a documentation (i.e. user) perspective. Now consider:
void foo(T)(T t) if (A || B)
{
static if (A) { ... }
else static if (B) { ... }
else static assert(0);
}
Makes a lot more sense to the user, who just sees one function that needs A
or B, and doesn't see the internal logic.
This! I've felt this way with phobos in particular for ages.
I've argued this exact case before, and it's been rejected.
I much prefer static if inside functions rather than pollute the
namespace (and docs) with a bunch of overloads. Also, these symbols
with lots of constraints can get really long!
Re: Named parameters
On Saturday, 25 July 2015 at 13:52:09 UTC, Andrei Alexandrescu wrote: For one thing, it avoids the ugly hack which is the Flag template and Yes/No structs. With Flag: The idiom goes like this. /// Flag to control whether or not to keep line endings alias KeepTerminator = Flag!KeepTerminator; /// string getLine(KeepTerminator KeepTerminator); usage: getLine(KeepTerminator.yes); or getLine(Yes.keepTerminator); So named Boolean flags are a solved problem and are a good improvement over getLine(true) IMO.
Vibe-d MQTT client library
I wanted to announce the first tagged version[0] of native D MQTT client library for vibe-d. It's just the first release so there are features missing, but hopefully with community help, they will be there soon. It's tested against RabbitMQ[1] message broker. I wanted it to be as lightweight as possible, so it has no other direct dependencies but vibe-d. There are already mqttd broker implementation by Atila Nevens[2] and his cerealed serializer I know of. Actually they were both helpfull resources - so thanks for that. Main differences are: - messages are structs not classes - avoid GC as much as possible - focus on the client side - serialization is done simply, just to work with defined messages (not as a generic serialization) with range interfaces - speed is on par with msgpack-d[3] - hopefully clean easily understandable code with a lot of comments in it to make it easier for contributors - supports the latest MQTT protocol - 3.1.1 I still consider myself as a D rookie, so there are surely places which can be done better, more D idiomatic way. You are welcome to point me to them or even create pull requests. [0] http://code.dlang.org/packages/vibe-mqtt [1] https://www.rabbitmq.com/ [2] http://code.dlang.org/packages/mqtt [3] https://github.com/msgpack/msgpack-d
Re: Named parameters
On Fri, 24 Jul 2015 14:15:10 +, Shammah Chancellor wrote: Since D has optional arguments -- why don't we support named parameters? There are extremely handy and work beautifully in languages like C#. 'cause core devs doesn't see much added value in named args. this question was talked to death already. alas. signature.asc Description: PGP signature
Re: Read text file fast, how?
On Sat, Jul 25, 2015 at 7:14 PM, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 7/25/15 8:19 AM, Johan Holmberg via Digitalmars-d wrote: Hi! I am trying to port a program I have written earlier to D. My previous versions are in C++ and Python. I was hoping that a D version would be similar in speed to the C++ version, rather than similar to the Python version. But currently it isn't. Part of the problem may be that I haven't learned the idiomatic way to do things in D. One such thing is perhaps: how do I read large text files in an efficient manner in D? Currently I have created a little test-program that does the same job as the UNIX-command wc -lc, i.e. counting the number of lines and characters in a file. The timings I get in different languages are: D: 15s C++: 1.1s Python: 3.7s Perl:2.9s I think this harkens back to the problem discussed here: http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d/29153508 As I discuss there, the performance bug has been fixed for 2.068. With your code: $ time wc -l (repeat 100 echo hello) 100 /dev/fd/11 wc -l (repeat 100 echo hello) 0.11s user 2.35s system 54% cpu 4.529 total $ time ./test.d (repeat 100 echo hello) 100 600 /dev/fd/11 ./test.d (repeat 100 echo hello) 0.73s user 1.76s system 64% cpu 3.870 total The compilation was flag free (no -O -inline -release etc). Andrei Thanks, my question seems like a carbon copy of the Stack Overflow article :) Somehow I had missed it when googling. I download a dmd 2.068 beta, and re-tried with my input file: now the D program takes 1.6s (a 10x improvement). /johan
Re: Rant after trying Rust a bit
On 7/25/15 5:34 AM, Walter Bright wrote:
On 7/25/2015 2:14 AM, Jonathan M Davis wrote:
I do think that it can make sense to put very similar overloads in a
single
function with static if branches like you're suggesting, but I do
think that
it's a bit of a maintenance issue to do it for completely distinct
overloads -
especially if there are several of them rather than just a couple. But
it's
still possible to combine their template constraints at a higher level
and have
overloaded functions rather than simply using static ifs.
I also sometimes see:
void foo(T)(T t) if (A B) { ... }
void foo(T)(T t) if (A !B) { ... }
The user should never have to see the B constraint in the documentation.
This should be handled internally with static if.
There are problems with that but I do agree with the sentiment. -- Andrei
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 14:20:28 UTC, Joakim wrote: The IR is only for Apple, they're still compiling it and distributing ASM to the device. Yes, but if they go down that road it means you cannot target SIMD instructions. So you cannot get serious performance.
Read text file fast, how?
Hi!
I am trying to port a program I have written earlier to D. My previous
versions are in C++ and Python. I was hoping that a D version would be
similar in speed to the C++ version, rather than similar to the Python
version. But currently it isn't.
Part of the problem may be that I haven't learned the idiomatic way to do
things in D. One such thing is perhaps: how do I read large text files in
an efficient manner in D?
Currently I have created a little test-program that does the same job as
the UNIX-command wc -lc, i.e. counting the number of lines and characters
in a file. The timings I get in different languages are:
D: 15s
C++: 1.1s
Python: 3.7s
Perl:2.9s
The central loop in my D program looks like:
foreach (line; f.byLine) {
nlines += 1;
nchars += line.length + 1;
}
I have also tried another variant with this inner loop:
char[] line;
while(f.readln(line)) {
nlines += 1;
nchars += line.length;
}
but in both cases this D program is much slower than any of the others in
C++/Python/Perl. I don't understand what can cause this dramatic difference
to C++, and a factor 4 to Python. My D programs are built with DMD 2.067.1
on MacOS Yosemite, using the flags -O -release.
Is there something I can do to make the program run faster, and still be
idiomatic D?
(I append the whole program for reference)
Regards,
/Johan Holmberg
===
import std.stdio;
import std.file;
void main(string[] argv) {
foreach (fname; argv[1..$]) {
auto f = File(fname);
int nlines = 0;
int nchars = 0;
foreach (line; f.byLine) {
nlines += 1;
nchars += line.length + 1;
}
writeln(nlines, \t, nchars, \t, fname);
}
}
===
GC stats
Hello! I was wondering if anyone has suggestions on the easiest way to time how long GC collections take? I haven't seen anything in the docs. What I want is a clean non-intrusive way to log when a collection happened, how long my threads were stopped, how much total memory and how many blocks were recovered. i.e. how much garbage was created in between collections. Are there any hooks on the runtime? Cheers, -M
Re: [RFC] std.experimental.concepts
On 7/24/15 7:13 PM, deadalnix wrote: On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor wrote: I put up a PR for phobos awhile ago for concepts as a library to kind of start the discussion around concepts. There seemed to be some interest around the PR, so I have rebased it and fixed the formatting. Please take a look: https://github.com/D-Programming-Language/phobos/pull/2627 -Shammah Doing it as a library would miss a lot of the point of concepts : - Compiler can do a fair amount of semantic analysis on template before instantiating them. This work is done once rather than repeating it a every template instantiation. Interesting. - It allow for much more clearer error messages. Anyone having to maintain some meta code will understand what I'm talking about here. Agreed, though I would more if much were dropped. - It make compile time and runtime polymorphism more alike. I do think we'd all agree that Andrei approach to mention template arguments as compile time arguments and go from there is a good move. Concept would be the same move, but for typing. By reusing common language constructs (C++ failed to use that opportunity) for instance. Meh to that. Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 13:37:15 UTC, Andrei Alexandrescu wrote: On 7/24/15 6:12 PM, deadalnix wrote: The most intriguing part of this conversation is that the argument made about unitests and complexity are the very same than for dynamic vs strong typing (and there is hard data that strong typing is better). No, that's not the case at all. There is a distinction: in dynamic typing the error is deferred to run time, in this discussion the error is only deferred to instantiation time. -- Andrei Runtime errors are a usability problem for users and maintianability problem for developers. Instatiation time errors are a maintianability problem for library authors and a usability problem for developers. I would argue that the latter is better than the former, but the poor developer experience of using Phobos is what made me move away from D a couple of years ago.
Re: Rant after trying Rust a bit
On 7/24/15 6:12 PM, deadalnix wrote: The most intriguing part of this conversation is that the argument made about unitests and complexity are the very same than for dynamic vs strong typing (and there is hard data that strong typing is better). No, that's not the case at all. There is a distinction: in dynamic typing the error is deferred to run time, in this discussion the error is only deferred to instantiation time. -- Andrei
Re: Rant after trying Rust a bit
On 7/24/15 6:58 PM, Justin Whear wrote: I agree that there's really no excuse and think we ought to orient the language towards serious professionals who will produce quality code. Bad code is bad code, regardless of the language. YES! Amen to that. -- Andrei
Re: Rant after trying Rust a bit
On 7/24/15 11:12 PM, Walter Bright wrote: On 7/24/2015 7:28 PM, Jonathan M Davis wrote: I confess that I've always thought that QueryInterface was a _horrible_ idea, Specifying every interface that a type must support at the top of the hierarchy is worse. That would be an oversimplification. Once again, Exception Specifications. And that simile would be superficial. Andrei
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 14:06:05 UTC, Daniel N wrote:
On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor
wrote:
I put up a PR for phobos awhile ago for concepts as a library
to kind of start the discussion around concepts. There
seemed to be some interest around the PR, so I have rebased it
and fixed the formatting.
Please take a look:
https://github.com/D-Programming-Language/phobos/pull/2627
-Shammah
For those who are on a sugar-rush from Concepts, maybe this is
a fun trick?
It almost works, if only IFTI was smart enough to deal with
eponymous identity templates.
int fun(T)(T t) if(is(typeof(T.Put)))
{
}
template Putty(T)
{
static assert(is(typeof(T.Put)));
alias Putty = T;
}
void fun(T)(Putty!T t)
{
}
Templates are not bijective, so we'll never be generally able to
determine T by matching Putty, i.e. 2 different T could have the
same Putty!T type.
Adding an exception for identity templates seems to be a hack.
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 14:14:52 UTC, Martin Nowak wrote: Templates are not bijective, so we'll never be generally able to determine T by matching Putty, i.e. 2 different T could have the same Putty!T type. Adding an exception for identity templates seems to be a hack. If it only was done for the sake of IFTI, then yes indeed it would be a hack, but probably other things as well such as shorter mangling could benefit from the compiler being aware of identity templates.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 14:35:18 UTC, Ola Fosheim Grøstad wrote: Yes, but if they go down that road it means you cannot target SIMD instructions. Why would that be so? You can still e.g. keep vector instructions in the IR and specialize according to the actual hardware width when you generate the binary. — David
Re: Named parameters
On 2015-07-25 13:02, Gary Willoughby wrote: When showing code don't purposefully make it verbose to strengthen your case. Here is how Flag is usually used: I didn't, I just copied it from the documentation. I never used it myself. getLine(Yes.keepTerminator); Which is way more readable. Named parameters are not needed! I disagree, Flag/Yes/No is a gigantic ugly hack. -- /Jacob Carlborg
Re: Named parameters
On Sat, 25 Jul 2015 17:16:23 +0200 Johannes Pfau via Digitalmars-d digitalmars-d@puremagic.com wrote: Named boolean flags are only one very common special case though. That solution doesn't work that well for integers: auto w = Window(0, 0, 100, 200); auto w = Window(x = 0, y = 0, width = 100, height = 200); //auto w = Window(x.0, y.0, width.100, height.200); You could introduce new types for X,Y, Width, Height: auto w = Window(X(0), Y(0), Width(100), Height(200)); auto w = Window(Position(0,0), Dimension(100, 200)); // this is what I prefer but if someone want to be more explicit: auto w = Window(Position.x(0).y(0), Dimension.width(100).height(200));
Re: GC stats
On Saturday, 25 July 2015 at 17:34:26 UTC, Márcio Martins wrote: What I want is a clean non-intrusive way to log when a collection happened, how long my threads were stopped, how much total memory and how many blocks were recovered. i.e. how much garbage was created in between collections. Are there any hooks on the runtime? http://dlang.org/changelog.html#gc-options https://github.com/D-Programming-Language/druntime/blob/1e25749cd01ad08dc08319a3853fbe86356c3e62/src/rt/config.d#L14
Re: Vibe-d MQTT client library
On Saturday, 25 July 2015 at 15:23:48 UTC, TC wrote: It's tested against RabbitMQ[1] message broker. You also intend to work on a direct AMQP implementation?
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 12:09:34 UTC, Andrei Alexandrescu wrote: However, making it built-in feels really convenient in Rust: - considerably less function declaration visual noise - much better error messages: trying to use methods of T not defined by a trait will result in compile-time error even without instantiating the template Yah, building stuff in does have its advantages. I feel it is not as much about built-in vs library, but generic vs templates - somewhat deeper ideological difference that consequently calls for different tools. Metaprogramming with traits in Rust is inconvenient to the point of being almost impossible but generics have a very strong static API verification. In D you can get destroyed by flow of deeply nested error messages but the magic you can do with templates with minimal effort investment is beyond comparison. Different values, different trade-offs.
Re: Rant after trying Rust a bit
On 7/25/15 6:05 AM, Tofu Ninja wrote: On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote: if the template body uses an interface not present in the type and not checked for in the constraint, you will *still* get a compile time error. But only if the template gets instantiated with a bad type. Unit tests don't catch every thing and have to be written properly. A proper type system should catch it. I disagree. -- Andrei
Re: Named parameters
On 7/25/15 6:32 AM, Jonathan M Davis wrote: On Saturday, 25 July 2015 at 09:41:19 UTC, Jacob Carlborg wrote: On 2015-07-24 23:04, Walter Bright wrote: The question is what problem does it solve. For one thing, it avoids the ugly hack which is the Flag template and Yes/No structs. With Flag: string getLine(Flag!keepTerminator keepTerminator); getLine(Flag!keepTerminator.yes); With named parameters: string getLine(bool keepTerminator); getLine(keepTerminator: true); If Andrei weren't insisting that we use that idiom everywhere in Phobos, I'd honestly just be using bools and be done with it. It adds some value, but I seriously question that it's worth the extra verbosity. But regardless, I'd hate to see named arguments get added to the language just to clean that mess up. Honest I didn't insist, and am a bit surprised that it did catch up. -- Andrei
Re: Named parameters
On 7/25/15 5:41 AM, Jacob Carlborg wrote: On 2015-07-24 23:04, Walter Bright wrote: The question is what problem does it solve. For one thing, it avoids the ugly hack which is the Flag template and Yes/No structs. With Flag: string getLine(Flag!keepTerminator keepTerminator); getLine(Flag!keepTerminator.yes); Replace the second with: getLine(Yes.keepTerminator); Andrei
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 08:00:32 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 07:18:23 UTC, Joakim wrote: Given the trend towards native/AoT compilation and that Dart doesn't fit in, I don't see it. I have no idea, it is all about tooling, ease of development and end user experience. And iOS appears to be moving away from ASM and towards using an intermediate representation that is hardware independent. So not a strict trend towards native. The trend over the past 5 years appears to be going towards vendor specific solutions. The IR is only for Apple, they're still compiling it and distributing ASM to the device.
Re: [RFC] std.experimental.concepts
On 26/07/2015 2:14 a.m., Martin Nowak wrote:
On Saturday, 25 July 2015 at 14:06:05 UTC, Daniel N wrote:
On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor wrote:
I put up a PR for phobos awhile ago for concepts as a library to kind
of start the discussion around concepts. There seemed to be some
interest around the PR, so I have rebased it and fixed the formatting.
Please take a look:
https://github.com/D-Programming-Language/phobos/pull/2627
-Shammah
For those who are on a sugar-rush from Concepts, maybe this is a fun
trick?
It almost works, if only IFTI was smart enough to deal with eponymous
identity templates.
int fun(T)(T t) if(is(typeof(T.Put)))
{
}
template Putty(T)
{
static assert(is(typeof(T.Put)));
alias Putty = T;
}
void fun(T)(Putty!T t)
{
}
Templates are not bijective, so we'll never be generally able to
determine T by matching Putty, i.e. 2 different T could have the same
Putty!T type.
Adding an exception for identity templates seems to be a hack.
==
template Putty(T)
{
static assert(is(typeof(T.Put)));
alias Putty = T;
}
void fun(!T)(Putty!T t)
{
}
===
void fun(__original_T)(__original_T t) if (is(Putty!__original_T ==
__original_T))
{
}
===
Humm, minor rewrite of source by the front end. Definitely would be doable.
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote: On 7/25/2015 12:19 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: The point of having a type system is to catch as many mistakes at compile time as possible. The primary purpose of a type system is to reduce flexibility. Again, the D constraint system *is* a compile time system, and if the template body uses an interface not present in the type and not checked for in the constraint, you will *still* get a compile time error. Well, I am not sure if the flexibility scales up when clever library authors start to write flexible introspective code. It basically requires library authors to be careful and conservative. Code coverage and unit tests cannot replace a robust type system when you get down to composable datastructures due to the combinatorial explosion you get. The idea that Rust traits check at compile time and D does not is a total misunderstanding. I'm not arguing in favour of copying Rust… I don't think becoming more like Rust will buy D more friends. It will just be an argument for picking Rust over D. If I'd argue for something it would be for having a real deductive database at the heart of the templating type system. BTW, you might want to remove the UTF-8 characters from your user name. Evidently, NNTP doesn't do well with them. Hm. It works in the web interface when I reply to my own messages, maybe just a client issue?
Re: Looking for MQTT client library
On Thursday, 7 May 2015 at 20:28:27 UTC, Orfeo wrote: On Thursday, 23 April 2015 at 14:40:01 UTC, Frank Pagliughi wrote: I got the OK to submit the D library to Eclipse Paho. So, hopefully within the next few weeks there will be a Paho incubator project for the D language client. Hi Frank, any news about your MQTT client project? Thank you I needed it too so - http://forum.dlang.org/thread/isznbdlzfyvprkena...@forum.dlang.org Hope it helps and gets better with shared efforts
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 14:28:31 UTC, Andrei Alexandrescu wrote: On 7/25/15 9:35 AM, Dicebot wrote: This is absolutely impractical. I will never even consider such attitude as a solution for production projects. If test coverage can't be verified automatically, it is garbage, period. No one will ever manually verify thousands lines of code after some trivial refactoring just to make sure compiler does its job. Test coverage shouldn't totter up and down as application code is written - it should be established by the unittests. And yes one does need to examine coverage output while writing unittests. Does word refactoring or adding new features ring a bell? In the first case no one manually checks coverage of all affected code because simply too much code is affected. Yet it can become reduced by an accident. In the second case developer is likely to check coverage for actual functionality he has written - and yet coverage can become reduced in different (but related) parts of code because that is how templates work. You will have a very hard time selling this approach. If official position of language authors is that one must manually check test coverage all the time over and over again, pragmatical people will look into other languages. I do agree more automation is better here (as is always). For example, if a template is followed by one or more unittests, the compiler might issue an error if the unittests don't cover the template. This isn't better. This is bare minimum for me to call that functionality effectively testable. Manual approach to testing doesn't work, I thought everyone has figured that out by 2015. It works better than no tests at all, sure, but this is not considered enough anymore.
Re: Rant after trying Rust a bit
On 07/25/2015 05:03 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote: BTW, you might want to remove the UTF-8 characters from your user name. Evidently, NNTP doesn't do well with them. Hm. It works in the web interface when I reply to my own messages, maybe just a client issue? I'd say it is a problem with the way the web interface encodes the sender name, and especially the fact that it starts with a double quote. In the message source, it looks like: From: Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com According to RFC 2047 [1]: An 'encoded-word' MUST NOT appear within a 'quoted-string'. (top of page 7), so this should be written as: From: Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= ola.fosheim.grostad+dl...@gmail.com Jerome [1] https://tools.ietf.org/html/rfc2047 -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Read text file fast, how?
On 7/25/15 8:19 AM, Johan Holmberg via Digitalmars-d wrote: Hi! I am trying to port a program I have written earlier to D. My previous versions are in C++ and Python. I was hoping that a D version would be similar in speed to the C++ version, rather than similar to the Python version. But currently it isn't. Part of the problem may be that I haven't learned the idiomatic way to do things in D. One such thing is perhaps: how do I read large text files in an efficient manner in D? Currently I have created a little test-program that does the same job as the UNIX-command wc -lc, i.e. counting the number of lines and characters in a file. The timings I get in different languages are: D: 15s C++: 1.1s Python: 3.7s Perl:2.9s I think this harkens back to the problem discussed here: http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d/29153508 As I discuss there, the performance bug has been fixed for 2.068. With your code: $ time wc -l (repeat 100 echo hello) 100 /dev/fd/11 wc -l (repeat 100 echo hello) 0.11s user 2.35s system 54% cpu 4.529 total $ time ./test.d (repeat 100 echo hello) 100 600 /dev/fd/11 ./test.d (repeat 100 echo hello) 0.73s user 1.76s system 64% cpu 3.870 total The compilation was flag free (no -O -inline -release etc). Andrei
Re: Rant after trying Rust a bit
On Friday, 24 July 2015 at 04:42:59 UTC, Walter Bright wrote:
On 7/23/2015 3:12 PM, Dicebot wrote:
On Thursday, 23 July 2015 at 22:10:11 UTC, H. S. Teoh wrote:
OK, I jumped into the middle of this discussion so probably
I'm speaking
totally out of context...
This is exactly one major advantage of Rust traits I have been
trying to
explain, thanks for putting it up in much more understandable
way :)
Consider the following:
int foo(T: hasPrefix)(T t) {
t.prefix();// ok
bar(t);// error, hasColor was not specified for T
}
void bar(T: hasColor)(T t) {
t.color();
}
Now consider a deeply nested chain of function calls like this.
At the bottom, one adds a call to 'color', and now every
function in the chain has to add 'hasColor' even though it has
nothing to do with the logic in that function. This is the pit
that Exception Specifications fell into.
I can see these possibilities:
1. Require adding the constraint annotations all the way up the
call tree. I believe that this will not only become highly
annoying, it might make generic code impractical to write
(consider if bar was passed as an alias).
2. Do the checking only for 1 level, i.e. don't consider what
bar() requires. This winds up just pulling the teeth of the
point of the constraint annotations.
3. Do inference of the constraints. I think that is
indistinguishable from not having annotations as being
exclusive.
Anyone know how Rust traits and C++ concepts deal with this?
I don't know about this. The problem is that if you don't list
everything in the constraint, then the user is going to get an
error buried in your templated code somewhere rather than in
their code, which is _not_ user friendly and is why we usually
try and put everything required in the template constraint. On
the other hand, you're very much right in that this doesn't scale
if you have enough levels of template constraints, especially if
some of the constraints in the functions being called internally
change. And yet, the caller needs to know what the requirements
are of the template or templated function actually are when they
pass it something. So, it does kind of need to be at the top
level from that aspect of usability as well. So, this is just
plain ugly regardless.
One option which would work at least some of the time would be to
do something like
void foo(T)(T t)
if(hasPrefix!T is(typeof(bar(t
{
t.prefix();
bar(t);
}
void bar(T)(T t)
if(hasColor!T)
{
t.color();
}
then you don't have to care what the current constraint for bar
is, and it still gets checked in foo's template constraint.
...
Actually, I just messed around with some of this to see what
error messages you get when foo doesn't check for bar's
constraints in its template constraint, and it's a _lot_ better
than it used to be. This code
void foo(T)(T t)
if(hasPrefix!T)
{
t.prefix();
bar(t);
}
void bar(T)(T t)
if(hasColor!T)
{
t.color();
}
struct Both { void prefix() { } void color() { } }
struct OneOnly { void prefix() { } }
enum hasPrefix(T) = __traits(hasMember, T, prefix);
enum hasColor(T) = __traits(hasMember, T, color);
void main()
{
foo(Both.init);
bar(Both.init);
foo(OneOnly.init);
}
results in these error messages:
q.d(5): Error: template q.bar cannot deduce function from
argument types !()(OneOnly), candidates are:
q.d(8):q.bar(T)(T t) if (hasColor!T)
q.d(25): Error: template instance q.foo!(OneOnly) error
instantiating
It tells you exactly which line in your code is wrong (which it
didn't used to when the error was inside the template), and it
clearly gives you the template constraint which is failing,
whereas if you foo tests for bar in its template constraint, you
get this
q.d(25): Error: template q.foo cannot deduce function from
argument types !()(OneOnly), candidates are:
q.d(1):q.foo(T)(T t) if (hasPrefix!T
is(typeof(bar(t
And that doesn't tell you anything about what bar requires.
Actually putting bar's template constraint in foo's template
constraint would fix that, but then you wouldn't necessarily know
which is failing, and you have the maintenance problem caused by
having to duplicate bar's constraint.
So, I actually think that how the current implementation reports
errors makes it so that maybe it's _not_ a good idea to put all
of the sub-constraints within the top-level constraint, because
it actually makes it harder to figure out what you've done wrong.
Unfortunately, it probably requires that you look at the source
code of the templated function that you're calling regardless,
since the error message doesn't actually make it clear that it's
the argument that you passed to foo that's being passed to bar
rather than an actual bug in foo (and to make matters more
complicated, it could actually be something that came from what
you passed to foo rather than actually being
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 05:27:48 UTC, Walter Bright wrote: On 7/24/2015 11:50 AM, H. S. Teoh via Digitalmars-d wrote: The only way to achieve this is to explicitly negate every condition in all other overloads: Another way is to list everything you accept in the constraint, and then separate out the various implementations in the template body using static if. It's a lot easier making the documentation for that, too. I've considered off and on arguing that a function like find should have a top level template that has the constraints that cover all of the overloads, and then either putting each of the individual functions with their own constraints internally or use separate static ifs within a single function (or some combination of the two). That way, you end up with a simple template constraint that the user sees rather than the huge mess that you get now - though if you still have individual functions within that outer template, then that doesn't really fix the overloading problem except insomuch as the common portion of their template constraints (which is then in the outer template's constraint) would then not have to be repeated. However, when anyone has brought up anything like this, Andrei has argued against it, though I think that those arguments had to do primarily with the documentation, because the person suggesting the change was looking for simplified documentation, and Andrei thought that the ddoc generation should be smart enough to be able to combine things for you. So, maybe it wouldn't be that hard to convince him of what I'm suggesting, but I don't know. I haven't tried yet. It's just something that's occurred to me from time to time, and I've wondered if we should change how we go about things in a manner along those lines. It could help with the documentation and understanding the template constraint as well as help reduce the pain with the overloads. Andrei has definitely been against overloading via static if though whenever that suggestion has been made. I think that he thinks that if you do that, it's a failure of template constraints - though if you use an outer template and then overload the function internally, then you're still using template constraints rather than static if, and you get simplified template constraints anyway. So, maybe we should look at something along those lines rather than proliferating the top-level function overloading like we're doing now. - Jonathan M Davis
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 03:44:23 UTC, Joakim wrote: No, Swift is already general-purpose because it isn't highly optimized for a single purpose or feature and it's a fairly low-level native language which could be used to write everything from hardware drivers to webapps. Hardware drivers? In fact, I now see that Apple announced that they will be contributing a linux port when they open-source it later this year, so it won't even be tied to Apple's platform soon. GNUStep has existed for decades. And gone nowhere. As for Apple's subconscious gratifications, considering I bought my first and last Apple product, a Powerbook G4, a decade ago and would never buy any of their products since, because of their crazy patent stance, that certainly doesn't describe me. Ola brought up Swift as some sort of exception to the general-purpose native languages on mobile trend and I'm simply pointing out that's not true. http://www.primatelabs.com/blog/2014/12/swift-performance/ Swift is 24x slower than C++ for FFT… Standard apps on Android, iOS and in browsers rely heavily upon the builtin rendering/animation engines of their platforms (written in C/C++). The bottleneck for Javascript apps on mobile is the animation engine and emulating the native GUI. For the vast majority of apps Javascript itself performs well enough. For many mobile apps 80% of the code is GUI code. That means you pay a high price for not using the default language and TOOLING for the platform. As I've pointed out cross platform GUI is no longer a realistic option since the Apple/Google have differentiated their GUIs on purpose in order to make it harder. From a performance perspective you could probably do most mobile apps in Javascript/V8 with no noticeable impact. Btw, Dart has picked up the null-related-operators from Swift. It also has async syntax sugar over Futures. It might eventually be positioned as a mobile language for Android, through Sky SDK and Material Design widgets.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: Swift is 24x slower than C++ for FFT… http://www.primatelabs.com/blog/2015/02/swift-performance-updated/ With some optimizations it is now down to… 10x the execution time of C++...
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:24:57 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: Swift is 24x slower than C++ for FFT… http://www.primatelabs.com/blog/2015/02/swift-performance-updated/ With some optimizations it is now down to… 10x the execution time of C++... Nnngh, typo. With latest version of Swift it is down to 10x the execution time and with careful programmer optimizations that more or less sidesteps the default semantics you can get within 10%.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:27:29 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:24:57 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: Swift is 24x slower than C++ for FFT… http://www.primatelabs.com/blog/2015/02/swift-performance-updated/ With some optimizations it is now down to… 10x the execution time of C++... Nnngh, typo. With latest version of Swift it is down to 10x the execution time and with careful programmer optimizations that more or less sidesteps the default semantics you can get within 10%. Already outdated given the performance improvements in Swift 2.0 toolchain.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 06:54:09 UTC, Paulo Pinto wrote: On Saturday, 25 July 2015 at 06:27:29 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:24:57 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad wrote: Swift is 24x slower than C++ for FFT… http://www.primatelabs.com/blog/2015/02/swift-performance-updated/ With some optimizations it is now down to… 10x the execution time of C++... Nnngh, typo. With latest version of Swift it is down to 10x the execution time and with careful programmer optimizations that more or less sidesteps the default semantics you can get within 10%. Already outdated given the performance improvements in Swift 2.0 toolchain. I think those are 20%? Or? https://github.com/vsco/swift-benchmarks
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 00:28:19 UTC, Walter Bright wrote: On 7/24/2015 3:07 PM, Jonathan M Davis wrote: D has done a great job of making unit tests the rule, rather than the exception. Yeah. I wonder what would happen with some of the folks that I've worked with who were anti-unit testing if they were programming in D. It would be more or less shoved in their face at that point rather than having it in a separate set of code somewhere that they could ignore, and it would be so easy to put them in there that it would have to be embarrassing on some level at least if they didn't write them. But they'd probably still argue against them and argue that D was stupid for making them so prominent... :( I do think that our built-in unit testing facilities are a huge win for us though. It actually seems kind of silly at this point that most other languages don't have something similar given how critical they are to high quality, maintainable code. We should be ashamed when our code is not as close to 100% code coverage as is feasible (which is usually 100%). Right on, Jonathan! I must say that this is a rather odd argument to be having though, since normally I'm having to argue that 100% test coverage isn't enough rather than that code needs to have 100% (e.g. how range-based algorithms need to be tested with both value type ranges and reference type ranges, which doesn't increase the code coverage at all but does catch bugs with how save is used, and without that, those bugs won't be caught). So, having to argue that all code should have 100% code coverage (or as close to it as is possible anyway) is kind of surreal. I would have thought that that was a given at this point. The real question is how far you need to go past that to ensure that your code works correctly. - Jonathan M Davis
Re: [RFC] std.experimental.concepts
On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor wrote:
I put up a PR for phobos awhile ago for concepts as a library
to kind of start the discussion around concepts. There seemed
to be some interest around the PR, so I have rebased it and
fixed the formatting.
Please take a look:
https://github.com/D-Programming-Language/phobos/pull/2627
-Shammah
For those who are on a sugar-rush from Concepts, maybe this is a
fun trick?
It almost works, if only IFTI was smart enough to deal with
eponymous identity templates.
int fun(T)(T t) if(is(typeof(T.Put)))
{
}
template Putty(T)
{
static assert(is(typeof(T.Put)));
alias Putty = T;
}
void fun(T)(Putty!T t)
{
}
Re: Named parameters
On 7/25/15 10:05 AM, Martin Nowak wrote: On Saturday, 25 July 2015 at 13:52:09 UTC, Andrei Alexandrescu wrote: For one thing, it avoids the ugly hack which is the Flag template and Yes/No structs. With Flag: The idiom goes like this. /// Flag to control whether or not to keep line endings alias KeepTerminator = Flag!KeepTerminator; /// string getLine(KeepTerminator KeepTerminator); I think dispensing with the alias is significantly better. -- Andrei
Re: Rant after trying Rust a bit
On 7/25/15 9:35 AM, Dicebot wrote: This is absolutely impractical. I will never even consider such attitude as a solution for production projects. If test coverage can't be verified automatically, it is garbage, period. No one will ever manually verify thousands lines of code after some trivial refactoring just to make sure compiler does its job. Test coverage shouldn't totter up and down as application code is written - it should be established by the unittests. And yes one does need to examine coverage output while writing unittests. I do agree more automation is better here (as is always). For example, if a template is followed by one or more unittests, the compiler might issue an error if the unittests don't cover the template. Andrei
Re: Named parameters
On 2015-07-25 13:14, Gary Willoughby wrote: Here's one: https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135 That's ugly and it doesn't work fine, at least not that implementation. It doesn't handle delegate/function parameters. -- /Jacob Carlborg
Re: Named parameters
On 2015-07-25 15:52, Andrei Alexandrescu wrote: Replace the second with: getLine(Yes.keepTerminator); As I answered in the other post I just copied the example from the documentation. -- /Jacob Carlborg
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 14:35:18 UTC, Ola Fosheim Grøstad wrote: On Saturday, 25 July 2015 at 14:20:28 UTC, Joakim wrote: The IR is only for Apple, they're still compiling it and distributing ASM to the device. Yes, but if they go down that road it means you cannot target SIMD instructions. So you cannot get serious performance. Most apps do not care about serious performance from SIMD, as you yourself pointed out. But if they can get good performance from native languages, that is worth it.
Re: Where will D sit in the web service space?
On Saturday, 25 July 2015 at 14:49:36 UTC, David Nadlinger wrote: Why would that be so? You can still e.g. keep vector instructions in the IR and specialize according to the actual hardware width when you generate the binary. You have several rather peculiar SIMD instructions that reflect the specifics of the CPU pipeline that can shave off quite a few cycles for specific algorithms. Different CPUs have different penalties for alignments, ARM can do rather well with misalignments. Different CPUs have different primitives, e.g. on ARM complex functions like sincos can be broken down into simpler primitives, so you can do less exact calculations (fewer iterations than on x86).
Re: Named parameters
Am Sat, 25 Jul 2015 14:05:32 + schrieb Martin Nowak c...@dawg.eu: On Saturday, 25 July 2015 at 13:52:09 UTC, Andrei Alexandrescu wrote: For one thing, it avoids the ugly hack which is the Flag template and Yes/No structs. With Flag: The idiom goes like this. /// Flag to control whether or not to keep line endings alias KeepTerminator = Flag!KeepTerminator; /// string getLine(KeepTerminator KeepTerminator); usage: getLine(KeepTerminator.yes); or getLine(Yes.keepTerminator); So named Boolean flags are a solved problem and are a good improvement over getLine(true) IMO. Named boolean flags are only one very common special case though. That solution doesn't work that well for integers: auto w = Window(0, 0, 100, 200); auto w = Window(x = 0, y = 0, width = 100, height = 200); //auto w = Window(x.0, y.0, width.100, height.200); You could introduce new types for X,Y, Width, Height: auto w = Window(X(0), Y(0), Width(100), Height(200)); It doesn't look that bad. But you'll also have to make sure it converts back to the correct integer types, operator overloading, ... In the end you always introduce new types for something that is one type with named parameters. Having extra types is sometimes the correct thing, sometimes it's not.
Re: Rant after trying Rust a bit
On 7/25/2015 11:40 AM, Tobias Müller wrote: I'm not convinced at all that checked exceptions (as implemented in Java, not C++) don't work. My suspicion is that the usual Java code monkey is just too sloppy to care and thus sees it more as a nuisance rather than the help that it is. Unfortunately, Bruce Eckel's seminal article on it http://www.mindview.net/Etc/Discussions/CheckedExceptions has disappeared. Eckel is not a Java code monkey, he wrote the book Thinking In Java http://www.amazon.com/gp/product/0131002872/
[Issue 9721] Code coverage for templates
https://issues.dlang.org/show_bug.cgi?id=9721 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14825 --
[Issue 14825] New: Coverage analyzer should mark uninstantiated template code lines
https://issues.dlang.org/show_bug.cgi?id=14825
Issue ID: 14825
Summary: Coverage analyzer should mark uninstantiated template
code lines
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
http://www.digitalmars.com/d/archives/digitalmars/D/Rant_after_trying_Rust_a_bit_268458.html#N268741
A coverage report:
===
|void foo (T) ()
|{
|import std.stdio;
|static if (is(T == int))
1|writeln(1);
|else
|writeln(2);
|}
|
|unittest
|{
1|foo!int();
|}
|
foo.d is 100% covered
The 'writeln(2);' should be marked as not covered.
--
[Issue 14825] Coverage analyzer should mark uninstantiated template code lines
https://issues.dlang.org/show_bug.cgi?id=14825 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=9721 --
Re: Beta D 2.068.0-b1
On 07/14/2015 08:47 PM, Jacob Carlborg wrote: It appears this is part of Apple's new security policies. The root user cannot change system directories/files. /System, /bin, /usr/ and /sbin are all part of what's now considered system directories. /usr/local is available to developers [1]. I guess we can just create the symlinks in /usr/local/bin instead. It's already included in the default PATH, if I recall correctly. [1] https://developer.apple.com/videos/wwdc/2015/?id=706 Can you help with fixing the installer?
Re: Rant after trying Rust a bit
On 7/25/2015 6:35 AM, Dicebot wrote: If compiler would actually show 0 coverage for non-instantiated lines, than automatic coverage control check in CI would complain and code would never be shipped unless it gets covered with tests (which check the semantics). Your are putting it totally backwards. A good case. https://issues.dlang.org/show_bug.cgi?id=14825
Re: Beta D 2.068.0-b1
On 07/15/2015 09:39 AM, Suliman wrote: There was plan to include dub (and other tools) in DMD distrib. In what release it would be done? The current plan is to do so when dub reaches 1.0, should be pretty soon.
[Issue 14801] OS X installer not compatible with OS X 10.11
https://issues.dlang.org/show_bug.cgi?id=14801 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #1 from Martin Nowak c...@dawg.eu --- *** Issue 14826 has been marked as a duplicate of this issue. *** --
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy.
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 20:48:06 UTC, Walter Bright wrote: On 7/25/2015 11:40 AM, Tobias Müller wrote: I'm not convinced at all that checked exceptions (as implemented in Java, not C++) don't work. My suspicion is that the usual Java code monkey is just too sloppy to care and thus sees it more as a nuisance rather than the help that it is. Unfortunately, Bruce Eckel's seminal article on it http://www.mindview.net/Etc/Discussions/CheckedExceptions has disappeared. Eckel is not a Java code monkey, he wrote the book Thinking In Java http://www.amazon.com/gp/product/0131002872/ This ? http://www.artima.com/intv/handcuffs.html
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 02:28:49 UTC, Jonathan M Davis wrote: On Saturday, 25 July 2015 at 01:22:15 UTC, Tofu Ninja wrote: On Saturday, 25 July 2015 at 00:49:38 UTC, Walter Bright wrote: On 7/24/2015 2:27 PM, Tofu Ninja wrote: No it isn't. Google QueryInterface(). Nobody lists all the interfaces at the top level functions, which is that Rust traits and C++ concepts require. The only time you don't use the right interface for your needs is if you plan on casting somewhere down the line. But certainly there are people who don't do that, I for one feel it's bad practice to need to use casts to circumvent the type system like that. I confess that I've always thought that QueryInterface was a _horrible_ idea, and that if you need to cast your type to something else like that, you're doing something wrong. *shudder* I really have nothing good to say about COM actually... - Jonathan M Davis Well yes and now. When you design is new and shinny, sure, that is a sign that somewhere it is broken. When you are patching a hundred of thousand line of code, you may not be able to get the refactoring in all at once in a realistic manner and need to build some debt. Hopefully, as the refactoring progress, these hacks are removed, but not having just makes cost of change prohibitive, which is bad.
Re: Rant after trying Rust a bit
I'm not quite sure I understand why this thread is so hot... Here's my case in point: Rust may as well be a system-language however it appeals more to the high-level programmers of today. Your folks from Java, C#, etc. are going to look at Rust with awe. Technically speaking, Rust doesn't do anything that cannot be done in D. The way you go about doing things may be different, and frustrating at times, however that's the basis behind any language. D on the other hand is more of a systems language for C and C++ guys. I'm personally of the opinion that D is wonderful, and it certainly has already reduced my headache count tremendously from my C++ days. As for marketing, for novice and intermediate programmers, the IDE is the language. D does not have very good IDE support. DDT is by far the best, but is fairly easy to break, and still lacks the feel of an IDE designed for D natively, as opposed to a Java IDE with a plugin running in the background to manage DUB for us.
Re: [OT] What D really needs :D
On Saturday, 25 July 2015 at 20:27:12 UTC, Jonathan M Davis wrote: On Saturday, 25 July 2015 at 18:38:56 UTC, Daniel Kozak wrote: https://github.com/avinassh/rockstar?utm_content=buffer64b3cutm_medium=socialutm_source=twitter.comutm_campaign=buffer LOL. Well, clearly he didn't use the program himself, because his github activity doesn't look anything like his example. ;) - Jonathan M Davis Probably wasn't too inclined to explain his deception to future employers ;)
Re: Read text file fast, how?
On Saturday, 25 July 2015 at 20:12:26 UTC, Andrei Alexandrescu wrote: On 7/25/15 1:53 PM, Johan Holmberg via Digitalmars-d wrote: Thanks, my question seems like a carbon copy of the Stack Overflow article :) Somehow I had missed it when googling. I download a dmd 2.068 beta, and re-tried with my input file: now the D program takes 1.6s (a 10x improvement). Great, though it still seems to be behind the C++ version, which is a bummer. -- Andrei Do you happen to have a link to that source where you fixed it. I feel like contributing some reading effort today.
D Web Services Application Potential?
Hi All, Not entirely certain if there is a decent D web applications server implementation as of yet, but if there is a project going on, I'd love to have a gander. On the off-chance there isn't one, who would be interested in going at it, call it, a 'group' project. I've been yearning for a D web app server for a while, as most of my day to day work is done on Java EE containers (think Glassfish, Weblogic, etc. Java Beans, lalala) and the insane system usage has bothered me from day one. There's Wt for C++, although I don't see much coming from that, though the concept is grand. Rust has a few up and coming web server frameworks as well. D could really excel here. -Thoughts? Am I crazy (probably)?
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote: On 7/25/2015 12:19 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: The point of having a type system is to catch as many mistakes at compile time as possible. The primary purpose of a type system is to reduce flexibility. Again, the D constraint system *is* a compile time system, and if the template body uses an interface not present in the type and not checked for in the constraint, you will *still* get a compile time error. The idea that Rust traits check at compile time and D does not is a total misunderstanding. Obvious, everything is at compile time here. Still, there is 2 steps, compiling the template (equivalent to compile time in the dynamic dispatch case), and instantiating the template (equivalent to runtime in the dynamic dispatch case). That is the exact same problem.
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 12:53:37 UTC, Andrei Alexandrescu wrote: FWIW I think traits are better than concepts. -- Andrei Can you explain this in more details ?
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 12:15:04 UTC, Andrei Alexandrescu wrote: On 7/23/15 4:52 PM, Walter Bright wrote: On 7/23/2015 1:08 PM, Dicebot wrote: I am not sure how it applies. D interfaces (defined with the 'interface' keyword) are simple dispatch types, they don't require an Object. Such interfaces can also have default implementations. Is this new? I agree we should allow it, but I don't think it was added to the language yet. Andrei This is not in the language and should not be added lightly. There is all kind of collisions that could happen, and they need proper disambiguate rules. Scala trait (different beast from Rust traits) is a successful implementation of this.
Re: Named parameters
On Saturday, 25 July 2015 at 21:14:00 UTC, Walter Bright wrote: On 7/25/2015 6:54 AM, Andrei Alexandrescu wrote: On 7/25/15 6:32 AM, Jonathan M Davis wrote: If Andrei weren't insisting that we use that idiom everywhere in Phobos, I'd honestly just be using bools and be done with it. It adds some value, but I seriously question that it's worth the extra verbosity. But regardless, I'd hate to see named arguments get added to the language just to clean that mess up. Honest I didn't insist, and am a bit surprised that it did catch up. -- Andrei Well, somebody was insisting and my PR's wouldn't get pulled without converting to it. Bluntly, I think insisting on using Flag instead of bool is not worth the bother. Several of those with commit access seem to have taken a liking to it and insist that it's best practice, and I'm not enthused about it either. Maybe some of those same devs would like to have named arguments as well. I don't know. - Jonathan M Davis
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 13:37:15 UTC, Andrei Alexandrescu wrote: On 7/24/15 6:12 PM, deadalnix wrote: The most intriguing part of this conversation is that the argument made about unitests and complexity are the very same than for dynamic vs strong typing (and there is hard data that strong typing is better). No, that's not the case at all. There is a distinction: in dynamic typing the error is deferred to run time, in this discussion the error is only deferred to instantiation time. -- Andrei In case 1, it is argued that unitest check runtime, so we are good, and in case 2, unitest check instantiation, so we are good. That is the very same argument and it is equally bogus in both cases.
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 13:47:05 UTC, Andrei Alexandrescu wrote: On 7/24/15 9:16 PM, Tofu Ninja wrote: Current template types work like duck typing, which works, but its error prone, and your argument of unittests is obviously bad in the context of duck typing. Could you please make the obvious explicit? We want a real type system for our template types. Every time this (or really any apology of C++ concepts) comes up, the discussion has a similar shape: 1. Concepts are great because they're a type system for the type system! And better error messages! And look at these five-liners! And Look at iterators! And other nice words! 2. I destroy them. So far, you've just rehashed bogous claim made for dynamic typing decades ago and proven wrong decades ago. 3. But we want concepts because they're a type system for the type system! And ... etc. etc. I have no idea how people can simply ignore the fact that their arguments have been systematically dismantled. Andrei Because you only think you did, but really didn't.
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 13:59:11 UTC, Andrei Alexandrescu wrote: Understood, but by the same token library authors shouldn't ship untested code. This is basic software engineering. Once we agree on that, we figure that concepts help nobody. -- Andrei Understood, but by the same token library authors shouldn't ship untested code. This is basic software engineering. Once we agree on that, we figure that [type system|grizzly|unicorns] help nobody. That is a statement, not an argument.
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 22:09:08 UTC, Andrei Alexandrescu wrote: On 7/25/15 5:24 PM, deadalnix wrote: On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy. We could have both (i.e. add traits to D), but would we want to? -- Andrei Yes. Most template code would benefit from it. For the same reason that being able to bypass the type system is important, you also would like that most of the code don't.
Re: Named parameters
On 7/25/2015 6:54 AM, Andrei Alexandrescu wrote: On 7/25/15 6:32 AM, Jonathan M Davis wrote: If Andrei weren't insisting that we use that idiom everywhere in Phobos, I'd honestly just be using bools and be done with it. It adds some value, but I seriously question that it's worth the extra verbosity. But regardless, I'd hate to see named arguments get added to the language just to clean that mess up. Honest I didn't insist, and am a bit surprised that it did catch up. -- Andrei Well, somebody was insisting and my PR's wouldn't get pulled without converting to it. Bluntly, I think insisting on using Flag instead of bool is not worth the bother.
[Issue 14801] OS X installer not compatible with OS X 10.11
https://issues.dlang.org/show_bug.cgi?id=14801 Martin Nowak c...@dawg.eu changed: What|Removed |Added Severity|enhancement |blocker --
[Issue 14826] New: Installer does not work on OSX 10.11
https://issues.dlang.org/show_bug.cgi?id=14826 Issue ID: 14826 Summary: Installer does not work on OSX 10.11 Product: D Version: D2 Hardware: All OS: Mac OS X Status: NEW Severity: blocker Priority: P1 Component: installer Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Reported by Andrew. http://forum.dlang.org/post/diappwxrjeupzgvuc...@forum.dlang.org I did notice that I can no longer create folders or links in the /usr/bin || /usr/lib || /usr/share directory or any subs there. I can however do so in /usr/local/* which is where I've installed the contents of dmd.2.068.0-b1. All seems to work fine. --
