Re: Release Candidate D 2.067.0-rc1
On 18.03.2015 01:46, Martin Nowak wrote: On 03/18/2015 01:13 AM, Manu via Digitalmars-d-announce wrote: Yes. Has for a while. We're really hanging out for the 32bit COFF libs to ship with DMD. Well, someone should add a build target to https://github.com/D-Programming-Language/phobos/blob/master/win32.mak. How is the phobos.lib called to avoid conflicts? It's a bit late to come up with this, will see if I can find enough time for this. The COFF32 lib is built through win64.mak. This is an excerpt from my build script to create lib32\phobos32mscoff.lib: set dm_make=c:\l\dmc\bin\make set vs=vs12 set vcdir=c:\l\%vs%\vc set cl32=%vcdir%/bin/cl.exe set ar32=%vcdir%/bin/lib.exe set MSLINK=%vcdir%\bin\link.exe set lib32coff=m:\s\d\rainers\lib32;%vcdir%\vc\lib;%sdkdir%\lib set sdkdir=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A set LINKCMD=%MSLINK% set LIB=%LIB32COFF% set ARGS=DMD=%DMD% MAKE=%dm_make% CC=\%cl32%\ AR=\%ar32%\ VCDIR=%vcdir% SDKDIR=%sdkdir% cd druntime %dm_make% -f win64.mak MODEL=32mscoff %ARGS% target if errorlevel 1 goto xit cd .. cd phobos %dm_make% -f win64.mak MODEL=32mscoff %ARGS% LIB=..\lib32\phobos32mscoff.lib if errorlevel 1 goto xit cd ..
Re: A few notes on choosing between Go and D for a quick project
On Friday, 20 March 2015 at 00:30:25 UTC, deadalnix wrote: On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote: Its the emperor's new clothes. Type inference is useful. Deal with it. I like type inference. I dont like voldomort types, the cost/benefit is fail.
[Issue 14310] [REG2.067a] InvalidMemoryOperationError in std.stdio.File.byLine
https://issues.dlang.org/show_bug.cgi?id=14310 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Martin Krejcirik m...@krej.cz --- *** This issue has been marked as a duplicate of issue 13856 *** --
[Issue 13856] std.stdio.readln stomps arrays
https://issues.dlang.org/show_bug.cgi?id=13856 Martin Krejcirik m...@krej.cz changed: What|Removed |Added CC||m...@krej.cz --- Comment #4 from Martin Krejcirik m...@krej.cz --- *** Issue 14310 has been marked as a duplicate of this issue. *** --
Re: 2nd London D Programmers Meetup - Robot Tank Battle Tournament
Just a reminder - this is happening next Tuesday - please come along if you are in London and fancy a bit of D programming fun. On Thursday, 26 February 2015 at 15:56:13 UTC, Kingsley wrote: Hi, The second London D Programmers Meetup is now officially scheduled for Tuesday 24th March. As usual it's sponsored by Skills Matter and will be at their awesome training facility. This meetup will be all about an awesome robot battle tournament. Come along and bring your laptop and be prepared to build a tank robot that can destroy the opposition in our custom made 2D battle arena. I've used the very excellent DSFML library for the graphics so it's looks nice :) If we come up with a super tank we may start challenging other D meetup groups to a robot tank battle royale extravaganza!! So watch out!!! Here are the details - spread the word: http://www.meetup.com/London-D-Programmers/events/220610394/ thanks --Kingsley
Re: A few notes on choosing between Go and D for a quick project
On Thursday, 19 March 2015 at 23:02:07 UTC, w0rp wrote: On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote: On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote: On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote: On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote: On 17/03/2015 10:31, Almighty Bob wrote: It's far more useful for csvReader to return a type I know and can use than it is to obscure the return type for the sake of some philosophical ideal of increasing encapsulation. Part of the art of API design is to hide implementation where it's not necessarily needed. Designers might err on the side of hiding things, because how you expose something is important as it has to be maintained indefinitely. If they expose everything then the internals can never be redesigned for better performance, etc. They don't increase encapsulation. The public members of a voldomort type are still public, you still have to code to the API of the return type whether it's a regular or voldomort type. You can keep as much private or public in either case as you like. All they do take the typename out of circulation, they make life harder for the user. There's no benefit. None. But at least the library author can stroke his chin a feel smug that there's one less type in the modules' namespace. Totally missing the point. The crux of the matter is this: changing a voldemort type (assuming the public semantics are the same) is not a breaking API change, because no-one else's code ever names it. Seriously? You cant have a public API and private implementation with a regular type? That's something specific to voldomort types? Ask yourself what exactly do voldomort types enable you to hide that cant be hidden with a regular type? Just one thing. Their name. As you said no one else can ever name the type. That is no benefit to me the user. No-one has been able to even describe a benefit. Walters article on Dr Dobbs doesn't describe a benefit. It increases encapsulation you all squawk. No it doesn't. The private bits are still private, the public bits are still public. All it does is complicate the user side. Its the emperor's new clothes. It's not possible to construct a voldemort type outside of the function where it was declared, and you can't know what that type is, just what the API is. You can force type deduction so the type returned can be changed without breaking code, so long as the API is the same. That's how it increases encapsulation. voldemort types sort of feel like a hack to work around the lack of real compile-time interfaces(concepts,) the same thing IMO currently plaguing template constraints and honestly causes a lot of compiler errors to be confusing. I believe a few major patches in phobos were related to removing constraints and rewriting them as static asserts for better error handling. see: http://forum.dlang.org/thread/jronroxajqkrqitxw...@forum.dlang.org
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On 3/19/2015 2:43 AM, deadalnix wrote:
Here is what will pass review :
Presumably the reviewers will have some common sense and taste.
class User {
/**
* Accessor to get the id of the user.
*
* @return : the id of the user
*/
uint getUserID() { ... }
/**
* Accessor to get the name of the user.
*
* @return : the name of the user
*/
string getName() { ... }
Accessor functions that merely return a field variable are bull anyway.
This is very popular in enterprise code, and there is a reason everybody hates
it.
I think the problem is more with the desire to have noise wrappers like:
int foo;
int getFoo() { return foo; }
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Thursday, 19 March 2015 at 22:05:51 UTC, Walter Bright wrote: On 3/19/2015 2:40 AM, deadalnix wrote: And I'm sorry, but if most function require DDoc, your code probably sucks quite badly and some renaming should be considered. I've never seen any code that self-documented why. Indeed, that is why comment are useful. If all your method require a why, you probably should consider refactoring instead of adding comments all over the place.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Thursday, 19 March 2015 at 22:14:02 UTC, Jeremy Powers wrote: As for the documentation - yeah, don't write docs that duplicate what is there in the method signature. I'm not a big fan of that. It's one of those slippery slope things. The documentation should be written for a new D user, but the person that writes the method has a very different view of what constitutes duplication. There's too much of that attitude in the existing documentation. If it really is duplication, that should be a decision made by someone else, preferably someone that doesn't know much about the library.
[Issue 14310] [REG2.067a] InvalidMemoryOperationError in std.stdio.File.byLine
https://issues.dlang.org/show_bug.cgi?id=14310 --- Comment #3 from Martin Krejcirik m...@krej.cz --- It depend(In reply to Vladimir Panteleev from comment #2) I can't reproduce this on Windows. Looks like a duplicate of issue 13856 and particularly issue 14005 except for that this one is a regression? I have tried several older dmd versions and none crash, but it may be a coincidence. Also depends on input. --
Re: A few notes on choosing between Go and D for a quick project
On Thursday, 19 March 2015 at 23:02:07 UTC, w0rp wrote: No it doesn't. The private bits are still private, the public bits are still public. All it does is complicate the user side. Its the emperor's new clothes. It's not possible to construct a voldemort type outside of the function where it was declared, and you can't know what that type is, just what the API is. You can force type deduction so the type returned can be changed without breaking code, so long as the API is the same. That's how it increases encapsulation. Ok I can see the benefit of having a return type that can only be constructed by the function returning it. ***In some cases*** But being able to change the return type doesnt actualy increase encapsulation. you still have to return something with the same public API. Only now you have ***less*** guarantees over what your getting than you did before. Could be an array could be a linked list. Who knows? Maybe I'm a bit long in the tooth but for something like cvsReader I want an array of records, there's isnt anything else that would ever make any sense. So the idea that I now how to jump through hoops to keep hold of whatever that function returns, just in case some divvy might want change what kind of structure it returns one day, is frankly absurd.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Thursday, March 19, 2015 22:27:33 deadalnix via Digitalmars-d wrote: On Thursday, 19 March 2015 at 22:05:51 UTC, Walter Bright wrote: On 3/19/2015 2:40 AM, deadalnix wrote: And I'm sorry, but if most function require DDoc, your code probably sucks quite badly and some renaming should be considered. I've never seen any code that self-documented why. Indeed, that is why comment are useful. If all your method require a why, you probably should consider refactoring instead of adding comments all over the place. There are plenty of functions that require documentation - especially when they're more powerful. This is especially true when talking about free functions rather than member functions. And having documentation for stuff like what exceptions a function throws can be quite valuable even if the function's primary functionality doesn't need much explanation. I think that it's safe to say that most functions need at least minimal documentation. However, I completely agree that there are a number of functions (especially property functions and other types of simple accessors) which don't need a detailed explanation, and having both a main comment on them and a return and/or param comment on them is redundant and just noise. So, I fully expect that requiring a return comment or a comment per param will quickly result in documentation comments being overly verbose. That being said, most functions do need some sort of documentation, and there are definitely some functions that will need both the return and param comments (especially the sort of stuff that goes in std.algorithm). - Jonathan M Davis
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Thursday, 19 March 2015 at 23:45:03 UTC, bachmeier wrote: On Thursday, 19 March 2015 at 22:14:02 UTC, Jeremy Powers wrote: As for the documentation - yeah, don't write docs that duplicate what is there in the method signature. I'm not a big fan of that. It's one of those slippery slope things. The documentation should be written for a new D user, but the person that writes the method has a very different view of what constitutes duplication. There's too much of that attitude in the existing documentation. If it really is duplication, that should be a decision made by someone else, preferably someone that doesn't know much about the library. Ok let's be clear. This kind of overpedantic commenting is a good thing in a public, widespread API, like phobos's. Especially since you can generate documentation from it, this is going to be googled for. That is very bad idea in the general case.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Thursday, 19 March 2015 at 22:04:01 UTC, Walter Bright wrote:
On 3/19/2015 2:43 AM, deadalnix wrote:
Here is what will pass review :
Presumably the reviewers will have some common sense and taste.
class User {
/**
* Accessor to get the id of the user.
*
* @return : the id of the user
*/
uint getUserID() { ... }
/**
* Accessor to get the name of the user.
*
* @return : the name of the user
*/
string getName() { ... }
Accessor functions that merely return a field variable are bull
anyway.
That is completely missing the point. If that is not clear enough
:
/**
* This class is the in program represention for a user.
* It contains various user related data, and provides
* various facilities for common user related operations.
*/
class User {
/**
* Accessor to get the id of the user.
*
* @return : the id of the user
*/
uint getUserID() { ... }
/**
* Accessor to get the name of the user.
*
* @return : the name of the user
*/
string getName() { ... }
/**
* This method will subscribe the user to the Subscribable
* passed as argument.
*
* S: The Subscribable the user is going to subsribe to.
*
* @throw CantSubscribeException : In case the subscription
fails,
* an exception is thrown.
*/
void subscribeUserTo(Subsribable S) { ... }
/**
* Send a message to the user. This can be used for
commercial offers
* or general information about the system.
*
* msg: The message you wish to send to the user.
*
* @throw MessageNotSentException : If for some reason, the
message isn't
* sent properly, a MessageNotSentException is sent.
*/
sendMessage(string msg) { ... }
// And so on like forever...
}
Mandatory comment block is how you end up with overbloated code
like this where it is explained to you 3 times in the comment
what the method's name already tells you. And that is only the
begging because starting from this point, overtime, comment
become more and more out of date to ends up looking like an
surrealistic form of humor.
[Issue 14310] [REG2.067a] InvalidMemoryOperationError in std.stdio.File.byLine
https://issues.dlang.org/show_bug.cgi?id=14310 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- I can't reproduce this on Windows. Looks like a duplicate of issue 13856 and particularly issue 14005 except for that this one is a regression? --
[Issue 14310] [REG2.067a] InvalidMemoryOperationError in std.stdio.File.byLine
https://issues.dlang.org/show_bug.cgi?id=14310 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Component|druntime|Phobos --
Re: A few notes on choosing between Go and D for a quick project
On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote: Its the emperor's new clothes. Type inference is useful. Deal with it.
Re: The next iteration of scope
On Wednesday, 18 March 2015 at 13:01:50 UTC, Oren Tirosh wrote: The scope storage class is a two way contract. The function promises not to escape the reference. The caller promises to ensure the storage that the reference is pointing to will remain valid for the duration of the function call. In some cases, the caller code may need to take active steps to ensure that, like keeping an otherwise temporary reference alive to prevent it from being deallocated. But what if the pointer is null? Can this be considered to fulfill the caller's part of the deal? Yes, the old @notnull debate again. For me, @safe by default and scope by default also suggests @notnull by default for scope references. Sorry if this opens up directions you don't want to think about at the moment... Don't be sorry, I agree with you 100%, and you stated it more clearly than i could have.
[Issue 14301] [2.067-rc1] Private symbols of module conflicts with public from another
https://issues.dlang.org/show_bug.cgi?id=14301 Ivan Kazmenko ga...@mail.ru changed: What|Removed |Added CC||ga...@mail.ru --- Comment #11 from Ivan Kazmenko ga...@mail.ru --- Meanwhile, and a bit off topic, is there a convenient tool to do just that: diagnose missing imports? I asked on D.learn but received no response so far: http://forum.dlang.org/thread/yxzowmbhrcpkivkla...@forum.dlang.org --
Re: Is it possible to call D functions from C++
On Thursday, 19 March 2015 at 08:38:45 UTC, Kagamin wrote: Hmm... I read it as it shall have the return type of int, but if not, then it's implementation-defined. In that case, I refer you to https://www.ietf.org/rfc/rfc2119.txt
Re: Is it possible to call D functions from C++
On Thursday, 19 March 2015 at 07:42:48 UTC, Kagamin wrote: On Wednesday, 18 March 2015 at 15:54:04 UTC, krzaq wrote: Oh, right. I'm sorry, I assumed void main() means D, since it's not legit C++. C++ allows implementation-defined return type of main. I'm afraid that you've mistaken C++ for C. The C++ standard quite clearly says: An implementation shall not predefine the main function. This function shall not be overloaded. **It shall have a return type of type int**, but otherwise its type is implementation-defined.
Re: Is it possible to call D functions from C++
On Thursday, 19 March 2015 at 08:32:10 UTC, krzaq wrote: but otherwise its type is implementation-defined. This.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On 3/18/2015 3:05 PM, Brian Schott wrote: On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. D-Scanner has had this feature for a while. Here's the list for Phobos: http://dpaste.dzfl.pl/7d018aad2b10 Thank you!
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Wednesday, 18 March 2015 at 19:43:47 UTC, Andrei Alexandrescu
wrote:
On 3/18/15 12:28 PM, Jacob Carlborg wrote:
On 2015-03-18 19:48, Walter Bright wrote:
I'm fed up with this problem. It is actively hurting us every
day.
https://issues.dlang.org/show_bug.cgi?id=14307
Anyone want to take this on? Shouldn't be particularly
difficult.
I'm not so sure about this. I think there's a big chance that
users will
just add an empty documentation comment to silence the error.
That won't pass review. -- Andrei
Here is what will pass review :
class User {
/**
* Accessor to get the id of the user.
*
* @return : the id of the user
*/
uint getUserID() { ... }
/**
* Accessor to get the name of the user.
*
* @return : the name of the user
*/
string getName() { ... }
// ...
}
This is very popular in enterprise code, and there is a reason
everybody hates it.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Wednesday, 18 March 2015 at 19:28:44 UTC, Jacob Carlborg wrote: On 2015-03-18 19:48, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. I'm not so sure about this. I think there's a big chance that users will just add an empty documentation comment to silence the error. It is not a good chance, it is 100% guaranteed. And I'm sorry, but if most function require DDoc, your code probably sucks quite badly and some renaming should be considered.
[Issue 12744] auto ref crashes DMD on ASSERT
https://issues.dlang.org/show_bug.cgi?id=12744
--- Comment #1 from Tomer Filiba tomerfil...@gmail.com ---
happens on dmd 2.66.1 as well:
void f(int x, out int y) {
}
void g(ref ParameterTypeTuple!f params) {
f(params);
}
dmd: mtype.c:9529: void Parameter::toDecoBuffer(OutBuffer*): Assertion `0'
failed.
[1]14388 abort (core dumped) dmd source/main.d
--
Re: Is it possible to call D functions from C++
On Thursday, 19 March 2015 at 08:33:07 UTC, Kagamin wrote: On Thursday, 19 March 2015 at 08:32:10 UTC, krzaq wrote: but otherwise its type is implementation-defined. This. I'm not sure what you're failing to understand here. It **shall* have the return type of int. The rest (as in: parameter list) is implementation defined.
Re: Is it possible to call D functions from C++
Hmm... I read it as it shall have the return type of int, but if not, then it's implementation-defined.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
Indeed, dfmt and/or dfix can handle that just fine. They can also try to differentiate between public and private types.
Re: Mental models of programs [was A few notes on choosing between Go and D for a quick project]
On Thursday, 19 March 2015 at 08:17:42 UTC, Russel Winder wrote: On Wed, 2015-03-18 at 13:27 +, CraigDillabaugh via Digitalmars-d wrote: […] There is quite possibly something too that, and as I imagine with more functional experience it will come easier to me. However, I still think imperative code is generally easier to reason about because (usually) each line of code is performing a single task, whereas with functional coding the goal seems to be to cram as many operations as possible into a single line (I know that isn't the real reason, it just seems that way at times). Trying to 'unroll' everything in your head can be a challenge. Throw in a lambda function or two with the mess of braces/symbols and then you have a real puzzler. Each imperative statement may (or may not) be easier to understand, but the problem is putting them together in combination. The issue here is creating chunks on which you put a label for reasoning with. Everything is about the abstractions you reason with. A person who is familiar only with C-style programming (as per OPs code fragment) has built up various abstractions, but they are nonetheless at a very low level and so many have to be combined. Someone who has learned the internal iteration abstraction and higher- order functions is actually working at a higher level of abstraction and generally needs to combine fewer things to achieve the overall goal. Cramming operations on a line is nothing to do with the abstractions, that is to do with some people playing code golf. If you find yourself reading declarative style code and having to unroll to imperative equivalent to understand, it just means you have not yet internalized the declarative abstraction yet into your mental model and personal programming language. There is a lot of work on all this sort of stuff in the psychology of programming research literature. We can speculate all we like here based on personal experience and anecdotal evidence, they do experiments and have real data. Of course if you see any experimenting on first and second year undergraduates of computer science, ignore the results. I am talking about those who experiment with practicing programmers, people with real experience and expertise. I just saw a talk of one of those studies. One of the points was that curly braces languages lead to more bugs than languages that follow the Algol more verbose style. CodeMesh 2014 - Andreas Stefik - The Programming Language Wars https://www.youtube.com/watch?v=mDZ-QSLQIB8 Quite interesting when one mixes psychology research with language features, backed by validated research data. -- Paulo
[Issue 14308] New: Compiling druntime with -release breaks range exceptions
https://issues.dlang.org/show_bug.cgi?id=14308 Issue ID: 14308 Summary: Compiling druntime with -release breaks range exceptions Product: D Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: temta...@gmail.com Hi ! When i compile druntime with -release flag and then builds an app using it, following code crashes: ubyte[3] aa; int n = 4; aa[n] = 5; If i compile it without -release, then all is OK. I don't know how this flag affects range exceptions in applications. Also i don't know is it a bug or as designed. But i think that druntime with -release flag should work. --
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Wednesday, 18 March 2015 at 22:05:18 UTC, Brian Schott wrote: On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. D-Scanner has had this feature for a while. Here's the list for Phobos: http://dpaste.dzfl.pl/7d018aad2b10 That's a very interesting list. Things like this: std/regex/package.d(320:13)[warn]: Public declaration 'regexImpl' is undocumented. appear to be public only as an workaround (necessary for mixins or something). Perhaps such things shouldn't actually be documented. But we don't have a mechanism for that.
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 15:03:37 UTC, bearophile wrote: Andrei Alexandrescu: That's a rather random collection - strict seems to be D without the stuff bearophile dislikes. -- Andrei I am OK with that definition. Is that your best critique to those suggestions? :-) Bye, bearophile :) I'd use that.
Re: Mental models of programs [was A few notes on choosing between Go and D for a quick project]
On Wed, 2015-03-18 at 13:27 +, CraigDillabaugh via Digitalmars-d wrote: […] There is quite possibly something too that, and as I imagine with more functional experience it will come easier to me. However, I still think imperative code is generally easier to reason about because (usually) each line of code is performing a single task, whereas with functional coding the goal seems to be to cram as many operations as possible into a single line (I know that isn't the real reason, it just seems that way at times). Trying to 'unroll' everything in your head can be a challenge. Throw in a lambda function or two with the mess of braces/symbols and then you have a real puzzler. Each imperative statement may (or may not) be easier to understand, but the problem is putting them together in combination. The issue here is creating chunks on which you put a label for reasoning with. Everything is about the abstractions you reason with. A person who is familiar only with C-style programming (as per OPs code fragment) has built up various abstractions, but they are nonetheless at a very low level and so many have to be combined. Someone who has learned the internal iteration abstraction and higher- order functions is actually working at a higher level of abstraction and generally needs to combine fewer things to achieve the overall goal. Cramming operations on a line is nothing to do with the abstractions, that is to do with some people playing code golf. If you find yourself reading declarative style code and having to unroll to imperative equivalent to understand, it just means you have not yet internalized the declarative abstraction yet into your mental model and personal programming language. There is a lot of work on all this sort of stuff in the psychology of programming research literature. We can speculate all we like here based on personal experience and anecdotal evidence, they do experiments and have real data. Of course if you see any experimenting on first and second year undergraduates of computer science, ignore the results. I am talking about those who experiment with practicing programmers, people with real experience and expertise. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: A few notes on choosing between Go and D for a quick project
On 3/18/2015 4:41 PM, Walter Bright wrote:
#include stdbool.h
#include stdio.h
typedef long T;
bool find(T *array, size_t dim, T t) {
int i;
for (i = 0; i = dim; i++);
{
int v = array[i];
if (v == t)
return true;
}
}
Bugs:
1. i should be size_t
2. = should be
3. extraneous ;
4. v should be type T
5. missing return
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On 2015-03-18 20:43, Andrei Alexandrescu wrote: That won't pass review. -- Andrei If that's the case, how did an undocumented symbol pass review in the first place? -- /Jacob Carlborg
Re: Phobos Documentation - call to action
On 3/18/2015 8:17 PM, H. S. Teoh via Digitalmars-d wrote: I have pathetically little experience with most of phobos. I most certainly hold the record for amount of passion associated with the D language versus number of lines actually coded in it. That said, it can't be that hard to figure out what the parameters are and what they return. If you give me a specific module, I'll start making pull requests for it. What about just picking a random Phobos module from dlang.org and scrolling through to find an undocumented (or poorly-documented) function? There are sadly a *lot* of such modules in Phobos; it won't be long before you find something. True, I find them everywhere I look.
[Issue 14309] New: The difference between Microsoft's GUID and std.uuid.UUID
https://issues.dlang.org/show_bug.cgi?id=14309
Issue ID: 14309
Summary: The difference between Microsoft's GUID and
std.uuid.UUID
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: zan77...@nifty.com
In following code, I think it is hoped that `id` is the same as
`IID_IClassFactory`, why does this happen?
--
import std.stdio, core.sys.windows.com, std.uuid;
pragma(lib, uuid); // for IID_IClassFactory
void main()
{
// IID of IClassFactory
//
https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.ole.interop.iclassfactory.aspx
immutable id = UUID(0001---C000-0046);
static assert(UUID.sizeof == 16);
static assert(IID_IClassFactory.sizeof == 16);
// 01 00 00 00 00 00 00 00 C0 00 00 00 00 00 00 46
writefln(IID_IClassFactory: %(%02X %),
*cast(ubyte[16]*)IID_IClassFactory);
// 00 00 00 01 00 00 00 00 C0 00 00 00 00 00 00 46
writefln(std.uuid.UUID: %(%02X %), id.data);
assert(id.data == *cast(ubyte[16]*)IID_IClassFactory); // failure
assert(UUID(0100---C000-0046).data
== *cast(ubyte[16]*)IID_IClassFactory); // success
}
--
Re: Phobos Documentation - call to action
Two low-hanging fruits are to document bug https://issues.dlang.org/show_bug.cgi?id=2742 (phobos) and https://issues.dlang.org/show_bug.cgi?id=1983 (language) Only two lines in docs.
Re: Is it possible to call D functions from C++
On Wednesday, 18 March 2015 at 15:54:04 UTC, krzaq wrote: Oh, right. I'm sorry, I assumed void main() means D, since it's not legit C++. C++ allows implementation-defined return type of main.
[Issue 14307] Ddoc: issue error on all functions that are missing ddoc sections
https://issues.dlang.org/show_bug.cgi?id=14307 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #3 from Jacob Carlborg d...@me.com --- If you implement this, it should apply for protected symbols as well. --
Re: A few notes on choosing between Go and D for a quick project
On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote: On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote: On 17/03/2015 10:31, Almighty Bob wrote: It's far more useful for csvReader to return a type I know and can use than it is to obscure the return type for the sake of some philosophical ideal of increasing encapsulation. Part of the art of API design is to hide implementation where it's not necessarily needed. Designers might err on the side of hiding things, because how you expose something is important as it has to be maintained indefinitely. If they expose everything then the internals can never be redesigned for better performance, etc. They don't increase encapsulation. The public members of a voldomort type are still public, you still have to code to the API of the return type whether it's a regular or voldomort type. You can keep as much private or public in either case as you like. All they do take the typename out of circulation, they make life harder for the user. There's no benefit. None. But at least the library author can stroke his chin a feel smug that there's one less type in the modules' namespace. Totally missing the point. The crux of the matter is this: changing a voldemort type (assuming the public semantics are the same) is not a breaking API change, because no-one else's code ever names it. Admittedly this is sort-of true for any function that returns auto and doesn't document its return type, but that is by convention (the type is always readable in the relevant .d or .di file) whereas using a voldemort type enforces it. Note that if you really want a name to use in your code: alias IotaFloat = typeof(iota(0f, 2f, 1f));
Re: refactoring issues
On Tuesday, 17 March 2015 at 15:11:02 UTC, Ivan Kazmenko wrote: For the former problem, is there a tool which jumps out and tells you use Phobos without importing things properly, or suggests a Phobos import by the name of the stuff. I did make something simple for myself, but it doesn't work in the more complicated cases you mentioned (contracts failing because of missing imports). http://dump.thecybershadow.net/e91be687ebaeb0171d830025adf82848/autofix.gif I could post the code but the editor integration part is pretty specific to my editor.
New Russian doc in wiki.dlang.org
My friend Ruslan wrote pretty big doc for D-noobs about using D. It's pretty much inspired by Ali book (thanks Ali!) but not so big. I hope that doc will help to newcomers to start programming. Any feed back are welcome! http://wiki.dlang.org/Reading_the_documentation_%28in_Russian%29 P.S. the work on dlang.ru is not stop. We done huge refactoring of engine, but now our programmer again have not free time. But I keep hand on pulse.
[Issue 10664] Win64: exception handling does not work with COMDAT folding
https://issues.dlang.org/show_bug.cgi?id=10664 Temtaime temta...@gmail.com changed: What|Removed |Added CC||temta...@gmail.com --- Comment #1 from Temtaime temta...@gmail.com --- Is there any fix not workaround ? It increases .exe's size significantly. --
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. I would like this but issue warnings not errors. I like every function to be documented. Also don't make the Example mandatory because people tend to use unittest blocks as the examples.
Re: Is it possible to call D functions from C++
On Wednesday, 18 March 2015 at 15:52:33 UTC, Benjamin Thaut wrote: On Wednesday, 18 March 2015 at 14:50:21 UTC, Namal wrote: Can you help me show how to compile and link it together please, thank you. What platform are you on, windows, linux, osx? What c++ compiler do you use? msvc, clang, gcc? Linux, gcc and dmd. In my case c++ refuses to compile if main is void.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. This is going to be a lot of fun as soon as tons of currently private functions in phobos are public due to the usage of export.
Re: DDT 0.11.0 released
On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote: On Wednesday, 18 March 2015 at 21:49:17 UTC, Bruno Medeiros wrote: Why is it insufficient? You don't have to use DUB to the exclusion of everything else. Isn't the use of the preGenerateCommands (http://code.dlang.org/package-format#build-settings) enough to call these other build systems you use? You're joking, right? The only sensible way to use multiple languages in the same project is to use the same build system for them. Anything else is way too fragile and hackish. Arbitrary, contrived example (though not entirely unrealistic): * a C(++) executable needs a static D library * Said D library in turn uses a C(++) library * All three of these are built as components of the same project So now I need a weird tangled mess of build systems calling each other back and forth. Dub really doesn't pull its weight here. I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much.
Re: A few notes on choosing between Go and D for a quick project
On Wednesday, 18 March 2015 at 01:52:00 UTC, Laeeth Isharc wrote: On Tuesday, 17 March 2015 at 21:00:11 UTC, bachmeier wrote: On Tuesday, 17 March 2015 at 19:00:06 UTC, jmh530 wrote: In addition, further development of the ability to call D from R or Python* or Julia (or vice-versa) would also be a positive. What do you have in mind? I no longer work much with Python so my knowledge is limited, but calling D from R or Julia should be no different from calling C from those languages, as you normally compile your C code into a shared library anyway. I've done the R-D thing many times and in the process have worked with a big chunk of the R API. Things like allocating R data structures from a D function, adding assertions to your D code to allow for an easy exit when things don't work out, and calling functions in the R math library, among other things, are not difficult. (I wonder how well cython works with interfacing with D via the C++ interface, because that way you could extend python with D classes and have them be faster than going through PyD). This is a good idea. dtoh could speed up this workflow, see https://github.com/adamdruppe/dtoh/blob/master/dtoh.d and http://forum.dlang.org/post/uyuwdptkpukshxzyg...@forum.dlang.org
Re: Formal review of dtoh
On Tuesday, 25 March 2014 at 20:38:40 UTC, Jacob Carlborg wrote: This is the formal review of Adam D. Ruppe's tool dtoh for inclusion in the tools repository [1]. Dtoh is a tool used to convert D modules to C/C++ headers. This allows to use D libraries in C/C++ code. This review might be a bit special since this is the first time a tool is reviewed. Since this is a review of a tool the standard guidelines for reviewing might not apply. For example, we might require that the tool should have documentation like DMD does [3]. There's already a pull request with some discussion [2]. Note, the pull request has already been merged but we would like to do a review anyway. Code: https://github.com/adamdruppe/tools/blob/dtoh/dtoh.d The review will last for two weeks, ending on April 8. [1] https://github.com/D-Programming-Language/tools [2] https://github.com/D-Programming-Language/tools/pull/39 [3] http://dlang.org/dmd-osx.html Adam, have you considered sprucing this up for review? There are so many things out there with c++ extension architectures that, with this tool in a solid state and more widely distributed, could trivially take D extensions too.
[Issue 14133] [REG 2.067] struct ctor init compiles very slow and produces excessive amounts of code
https://issues.dlang.org/show_bug.cgi?id=14133 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||etci...@gmail.com --- Comment #3 from Martin Nowak c...@dawg.eu --- Reported by Etienne Cimon. https://github.com/rejectedsoftware/vibe.d/issues/1016#issuecomment-83735025 --
[Issue 14301] [2.067-rc1] Private symbols of module conflicts with public from another
https://issues.dlang.org/show_bug.cgi?id=14301 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull --- Comment #15 from Martin Nowak c...@dawg.eu --- https://github.com/D-Programming-Language/phobos/pull/3081 --
Re: DDT 0.11.0 released
On 20 March 2015 at 01:31, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 19/03/2015 11:18, Dicebot wrote: On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote: Arbitrary, contrived example (though not entirely unrealistic): * a C(++) executable needs a static D library * Said D library in turn uses a C(++) library * All three of these are built as components of the same project So now I need a weird tangled mess of build systems calling each other back and forth. Dub really doesn't pull its weight here. I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) Indeed, I reckon in these more complex examples, you'd call DUB from make/cmake/whatever. DUB would be in charge of building the D library aspect/component of that whole project. I don't see why this would not be possible, or otherwise why it would be a tangled messed. Pushing variables, lib paths, include paths, etc around immediately comes to mind. It might force to think of your build components in a more structured/componentized way, instead of the paradigm of building on a file by file basis, the `make` way. (I've only used make though, not cmake, so dunno how much this comment applies to the later) In premake, D projects are emit as a single invocation of the compiler given all source files at once, and this works seamlessly with C/C++ projects which are done in the traditional file-by-file way. VisualD and Mono-D also perform D compilation in single step, while interoperating with C compilation in the traditional way.
[Semi OT] The programming language wars
I let this here. Very interesting and relevant to anyone here. https://www.youtube.com/watch?v=mDZ-QSLQIB8
[Issue 14300] [2.067-rc1] DList casting to base type is broken
https://issues.dlang.org/show_bug.cgi?id=14300 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull CC||c...@dawg.eu --- Comment #2 from Martin Nowak c...@dawg.eu --- https://github.com/D-Programming-Language/phobos/pull/3082 --
Re: A few notes on choosing between Go and D for a quick project
On Wednesday, 18 March 2015 at 18:48:59 UTC, bachmeier wrote: On Wednesday, 18 March 2015 at 15:13:24 UTC, jmh530 wrote: You might be able to download the zip here: https://bitbucket.org/bachmeil/dmdinline/downloads and then install from a USB disk using install_local. I ended up trying this on my home computer because it makes life much easier. The Debian file I was trying to get for libgretl-dev was a package rather than the source, I think, and I couldn't find the source or any sort of Windows version. Anyway commands like install_librtod2(gretl=usr/lib/libgretl-1.0.so, libr=usr/lib/R/lib/libR.so) don't make much sense as .so is only for linux. I tried it anyway and got an error about the cd command not being found (wasn't the error I expected, but oh well). I seem to be able to import the dmdinline library just fine. When I run compileD(foo, txt) I get Error in file(filename, r, encoding = encoding) : cannot open the connection In addition: Warning message: In file(filename, r, encoding = encoding) : cannot open file 'C:/Users/John/Documents/.rtod2/config.R': No such file or directory I don't know where the config.R file is located.
Re: DDT 0.11.0 released
On 20 March 2015 at 00:45, Trent Forkert via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) I use Vim myself, but I think people who use IDEs would like to, well, use IDEs. Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. Precisely, I was expecting a .dproject file to appear, but it didn't. I also maintain the D (and Eclipse) support for premake (like cmake), but I can't support D in Eclipse like C/C++ as it is.
[Issue 14133] [REG 2.067] struct ctor init compiles very slow and produces excessive amounts of code
https://issues.dlang.org/show_bug.cgi?id=14133
Martin Nowak c...@dawg.eu changed:
What|Removed |Added
Priority|P1 |P3
CC||c...@dawg.eu
Summary|change in struct ctor |[REG 2.067] struct ctor
|lowering generates |init compiles very slow and
|excessive init code |produces excessive amounts
||of code
Severity|normal |regression
--- Comment #1 from Martin Nowak c...@dawg.eu ---
cat bug.d CODE
struct Bug
{
size_t[16 * 1024] data;
}
void test()
{
auto b = Bug();
}
CODE
dmd -c bug
It looks like related to issue 11233, but is most likely due to the change
struct literal code, that not performs field assignment instead of copying the
init array.
--
[Issue 14304] [REG2.067a] ICE with static immutable variable CTFE
https://issues.dlang.org/show_bug.cgi?id=14304 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9a6b349c3d9a1d991d429714c00fd103048ca792 fix Issue 14304 - ICE with static immutable variable CTFE https://github.com/D-Programming-Language/dmd/commit/6d8634bf1421be51413e5ba87154f5adf4bc7e30 Reduce memory space for CTFE The prior fix for issue 14304 is simple, but it will also increase the amount of memory space for CTFE (and actually breaks Phobos unittest in Windows platform). To fix performance issue without breaking CTFE behavior: - Mark the cached value of non-mutable static variable specially, to represent read-only constant. - Prevent modifications of read-only constant. - Once a value is owned by CTFE (including cached ones), we can avoid redundant copies for that, because the expression object can be used directly during interpretation. https://github.com/D-Programming-Language/dmd/commit/06537bcd9128b948a1feb35b4fd5e3cdd55c201c Merge pull request #4503 from 9rnsr/fix14304 [REG2.067a] Issue 14304 - ICE with static immutable variable CTFE --
Re: DDT 0.11.0 released
On 19 March 2015 at 07:49, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote: I just checked out DDT, and I noticed it seems to use DUB... _ Why this marriage? I was really hoping it would be a lot more like CDT (ie, raw and flexible). In the project configuration I just see the one DUB Options box. The comprehensive suite of build options CDT presents would be much nicer. It makes no sense for DDT to use anything else than DUB. At a minimum, DDT needs a way to describe projects: the source files that are part of the project, and which other projects are dependencies of said project. Other aspects of a projects that are good to be able to describe are: which build configurations the project supports, which executables are produced (if any), etc.. Now the reason DUB is used is that it's a bad paradigm for this description mechanism to be Eclipse/DDT specific. It's unequivocally much better to be Eclipse-independent, such that other tools (not just other IDEs, but even other command-line analysis tools) can understand D projects/bundles/packages just as well as DDT. It also saved me a lot of work. If I had to develop my own format to describe all these aspects, it would not be as good as DUB's, guaranteed! I reckon this is true for any other D IDE out there. I use Mono-D and VisualD extensively, and in lieu of those, I fallback to makefiles. Those certainly did make their own equivalent build systems matching the IDE's existing styles. Those IDE's integrate D nicely with the C/C++ experiences. DUB is insufficient for any of my projects, and sadly, that makes DDT insufficient for my projects too:( The problem with DUB is it's self-contained. My projects involve cross-language interaction, and the build environments can be complex. DUB can't express this. Why is it insufficient? You don't have to use DUB to the exclusion of everything else. Isn't the use of the preGenerateCommands (http://code.dlang.org/package-format#build-settings) enough to call these other build systems you use? I have no idea how Eclipse operates internally... and I shouldn't have to. Isn't that the point of an IDE? All I can say is that CDT works, and I don't know how. If DDT doesn't automatically work with it out of the box, then the IDE experience is kinda pointless (to me at least). If I have to fiddle with a build system by hand, then that undermines the whole point of the IDE as far as I'm concerned. C/C++ and D are related, and they must interoperate. It's the top of the D roadmap. If I'm an IDE user, I think that's more-or-less an admission that I don't understand build environments, and I don't want to. So from that perspective, I think it would be valuable work to make sure DDT and CDT understand eachother. The only problem so far is that DDT doesn't support mutiple build configurations, but that's a DDT limitation, not a DUB one. You can also disable the DUB builder in DDT, as albatroz mentioned, however that isn't ideal since you won't get the compiler build errors reported back to Eclipse (DDT only has parsing errors built-in, other errors come externally, from the compiler.). There should be a way to integrate DUB with your build environment. There may very well be, but it would seem to be more work than not, and added complexity and for the cost of additional work doesn't make for a good sales pitch :) As far as I can tell, dub is good for self-contained D apps, and that's about it. Beyond that, there are much simpler solutions, and that includes IDE support.
Re: A few notes on choosing between Go and D for a quick project
On 3/19/2015 9:59 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
High level constructs in D are often slower than low-level code, so in some
cases you don't want to use them.
I actually found that LDC does an _amazing_ job of optimizing high level
constructs and converting low level code to higher level functional code
resulted in minor speedups in a lot of cases.
(Other performance benefits include the algorithm primitives being extensively
optimized in phobos.)
If the code/compiler generates suboptimal code in the first place then
improvements can be somewhat random. But if you write code with good cache
locality, filling the pipeline properly then there is no alternative to going
low level.
Btw, take a look at this:
http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d
That's really bad marketing...
Sigh. The Python version:
---
import sys
if __name__ == __main__:
if (len(sys.argv) 2):
sys.exit()
infile = open(sys.argv[1])
linect = 0
for line in infile:
linect += 1
print There are %d lines % linect
--
does not allocate memory. The splitLines() version:
--
import std.stdio;
import std.string;
import std.file;
int main(string[] args)
{
if (args.length 2) {
return 1;
}
auto c = cast(string) read(args[1]);
auto l = splitLines(c);
writeln(There are , l.length, lines.);
return 0;
}
-
allocates memory for all the lines and an array of them. No wonder it's slow!
The allocations are slow, and filling them all when they are cold-cached -
AWFUL! (It also uselessly and maddeningly auto-decodes, a misfeature of Phobos
if there ever was one.)
http://dlang.org/phobos/std_string.html#.splitLines
[Issue 14304] [REG2.067a] ICE with static immutable variable CTFE
https://issues.dlang.org/show_bug.cgi?id=14304 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||ice, pull Hardware|x86_64 |All Summary|dmd: interpret.c:6724: void |[REG2.067a] ICE with static |setValue(VarDeclaration*, |immutable variable CTFE |Expression*): Assertion | |`(vd-storage_class| |(0x1000LL | 0x20LL)) ? | |isCtfeReferenceValid(newval | |) : | |isCtfeValueValid(newval)' | |failed. | OS|Linux |All --- Comment #3 from Kenji Hara k.hara...@gmail.com --- The occurred ICE (moved from the summary): dmd: interpret.c:6724: void setValue(VarDeclaration*, Expression*): Assertion `(vd-storage_class (0x1000LL | 0x20LL)) ? isCtfeReferenceValid(newval) : isCtfeValueValid(newval)' failed. Compiler fix: https://github.com/D-Programming-Language/dmd/pull/4503 --
[Issue 14133] [REG 2.067] struct ctor init compiles very slow and produces excessive amounts of code
https://issues.dlang.org/show_bug.cgi?id=14133 --- Comment #2 from Martin Nowak c...@dawg.eu --- mov%eax,-0x2(%rbp) mov%eax,-0x1fffc(%rbp) mov%eax,-0x1fff8(%rbp) ... mov%ecx,-0x1f804(%rbp) xor%edx,%edx // Why edx all of a sudden? mov%edx,-0x1f800(%rbp) ... mov%edx,-0xc(%rbp) mov%edx,-0x8(%rbp) mov%edx,-0x4(%rbp) In total 32768 4-byte assignments to initialize the struct. --
[Issue 14301] [2.067-rc1] Private symbols of module conflicts with public from another
https://issues.dlang.org/show_bug.cgi?id=14301 --- Comment #14 from Martin Nowak c...@dawg.eu --- yes, those fixes will break some code. but refusing to fix 'em will leave features broken forever, as there are more and more code that rely on broken things. https://yourlogicalfallacyis.com/strawman This is not what I was saying, Kenji's patch fixes 313 and 314, which is great, but it also unnecessarily changes how selective imports work. This will break a lot of code to make a behavior different not better. Nobody is against fixing imports, but it's a core language feature and has to be done carefully. --
[Issue 14056] std.array.assocArray with a const value
https://issues.dlang.org/show_bug.cgi?id=14056 Martin Nowak c...@dawg.eu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --
[Issue 14301] [2.067-rc1] Private symbols of module conflicts with public from another
https://issues.dlang.org/show_bug.cgi?id=14301 --- Comment #16 from Ketmar Dark ket...@ketmar.no-ip.org --- (In reply to Martin Nowak from comment #14) This is not what I was saying, Kenji's patch fixes 313 and 314, which is great, but it also unnecessarily changes how selective imports work. it fixes *all* issues with selective imports. it *does* *not* contradicts specs. what is wrong then? --
Re: DDT 0.11.0 released
On 19 March 2015 at 07:12, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 18/03/2015 00:12, Trent Forkert wrote: Unless something has changed recently, it shouldn't require dub. Last time I checked, my CMake work[1] could still generate projects for Eclipse from a D codebase, using Makefiles or Ninja. Not that that helps if you are creating a project from an Eclipse Wizard, which I haven't done in a long time. [1] https://github.com/trentforkert/cmake What kind of Eclipse projects does it generate? If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), and DDT doesn't work with CDT projects (also duh). Why is that 'duh'? I would expect nothing less than for DDT and CDT to interact comprehensively. VisualD and Mono-D interact extensively with the existing C/C++ toolsets present on those platforms.
Re: A few notes on choosing between Go and D for a quick project
On 3/19/2015 10:44 AM, Joakim wrote: One underused resource seems to be all the examples bearophile has put on Rosetta Code: http://rosettacode.org/wiki/Category:D If he, Adam, or some other proficient D user were to do a weekly series breaking down each of those 733 examples one at a time- what idioms were used, why certain variations were more efficient- that could go a long way to introduce the language and its idioms to beginners. It would provide enough examples for 14 years of such a weekly series, by which time D3 will be getting started! I didn't know about rosettacode. Thanks! It also might be a great resource for better examples to use in the Phobos documentation.
[Issue 14285] [REG2.063] alias this to nothing is accepted
https://issues.dlang.org/show_bug.cgi?id=14285 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/dc0316f77b3c00ce1e483daffa8e28e2f5cded35 fix Issue 14285 - alias this to nothing is accepted https://github.com/D-Programming-Language/dmd/commit/83fe805eacc64e66818f726c1ad291ed28c48843 Merge pull request #4500 from 9rnsr/fix14285 [REG2.063] Issue 14285 - alias this to nothing is accepted --
[Issue 14285] [REG2.063] alias this to nothing is accepted
https://issues.dlang.org/show_bug.cgi?id=14285 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14285] [REG2.063] alias this to nothing is accepted
https://issues.dlang.org/show_bug.cgi?id=14285 --- 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/7a0669d0081001bad8d72b592fe19bc9d6a63e82 Merge pull request #4500 from 9rnsr/fix14285 [REG2.063] Issue 14285 - alias this to nothing is accepted --
Re: A few notes on choosing between Go and D for a quick project
Andrei Alexandrescu: You may want to answer there, not here. I've also posted a response. There is this, with an attach: https://issues.dlang.org/show_bug.cgi?id=11810 Bye, bearophile
Re: New Russian doc in wiki.dlang.org
On 3/19/2015 4:41 AM, Suliman wrote: My friend Ruslan wrote pretty big doc for D-noobs about using D. It's pretty much inspired by Ali book (thanks Ali!) but not so big. I hope that doc will help to newcomers to start programming. Any feed back are welcome! http://wiki.dlang.org/Reading_the_documentation_%28in_Russian%29 P.S. the work on dlang.ru is not stop. We done huge refactoring of engine, but now our programmer again have not free time. But I keep hand on pulse. Thank you!
Lazy functions, lazy arrays
Hi, Is it possible for D to create lazy functions, lazy arrays? Or in addition to the function arguments can't be lazy in D?
Re: DDT 0.11.0 released
On 20 March 2015 at 01:14, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 19/03/2015 14:45, Trent Forkert wrote: On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. Exactly. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. DDT does support a .dproject ... it's called dub.json ! ;) I'm dead serious here though. Why would I invent my own file format to describe source folders and include/imports paths when dub.json does that already?? It would be silly to use anything else. If you absolutely don't want to use DUB to build things, there are ways to disable the DUB builder, as mentioned before in this thread, and this way you'll use dub.json merely to describe the import path structure of the D project. I would imagine that if you had complete control over the project description and build process, it would be much easier to integrate with other components in Eclipse? Of course, I have no idea whether that's true or not. But I will hazard a guess that using dub in this way must make it harder for you to interact with CDT/java tools than otherwise? It would also be really nice to have a UI with tick boxes and select boxes for all the relevant build settings like CDT.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On 3/19/2015 2:40 AM, deadalnix wrote: And I'm sorry, but if most function require DDoc, your code probably sucks quite badly and some renaming should be considered. I've never seen any code that self-documented why.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Thu, Mar 19, 2015 at 3:03 PM, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Accessor functions that merely return a field variable are bull anyway.
I would recommend against opening up this debate. Suffice it to say that
this is a well established pattern that many people use; there is well-trod
ground arguing both sides.
int foo;
int getFoo() { return foo; }
A valid reason for doing things like this is future-proof encapsulation.
You can change the internal foo to be something entirely different, and the
external api never changes (assuming 'foo' is private).
As for the documentation - yeah, don't write docs that duplicate what is
there in the method signature. In the above example, documentation should
explain what foo actually is, and why you might need it. Otherwise is just
duplicate boilerplate that should be generated by the doc generator.
Re: A few notes on choosing between Go and D for a quick project
On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote: On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote: On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote: On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote: On 17/03/2015 10:31, Almighty Bob wrote: It's far more useful for csvReader to return a type I know and can use than it is to obscure the return type for the sake of some philosophical ideal of increasing encapsulation. Part of the art of API design is to hide implementation where it's not necessarily needed. Designers might err on the side of hiding things, because how you expose something is important as it has to be maintained indefinitely. If they expose everything then the internals can never be redesigned for better performance, etc. They don't increase encapsulation. The public members of a voldomort type are still public, you still have to code to the API of the return type whether it's a regular or voldomort type. You can keep as much private or public in either case as you like. All they do take the typename out of circulation, they make life harder for the user. There's no benefit. None. But at least the library author can stroke his chin a feel smug that there's one less type in the modules' namespace. Totally missing the point. The crux of the matter is this: changing a voldemort type (assuming the public semantics are the same) is not a breaking API change, because no-one else's code ever names it. Seriously? You cant have a public API and private implementation with a regular type? That's something specific to voldomort types? Ask yourself what exactly do voldomort types enable you to hide that cant be hidden with a regular type? Just one thing. Their name. As you said no one else can ever name the type. That is no benefit to me the user. No-one has been able to even describe a benefit. Walters article on Dr Dobbs doesn't describe a benefit. It increases encapsulation you all squawk. No it doesn't. The private bits are still private, the public bits are still public. All it does is complicate the user side. Its the emperor's new clothes. It's not possible to construct a voldemort type outside of the function where it was declared, and you can't know what that type is, just what the API is. You can force type deduction so the type returned can be changed without breaking code, so long as the API is the same. That's how it increases encapsulation.
Re: Terminal ANSI Colouring Library
On Monday, 16 March 2015 at 15:39:52 UTC, Kingsley wrote: Hi, As a learning project I've knocked up a tiny library to output ansi coloured text on linux/osx. Have a look here for an earlier attempt: http://forum.dlang.org/thread/mailman.41.1317934445.28623.digitalmar...@puremagic.com This would be great to have in Phobos!
Re: Replace core language HexStrings with library entity
On 18/03/2015 14:45, H. S. Teoh via Digitalmars-d wrote: On Wed, Mar 18, 2015 at 07:45:54PM +1100, Daniel Murphy via Digitalmars-d wrote: Kagamin wrote in message news:pltiewdojqrmgxrwh...@forum.dlang.org... The compiler lexer can be of arbitrary complexity, because it's already written. If you write a compiler, you just grab the ready lexer and use it, you don't need to count lines. The problem is with other, non-compiler tools. I have no idea what your point is. Lexer complexity matters for every tool that needs to lex D code. Not if we have libdmdlexer that they can reuse... ;-) Some tools can't require D due to project limitations.
Re: buffer to struct type conversion...TArrayStream?
On Thu, 19 Mar 2015 10:47:05 -0700, Charles Hixson via Digitalmars-d-learn wrote: turn it 90 degrees. ;-) auto cvt = cast(Node_*)buf.ptr; n = cvt[0]; signature.asc Description: PGP signature
updated SDC-32bit again
My sdc32-experimental has now limited support for : * foreach on forward-ranges * inference of purity * checking the returnType of main currently it CANNOT generate 32bit code anymore ...
Re: A few notes on choosing between Go and D for a quick project
On 3/19/15 10:40 AM, weaselcat wrote:
On Thursday, 19 March 2015 at 16:59:36 UTC, Ola Fosheim Grøstad wrote:
On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
High level constructs in D are often slower than low-level code, so
in some cases you don't want to use them.
I actually found that LDC does an _amazing_ job of optimizing high
level constructs and converting low level code to higher level
functional code resulted in minor speedups in a lot of cases.
(Other performance benefits include the algorithm primitives being
extensively optimized in phobos.)
If the code/compiler generates suboptimal code in the first place then
improvements can be somewhat random. But if you write code with good
cache locality, filling the pipeline properly then there is no
alternative to going low level.
Btw, take a look at this:
http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d
That's really bad marketing...
python:
time python2 wc.py enwiki-latest-pages-articles1.xml-p00010p1
There are 1245473 lines
python2 wc.py enwiki-latest-pages-articles1.xml-p00010p1
0.21s user 0.08s system 99% cpu 0.294 total
wc -l:
time wc -l enwiki-latest-pages-articles1.xml-p00010p1
1245472 enwiki-latest-pages-articles1.xml-p00010p1
wc -l enwiki-latest-pages-articles1.xml-p00010p1 0.05s user
0.02s system 96% cpu 0.072 total
iterative version:
ldc -O5 -inline -release -boundscheck=off wc.d
time ./wc
There are 1245473 lines.
./wc enwiki-latest-pages-articles1.xml-p00010p1 0.59s user
0.07s system 99% cpu 0.661 total
functional version:
writeln(There are ,
(cast(string)read(args[1])).splitter('\n').array.length, lines.);
ldc -O5 -inline -release -boundscheck=off wc.d
time ./wc enwiki-latest-pages-articles1.xml-p00010p1
There are 1245473 lines.
./wc enwiki-latest-pages-articles1.xml-p00010p1 0.04s user
0.08s system 98% cpu 0.125 total
You may want to answer there, not here. I've also posted a response.
Andrei
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote: I'm fed up with this problem. It is actively hurting us every day. https://issues.dlang.org/show_bug.cgi?id=14307 Anyone want to take this on? Shouldn't be particularly difficult. I think this is a good idea. Even the most trivial looking function might not be so trivial looking to consumers of the API. Document everything. If you can't explain a function in a public API (where protected is also public), then why should it exist?
[Issue 14183] Updates to groupBy
https://issues.dlang.org/show_bug.cgi?id=14183 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: buffer to struct type conversion...TArrayStream?
On 03/19/2015 12:05 PM, via Digitalmars-d-learn wrote:
On Thursday, 19 March 2015 at 18:42:03 UTC, Marc Schütz wrote:
3) Using std.bitmap.peek(), which also supports conversion between
big- and little-endian:
import std.bitmap;
n.self = buf.peek!(Node.Node_, Endian.bigEndian);
(The examples are untested, it's possible you'll need to make some
adjustments to make them work.)
You should probably use option 3). It is safe, because it checks that
the buffer has the right size, and it also allows you to specify the
endian-ness (many file formats have a standardized endian-ness).
While you're at it, you can also try std.bitmanip.read(). It can be
applied to any range, so you can probably do something like this
(also untested):
auto input = btFile.byChunk(4096).joiner;
while(!input.empty) {
auto node = input.read!(Node.Node_, Endian.bigEndian);
// use `node`
}
Urgh... it seems `peek()` and `read()` only work with numerical types
:-( Is this intentional? It would be quite useful for arbitrary types,
IMO, even if care must be taken with regard to pointers.
Note: Thanks for the prior comment about where to place the array
markers. I keep forgetting.
Umnf...I don't plan on needing conversion between Endian versions, but I
guess that's important. But more significant if it only handles numeric
types I wonder about handling arrays of structs, even if those structs
*are* composed entirely of numerical types. Being secure against a
future need to handle Endian variations would be good, but not enough to
both increase the complexity that way and deal with possible unexpected
errors.
P.S.: Looking at the std.bitmanip documentation causes me to feel that
the restriction to integral types was intentional, though admittedly it
doesn't seem to be stated explicitly, but all of the examples seem to be
simple arrays. I'll grant that this could be just to keep things
simple. And the wording of the docs causes me to think it would
probably only work for integral values, as in not even floats. This is
reasonable if you are thinking of it as a set of routines for bit
manipulation.
At all events, I think that it involves excessive overhead (in code
verbosity) and that I'ld likely need to use a loop to read the array
within the struct. A simple bit copy is much more straightforwards (I
was already checking that the read was the correct length, though I
haven't decided what to do if that ever fails. Currently it's an assert
statement, but this clearly needs to be changed to either an enforce
statement or to a thrown exception...but I haven't yet thought of a
valid case where the block would be an incorrect length.
Re: const as default for variables
On Saturday, 14 March 2015 at 20:15:30 UTC, Walter Bright wrote: I've often thought, as do many others here, that immutability should be the default for variables. Case (1) is what I'm talking about here. If it is made const, then there are a couple ways forward in declaring a mutable variable: The following is just my point of view, so take it with a grain of salt and correct me if I state/understand something wrong: I usually abstain from participating in discussions here, because more often than not someone else will already more or less write what I would, so there is little point in my writing what has already been posted. This issue, however, I consider fairly important, as what you propose would make me classify D as don't touch, which I really don't want considering that I've been following and using D for the better part of ten years; let me explain why: There exists an abstract amount of data that I want to store somewhere and access within my program. I shall call one instance of something I put my data into storage entity (SE for short). Now depending on what properties my data inherently has (or I may additionally attribute to it) I may want or need a SE to - allow any data within it to be changed ([wholly] mutable) - prohibit any data within it to be changed ([wholly] immutable) - allow some of the data within it to be changed (partially mutable) [Here and unless otherwise stated I do not use immutable in the transitive meaning that D currently applies to it, instead it is only applied to one SE] The first of the three is what is generally in computer science (CS) called a variable, the second a constant. SEs of the third type are also mostly referred to as variables, as they are usually implemented as an extension to the first. I know that from a mathematical standpoint, a variable is only a symbol with an attributed value without any associated notion about (im)mutability, so even a contant would be a variable, but this is not how the terminology is used in CS. In CS a variable must allow some kind of mutability; not necessarily wholly, but without mutability it would be a constant, not a variable. As such, should D's SEs default to being wholly immutable (which you seem to propose), it should not call them variables anymore (since they aren't), but instead clearly state that D's SE default to being constants and if you want a variable, do [...]. With only primitives (no pointers), there can be no partial mutability, you are either allowed to assign a new (primitive) value or you are not. Partial mutability becomes a serious concern, however, once pointers/references are involved, e.g. if you want to reference an SE that is wholly immutable. Does your reference automatically also become immutable (as I understand if - and please correct me if I am wrong here - this is what D's transitive immutable means)? I understand that with this extremely complex issue, it may seem desirably to instead default to whole non-transtitive immutability and make people explicitly state when they want their SEs to be mutable. One might argue that it would make a lot of things simpler for everyone involved. However, D is a systems programming language and I would counter-argue that I believe the amount of partially mutable SEs to far outweight the amount of wholly immutable ones and having something like int foo = 5; [...] foo = 6; produce a compile-error because foo is by default non-transitive immutable [D terminology would be const I think] is something I can only call absurd for the following reason: It breaks with the convention systems programming languages have been using for a very long time. While I'm not generally against cutting off traditions no longer needed, I believe this would have a serious negative impact on people coming form C/C++ who are expecting new cool stuff (which D definitely has) without ground-breaking changes. The longer the list of core differences to the way you code you have to remind yourself about when switching to D, the less likely you will switch to D, I think. What I would propose is the following: Have the compiler-frontend track for all SE whether they are assigned to more than once (counting the initial assignment). Any SE that isn't can safely be marked const (or non-transitive immutable) the way to described in your opening post. However, is an SE assigned to at least twice is must not be marked as const. This should - in my opinion - give about the same level of safety as marking everything as const by default while not breaking with any long-standing conventions.
[Issue 14183] Updates to groupBy
https://issues.dlang.org/show_bug.cgi?id=14183 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/c6520969eaa317d373bc288aec49e9e2ca077dc4 Fix Issue 14183 - Changes to groupBy * Renamed `groupBy` to `chunkBy` * Undocumented `aggregate` * Added `groupBy` member function to `SortedRange` * Unary `chunkBy` returns tuple of key and chunk. https://issues.dlang.org/show_bug.cgi?id=14183 https://github.com/D-Programming-Language/phobos/commit/fa297af0e69f5b097fad81263da74d2033fd2541 Merge pull request #3005 from Poita/Issue14183 Fix Issue 14183 - Changes to groupBy --
Re: Should this work: export extern(C) auto ...
On Thursday, 19 March 2015 at 12:58:42 UTC, Robert M. Münch wrote: On 2015-03-18 21:50:39 +, Adam D. Ruppe said: It will not work because a function with an auto return value is actually a template, and unused templates won't be put into a dll. Ok, that makes it clear. Thanks. Generally don't expect to many things to work with DLLs at the moment. Generally speaking only exporting global functions works. Don't try to export classes / structs or anything fancy.
[Issue 14291] Druntime master no longer builds
https://issues.dlang.org/show_bug.cgi?id=14291 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Keywords||pull Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- https://github.com/D-Programming-Language/druntime/pull/1191 --
Re: Should this work: export extern(C) auto ...
On 2015-03-18 21:50:39 +, Adam D. Ruppe said: It will not work because a function with an auto return value is actually a template, and unused templates won't be put into a dll. Ok, that makes it clear. Thanks. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: variadic mixin - the right tool for the job?
On 2015-03-18 15:27:03 +, Daniel Kozák via Digitalmars-d-learn said:
You probably does not need mixins:
void log(string file = __FILE__, size_t line = __LINE__, T...)
(T variadic_arg) {
some_fun(variadic_arg[0], file, line, variadic_arg[1 .. $]);
}
Hi, ha, forgot about default arguments. Great that this works and take
the file line number where the tempate function is used.
Thanks.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Is it possible to call D functions from C++
On Thursday, 19 March 2015 at 11:47:37 UTC, Namal wrote: On Wednesday, 18 March 2015 at 15:52:33 UTC, Benjamin Thaut wrote: On Wednesday, 18 March 2015 at 14:50:21 UTC, Namal wrote: Can you help me show how to compile and link it together please, thank you. What platform are you on, windows, linux, osx? What c++ compiler do you use? msvc, clang, gcc? Linux, gcc and dmd. In my case c++ refuses to compile if main is void. well then change it to the full signature ;-)
[Issue 14309] The difference between Microsoft's GUID and std.uuid.UUID
https://issues.dlang.org/show_bug.cgi?id=14309 --- Comment #1 from Sobirari Muhomori dfj1es...@sneakemail.com --- UUID is big endian, GUID is little endian, hence mismatch. --
buffer to struct type conversion...TArrayStream?
I've read a chunk of data into a buffer and want to convert it into a
struct. The reading routine is in a class that doesn't know about the
struct, but the size should be exactly the same. (I.e., I want to use
the converse procedure to write it.)
Is there a better way to do this than using TArrayStream?
The idea here is to have a file of fixed length records (rather like
Fortran binary records, except that there's a header record which is a
different size and which specifies various things about the file). The
class (well, struct) that handles the fixed length records only knows
what the record size is, and a couple of other quite general things.
The class which uses it holds each record in a fixed length struct with
no indirections. So I thought I could just cast the buffer to the
struct...but this doesn't work. Every straightforward way I've tried of
doing it yields:
Error: cannot cast from Node_ to ubyte[]
or something reasonably analogous. The current version of the
(non-working) code is:
ubytebuf[];
autolen=btFile.read(nodeId, buf);
assert(len == n.self.sizeof);
n.self=to!(Node.Node_)(buf);
//TODOwrite the code
which yields the error:
Error: template instance std.conv.to!(Node_).to!(ubyte[]) error
instantiating
Node_ is (approximately, I've renamed aliased values to their base value):
structNode_
{ ulongidvalue;
ulongkeyvalue;
inteLen;
Entry e[23];
}
and Entry is (approximately):
structEntry
{ ulongkey;
ulongd;
ulongd2;
}
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On Thursday, 19 March 2015 at 11:27:20 UTC, Gary Willoughby wrote: I would like this but issue warnings not errors. I like every function to be documented. Also don't make the Example mandatory because people tend to use unittest blocks as the examples. Why not just make unittests mandatory, and completely forego the examples?
Re: A few notes on choosing between Go and D for a quick project
On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote: On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote: High level constructs in D are often slower than low-level code, so in some cases you don't want to use them. I actually found that LDC does an _amazing_ job of optimizing high level constructs and converting low level code to higher level functional code resulted in minor speedups in a lot of cases. (Other performance benefits include the algorithm primitives being extensively optimized in phobos.) If the code/compiler generates suboptimal code in the first place then improvements can be somewhat random. But if you write code with good cache locality, filling the pipeline properly then there is no alternative to going low level. Btw, take a look at this: http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d That's really bad marketing...
Re: Digger 1.1
On Thursday, 19 March 2015 at 15:40:19 UTC, Robert M. Münch wrote: On 2015-03-18 12:14:01 +, Vladimir Panteleev said: I've pushed support for DMD bootstrapping, so if you need to build master now, build latest Digger from source. I'll make a binary release after 2.067 is out. I just tried it and get this here: Entering 'phobos' Entering 'tools' error: Your local changes to the following files would be overwritten by checkout: test/d_do_test.d Please, commit your changes or stash them before you can switch branches. Aborting Unable to checkout '229edba461ef6f6e2254e060eb498f302e982563' in submodule path 'dmd' Fatal error: Command [git, --work-tree=D:\\develop\\d-language\\Digger\\repo, --git-dir=D:\\develop\\d-language\\Di gger\\repo\\.git, submodule, update] failed with status 1 I don't have done any changes to test/d_do_test.d so no idea what this means or where it comes from... any idea? Hmm... Does it happen with a fresh Digger install? What is your core.autocrlf set to?
Re: A few notes on choosing between Go and D for a quick project
On Thursday, 19 March 2015 at 16:59:36 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
High level constructs in D are often slower than low-level
code, so in some cases you don't want to use them.
I actually found that LDC does an _amazing_ job of optimizing
high level constructs and converting low level code to
higher level functional code resulted in minor speedups in a
lot of cases.
(Other performance benefits include the algorithm primitives
being extensively optimized in phobos.)
If the code/compiler generates suboptimal code in the first
place then improvements can be somewhat random. But if you
write code with good cache locality, filling the pipeline
properly then there is no alternative to going low level.
Btw, take a look at this:
http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d
That's really bad marketing...
python:
time python2 wc.py
enwiki-latest-pages-articles1.xml-p00010p1
There are 1245473 lines
python2 wc.py
enwiki-latest-pages-articles1.xml-p00010p1 0.21s
user 0.08s system 99% cpu 0.294 total
wc -l:
time wc -l enwiki-latest-pages-articles1.xml-p00010p1
1245472 enwiki-latest-pages-articles1.xml-p00010p1
wc -l enwiki-latest-pages-articles1.xml-p00010p1
0.05s user 0.02s system 96% cpu 0.072 total
iterative version:
ldc -O5 -inline -release -boundscheck=off wc.d
time ./wc
There are 1245473 lines.
./wc enwiki-latest-pages-articles1.xml-p00010p1
0.59s user 0.07s system 99% cpu 0.661 total
functional version:
writeln(There are ,
(cast(string)read(args[1])).splitter('\n').array.length,
lines.);
ldc -O5 -inline -release -boundscheck=off wc.d
time ./wc enwiki-latest-pages-articles1.xml-p00010p1
There are 1245473 lines.
./wc enwiki-latest-pages-articles1.xml-p00010p1
0.04s user 0.08s system 98% cpu 0.125 total
ahem
I actually found that LDC does an _amazing_ job of optimizing
high level constructs and converting low level code to
higher level functional code resulted in minor speedups in a
lot of cases.
