[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 Ali Cehreli acehr...@yahoo.com changed: What|Removed |Added CC||acehr...@yahoo.com --- Comment #13 from Ali Cehreli acehr...@yahoo.com --- If the implicitly-converted value is an rvalue (as it is), where is it stored to take the reference of? Since it is not possible to take the address of an rvalue simply because it may be sitting in a register, I can't see how this fix can be reverted without special-casing the compiler. What kinds of rvalues should we start taking references of? It is unfortunate that this breaks compilation of wrong code but I think the extent of code change should be minimal. Anyway, 2.066.1 is still available. :) Ali --
Re: D + .NET
Only native libraries are more or less accessible from D, not .net. For .net you can use pinvoke (if you can build D dll) or IPC.
Re: How does laziness and UFCS interact?
On 03/10/2015 08:00 AM, John Colvin wrote:
On Tuesday, 10 March 2015 at 14:41:00 UTC, Logan Capaldo wrote:
On Monday, 9 March 2015 at 22:15:43 UTC, Ali Çehreli wrote:
You are right. I had the same observation at minute 11:27 below,
where I warn against UFCS with assumeWontThrow:
http://www.youtube.com/watch?feature=player_detailpagev=oF8K4-bieaw#t=687
Ali
Sorry, which is right?
You are right that it is confusing. :)
I know ifThrown is lazy, I'm curious about the
amount of the expression that is evaluated lazily.
a.b().c().assumeWontThrow vs. a.b().c().assumeWontThrow
^--+^^-^
| |
+- lazy? +- lazy?
As John Colvin said, the first one is right. A test:
import std.stdio;
struct S
{}
S a(S s)
{
writeln(entered a);
return s;
}
S b(S s)
{
writeln(entered b);
return s;
}
void lazily(T)(lazy T expression)
{
writeln(entered lazily);
expression();
}
void main()
{
S().a.b.lazily;
}
Outputs
entered lazily
entered a
entered b
The video seems to say don't use lazy functions with UFCS because you
might think the lazy part gets evaluated first, when it does not.
Seems reasonable, although I don't know it's any different than
assumeWontThrow(f()).
You are right again. :) However, putting the lazy-taking function
outside the whole expression makes it visible right away, making easy
for me to realize that the execution order may be different from common
chains.
Ali
Re: D + .NET
On 2015-03-11 14:30, Sativa wrote: Can you point out where it says anything about wpf or .NET? I'm having trouble finding it. I even searched for .net and wpf but still no luck ;/ Maybe you posted the wrong link by accident? You did mention win32 ;) For OS X Cocoa is the GUI framework. To access that you need to interface with Objective-C. That can either be done using the Objective-C runtime library [1], available from C. This is very tedious and verbose, or wait for this pull request [2] which will add support for linking with Objective-C. [1] https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ObjCRuntimeRef/index.html [2] https://github.com/D-Programming-Language/dmd/pull/4321 -- /Jacob Carlborg
Re: DIP75 - Release Process
On 2015-03-11 17:27, Anon wrote: Ignoring that for a moment, where does it stop? Do we include an editor? [sarcasm] Why not? Every D developer needs to edit their code! Let's go ahead and call Eclipse+DDT the standard D editor, and bundle that with dmd. [/sarcasm] I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's. -- /Jacob Carlborg
[Issue 14267] [REG2.067beta2] ICE when determining if a function can be inlined
https://issues.dlang.org/show_bug.cgi?id=14267 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c29d893a456a9dfee532c2b0a5f6615b3dbc080f Merge pull request #4471 from 9rnsr/fix14267 [REG2.067beta2] Issue 14267 - ICE when determining if a function can be inlined --
Re: How to find the cause of crash?
I want to know how to locate the position of crashing in dlang? for example: there is stack dump in c, exception stack in java, they could help to locate the root of problems.
Re: DIP75 - Release Process
On Wednesday, 11 March 2015 at 08:57:14 UTC, Rikki Cattermole wrote: On 11/03/2015 9:00 p.m., Vladimir Panteleev wrote: On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote: It doesn't seem so to me. You find easy weaknesses in my vision and pump on them instead of working on making it stronger. That's the easy but that business won't work, and here are the reasons why approach. The harder part is finding ways to make it work by overcoming its weaknesses. Here is a counter-proposal: 1. Add Dub to D. 2. Add a web development link in the sidebar, which simply links to vibed.org. 3. Add an example on the front page on how to create a simple web server. It needs to list only main.d and package.json, and the dub command line to build it. A package.json will be needed for non-trivial things anyway, so might as well get that out of the way anyway. 4. Unite the Vibe.d forum with forum.dlang.org. I should be able to do this by making forum.dlang.org connect to it via NNTP. I think this will achieve much of your goal without the drawbacks. I would like to add putting focus on getting libasync[0] phobos ready instead of the vibe.d direction. It might be a lot younger, but it is also have a lot smaller scope. Perhaps even a rewrite of std.socket to use it? It is a lot of work, but its probably a more manageable unit of work in the short term. [0] https://github.com/etcimon/libasync +10!!! and yes, we are using vibe.d in production, but libasync also. --- Paolo
Re: Post increment and decrement
On Thursday, 12 March 2015 at 04:06:14 UTC, Rikki Cattermole
wrote:
On 12/03/2015 1:50 p.m., Andrei Alexandrescu wrote:
On 3/11/15 10:23 AM, welkam wrote:
Observation Nr. 1
People prefer to write var++ instead of ++var.
Observation Nr. 2
Because of observation Nr. 1 and other reasons compilers
became good at
removing code that is not needed making var++ and ++var to
produce the
same code if returned value is not used.
Observation Nr. 3
Because of observation Nr. 2 more people use var++ in place
where they
really only need ++var.
Observation Nr. 4
Because of observation Nr. 3 people learning to program may
mistakenly
learn that var++ is just incrementing. (I am included in that
list)
Observation Nr. 5
Because of observation Nr. 4 people can write slower than
necessary code
for classes with overloaded operator or even get bugs.
Because of all this why not make only one increment/decrement
operator
and have post increment/decrement to be called by template
name, because
it is a template?
template post_inc(T) {
auto tmp = T;
T++;
return tmp;
}
Observation Nr. 6
Somebody didn't Read The Fine Manual. Page 369:
=
If the result of a++ is not needed, the rewrite is ++a, which
is
subsequently rewritten to a.opUnary!++().
=
Andrei
+1
Compiler should work for you. This is one of those things it
can rewrite to preference. During optimization.
It doesn't even rely on the optimizer. This happens in the
front-end, in the semantic pass.
Looking for MQTT client library
I'm looking a MQTT [0] client library written in D, if it exists. Anyone know of any? I found the great Atila Neves MQTT broker (server) [1], and some C/C++ libraries [2], so, possible solutions are: a. Write a native D library from scratch b. Adapt/copy some parts of [1] to convert from server to client c. Create a binding from [2] Anyone has other idea that I could use to create this myself? Thanks [0]http://mqtt.org/ [1]https://github.com/atilaneves/mqtt [2]http://www.eclipse.org/paho/clients/c/
Re: How to use UFCS and std.algorithm.sort?
On 03/10/2015 01:40 AM, Jonathan M Davis via Digitalmars-d-learn wrote: .sort on an array is going to use the built-in sort property. You need to use parens if you want to use the function in std.algorithm with an array and UFCS, e.g. arr.sort(); Didn't know that. Nice! Another option is to use renamed imports[1] but it is hard to come up with an acceptable name other than sort: import std.algorithm: algSort = sort, uniq, map; // -- HERE // ... string[] result = arr .map!(n = n) // minified .array .algSort // -- HERE .uniq .array; Ali [1] http://dlang.org/module.html
[Issue 12420] [AA] Can't set associative array with array as key value using key type
https://issues.dlang.org/show_bug.cgi?id=12420 --- Comment #9 from Denis Shelomovskij verylonglogin@gmail.com --- (In reply to Kenji Hara from comment #8) (In reply to Martin Nowak from comment #7) So what's the conclusion here? Denis argues that mutable key char[] should be allowed for the AA indexing. But AA key should be const on indexing, and should be immutable on setting. Therefore specifying mutable key char[] is not possible. Everything I want is to clarify AA behviour (emn... no, really I'd like to remove this from a language as a terrible misfeature, but I'm almost alone here so I do not propose it). Regarging to types accepted by AAs I'd like Issue 12491 Issue 12492 to be discussed and resolved some way. (I'm saying if and only if a NewExpression `new char[1]` is directly used, it can be convertible to immutable(char[]) by the uniqueness. But it's different from his intention.) This issue isn't connected with `immutable` at all. As I wrote in description it's just a misleading error mesage. Go to enhancement Issue 12491 for AA and immutability discussion. Therefore this issue should be closed as invalid. I can't believe anyone can accept bahaviour shown in Comment 6. --
[Issue 14270] New: final interface: attribute is ignored
https://issues.dlang.org/show_bug.cgi?id=14270
Issue ID: 14270
Summary: final interface: attribute is ignored
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: rswhi...@gmail.com
This code works:
final interface Foo { }
class Bar : Foo { }
But it shouldn't. It seems that the final attribute is ignored.
So we have two choices:
#1: Disallow the final attribute for interfaces
#2: Recognize it correctly
Since this code works (to emulate C++ namespaces, I think):
---
final abstract class Quatz { }
and this is disallowed:
class Test : Quatz { }
We should go with #2
--
Re: Post increment and decrement
On 12/03/2015 9:12 p.m., Don wrote:
On Thursday, 12 March 2015 at 04:06:14 UTC, Rikki Cattermole wrote:
On 12/03/2015 1:50 p.m., Andrei Alexandrescu wrote:
On 3/11/15 10:23 AM, welkam wrote:
Observation Nr. 1
People prefer to write var++ instead of ++var.
Observation Nr. 2
Because of observation Nr. 1 and other reasons compilers became good at
removing code that is not needed making var++ and ++var to produce the
same code if returned value is not used.
Observation Nr. 3
Because of observation Nr. 2 more people use var++ in place where they
really only need ++var.
Observation Nr. 4
Because of observation Nr. 3 people learning to program may mistakenly
learn that var++ is just incrementing. (I am included in that list)
Observation Nr. 5
Because of observation Nr. 4 people can write slower than necessary
code
for classes with overloaded operator or even get bugs.
Because of all this why not make only one increment/decrement operator
and have post increment/decrement to be called by template name,
because
it is a template?
template post_inc(T) {
auto tmp = T;
T++;
return tmp;
}
Observation Nr. 6
Somebody didn't Read The Fine Manual. Page 369:
=
If the result of a++ is not needed, the rewrite is ++a, which is
subsequently rewritten to a.opUnary!++().
=
Andrei
+1
Compiler should work for you. This is one of those things it can
rewrite to preference. During optimization.
It doesn't even rely on the optimizer. This happens in the front-end, in
the semantic pass.
In our implementation yes. But I'm emphasizing it doesn't have to.
Re: enum and static if
On Wed, 11 Mar 2015 13:48:45 +, Namespace wrote:
This code does not work:
enum Test {
Foo,
static if (__VERSION__ = 2067)
Bar,
}
Quatz
}
Any chance that this could work?
nope. `static if` is statement, so it works only where statement is
allowed. the same is true for `version`. this is by design.
signature.asc
Description: PGP signature
[Issue 14280] New: Links to command line tools have disappeared from navigation
https://issues.dlang.org/show_bug.cgi?id=14280 Issue ID: 14280 Summary: Links to command line tools have disappeared from navigation Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com There is no way to navigate to the following pages: dmd-freebsd.html dmd-linux.html dmd-osx.html dmd-windows.html from dlang.org --
[Issue 14277] New: Compile-time array casting error - ugly error report
https://issues.dlang.org/show_bug.cgi?id=14277 Issue ID: 14277 Summary: Compile-time array casting error - ugly error report Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: czda...@gmail.com Hey, look at this code: http://dpaste.dzfl.pl/ce4c5230ac18 If not working:: static ubyte[] u = new char[]; The error report is kinda ugly, isn't it? --
Re: D + .NET
You can also try to expose COM-accessible .net interface and use it through COM in D.
Link in the changelog broken
Hey, when clicking Change Log on the dlang.org it already says Version D 2.067 Mar 1, 2015 even tho big number on the left menu says 2.066.1. Regardless if this is desired (even if confusing) the link embedded at this header is broken.
Re: DIP75 - Release Process
On Wednesday, 11 March 2015 at 07:19:57 UTC, Vladimir Panteleev wrote: What is indubitably, actually, very important, and something I'm surprised you haven't pushed for since long ago, is making it EASY to get more things. Dub absolutely must be a part of D, and not today but one or more years ago. There is now a rift in this community, between people who use code.dlang.org and its packages, and those who do not. And those of us who don't use dub are *not* going to magically start using dub just because it is bundled with dmd. I don't use dub because it doesn't benefit me in any way, and really only gets in my way. Coming from a language with a package manager, and then trying to build a project with a dozen dependencies by manually cloning the repositories and making sure they are the correct version, is madness. A package manager encourages people to build many small reusable components, because the overhead of managing each component becomes very small, and this is something we really want. And any package manager that only operates in source, demands a central repository (that effectively just redirects to the actual Git repos), and only works for one language is utterly worthless for real world projects. Not to mention, putting extra tools like dustmite and dub in dmd will only ever benefit dmd users, not those of us who use ldc or gdc. Ignoring that for a moment, where does it stop? Do we include an editor? [sarcasm] Why not? Every D developer needs to edit their code! Let's go ahead and call Eclipse+DDT the standard D editor, and bundle that with dmd. [/sarcasm]
Re: [WORK] [IMPORTANT] [URGENT] ddox generation
On 3/10/2015 10:27 PM, Walter Bright wrote: While we're at it: http://dlang.org/ Note that there are no navigation links to the how to use dmd pages, like: http://dlang.org/dmd-windows.html These used to be there, but have vanished at some point in the last couple months. This is embarrassingly awful. https://issues.dlang.org/show_bug.cgi?id=14280 Who wants to take this on?
Re: Bypass the protection level
On Wednesday, 11 March 2015 at 15:22:43 UTC, Ali Çehreli wrote: On 03/11/2015 04:40 AM, Namespace wrote: I can call draw on Drawable, because it is declared public and I cannot call draw on Sprite because it is declared protected (this is already a bit weird, why can I redeclare the interface method draw as protected?) It is the same in C++. but I can call the protected draw method from Sprite through Drawable. Is this intended? As far as I know, yes it's intended and again the same in C++. Ali o.O nice to know. Thank you.
Re: auto function attributes based on type
On Thu, 12 Mar 2015 04:51:40 +, amber wrote:
On Thursday, 12 March 2015 at 04:04:28 UTC, weaselcat wrote:
On Thursday, 12 March 2015 at 03:12:15 UTC, amber wrote:
...
http://dlang.org/function.html#function-attribute-inference might be a
good read if you haven't read it already.
I did read it but didn't really understand it, so I've come to D.learn
for more help.
I think it means I can just write the function like so:
struct S(T) {
someFunc(int i) {// impl}
}
and if possible it will be pure, nothrow, @safe and @nogc.
yes. all templated functions (and `someFunc()` is templated due to `S`
being templated) are subjects of attribute inference. due to this fact
people sometimes writing even free functions as argument-less templates,
void freeFunc() (...) { ... }
so compiler will infer attributes for `freeFunc()`. this has almost no
cost, as compiler will merge all produced templates into one.
signature.asc
Description: PGP signature
Re: is eC alot like D?
On Wed, 11 Mar 2015 19:26:13 -0700, Parke via Digitalmars-d-learn wrote: On Wed, 11 Mar 2015 06:22:32 +, sclytrack wrote: - You can include C library headers directly in your .ec code, without any special keyword (like extern C in C++) On Wed, Mar 11, 2015 at 1:59 AM, ketmar via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: either i missed something, misunderstood what he means or he is simply wrong. i remember that there is no CPP macro processor in eC, so... oops. why my C header is not working?! Maybe the eC compiler invokes a C compiler to do the preprocessing. and then we have things like `static inline` functions and many other quirks. ah, and alot of standard C headers included, which are platform- dependent, by the way. so the only way to make this work is to have full- featured native C compiler inside. signature.asc Description: PGP signature
Re: Post increment and decrement
On Wednesday, 11 March 2015 at 17:23:15 UTC, welkam wrote:
Because of all this why not make only one increment/decrement
operator and have post increment/decrement to be called by
template name, because it is a template?
template post_inc(T) {
auto tmp = T;
T++;
return tmp;
}
That's how it works
http://dlang.org/operatoroverloading.html#unary
But I see more optimization opportunity here: the result of ++a
may be not used too, but it still returns the value, which can be
still suboptimal.
Re: D + .NET
On Wednesday, 11 March 2015 at 13:30:27 UTC, Sativa wrote: On Wednesday, 11 March 2015 at 08:45:15 UTC, Kagamin wrote: http://wiki.dlang.org/Libraries_and_Frameworks#GUI_Libraries Can you point out where it says anything about wpf or .NET? I'm having trouble finding it. I even searched for .net and wpf but still no luck ;/ Maybe you posted the wrong link by accident? .net can also expose and call C API in mixed code assemblies.
Re: Smart references
On Wednesday, 11 March 2015 at 20:33:07 UTC, Andrei Alexandrescu wrote: #70: Attempting to copy a reference fails on account of the disabled postblit. There should be a way to tell the compiler to automatically invoke alias this and create a copy of that guy. #81: Moving from a reference works by moving the Ref object. There should be a way to tell the compiler that moving should really move the payload around. I suspect this will work automatically if #70 does.
[Issue 14135] std.uuid.randomUUID breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/9010ecd4b0942e0eb0c37c073d4d53f1984f7872 Merge pull request #2971 from monarchdodra/14135 Issue 14135 - std.uuid.randomUUID breaks @safety --
Re: moving from c++ to D is easy?
On Thu, 12 Mar 2015 13:01:29 +, ayush wrote: Is D a lot like c++ ? I am currently midway through learning c++ and I also want to learn D . So should i focus on one or learn both together? Will I find learning D easy if I already know c++ ? D is like C++, but made by human beings for human beings. and C++ is made by martians for monkeys. signature.asc Description: PGP signature
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:01:31 UTC, ayush wrote: Is D a lot like c++? Enough. So should i focus on one or learn both together? You can study both together, although it is better to focus on one. Will I find learning D easy if I already know c++? Yes.
Re: moving from c++ to D is easy?
On Thu, 12 Mar 2015 13:35:18 + ayush via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Thursday, 12 March 2015 at 13:13:40 UTC, Dennis Ritchie wrote: On Thursday, 12 March 2015 at 13:01:31 UTC, ayush wrote: Is D a lot like c++? Enough. So should i focus on one or learn both together? You can study both together, although it is better to focus on one. Will I find learning D easy if I already know c++? Yes. So on which language should I focus(learn) first D is much easier to learn so I will start with it. And then you can try learn C++ if you still want and need it.
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:13:40 UTC, Dennis Ritchie wrote: On Thursday, 12 March 2015 at 13:01:31 UTC, ayush wrote: Is D a lot like c++? Enough. So should i focus on one or learn both together? You can study both together, although it is better to focus on one. Will I find learning D easy if I already know c++? Yes. So on which language should I focus(learn) first
[Issue 14135] std.uuid.randomUUID breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 monarchdo...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:01:31 UTC, ayush wrote: Is D a lot like c++ ? I am currently midway through learning c++ and I also want to learn D . So should i focus on one or learn both together? Will I find learning D easy if I already know c++ ? D is very much like C++, but the biggest issue I found moving from C++ to D was trying to apply C++ idioms that only existed to work around ugly C++ warts(i.e, CRTP)
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:44:50 UTC, Daniel Kozák wrote: D is much easier to learn so I will start with it. And then you can try learn C++ if you still want and need it. Yes, but in D for beginners little literature, so I would recommend starting with C++.
Re: DIP75 - Release Process
On Thursday, 12 March 2015 at 07:44:01 UTC, Jacob Carlborg wrote: On 2015-03-11 17:27, Anon wrote: Ignoring that for a moment, where does it stop? Do we include an editor? [sarcasm] Why not? Every D developer needs to edit their code! Let's go ahead and call Eclipse+DDT the standard D editor, and bundle that with dmd. [/sarcasm] I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's. That's an IDE that includes a compiler, not a compiler that includes an IDE. You aren't downloading cl, you're downloading VisualStudio. That you also get cl is an implementation detail. If Bruno wanted to release a build of Eclipse+DDT that came with a compiler, I'd have no problem with that.
Re: moving from c++ to D is easy?
On Thu, 12 Mar 2015 13:56:28 +, Dennis Ritchie wrote: On Thursday, 12 March 2015 at 13:44:50 UTC, Daniel Kozák wrote: D is much easier to learn so I will start with it. And then you can try learn C++ if you still want and need it. Yes, but in D for beginners little literature, so I would recommend starting with C++. there are alot of books on C++ 'cause C++ is insanely complicated and inconsistend. D design is *MUCH* better, so D doesn't need so many books teaching arcane art of programming. signature.asc Description: PGP signature
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:56:29 UTC, Dennis Ritchie wrote: On Thursday, 12 March 2015 at 13:44:50 UTC, Daniel Kozák wrote: D is much easier to learn so I will start with it. And then you can try learn C++ if you still want and need it. Yes, but in D for beginners little literature, so I would recommend starting with C++. There is no need for dozens of books. I would even go as far as to say that the existing ones are more than enough. http://wiki.dlang.org/Books
Re: A few notes on choosing between Go and D for a quick project
On 3/12/2015 5:20 PM, Andrei Alexandrescu wrote: * Golang: simple! D1 was the simple version of D. People wanted more. Java was originally sold as, and got a great of adoption because, it was a C++ like language with all that annoying complexity removed. There's no doubt about it, people like simple languages. We should very much keep that in mind when evaluating proposals for new features.
Re: dmd 2.066.1 cannot build phobos 2.066.1
On Friday, 13 March 2015 at 00:15:32 UTC, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:mdt2mj$8gc$1...@digitalmars.com... I wonder how this could have happened. Here's what I did: git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/dmd.git dmd-2.066.1 None of these clone commands work for me, I get: warning: Remote branch v2.066.1 not found in upstream origin, using HEAD instead What Git version are you using? git clone --branch learned to work with tags in Git v1.7.10.
Re: Memoization in compile-time
On 13/03/2015 2:23 p.m., Dennis Ritchie wrote:
Is it possible to run this code in compile-time?
import std.stdio, std.functional;
ulong fact(ulong n)
{
alias mfact = memoize!fact;
return n 2 ? 1 : n * mfact(n - 1);
}
void main() {
writeln(fact(10));
}
In CommonLisp variable *factorial-cache* available in CT, and RT.
Moreover, in the compiler environment of your *factorial-cache* and RT.
Thus we memoires as calculations in CT (constants), and RT.
(eval-always
(defparameter *factorial-cache* (make-hash-table))
(defun factorial (n)
(if ( n 1)
1
(setf (gethash n *factorial-cache*) (* n (factorial (1- n)))
(define-compiler-macro factorial (whole whole n)
(if (constantp n) (factorial n) whole))
Here is an example I have in my Developing with compile time in mind
book[0]:
size_t factorial(size_t n) pure {
assert(n 11);
if (n == 0) {
return 1;
} else {
return n * factorial(n - 1);
}
}
static assert(factorial(5) == 120);
Notice how it is in a static assert? Yeah that is at compile time.
You could assign it to e.g. an enum. Or force it over using
meta-programming.
If you haven't already, I would strongly recommend that you read my book
on the subject.
[0] https://leanpub.com/ctfe
Re: dmd 2.066.1 cannot build phobos 2.066.1
Vladimir Panteleev wrote in message news:tlocllgihbddloqla...@forum.dlang.org... What Git version are you using? git clone --branch learned to work with tags in Git v1.7.10. Yeah, it was 1.7.1.
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #34 from Walter Bright bugzi...@digitalmars.com --- Here's the change that did it: https://github.com/D-Programming-Language/dmd/pull/4177/files Essentially, it's the removal of the toBasetype() call. The problem with deprecating rather than erroring is this function is not checking for errors, it does match levels, which can cause various changes upstream. --
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu wrote: I'd love us to derive a few action items from this and other feedback. I think the front page focuses too much on the language itself at the moment. Perhaps we should continue with the direction with forum integration, and devote a good piece of real estate for the ecosystem (e.g. latest code.dlang.org updates) and maybe an IDE screenshot carousel, OSLT. Making it up-front that we have three compilers, a built-in profiler, and tight GDB integration might also be worthwhile.
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 04:49:38 UTC, Walter Bright wrote: On 3/12/2015 8:40 PM, Joakim wrote: As for will it be around?, presumably he thinks Go will stick around because of Google. That cuts both ways, because if Google stops funding, maybe Pike and the other main devs abandon it, while D seemingly has never had anyone sponsoring Walter, so there's nobody holding the funding spigot here. Google does abandon significant projects now and then, such as this one: http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html Google Graveyard is awesome http://www.slate.com/articles/technology/map_of_the_week/2013/03/google_reader_joins_graveyard_of_dead_google_products.html :)
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 02:17:31 UTC, bearophile wrote: D can't be a single-purpose language. Yeah. The other side of the coin is that, from a D user's perspective, Go and Rust are one-trick ponies.
Re: A few notes on choosing between Go and D for a quick project
Andrei Alexandrescu: ## some or all of @safe, immutable, pure should be the default +1 I have a ER on @safe by default and Walter seems to agree. But I'd like more. A strict D mode? :-) # libraries, projects should be prominently listed and nurtured # single-idea advantage; D seems to embody too many ideas at once ## concurrency? ## networking? ## generics? ## interoperability with C and C++? ## focus on one! D can't be a single-purpose language. And it has more moving parts compared to Go. Bye, bearophile
[Issue 14279] [REG:git-head]Failed to make dmd because of idgen : HOST_DC missing
https://issues.dlang.org/show_bug.cgi?id=14279 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/4492 --
Re: chaining splitters
Yes. That's it! Thanks a lot.
On Wednesday, 11 March 2015 at 09:29:12 UTC, Dave S wrote:
On Wednesday, 11 March 2015 at 00:00:39 UTC, dnoob wrote:
Hello,
I am parsing some text and I have the following;
string text = some very long text;
foreach(line; splitter(text, [13, 10]))
{
foreach(record; splitter(line, '*'))
{
foreach(field; splitter(record, '='))
{
foreach(value; splitter(field, ','))
{
// do something...
}
}
}
}
I know there is a better way to do that but I'm a total D noob.
Thanks!
You can use std.algorithm's map to apply some function to all
the
items in a range:
---
import std.stdio, std.algorithm;
void main()
{
string text = foo*bar=qux\r\nHello*world!\r\nApril,May,June;
auto lines = splitter(text, \r\n);
auto records = map!(a = splitter(a, '*'))(lines).joiner();
auto fields = map!(a = splitter(a, '='))(records).joiner();
auto values = map!(a = splitter(a, ','))(fields).joiner();
foreach (value; values)
{
writeln(value);
}
}
---
This produces the output:
foo
bar
qux
Hello
world!
April
May
June
The joiner() is necessary because when you pass a range of
strings to splitter using map the result is a range of ranges of
strings. joiner() joins these together into one range of
strings.
Consider this code, for example:
---
string str = foo*bar=qux\r\nHello*world!\r\nApril,May,June;
auto lines = splitter(str, [13, 10]);
auto result = map!(a = splitter(a, '*'))(lines);
auto tokens = result.joiner();
---
The contents of result are:
[foo, bar=qux]
[Hello, world!]
[April,May,June]
The contents of tokens are:
[foo, bar=qux, Hello, world!, April,May,June]
I am not a D expert by any means so there it's possible there is
another way that I am not aware of.
Re: is eC alot like D?
To confirm guys eC does support C preprocessing. The C preprocessor is invoked before the eC compiler does its parsing. And all native C headers should work fine as well, although there might be some portability issues on more obscure platforms which have not yet been tested which would require attention, but as you can see at https://packages.debian.org/jessie/libecerecom0 it works fine on most popular platforms. eC tries to be a superset of C as much possible, with only a few keyword clashes like 'class' as an exception. Best regards, -Jerome On Thursday, 12 March 2015 at 11:02:11 UTC, ketmar wrote: On Wed, 11 Mar 2015 19:26:13 -0700, Parke via Digitalmars-d-learn wrote: On Wed, 11 Mar 2015 06:22:32 +, sclytrack wrote: - You can include C library headers directly in your .ec code, without any special keyword (like extern C in C++) On Wed, Mar 11, 2015 at 1:59 AM, ketmar via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: either i missed something, misunderstood what he means or he is simply wrong. i remember that there is no CPP macro processor in eC, so... oops. why my C header is not working?! Maybe the eC compiler invokes a C compiler to do the preprocessing. and then we have things like `static inline` functions and many other quirks. ah, and alot of standard C headers included, which are platform- dependent, by the way. so the only way to make this work is to have full- featured native C compiler inside.
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 02:17:31 UTC, bearophile wrote: A strict D mode? That sounds like an amazing idea.
Re: A few notes on choosing between Go and D for a quick project
I made a choice between Go and D in 2013. I started with Go and was very happy when I switched to D. The languages appeal to different users. This is how I interpreted some of the advantages of Go: + very small language, very concise simple A limited, inflexible language + feels like a better C (mostly) Feels like C + enforced style (indentation, exports) Ridiculously restricted for no reason other than developer arrogance. # big language An intuitive language that actually does things. General feeling: I don't feel smart enough for D and am looking for a quick way to accomplish a goal. If you want to be Rob Pike Jr., Go is great. If you want to program your way, not so much. For someone coming from a Lisp background but wanting a better C, Go had very little appeal. Bottom line: Emphasize the different philosophies of Go and D.
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu wrote: A friend of mine needed to complete a small project and thought of using a language he didn't know for it. He already knew I work on D so he considered it alongside Go. He ended up choosing the latter, and documented his decision making process in a few notes that he subsequently shared with me. I'll paste below a sort of transcript of his handwritten notes. I think this is valuable information from a relatively unbiased potential user, and good ideas and action items on how we can improve our curb appeal. Even mistaken perceptions are good signal - it means our materials weren't explicit enough to dispel them. * Golang: simple! + very small language, very concise simple + playground/tutorial + easy to start using it, no-nonsense + vast libraries + no inheritance + one binary to distribute + good for servers + feels like a better C (mostly) - can't write generic code involving arrays/slices - no good IDE + Google! + clear feeling it's here to stay + visible, many projects + enforced style (indentation, exports) * Dlang: big! # big language # IDE? # small subset? # libraries? # will it be around? # Perception matters ## how stable is it? ## not great for servers or UIs; what then? ## new house in unpopulated neighborhood; there's an Enter, it's open sign but sits emtpy; by comparison Go - condo in hip, trendy area When you said curb appeal, I was prepared to read how a cursory look at both websites turned him off on D and on to Go. But none of these qualities can be determined so easily, you have to look around for a while to know that D is bigger and Go is considered hip, trendy compared to a supposedly unpopulated D. Comparing the front pages of the respective language websites, dlang.org does a good job of actually introducing the language, while golang.org simply says Go is an open source programming language that makes it easy to build simple, reliable, and efficient software. That's it. You have to click a couple times to actually get to the Go tour or manual and find out what Go is: there's no pitch to sell you the language first. The recent dlang.org redesign seems to have done a good job of simplifying the front page, including the addition of the previously unavailable Getting Started option. Of course, the front page of dlang.org is not as spare and pretty as golang.org, will still take a designer to spiff it up a bit. As to his actual points, it seems to come down to D replaces C++, while Go replaces C. If you're looking for a better C, the more advanced, C++-esque features of D might distract and confuse you, even though you can ignore those and use it that way. As for will it be around?, presumably he thinks Go will stick around because of Google. That cuts both ways, because if Google stops funding, maybe Pike and the other main devs abandon it, while D seemingly has never had anyone sponsoring Walter, so there's nobody holding the funding spigot here. Not sure why he thinks D isn't good for servers, as that's what its key corporate backers all use it for. I don't deny that some of these perceptions exist, not sure how being considered hip, trendy is combated other than by having more success. * Ideas for D # what C++ should be but cannot ## too late for C++, but not for D ## some or all of @safe, immutable, pure should be the default # libraries, projects should be prominently listed and nurtured Good suggestion for the front page, perhaps a library of the month? # single-idea advantage; D seems to embody too many ideas at once ## concurrency? ## networking? Where is D advertised as being special or different with its ideas on networking? I don't see it. ## generics? ## interoperability with C and C++? ## focus on one! That's not D's approach, for better or worse. It's offering a buffet of features, not just a great steak. # must attract/hook casual users I agree that D's use in small programs and scripting could be better emphasized. In trying to attract the C++ crowd, this orthogonal audience is sometimes ignored. # unclear what's a good IDE - JetBrains? is there Vim support? The D Wiki lists supported IDEs, maybe the Getting Started page should directly link there. # what's D's equivalent to frameworks such as react.js? # language designers think of features, users think of purpose ## react, go, rust, java - purpose React is a UI framework, easy to state its purpose. Go has essentially nothing on their front page, while Rust just has a feature list. Java is the only one that talks about rationale and purpose: https://www.java.com/en/about/ ## D, C++ - Ivy league candidates having a response for every programming language design challenge there is, but less focused on purpose (Andrei's note: I assume D more at fault than C++ on this) I agree that dlang.org could go a bit more into
Re: A few notes on choosing between Go and D for a quick project
On 3/12/2015 8:40 PM, Joakim wrote: As for will it be around?, presumably he thinks Go will stick around because of Google. That cuts both ways, because if Google stops funding, maybe Pike and the other main devs abandon it, while D seemingly has never had anyone sponsoring Walter, so there's nobody holding the funding spigot here. Google does abandon significant projects now and then, such as this one: http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #23 from Dicebot pub...@dicebot.lv --- (In reply to Jonathan M Davis from comment #22) I think that allowing an implicit conversion to be used with a ref parameter is a clear violation of the type system. If we want to fix it via deprecation rather than immediately making it an error like we'd normally do with an accepts-invalid bug on the theory that the code actually works in spite of violating the type system, then fine. But I don't think that it's at all a good idea to leave the code as valid long term. This was my point from the very first comment here ;) Yes, this is bad code and disallowing it will make type system more uniform. But it isn't inherently broken and thus deprecation stage is mandatory. I will look into relevant code closer to the weekend if no one else will have done it by that point. --
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 14:47:22 UTC, ketmar wrote: there are alot of books on C++ 'cause C++ is insanely complicated and inconsistend. D design is *MUCH* better, so D doesn't need so many books teaching arcane art of programming. Well, in principle, can be started with a D, but personally, I started actually with ANSI C.
Re: DIP75 - Release Process
On Thursday, 12 March 2015 at 07:44:01 UTC, Jacob Carlborg wrote: On 2015-03-11 17:27, Anon wrote: Ignoring that for a moment, where does it stop? Do we include an editor? [sarcasm] Why not? Every D developer needs to edit their code! Let's go ahead and call Eclipse+DDT the standard D editor, and bundle that with dmd. [/sarcasm] I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's. The SDKs ship with Visual Studio, not the other way around. Both the Windows SDK and .NET Framework/SDK are separate products. The .NET Framework itself includes the .NET compiler, which Visual Studio uses, and the Windows SDK includes cl.exe which is the C/C++ compiler. Neither require Visual Studio. It's good to have a single installer that includes everything you need to get started (dmd, dub, IDE / IDE plugin) like Visual Studio is (cl/csc, Nuget, VS), but the compiler itself should definitely not ship with an IDE.
Re: Targeting Vulkan and SPIR-V
On 12 March 2015 at 15:57, John Colvin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote: On 6 Mar 2015 23:30, Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: The ground-up redesign of OpenGL, now called Vulkan, has been announced at GDC: http://www.phoronix.com/scan.php?page=articleitem=khronos-vulcan-spirv Both graphics shaders and the latest verson of OpenCL, which enables computation on the GPU, will target a new IR called SPIR-V: http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl Rather than being forced to use C-like languages like GLSL or OpenCL in the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions. This would be a good opportunity for D, if ldc or gdc could be made to target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V. Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is high level enough that you don't need to think (nor care) about your backend target. GCC itself will need a backend to support it though. ;) Iain Relevant: https://gcc.gnu.org/ml/gcc/2015-03/msg00020.html David is an awesome guy. Would be great if he picks up the baton on this. I reckon most things would be hashed out via GCC builtins, in which someone writes a library for.
Re: Looking for MQTT client library
Those are basically your options. You could wrap Mosquitto (a C implementation), but I'd just use the existing MQTT broker code. Then again, I would say that. :) Atila On Thursday, 12 March 2015 at 07:59:55 UTC, o3o wrote: I'm looking a MQTT [0] client library written in D, if it exists. Anyone know of any? I found the great Atila Neves MQTT broker (server) [1], and some C/C++ libraries [2], so, possible solutions are: a. Write a native D library from scratch b. Adapt/copy some parts of [1] to convert from server to client c. Create a binding from [2] Anyone has other idea that I could use to create this myself? Thanks [0]http://mqtt.org/ [1]https://github.com/atilaneves/mqtt [2]http://www.eclipse.org/paho/clients/c/
Re: Targeting Vulkan and SPIR-V
On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote: On 6 Mar 2015 23:30, Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: The ground-up redesign of OpenGL, now called Vulkan, has been announced at GDC: http://www.phoronix.com/scan.php?page=articleitem=khronos-vulcan-spirv Both graphics shaders and the latest verson of OpenCL, which enables computation on the GPU, will target a new IR called SPIR-V: http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl Rather than being forced to use C-like languages like GLSL or OpenCL in the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions. This would be a good opportunity for D, if ldc or gdc could be made to target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V. Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is high level enough that you don't need to think (nor care) about your backend target. GCC itself will need a backend to support it though. ;) Iain Relevant: https://gcc.gnu.org/ml/gcc/2015-03/msg00020.html
Re: Post increment and decrement
On 12/03/2015 10:14, monarch_dodra wrote: On Wednesday, 11 March 2015 at 17:23:15 UTC, welkam wrote: Observation Nr. 1 People prefer to write var++ instead of ++var. The root of your reasoning stems from this observation, which I argue is wrong. The recommendation has always been to chose ++var, unless you have a reason to chose var++. Where the result is not needed, var++ is probably more common. I'd rather read post-increments. Grep -c phobos for simple for loops: ; word++): etc/c/zlib/crc32.c:9 etc/c/zlib/deflate.c:1 etc/c/zlib/gzwrite.c:2 etc/c/zlib/inftrees.c:6 etc/c/zlib/trees.c:25 etc/c/zlib/zutil.c:2 std/algorithm.d:2 std/bitmanip.d:5 std/concurrency.d:1 std/container/rbtree.d:2 std/digest/md.d:1 std/digest/ripemd.d:1 std/digest/sha.d:2 std/math.d:3 std/parallelism.d:1 std/path.d:2 std/random.d:1 std/regex/internal/backtracking.d:3 std/regex/internal/ir.d:1 std/regex/internal/kickstart.d:5 std/regex/internal/parser.d:2 std/regex/internal/tests.d:1 std/regex/package.d:1 std/socket.d:8 std/stream.d:1 std/string.d:2 std/uni.d:18 std/uri.d:11 std/utf.d:3 std/uuid.d:2 std/windows/charset.d:1 std/zip.d:2 std/zlib.d:3 unittest.d:1 ; ++word): std/algorithm.d:8 std/bitmanip.d:1 std/encoding.d:7 std/format.d:4 std/internal/math/biguintcore.d:9 std/internal/math/biguintnoasm.d:17 std/internal/math/biguintx86.d:14 std/internal/math/gammafunction.d:2 std/math.d:1 std/numeric.d:2 std/process.d:3 std/random.d:3 std/stream.d:2 std/utf.d:1 std/windows/registry.d:4 std/xml.d:1
[Issue 14277] Compile-time array casting error - ugly error report
https://issues.dlang.org/show_bug.cgi?id=14277 --- Comment #2 from Ketmar Dark ket...@ketmar.no-ip.org --- Created attachment 1491 -- https://issues.dlang.org/attachment.cgi?id=1491action=edit trim output of long expressions as far as i know, `Expression::toChars()` is not using in anything vital, only in diagnostic output. so i trimming it's result to arbitrary limit of 200 chars. maybe it's better to fix array literal output, but this is easier, and it will additionaly limit output of other long expressions, which are unreadable anyway if they reaches that size. --
YOW 2014 talk on D now online
http://www.reddit.com/r/programming/comments/2yt1ek/andrei_alexandrescu_on_d_at_yow2014_local_imports/ https://twitter.com/D_Programming/status/576066527155367936 https://www.facebook.com/dlang.org/posts/1031487990198215 Andrei
[Issue 14277] Compile-time array casting error - ugly error report
https://issues.dlang.org/show_bug.cgi?id=14277 --- Comment #3 from Ketmar Dark ket...@ketmar.no-ip.org --- p.s. this can ruing long utf-8 literals, though. not that i really care. --
Video: Cool Things about D - Why and how we use it at Facebook
Found this on Reddit, thought you guys would like to take a look. https://yow.eventer.com/yow-2014-1222/cool-things-about-d-why-and-how-we-use-it-at-facebook-by-andrei-alexandrescu-1741 Reddit link: http://www.reddit.com/r/programming/comments/2yt1ek/andrei_alexandrescu_on_d_at_yow2014_local_imports/ Upvote away!
Re: Andrei Alexandrescu on D at YOW2014: Local imports, relaxed functional purity, generative programming
On Thursday, 12 March 2015 at 20:39:08 UTC, Walter Bright wrote: https://www.reddit.com/r/programming/comments/2yt1ek/andrei_alexandrescu_on_d_at_yow2014_local_imports/ http://forum.dlang.org/thread/mdsh5n$2kta$1...@digitalmars.com http://forum.dlang.org/thread/ionjnsvqcplgxuoip...@forum.dlang.org
Re: Looking for MQTT client library
My preferred option is b. that is convert your MQTT broker to MQTT client. I'm not a MQTT expert, so, in your opinion what parts of your code should I change? (i.e. message module should be the same, peraphs module stream...) Thanks for your support (and also for your unit-threaded project!) On Thursday, 12 March 2015 at 15:03:13 UTC, Atila Neves wrote: Those are basically your options. You could wrap Mosquitto (a C implementation), but I'd just use the existing MQTT broker code. Then again, I would say that. :) Atila
Re: Standard GUI framework inspired by Qt
On Tuesday, 10 March 2015 at 01:25:05 UTC, karl wrote: Please don't use SDL2 and such as basis, or OpenGL with glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm a GL driver dev (userspace) for a smaller company, and I see too much gore in popular software like that (gnome3 is the most-horrific). A fully-featured GUI with GL needs only a thin wrapper for glXGetProcAddress, GL context creation, BitBlt-like things and font-glyph cache (or better yet, signed-distance-field text rendering). Something like this: Base (sans clipping, I haven't ported it from asm yet): https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw SDF text: https://www.mapbox.com/blog/text-signed-distance-fields/ Also, GL should be optional, just like with Qt; it introduces noticeable lag of 16 to 48ms while being a resource hog unnecessary for most apps. I could help with implementing the abstraction layer and create a software blitter (I was professionally doing such stuff before, for GUI toolkits and stuff; but then again this stuff is trivial). A 32-bit backing-store is always vital (DDB+GDI dibsection, GL texture and such). Qt has it (and implemented really-well) and that's the first pixel-related thing we should implement. BGRA8 will be the best format (blue in LSB). A 9-cell blit will also be vital functionality. @karl Can you check the proposal of the new color module by Manu? https://github.com/D-Programming-Language/phobos/pull/2845 Do you see any issues there? Piotrek
Andrei Alexandrescu on D at YOW2014: Local imports, relaxed functional purity, generative programming
https://www.reddit.com/r/programming/comments/2yt1ek/andrei_alexandrescu_on_d_at_yow2014_local_imports/
Re: YOW 2014 talk on D now online
Great talk. This is what i found most interesting: Andrei @ 12:52: It doesn't have a large corporate sponsor at the moment, but that's due to change. Oooo. Any more information on this?
Re: Template Parameter Deduction
On Wednesday, 11 March 2015 at 23:04:15 UTC, Ali Çehreli wrote:
On 03/11/2015 03:44 PM, Paul D Anderson wrote:
This used to work in D2.065:
given
1) public T mul(T)(in T x, in T y,
Context context = T.context) if (isDecimal!T)
// one template parameter for the two input values
and
2) public T mul(T, U)(in T x, U n, Context context = T.context)
if (isDecimal!T isIntegral!U)
// two different template parameters for the two input
values
then
3) dec9 arg1 = dec9(1.20);
long arg2 = 3;
result = mul(arg1, arg2);
// correctly deduced function
But now (D2.066.1) either 1) has to be changed to
1) public T mul(T, U)(in T x, U y, Context context = T.context)
if (isDecimal!T isDecimal!U)
// two identical template parameters for the two input
values
or 3) has to be changed to
3) dec9 arg1 = dec9(1.20);
long arg2 = 3;
result = mul!(dec9,long)(arg1, arg2);
// template parameters have to be made explicit
Is this expecded behavior?
Paul
Hint: It makes it much simpler to work with complete code. The
following code took a while for me to put together:
template isDecimal(T)
{
enum isDecimal = true;
}
template isIntegral(T)
{
enum isIntegral = true;
}
public T mul(T)(in T x, in T y,
Context context = T.context) if (isDecimal!T)
// one template parameter for the two input values
{
return x;
}
alias Context = int;
public T mul(T, U)(in T x, U n, Context context = T.context)
if (isDecimal!T isIntegral!U)
// two different template parameters for the two input
values
{
return x;
}
struct dec9
{
string s;
enum context = 42;
}
void main()
{
dec9 arg1 = dec9(1.20);
long arg2 = 3;
dec9 result = mul(arg1, arg2);
// correctly deduced function
}
Yes, it fails with 2.066.1 but compiles fine with git head.
Ali
Thanks to you and John for taking the time to work this out. I
didn't mean for anyone to rebuild the example -- I was just
hoping there was a quick answer based on known language changes.
I should have included complete example code.
At any rate, it looks like there is a hiccup in the template
parameter deduction code and that it is being fixed. And it's
easy to work around. I'll dig a little deeper to see if I can
find a related bug report.
Paul
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #31 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Andrei Alexandrescu from comment #30) This is a simple accepts-wrong-code bug that needs to be fixed with no deprecation. Any code that relies on this bug was wrong. I don't know if this makes things clear. What should be wrong code? The situation in the unreleased compiler or the situation in 2.066.1? --
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 18:57:51 UTC, Ali Çehreli wrote:
On 03/12/2015 06:01 AM, ayush wrote:
Is D a lot like c++ ?
I came to D from C++. I remember the following being notable
differences:
- In D, classes have reference semantics. I quickly realized
that this is not an issue because so many of my C++ types were
hand-reference-typified :p by this idiom, almost everywhere:
class C { /* ... */ };
typedef boost::shared_ptrC CPtr;
void foo(CPtr c);
This is a common mistake. In 99 percent of cases you want to use
a std::unique_ptr. std::shared_ptr is rarely common and often an
indication of an error in design. In general, there is exactly
one owner only.
But I think you know that already. :)
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #33 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Andrei Alexandrescu from comment #32) Code that attempts to convert an lvalue of enum type to a ref to its base type is wrong. The compiler shouldn't accept it. Correcting it qualifies as a simple bug fix. OK, so that is what already happened. I don't agree with it, but I don't see that it is worth having a battle over. --
Re: dfmt 0.1.5 (codename: entomology)
https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.7 #92 Statement after case label after unbraced if is indented #93 Version-else inside if is indented incorrectly #94 Wrong indent with function literal
Re: YOW 2014 talk on D now online
On Thursday, 12 March 2015 at 17:08:08 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2yt1ek/andrei_alexandrescu_on_d_at_yow2014_local_imports/ https://twitter.com/D_Programming/status/576066527155367936 https://www.facebook.com/dlang.org/posts/1031487990198215 Andrei Gary beat you to it by 1 hour! http://forum.dlang.org/thread/ionjnsvqcplgxuoip...@forum.dlang.org
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 18:57:51 UTC, Ali Çehreli wrote: If you are a mortal like myself, you may find out years later that you are still at the midway point. Happened to me several times when I was learning C++. :) О, yeah.
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #32 from Andrei Alexandrescu and...@erdani.com --- (In reply to Steven Schveighoffer from comment #31) (In reply to Andrei Alexandrescu from comment #30) This is a simple accepts-wrong-code bug that needs to be fixed with no deprecation. Any code that relies on this bug was wrong. I don't know if this makes things clear. What should be wrong code? The situation in the unreleased compiler or the situation in 2.066.1? Code that attempts to convert an lvalue of enum type to a ref to its base type is wrong. The compiler shouldn't accept it. Correcting it qualifies as a simple bug fix. --
Re: YOW 2014 talk on D now online
On 3/12/15 1:03 PM, CraigDillabaugh wrote: On Thursday, 12 March 2015 at 17:08:08 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2yt1ek/andrei_alexandrescu_on_d_at_yow2014_local_imports/ https://twitter.com/D_Programming/status/576066527155367936 https://www.facebook.com/dlang.org/posts/1031487990198215 Andrei Gary beat you to it by 1 hour! http://forum.dlang.org/thread/ionjnsvqcplgxuoip...@forum.dlang.org Not to mention he posted in the right forum. -- Andrei
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #24 from Steven Schveighoffer schvei...@yahoo.com ---
(In reply to Jonathan M Davis from comment #22)
I think that allowing an implicit conversion to be used with a ref parameter
is a clear violation of the type system.
class C {}
void foo(Object o);
void main()
{
C c = new C;
foo(c); // works, and passed by ref!
}
I think clearly there is a similar relationship with enums and their base type.
--
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #26 from Ketmar Dark ket...@ketmar.no-ip.org ---
class C {}
void foo (Object o) {
o = new Object();
}
void main () {
C c = new C;
auto n = c;
foo(c);
assert(c == n); // assertion passed
}
--
Re: moving from c++ to D is easy?
On 03/12/2015 06:01 AM, ayush wrote:
Is D a lot like c++ ?
I came to D from C++. I remember the following being notable differences:
- In D, classes have reference semantics. I quickly realized that this
is not an issue because so many of my C++ types were
hand-reference-typified :p by this idiom, almost everywhere:
class C { /* ... */ };
typedef boost::shared_ptrC CPtr;
void foo(CPtr c);
- Garbage collector took longer to get used to. There are some issues
with the spec or implementation that some objects may never be
destructed (or is it finalized?).
Other than issues like that, everything in D feels like a fresh air.
I am currently midway through learning c++
If you are a mortal like myself, you may find out years later that you
are still at the midway point. Happened to me several times when I was
learning C++. :)
and I also want to learn D . So should i focus on one or learn
both together?
Economically, C++ may make more sense. But if you are learning just for
yourself, perhaps for fun, then I recommend D.
Will I find learning D easy if I already know c++ ?
I think so.
Ali
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #28 from Steven Schveighoffer schvei...@yahoo.com ---
The Object contents are passed by ref, just like the enum contents are.
The difference is that the ref is implicit for the object. In other words, a
ref to a C object is implicitly passable as a ref to a base Object. A ref to a
C object *reference* is not passable as a ref to a base Object reference for
correct reasons.
The equivalent to your code for enums would be:
void foo (int *o) {
o = new int;
}
enum E : int;
void main () {
E *c = new E;
auto n = c;
foo(c);
assert(c == n); // assertion passed
}
--
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #27 from Ketmar Dark ket...@ketmar.no-ip.org --- ah, sorry, replace that assert with `assert(c is n);` for clarity. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 Ketmar Dark ket...@ketmar.no-ip.org changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #25 from Ketmar Dark ket...@ketmar.no-ip.org --- (In reply to Steven Schveighoffer from comment #24) foo(c); // works, and passed by ref! but it's in no way passed by ref! O_O --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #30 from Andrei Alexandrescu and...@erdani.com --- This is a simple accepts-wrong-code bug that needs to be fixed with no deprecation. Any code that relies on this bug was wrong. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #29 from Jonathan M Davis issues.dl...@jmdavisprog.com ---
(In reply to Steven Schveighoffer from comment #24)
(In reply to Jonathan M Davis from comment #22)
I think that allowing an implicit conversion to be used with a ref parameter
is a clear violation of the type system.
class C {}
void foo(Object o);
void main()
{
C c = new C;
foo(c); // works, and passed by ref!
}
I think clearly there is a similar relationship with enums and their base
type.
In that case, you're not passing by ref. You're dealing with a reference type -
and a polymorphic one at that. There is nothing polymorphic about enums unless
they happen to have a class type as their base type. And this code does _not_
compile:
class C {}
void foo(ref Object o);
void main()
{
C c = new C;
foo(c);
}
ref and class references are not the same thing at all.
--
moving from c++ to D is easy?
Is D a lot like c++ ? I am currently midway through learning c++ and I also want to learn D . So should i focus on one or learn both together? Will I find learning D easy if I already know c++ ?
Re: dmd 2.066.1 cannot build phobos 2.066.1
Andrei Alexandrescu wrote in message news:mdt2mj$8gc$1...@digitalmars.com... I wonder how this could have happened. Here's what I did: git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/dmd.git dmd-2.066.1 None of these clone commands work for me, I get: warning: Remote branch v2.066.1 not found in upstream origin, using HEAD instead
A few notes on choosing between Go and D for a quick project
A friend of mine needed to complete a small project and thought of using a language he didn't know for it. He already knew I work on D so he considered it alongside Go. He ended up choosing the latter, and documented his decision making process in a few notes that he subsequently shared with me. I'll paste below a sort of transcript of his handwritten notes. I think this is valuable information from a relatively unbiased potential user, and good ideas and action items on how we can improve our curb appeal. Even mistaken perceptions are good signal - it means our materials weren't explicit enough to dispel them. * Golang: simple! + very small language, very concise simple + playground/tutorial + easy to start using it, no-nonsense + vast libraries + no inheritance + one binary to distribute + good for servers + feels like a better C (mostly) - can't write generic code involving arrays/slices - no good IDE + Google! + clear feeling it's here to stay + visible, many projects + enforced style (indentation, exports) * Dlang: big! # big language # IDE? # small subset? # libraries? # will it be around? # Perception matters ## how stable is it? ## not great for servers or UIs; what then? ## new house in unpopulated neighborhood; there's an Enter, it's open sign but sits emtpy; by comparison Go - condo in hip, trendy area * Ideas for D # what C++ should be but cannot ## too late for C++, but not for D ## some or all of @safe, immutable, pure should be the default # libraries, projects should be prominently listed and nurtured # single-idea advantage; D seems to embody too many ideas at once ## concurrency? ## networking? ## generics? ## interoperability with C and C++? ## focus on one! # must attract/hook casual users # unclear what's a good IDE - JetBrains? is there Vim support? # what's D's equivalent to frameworks such as react.js? # language designers think of features, users think of purpose ## react, go, rust, java - purpose ## D, C++ - Ivy league candidates having a response for every programming language design challenge there is, but less focused on purpose (Andrei's note: I assume D more at fault than C++ on this) General feeling: I don't feel smart enough for D and am looking for a quick way to accomplish a goal. I've read the Wikipedia article on D and didn't understand a few things. The examples seem to show off the language but that made them confusing. I wanted to get more into it, but by that time Go had already won - I looked at the tutorials, changed the sample code a bit right in the browser to see how it'd work for me, it was easy, I was in already. Some of my comments therefore illustrate my shortcomings than the language's, but that's true one way or another for all programmers (that's why technical superiority of a language doesn't guarantee its success). === I'd love us to derive a few action items from this and other feedback. Andrei
Re: dmd 2.066.1 cannot build phobos 2.066.1
On 3/12/15 5:15 PM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:mdt2mj$8gc$1...@digitalmars.com... I wonder how this could have happened. Here's what I did: git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/dmd.git dmd-2.066.1 None of these clone commands work for me, I get: warning: Remote branch v2.066.1 not found in upstream origin, using HEAD instead Could that be because our default remotes are different (e.g. yours is your own fork)? -- Andrei
Re: dmd 2.066.1 cannot build phobos 2.066.1
Andrei Alexandrescu wrote in message news:mdtb6c$f2f$1...@digitalmars.com... Could that be because our default remotes are different (e.g. yours is your own fork)? -- Andrei I don't think so, but it could be because I've got an older version of git. I took a quick look at the 2.066.1 tag on github, and it doesn't look like there's any mention of -conf in phobos' posix.mak (https://github.com/D-Programming-Language/phobos/blob/c8fccac8c20a3bdd6300128f610267a24d42473f/posix.mak) Do you maybe have it in an environment variable or dmd.conf that's getting picked up?
[Issue 7067] std.random.RandomSample and RandomCover are poorly designed
https://issues.dlang.org/show_bug.cgi?id=7067 --- Comment #23 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net --- @Martin @Jens: sorry for radio silence on this. It's a busy period, and I recently moved to a new apartment where I still don't have home internet. I don't think that sharing rng state among multiple consumers is a good idea. Of course it looks like you want random numbers and shouldn't care about the order, but often fixed seeds are used to get a reproducible pseudo-random range. When you share such a RNG as in auto rng = Random(fixedSeed); assert(!equal(randomCover(a, rng), randomCover(a, rng))); the sequences depends on the implementation of equal and randomCover. Yes, a case like this obviously creates complications. But I don't think subtleties like this should prevent a user from instantiating one RNG instance and using it with multiple consumers. The default case (where no RNG instance is passed) already employs a common RNG instance between different consumers; I'd rather have consistency of behaviour whether an RNG is explicitly provided or not. Of course, we can advise associating different RNG instances with different consumers (or making sure that a consumer does its work before associating an RNG with a new consumer), but that's different from compelling the user to follow this pattern. Note also that one-RNG-per-consumer really doesn't scale to e.g. a simulation where you are generating thousands or millions of random samples. The risk of the different RNG seeds generating correlated sequences seems greater than the risks associated with using one RNG underlying all sample instances. Also we'd set a bad precedent by making one of std's ranges a ref type. Ref ranges have a lot of subtleties and aren't that well tested with std.algorithm. I agree there are a lot of subtleties, but my feeling is that we need to embrace and explore those in order to identify what the best way forward is for RNGs. --
Discounted hotel rates for DConf 2015
DConf 2015 registration is OPEN! Hampton Inn offers a special hotel rate for DConf 2015 attendees. Just click through the link to it to get it: http://dconf.org/2015/venue.html. -- Andrei
Re: Deadcode: A code editor in D
On Sunday, 8 March 2015 at 20:33:44 UTC, Kingsley wrote: On Monday, 19 January 2015 at 20:41:11 UTC, Rikki Cattermole wrote: On 20/01/2015 1:48 a.m., Jonas Drewsen wrote: On Sunday, 18 January 2015 at 22:00:51 UTC, Piotrek wrote: On Friday, 16 January 2015 at 21:19:08 UTC, Jonas Drewsen wrote: I have been working on an editor written in D for use with D for some time now and have made a blog post about it. Any feedback or suggestions are welcome. http://deadcodedev.steamwinter.com Thanks Jonas Hi, This is an impressive work. I's really nice to see a presentation of how much help can be provided from the D editor and existing language labiaries. I have several questions as well: 1. Was the libdparser integrated with extension system or is it embedded in the core? Done with the extension system. 2. What are the dependencies? sdl2, opengl, freetype, libdparse (if you want the extension for D semantic) I am keeping an eye on some of the native D input/window libraries that is being worked on in the hope of being able to replace the SDL2 dependency. Please file any enhancement requests for any Devisualization projects you need. It would help me know what is needed of them more. 3. How hard it would be to change the feellook of the gui as it is in conventional editors (Visual, MonoDeveop, GtCreator, Eclipse). I mean menus, buttons, views etc? Would require some more views/controls to be created. The styling is done through CSS sheets. A common subset of CSS keys are supported but maybe a few more would be needed. What is the purpose of the widgets in deadcode Up to your imagination! Personally I will probably use them to integrate 3rd party tools or create small helpers in my day to day work that are currently small bash/bat scripts. Using D for scripting this way would be very nice imho. Of course the editor itself can (and does) make use of such widgets to show misc. info about you project state. /Jonas
Re: moving from c++ to D is easy?
On 03/12/2015 01:19 PM, Namespace wrote:
On Thursday, 12 March 2015 at 18:57:51 UTC, Ali Çehreli wrote:
On 03/12/2015 06:01 AM, ayush wrote:
Is D a lot like c++ ?
I came to D from C++. I remember the following being notable
differences:
- In D, classes have reference semantics. I quickly realized that this
is not an issue because so many of my C++ types were
hand-reference-typified :p by this idiom, almost everywhere:
class C { /* ... */ };
typedef boost::shared_ptrC CPtr;
void foo(CPtr c);
This is a common mistake. In 99 percent of cases you want to use a
std::unique_ptr.
Agreed. Here is an excerpt from a comment from one of our header files:
We could not use boost::unique_ptr because the version of the Boost
library that we currently use does not include it.
std::shared_ptr is rarely common and often an indication of an
error in design. In general, there is exactly one owner only.
Of course. We had definitions like the following as well, where the C
objects are stored in:
typedef vectorCPtr MyCs;
But I think you know that already. :)
I think so. :) Maybe we should pass weak_ptrs around instead of
shared_ptr. Anyway... That's old code and this is a D newsgroup.
Ali
dmd 2.066.1 cannot build phobos 2.066.1
I wonder how this could have happened. Here's what I did: git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/dmd.git dmd-2.066.1 git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/druntime.git druntime-2.066.1 git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/phobos.git phobos-2.066.1 After this I had three nice directories. Then I built dmd, it worked. Then I built druntime making sure I pass DMD=../dmd-2.066.1/src/dmd in make's command line. That worked, too. When I built phobos I got: Error: unrecognized switch '-conf=' How did it happen that the -conf= flag is required by phobos 2.066.1 yet was not implemented in the same version of dmd? Thanks, Andrei
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 21:41:07 UTC, Ali Çehreli wrote:
On 03/12/2015 01:19 PM, Namespace wrote:
On Thursday, 12 March 2015 at 18:57:51 UTC, Ali Çehreli wrote:
On 03/12/2015 06:01 AM, ayush wrote:
Is D a lot like c++ ?
I came to D from C++. I remember the following being notable
differences:
- In D, classes have reference semantics. I quickly realized
that this
is not an issue because so many of my C++ types were
hand-reference-typified :p by this idiom, almost everywhere:
class C { /* ... */ };
typedef boost::shared_ptrC CPtr;
void foo(CPtr c);
This is a common mistake. In 99 percent of cases you want to
use a
std::unique_ptr.
Agreed. Here is an excerpt from a comment from one of our
header files:
We could not use boost::unique_ptr because the version of the
Boost library that we currently use does not include it.
std::shared_ptr is rarely common and often an indication of an
error in design. In general, there is exactly one owner only.
Of course. We had definitions like the following as well, where
the C objects are stored in:
typedef vectorCPtr MyCs;
But I think you know that already. :)
I think so. :) Maybe we should pass weak_ptrs around instead of
shared_ptr.
You could also pass raw pointers around. Since they have no owner
it's fine. Or references.
Anyway... That's old code and this is a D newsgroup.
Ali
Agreed.
Re: Post increment and decrement
On Wednesday, 11 March 2015 at 17:23:15 UTC, welkam wrote: Observation Nr. 1 People prefer to write var++ instead of ++var. The root of your reasoning stems from this observation, which I argue is wrong. The recommendation has always been to chose ++var, unless you have a reason to chose var++. Because of all this why not make only one increment/decrement operator and have post increment/decrement to be called by template name, because it is a template? Or, instead of creating a new semantic, simply use the existing one. It really isn't that complicated.
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #21 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Ali Cehreli from comment #18) I think this boils down to whether an enum's conversion to its base type is an implicit cast (an rvalue), versus the enum itself (an lvalue). (Steven says it's the latter.) Since this change has broken code, the question to answer is, does this break code that should be broken? Final switch does not show a case of invalid code that is now fixed by this change, and I haven't seen any other challenges of breakage. So if it doesn't break anything worth breaking, why are we doing it? To me, this doesn't break any code that is invalid. Regardless of whether it's philosophically correct or not, avoiding breaking only valid code should take precedence. That is why I said I understand the reason and somewhat agree with the reason, but I still think it should be reverted. --
