Re: sudo apt-get install dmd
On Sat, 2015-03-14 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-d wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? It is the way I put DMD and other things in the repository into Debian Sid. These debs work nicely, the debs produced as part of the distribution have to be downloaded and installed into a local repository and it's all a mess: much easier having d-apt part of the release process. Should also look to get the RPMs into rpmfusion for Fedora 21, 22 and Rawhide. similarly much easier than downloading RPMs into -- 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: Post increment and decrement
On 03/14/2015 03:23 PM, deadalnix wrote: But, for some reason, the topic come up again and again from C++ devs that have no idea the optimization guys solved the issues for years now. If we are talking about C++, it is not possible to not take that copy for user-defined types. Due to separate compilation, the compiler does not even see the definition of operator++(int). And the compiler cannot replace calls to operator++(int) with calls to operator++() (when the return value is not used) because the programmer may have done different things than the canonical implmentation of post-increment. C++ needs a rule like D's, which will never be there. Ali
Re: Dlang seems like java now,but why not let d more like C# Style?
On Saturday, 14 March 2015 at 23:57:33 UTC, weaselcat wrote: On Saturday, 14 March 2015 at 23:46:28 UTC, Ellery Newcomer wrote: And C# has LINQ, which when combined with the last point is fricken awesome. what does LINQ offer that UFCS-style functional programming does not? LINQ basically is a UFCS-style api. AST reflection is what makes it nice. consider: X.Where(x = x.Members.Count() == x.Admins.Count()) straightforward in both D and C# when X is an array or container type. When X is a table in a database, things get tricky for D. C# can interpret the lambda as an ExpressionFunc (an AST type), so the implementation of X can reflect over the body of the lambda and use it to generate the appropriate SQL. ORMs such as entity framework and nhibernate do this now.
mixin template can't contain statements: workaround?
Why can't we allow mixin templates to contain statements, as is the case
for regular mixins?
Is there a workaround?
here's a dummy example:
template mixin Foo{
//some statement, eg: 'return;'
}
void fun(){
mixin Foo;
}
Note that I can do this with a regular mixin, but template mixins are
cleaner (esp in more complex examples).
const as default for variables
I've often thought, as do many others here, that immutability should be the default for variables. [This is a long term issue. Just thought maybe it's time for a conversation about it.] Because immutable is transitive, declaring variables as immutable by default would be problematic. A more practical way would be to make them const. As it is now: 1.int x = 1; // mutable 2.auto x = 1; // mutable 3.const x = 1; // const 4.immutable x = 1; // immutable 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: a) Introduce a new storage class, called 'var' or 'mut'. (Please, no bikeshedding on names at the moment. Let's stay on topic.) b) Use 'auto' as meaning 'mutable' if the initializer is also mutable. Extend 'auto' to allow an optional type, auto T t = initializer; There may be some ambiguity issues with 'auto ref', haven't thought it through. Once there is a non-default way to declare variables as mutable, a compiler switch can be added to change the default to be const. Eventually, the language can default to them being const, with a legacy switch to support the mutable default.
Re: const as default for variables
On Saturday, 14 March 2015 at 21:18:33 UTC, Douglas Peterson wrote: What would be the rationale for such a change ? safety, the same reason @safe should be the default. see: const correctness, virtually any ML-inspired language.
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote: The point is, with a library abstraction the core language can be simplified. D's ability to create user defined literals largely ends the pressure to make more complicated and specialized core language literals. It makes it sounds like you don't know the spec about string literals.
Re: A few notes on choosing between Go and D for a quick project
Le 13/03/2015 01:20, Andrei Alexandrescu a écrit : 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 IMO D seems more complicated than it really is. Mostly cause of presentation of documentation, lack of examples, tutorials,... Even there is some great changes can appear between versions, it's not a big issue, cause it will not impact small projects. I think that the main issue is the first impression the user can have of the D ecosystem. Newbies want to be taken by hand during their first steps with a new language. And the First page a the web site need to show what can be/is achieved with D, talk about main features, market benefits,... Documentation is only interesting for someone already use D, so it can be in a dedicated domain name. Take a look to the new Qt web site : http://www.qt.io/ Documentation : http://doc.qt.io/ I also want encourage everybody, cause the D website made some really good changes during last months.
Re: sudo apt-get install dmd
On Saturday, 14 March 2015 at 18:56:07 UTC, Russel Winder wrote: On Sat, 2015-03-14 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-d wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? It is the way I put DMD and other things in the repository into Debian Sid. These debs work nicely, the debs produced as part of the distribution have to be downloaded and installed into a local repository and it's all a mess: much easier having d-apt part of the release process. Should also look to get the RPMs into rpmfusion for Fedora 21, 22 and Rawhide. similarly much easier than downloading RPMs into I thought DMD wasn't included in free distros because of licensing issues? I don't think any major distro comes without LDC or GDC.
Re: A few notes on choosing between Go and D for a quick project
On 3/14/15 11:24 AM, Russel Winder via Digitalmars-d wrote: But yes, it certainly shows you can create shared-memory multi-threading this way, So your affirmation has been refuted. but anyone actually doing it would be being very silly. That's design by prayer. Aren't most bugs created by people doing very silly things? Sending addresses down multiple channels One is enough. is obvious here and definitely not the right thing to do unless the datum contains an embedded lock which is then used. cf. https://talks.golang.org/2012/10things.slide#3 Yes, of course it's not the right thing to do. Your point being...? It would be better if channels could only accept value types, and not reference types. Probably not as that would further hamstrung the language. Andrei
broken std.md5 link on phobos page
the std.md5 link on phobos index page [0] is broken. i did fork phobos, did a grep but could not find the link to the lib so could not send a PR. [0] http://dlang.org/phobos/
Re: OutputDebugString()
On Saturday, March 14, 2015 17:49:10 Robert M. Münch via Digitalmars-d-learn wrote: Now, just need to check why I don't see any debug output but that's not a DMD issue ;-). In case you didn't know, if you're not running the program in visual studio, you should see the output in in DebugView: https://technet.microsoft.com/en-us/library/bb896647.aspx - Jonathan M Davis
dfmt options
First, a disclaimer: I am an idiot for starting this thread. Moving on... I'm working on a list of configuration options for dfmt - a formatter for D source code. So far I have the following: * Insert spaces between if, while, for, foreach, etc loops and the ( * Allman vs One True Brace Style (Already supported by commant-line switch) * Operators at the end of the old line vs beginning of the new line when wrapping long expressions. * Insert space after the ) of a cast expression * Make case and default match the indent level of the enclosing switch * Labels for loops always on their own line vs the same line as the loop * Labels outdented one level * Label indentation matches the most recent switch * Hard limit for line length * Soft limit for line length What am I missing?
Re: A few notes on choosing between Go and D for a quick project
Unfortunately, for speech and language processing (synthesis, speech recognition etc) Python is too slow. Everybody uses Python at first, but the serious code that is later put into real world applications is usually written in C or C++. This is a fact. I know people who developed speech analysis frameworks in Python and are now thinking of rewriting it in C++ for commercial purposes. Python is good for protoyping, but if you need fast applications, it is usually C/C++ (or D). What you are saying is not wrong, except for the generalizations to everybody. Obviously you are not aware of the other people/industries who use python for non-performane critical applications (not prototype, but real large applications), there are several reasons, but don't want to bore you with details (one of which is the super structure). I do wish we were using D everywhere, and I do use it for personal and small tools at the job. - engineer
Re: Standard GUI framework inspired by Qt
Le 13/03/2015 20:38, Aram a écrit : On Wednesday, 11 March 2015 at 08:22:30 UTC, Xavier Bigand wrote: DQuick is just like QtQuick, a simple render coupled to a language that support property bindings, if you want more advanced GUI components like widgets the user have to create them based on primitives (images, border images,...). But just like Qt do, advanced components can be added after to the library as an extension (QtQuick.Controls). A such GUI library is in theory simpler to do, cause there is no tricky things to implement in it to follow native UI of platforms,... How can I take a look at DQuik? Is it in working state? It's on github : https://github.com/D-Quick/DQuick We have some tests working, but it's not enough to be usable on a real application. The DML engine is almost finished. This night we worked on the file reloading. This will allow direct update of GUI when modifying lua files without loosing states. Once the DML engine polished, we'll progress and the render part and event system. For the moment the mouse input aren't propagate correctly in the hierarchy,... But we hope finding more time to work on it this year.
Re: dfmt options
On 3/14/2015 4:59 PM, Brian Schott wrote: On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote: I suggest defining The One True Way and have no configuration options. I hope you like tabs as much as I do. We'll all have to compromise at some point to have a One True Way, but it'll be worth it. I gave up on my cherished notion of tabs for the Greater Good in Phobos formatting, for example.
Re: between and among: worth Phobosization? (reprise)
On 12/16/13 12:38 PM, Andrei Alexandrescu wrote:
bool between(T, U1, U2)(T v, U1 lo, U2 hi)
{
return v = lo v = hi;
}
uint among(T, Us...)(T v, Us vals)
{
foreach (i, U; Us)
{
if (v == vals[i]) return i + 1;
}
return 0;
}
Add?
Looks like among() has proven its worth since we introduced it. Now I
somehow forgot between() didn't make it, and reviewed some code at work
assuming it exists! Here's the original and proposed in a couple of
snippets:
return (path.asPath.logicalLength() = asPathLengths_[1]
path.asPath.logicalLength() = asPathLengths_[0]);
=
return path.asPath.logicalLength.between(asPathLengths_[0],
asPathLengths_[1]);
if (prefix.prefixLen prefixLenRange_[1] ||
prefix.prefixLen prefixLenRange_[0]) {
=
if (!prefix.prefixLen.between(prefixLenRange_[0], prefixLenRange_[1])) {
Well?
Andrei
Re: A few notes on choosing between Go and D for a quick project
On 3/14/2015 2:26 AM, Russel Winder via Digitalmars-d wrote: On Fri, 2015-03-13 at 00:22 -0700, Walter Bright via Digitalmars-d wrote: On 3/12/2015 11:57 PM, Russel Winder via Digitalmars-d wrote: How about lining up some features for removal. Easier said than done. I've proposed a couple things for removal, but got a lot of pushback. Some things have been successfully removed: Pushback can be ignored, and indeed should in some cases. Not ignored. But sometimes I do override others' judgement in the interest of doing what I believe is best. Somebody has to make decisions on controversial issues. (I had proposed removing the 'lazy' storage class.) . octal literals C should be incinerated for the 0777 abomination. At least 0o777 can work reasonably. Even better: octal!0777 The point is, with a library abstraction the core language can be simplified. D's ability to create user defined literals largely ends the pressure to make more complicated and specialized core language literals. . builtin complex numbers Electronics folk love these. Many people use Python exactly for this type. Complex numbers are still available, but as a library type, which is not inferior to the (former) builtin type. Has any language been successful at abandoning their user base (i.e. existing code)? Going from D1 to D2 nearly destroyed D. I'm not eager to try that again. The war is being played out in the Python 2/3 arena certainly. Interestingly though there are fewer and fewer Python 2 hold outs. Their holding out has made Python 3 change a little, and for the better in my view – even though I refuse to write any Python 2 specific code. It's a good example. Didn't Perl 6 go through a paroxysm, too? But not so successfully.
Re: A few notes on choosing between Go and D for a quick project
On 3/14/2015 2:12 AM, Russel Winder via Digitalmars-d wrote: On Fri, 2015-03-13 at 20:12 -0700, Andrei Alexandrescu via Digitalmars-d wrote: I'm surprised Russel fell for it. -- Andrei Fell for what? The mark of a successful long con! :-)
Re: Garbage collector returning pointers
On Saturday, 14 March 2015 at 18:26:34 UTC, Robert M. Münch wrote:
Hi, I have a question about how the GC handles this case:
export extern(C) char* foo(){
char[] x = This is a dynamic D string..dup;
return(cast(char*)x);
}
Since x is pointer to array data length if it goes out of
scope, it's destroyed and the last reference to the array data
is gone. Hence, the GC could kick in and free the array data.
Is this correct?
Or will the GC know, that there was a pointer to the array data
returned and hence a new reference exists as long until someone
tells the GC that the pointer is no longer used?
My situation is, that the returned pointer is used to copy the
result to some interpreter internal state. Depending on the
answers above, there could be a short time where the memory
state is collectable before the coyping was finished.
As long as the pointer remains on the stack or in a register, the
GC will keep the allocation alive. But if your C code stores the
pointer on the C heap or in a global, the GC won't know anything
about it and can free it.
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. [This is a long term issue. Just thought maybe it's time for a conversation about it.] Because immutable is transitive, declaring variables as immutable by default would be problematic. A more practical way would be to make them const. As it is now: 1.int x = 1; // mutable 2.auto x = 1; // mutable 3.const x = 1; // const 4.immutable x = 1; // immutable 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: a) Introduce a new storage class, called 'var' or 'mut'. (Please, no bikeshedding on names at the moment. Let's stay on topic.) b) Use 'auto' as meaning 'mutable' if the initializer is also mutable. Extend 'auto' to allow an optional type, auto T t = initializer; There may be some ambiguity issues with 'auto ref', haven't thought it through. Once there is a non-default way to declare variables as mutable, a compiler switch can be added to change the default to be const. Eventually, the language can default to them being const, with a legacy switch to support the mutable default. I like it! In fact I thought a lot of people asked to take the const-by-default route when D2 introduced it? ~S
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. There should be constants and variables but no such thing as... a constant variable or an immutable variable. It's either constant/immutable or it's variable, it cant be both.
Re: Post increment and decrement
On Saturday, 14 March 2015 at 10:11:27 UTC, Casper Færgemand wrote: What exactly is the downside of i++? Suppose the compiler doesn't lower it and I use the expression alone, what is the potential damage? You need to store a temporary of the value pre increment to be returned. But it doesn't matter as any compiler will optimize it away if you don't use it. But, for some reason, the topic come up again and again from C++ devs that have no idea the optimization guys solved the issues for years now.
Re: broken std.md5 link on phobos page
On Saturday, 14 March 2015 at 22:52:28 UTC, Mengu wrote: the std.md5 link on phobos index page [0] is broken. i did fork phobos, did a grep but could not find the link to the lib so could not send a PR. [0] http://dlang.org/phobos/ and i think that's because there's no more an std.md5 lib and its content is moved to std.digest.
Re: dfmt options
On Sat, 14 Mar 2015 23:15:34 +, Brian Schott wrote: First, a disclaimer: I am an idiot for starting this thread. Moving on... I'm working on a list of configuration options for dfmt - a formatter for D source code. So far I have the following: * Insert spaces between if, while, for, foreach, etc loops and the ( * Allman vs One True Brace Style (Already supported by commant-line switch) * Operators at the end of the old line vs beginning of the new line when wrapping long expressions. * Insert space after the ) of a cast expression * Make case and default match the indent level of the enclosing switch * Labels for loops always on their own line vs the same line as the loop * Labels outdented one level * Label indentation matches the most recent switch * Hard limit for line length * Soft limit for line length What am I missing? optional space before arguments in function declaration, if you please. i.e.: void foo(); vs void foo (); signature.asc Description: PGP signature
Re: Dlang seems like java now,but why not let d more like C# Style?
On Saturday, 14 March 2015 at 23:46:28 UTC, Ellery Newcomer wrote: And C# has LINQ, which when combined with the last point is fricken awesome. what does LINQ offer that UFCS-style functional programming does not?
Re: dfmt options
On 3/14/15 4:15 PM, Brian Schott wrote: First, a disclaimer: I am an idiot for starting this thread. Moving on... I'm working on a list of configuration options for dfmt - a formatter for D source code. So far I have the following: * Insert spaces between if, while, for, foreach, etc loops and the ( * Allman vs One True Brace Style (Already supported by commant-line switch) * Operators at the end of the old line vs beginning of the new line when wrapping long expressions. * Insert space after the ) of a cast expression * Make case and default match the indent level of the enclosing switch * Labels for loops always on their own line vs the same line as the loop * Labels outdented one level * Label indentation matches the most recent switch * Hard limit for line length * Soft limit for line length What am I missing? * Deduce bracing style from code * Deduce indent size and spaces vs. tabs from code * Deduce max line length from code (typical boundaries: 72, 80, 100, 120). Andrei
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. [This is a long term issue. Just thought maybe it's time for a conversation about it.] Because immutable is transitive, declaring variables as immutable by default would be problematic. A more practical way would be to make them const. As it is now: 1.int x = 1; // mutable 2.auto x = 1; // mutable 3.const x = 1; // const 4.immutable x = 1; // immutable 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: a) Introduce a new storage class, called 'var' or 'mut'. (Please, no bikeshedding on names at the moment. Let's stay on topic.) b) Use 'auto' as meaning 'mutable' if the initializer is also mutable. Extend 'auto' to allow an optional type, auto T t = initializer; There may be some ambiguity issues with 'auto ref', haven't thought it through. Once there is a non-default way to declare variables as mutable, a compiler switch can be added to change the default to be const. Eventually, the language can default to them being const, with a legacy switch to support the mutable default. Seriously: http://giphy.com/gifs/KmrpxSVxTB9Ty ? It sounds a bit like the bad idea of the month (not totally because at least a bad idea initially sounds good). What would be the rationale for such a change ? In fact, this would imply a huge breakage on any existing code, right ?
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.
[This is a long term issue. Just thought maybe it's time for a
conversation about it.]
Because immutable is transitive, declaring variables as
immutable by default would be problematic. A more practical way
would be to make them const.
As it is now:
1.int x = 1; // mutable
2.auto x = 1; // mutable
3.const x = 1; // const
4.immutable x = 1; // immutable
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:
a) Introduce a new storage class, called 'var' or 'mut'.
(Please, no bikeshedding on names at the moment. Let's stay on
topic.)
b) Use 'auto' as meaning 'mutable' if the initializer is also
mutable. Extend 'auto' to allow an optional type,
auto T t = initializer;
There may be some ambiguity issues with 'auto ref', haven't
thought it through.
Once there is a non-default way to declare variables as
mutable, a compiler switch can be added to change the default
to be const. Eventually, the language can default to them being
const, with a legacy switch to support the mutable default.
My two and a half cents, I think this is going to lead to all
sorts of complications and simply wouldn't be worth the hassle.
While I believe that immutable by default is a fine choice for
any new language, D was designed with mutable by default in
mind and it's simply too late to try and change that now.
For example, this could be an issue for generic functions:
void foo(T)(T[] arr){
T value = arr[0]; // Mutable or immutable?
}
Also, you forgot a fifth case where only part of the type is
const/immutable:
5. const(T)[] x = ...
Re: sudo apt-get install dmd
On Saturday, 14 March 2015 at 18:37:18 UTC, tcak wrote: On Saturday, 14 March 2015 at 17:31:56 UTC, Andrei Alexandrescu wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? Andrei Ubuntu, most of the time, used with GUI. I just click on Download button of DMD, and Firefox opens it with Software Centre, and I click on Install button. Update works in the same way. So, in this case, there is no need for apt-get. ...BUT... Especially for Raspberry PI, server OSs (e.g. CentOS), it is a good idea. But I do not thing, anyone would one to install it on a server unless they require libphobos to run an executable. apt-get will get you the updates automagically !
Re: dfmt options
On 3/14/2015 4:15 PM, Brian Schott wrote: What am I missing? I'd also suggest making dfmt an algorithm. Then people can use it like map, reduce, filter, etc., in their programs. dfmt as a program then becomes incidental and trivial.
Re: const as default for variables
On Sunday, 15 March 2015 at 00:03:37 UTC, Orvid King wrote: 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. [This is a long term issue. Just thought maybe it's time for a conversation about it.] Because immutable is transitive, declaring variables as immutable by default would be problematic. A more practical way would be to make them const. As it is now: 1.int x = 1; // mutable 2.auto x = 1; // mutable 3.const x = 1; // const 4.immutable x = 1; // immutable 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: a) Introduce a new storage class, called 'var' or 'mut'. (Please, no bikeshedding on names at the moment. Let's stay on topic.) b) Use 'auto' as meaning 'mutable' if the initializer is also mutable. Extend 'auto' to allow an optional type, auto T t = initializer; There may be some ambiguity issues with 'auto ref', haven't thought it through. Once there is a non-default way to declare variables as mutable, a compiler switch can be added to change the default to be const. Eventually, the language can default to them being const, with a legacy switch to support the mutable default. Why would this be even slightly useful? If a value is constant, it _should not_ be a variable. C heritage.
Re: dfmt options
On Saturday, 14 March 2015 at 23:15:35 UTC, Brian Schott wrote: First, a disclaimer: I am an idiot for starting this thread. Moving on... I'm working on a list of configuration options for dfmt - a formatter for D source code. So far I have the following: * Insert spaces between if, while, for, foreach, etc loops and the ( * Allman vs One True Brace Style (Already supported by commant-line switch) * Operators at the end of the old line vs beginning of the new line when wrapping long expressions. * Insert space after the ) of a cast expression * Make case and default match the indent level of the enclosing switch * Labels for loops always on their own line vs the same line as the loop * Labels outdented one level * Label indentation matches the most recent switch * Hard limit for line length * Soft limit for line length What am I missing? Have you given clang's formatter options a read over? It might spark an idea or two. http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote: The point is, with a library abstraction the core language can be simplified. D's ability to create user defined literals largely ends the pressure to make more complicated and specialized core language literals. user defined literals can be quite ugly where sugar is expected(i.e, Tuples)
Re: Dlang seems like java now,but why not let d more like C# Style?
On Sunday, 15 March 2015 at 00:56:24 UTC, Ellery Newcomer wrote:
On Saturday, 14 March 2015 at 23:57:33 UTC, weaselcat wrote:
On Saturday, 14 March 2015 at 23:46:28 UTC, Ellery Newcomer
wrote:
And C# has LINQ, which when combined with the last point is
fricken awesome.
what does LINQ offer that UFCS-style functional programming
does not?
LINQ basically is a UFCS-style api. AST reflection is what
makes it nice.
consider:
X.Where(x = x.Members.Count() == x.Admins.Count())
straightforward in both D and C# when X is an array or
container type.
When X is a table in a database, things get tricky for D.
C# can interpret the lambda as an ExpressionFunc (an AST
type), so the implementation of X can reflect over the body of
the lambda and use it to generate the appropriate SQL. ORMs
such as entity framework and nhibernate do this now.
Somewhat off-topic, but you could theoretically embed SQL
directly in your D code using string mixins and have it
statically checked at compile time (this would be pretty advanced
usage, though).
mixin SQL!q{
INSERT INTO Person(name, age, occupation)
VALUES ('John', 25, 'Programmer')
};
[GUI-lib] Maybe a better year for DQuick
The DML engine is almost finished. This night we worked on the file reloading. This will allow direct update of GUI when modifying lua files without loosing states. For example if you only modify the color property of a Rectangle item it will be the only thing that will be updated (and binded properties will be update). Once the DML engine polished, we'll progress on the render part and the event system. We hope finding more time to work on it this year. https://github.com/D-Quick/DQuick
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote: I take the risk to be blamed, but let me tell you that the developer world does not spin around R, Python, Fortran, Haskell and Go. These are nice languages for a bunch of *nix nerds or very specialized engineers but their usage is very limited. For some definition of very limited - the developers you hang out with. The developer world is a big place.
Re: dfmt options
Brian Schott wrote in message news:iobidfcyoneyxrzkh...@forum.dlang.org... First, a disclaimer: I am an idiot for starting this thread. Hahaha. What am I missing? - Enum members each on new line or all on same line - Threshold for array initializers, when exceeded each element is on own line eg auto x = [ item, item, item ];
Re: dfmt options
Andrei Alexandrescu wrote in message news:me2orn$2fjp$1...@digitalmars.com... I think a simple starting point would be to define and enforce automatically one style for all phobos pull requests. -- Andrei And with ddmd, we can do the same.
Re: A few notes on choosing between Go and D for a quick project
Hi. Some points I think are important follow. I can't do much on these myself for now as computer use limited by a spinal injury. 1. Compilation speed of D under reference compiler compares very favourably to most (all?) other compiled languages. This facilitates rapid iteration, which works nicely with the 'plasticity' of D code. This should be emphasized on the landing page, and there should be a few standardised concrete reference points since for better or for worse modern people don't take you seriously if you don't quantify it. 2. D is a very powerful language whose essential features are easy to learn. Coming from C, and not having written a great deal of code since about twenty years ago, it took me a few months to be productive in D (about the same as python, which I learnt shortly before D). The generics and metaprogramming are not so straightforward, but you don't need to use them to be productive very quickly. We should emphasize D can be a native code python (but is more than this if that is what you need) 3. I have said so before (the GroupBy docs) - standard library documentation is 'perfectly clear' if you have a technical mindset and are used to reading formalisms, but it is horrendously intimidating if not (which applies to many people). We need more examples, and they should put the use in context rather than just being tiny fragments - ie show how to do something useful with the function (cf python docs). There should also be a guide to functions writing from point of what one wants to achieve. toLower in std.string, but I need to go to std.ascii for doing the same thing to a character. Eminently logical, but not obvious if you don't know where to look. 4. Need a better guide to libraries and frameworks oriented to how to accomplish common tasks. (I really don't see why you wouldn't bundle vibed with dmd+phobos since small frictions have large consequences when you are starting out). 5. Different channels for tutorials organized by use case (accessible from front page not sidebar) - writing a server, writing a script, pulling data from the Fed website and charting it, simple gui app, simple database app. Take cybershadow's slides comparing nodejs code to vibed code. 6. More user stories accessible from front page and well organised. Make it visual and personal. Facebook (not just warp, but odbc, any other stories), Sociomantic, Adroll, Remedy, etc. 7. It doesn't make sense for D to 'concentrate on XYZ use case' (languages can't be centrally planned - which is not to say identifying impediments is not useful), and nor is it a problem that it 'hasn't gone anywhere' since 2001. Things develop at their own pace, and periods of quiet building are often needed before breaking out into the next stage. An overnight success is a long time indeed in the making. 8. Libraries are a rougher area. RSS, XML, JSON, Redis, databases, MIME, IMAP, HDF5, etc - there are solutions, but nothing standard and no consistency in documentation. 9. Mobile seems important for future of the language but seems the effort of a small number of people. 10. Calling D a systems programming language makes me think I shouldn't use it for non-systems purposes. That's no longer on the front page, but it is the next thing I see here: http://dlang.org/getstarted.html. What proportion of newcomers to D want to use it for systems programming? 11. This week in D. should there be a tour of useful frameworks from code.dlang? 12. a good part of Pandas style functionality is not so hard to do. Vlad Levenfeld has written a framework that may be interesting here, but it is still under development. 13. charting?
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 18:24:51 UTC, Russel Winder wrote: I see no threads in this code! :-) But yes, it certainly shows you can create shared-memory multi-threading this way, but anyone actually doing it would be being very silly. Sending addresses down multiple channels is obvious here and definitely not the right thing to do unless the datum contains an embedded lock which is then used. cf. https://talks.golang.org/2012/10things.slide#3 So now we are going from Go is safe, to well, it is obviously not safe (then, why were you so eager to have a proof ?) but nobody in their right mind would do something like this. But this is only a short snippet. This can happen the same way in a million line codebase, and good luck finding it. Also, the no good programmer would do this is an immediate red flag. Not only programmer will do this, but the one that claim they won't will do it even sooner as they evidently lack self awareness.
Re: dfmt options
On Saturday, 14 March 2015 at 23:51:51 UTC, Walter Bright wrote: On 3/14/2015 4:15 PM, Brian Schott wrote: What am I missing? I'd also suggest making dfmt an algorithm. Then people can use it like map, reduce, filter, etc., in their programs. dfmt as a program then becomes incidental and trivial. I'm not sure if you're trolling or not. I mean, when you said that writing a D lexer and parser was a weekend project I knew that you were, but with this I'm not sure.
Re: dfmt options
On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote: I suggest defining The One True Way and have no configuration options. I hope you like tabs as much as I do.
Re: const as default for variables
On 3/14/2015 3:06 PM, Xinok wrote:
For example, this could be an issue for generic functions:
void foo(T)(T[] arr){
T value = arr[0]; // Mutable or immutable?
}
Not really.
const T value = arr[0];
means that value isn't going to be subsequently reassigned or anything mutated
through it.
Also, you forgot a fifth case where only part of the type is const/immutable:
5. const(T)[] x = ...
The default const'ness would apply to the [] part.
Re: mixin template can't contain statements: workaround?
On Sunday, 15 March 2015 at 01:20:55 UTC, Timothee Cour wrote:
Why can't we allow mixin templates to contain statements, as is
the case
for regular mixins?
Is there a workaround?
here's a dummy example:
template mixin Foo{
//some statement, eg: 'return;'
}
void fun(){
mixin Foo;
}
Note that I can do this with a regular mixin, but template
mixins are
cleaner (esp in more complex examples).
Wouldn't the most basic explanation be that templates cannot
contain statements, therefore mixin templates can't either?
Re: dfmt options
On 3/14/2015 5:01 PM, Orvid King wrote: At which point you realize that The One True Way is wrong, Maybe it's time to transcend that. Correct me if I'm wrong, but I believe the purpose of a formatter is to make the formatting of the code consistent in the way that the user wants it to be. https://golang.org/cmd/gofmt/ Note the lack of configuration. Generally, it's been a big success for Go.
Re: dfmt options
On 3/14/2015 4:58 PM, Brian Schott wrote: On Saturday, 14 March 2015 at 23:51:51 UTC, Walter Bright wrote: On 3/14/2015 4:15 PM, Brian Schott wrote: What am I missing? I'd also suggest making dfmt an algorithm. Then people can use it like map, reduce, filter, etc., in their programs. dfmt as a program then becomes incidental and trivial. I'm not sure if you're trolling or not. I mean, when you said that writing a D lexer and parser was a weekend project I knew that you were, but with this I'm not sure. void format(OutputRange)(string source_desc, ubyte[] buffer, OutputRange output, FormatterConfig* formatterConfig) isn't quite set up as an algorithm. An algorithm would look like: auto format(InputRange)(InputRange r, string source_desc, FormatterConfig* formatterConfig) and would return another input range.
Re: sudo apt-get install dmd
On 3/14/15 11:37 AM, tcak wrote: On Saturday, 14 March 2015 at 17:31:56 UTC, Andrei Alexandrescu wrote: I was looking at easy installation of dmd on ubuntu, and found this: http://d-apt.sourceforge.net/ Should we make it part of the official distribution? Andrei Ubuntu, most of the time, used with GUI. I just click on Download button of DMD, and Firefox opens it with Software Centre, and I click on Install button. Update works in the same way. So, in this case, there is no need for apt-get. Well among other things I'm thinking of getting it programmatically in tools/update.sh. -- Andrei
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 18:33:24 UTC, Russel Winder wrote: On Sat, 2015-03-14 at 18:11 +, Chris via Digitalmars-d wrote: […] This may be part of it. But I know that open source free software in this sector is also written in C/C++ or Java. I haven't seen a single system that was acceptable in Python. Sooner or later they all go back to C. Java will have the same problem as Python regarding shipping source to anyone who knowns how to decompile Java. I just don't see the point in using Python only to rewrite performance critical parts in C/C++ or D. Why not start with D or C from scratch. Also, I know that this Cython and C module mixing becomes a mess very quickly which makes development tricky and deployment a pain in the a**. I believe that as soon as you have to mix languages like that, there is something wrong, and you begin to rely heavily on an infrastructure that helps you to keep track of the whole mess. I would reject C as a language of implementation for everything except small operating systems – which includes many embedded things, most being effectively operating systems. I can see people using C++, but it would be better if they used D, but I doubt this will happen :-( Mixing Python, Cython, and C does require standard compiled project management, but is no worse than pure C, C++ or D systems. I would suggest that the messiness is due to the Python people not doing the Cython and C properly, and the C people objecting to having Python involved. It usually comes down to the people and not the technology. But why do they keep inventing new technologies and compilation methods for Python when it's already s good? Every year I hear now Python is fast, now you can write fast and efficient code in Python, and more often than not it is some C-based stuff, some additional layer of complexity. Try to integrate Python into third party software or some OS framework, and you'll begin to hate it. The question of which version of Python to use is enough to put you off. Some programs are delivered with their own Python version to avoid problems. All this is messy, not clean. I've seen it, and I've done it. I prefer D that gives me native efficiency and can interface with C. No Cython magic needed.
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. [This is a long term issue. Just thought maybe it's time for a conversation about it.] Because immutable is transitive, declaring variables as immutable by default would be problematic. A more practical way would be to make them const. As it is now: 1.int x = 1; // mutable 2.auto x = 1; // mutable 3.const x = 1; // const 4.immutable x = 1; // immutable 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: a) Introduce a new storage class, called 'var' or 'mut'. (Please, no bikeshedding on names at the moment. Let's stay on topic.) b) Use 'auto' as meaning 'mutable' if the initializer is also mutable. Extend 'auto' to allow an optional type, auto T t = initializer; There may be some ambiguity issues with 'auto ref', haven't thought it through. Once there is a non-default way to declare variables as mutable, a compiler switch can be added to change the default to be const. Eventually, the language can default to them being const, with a legacy switch to support the mutable default. Why would this be even slightly useful? If a value is constant, it _should not_ be a variable.
Re: dfmt options
On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote: On 3/14/2015 4:15 PM, Brian Schott wrote: What am I missing? I suggest defining The One True Way and have no configuration options. At which point you realize that The One True Way is wrong, ask for it to be changed, and are then told that it is The One True Way. Take tabs vs. spaces for instance, phobos' style guide states that indents should be 4 spaces, but I'd much prefer it to be a single tab. Correct me if I'm wrong, but I believe the purpose of a formatter is to make the formatting of the code consistent in the way that the user wants it to be.
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 18:33:24 UTC, Russel Winder wrote: On Sat, 2015-03-14 at 18:11 +, Chris via Digitalmars-d wrote: […] This may be part of it. But I know that open source free software in this sector is also written in C/C++ or Java. I haven't seen a single system that was acceptable in Python. Sooner or later they all go back to C. Java will have the same problem as Python regarding shipping source to anyone who knowns how to decompile Java. I just don't see the point in using Python only to rewrite performance critical parts in C/C++ or D. Why not start with D or C from scratch. Also, I know that this Cython and C module mixing becomes a mess very quickly which makes development tricky and deployment a pain in the a**. I believe that as soon as you have to mix languages like that, there is something wrong, and you begin to rely heavily on an infrastructure that helps you to keep track of the whole mess. I would reject C as a language of implementation for everything except small operating systems – which includes many embedded things, most being effectively operating systems. I can see people using C++, but it would be better if they used D, but I doubt this will happen :-( Mixing Python, Cython, and C does require standard compiled project management, but is no worse than pure C, C++ or D systems. I would suggest that the messiness is due to the Python people not doing the Cython and C properly, and the C people objecting to having Python involved. It usually comes down to the people and not the technology. +1 Using Python with C++ for small critical sections reduces our code development and maintenance costs significantly. The C++ constitutes about 3% of our code base. For the rest Python does the job very well. There is no mess, the code base and build system are nicely segregated into performance critical code and the rest. My hope is that D can replace the Python/C++ mix with one language that is both cheap for development/maintenance and achieve the C++ performance when necessary. But even with a single language the performance critical code would still be kept separate. It can often get messy and it's important that only those with specific algorithm and low-level expertise make changes in it. Cheers, Stew
Re: dfmt options
On 3/14/15 6:45 PM, Walter Bright wrote: On 3/14/2015 4:59 PM, Brian Schott wrote: On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote: I suggest defining The One True Way and have no configuration options. I hope you like tabs as much as I do. We'll all have to compromise at some point to have a One True Way, but it'll be worth it. I gave up on my cherished notion of tabs for the Greater Good in Phobos formatting, for example. I think a simple starting point would be to define and enforce automatically one style for all phobos pull requests. -- Andrei
Re: dfmt options
On 15/03/2015 12:15 p.m., Brian Schott wrote: First, a disclaimer: I am an idiot for starting this thread. Moving on... I'm working on a list of configuration options for dfmt - a formatter for D source code. So far I have the following: * Insert spaces between if, while, for, foreach, etc loops and the ( * Allman vs One True Brace Style (Already supported by commant-line switch) * Operators at the end of the old line vs beginning of the new line when wrapping long expressions. * Insert space after the ) of a cast expression * Make case and default match the indent level of the enclosing switch * Labels for loops always on their own line vs the same line as the loop * Labels outdented one level * Label indentation matches the most recent switch * Hard limit for line length * Soft limit for line length What am I missing? This might be a bit of a out of scope, but auto generating of DDOC comments for symbols would be nice. Basically to enforce before e.g. committing that everything has been explained. Perhaps also change existing ones to match e.g. params and return variable.
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 11:51:54 UTC, Russel Winder wrote: On Sat, 2015-03-14 at 09:44 +, deadalnix via Digitalmars-d wrote: […] No, that is the classical prove that god do not exist trick. This is up to Go to prove it is safe. Hint: it isn't. This could go on ad nauseam. It is up to C, C++, D, Rust, Fortran, Java, Python, Ruby, etc., etc. to prove they are safe. Hint: they aren't. The closest there is is Spark Ada, and that has problems. When it come to concurrency, Rust is. None of the other are. Now you can double down on trying to make me prove a negative, but that only makes you sound like a religious zealot.
Re: A few notes on choosing between Go and D for a quick project
On 3/14/2015 3:19 PM, deadalnix wrote: On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote: The point is, with a library abstraction the core language can be simplified. D's ability to create user defined literals largely ends the pressure to make more complicated and specialized core language literals. It makes it sounds like you don't know the spec about string literals. I know I don't know what you're driving at :-)
Re: dfmt options
On 3/14/2015 4:15 PM, Brian Schott wrote: What am I missing? I suggest defining The One True Way and have no configuration options.
Re: Dlang seems like java now,but why not let d more like C# Style?
On Saturday, 14 March 2015 at 13:52:13 UTC, Craig Dillabaugh wrote: I don't have any C# experience so I can't compare those languages much, but I've heard people say their are D / C# similarities. Anyway, this isn't a criticism of your comment, I was just curious what (other than the shared C++ syntax heritage) you find so Java-like in D? Cheers, Craig I've been using C# pretty extensively for the last year or so. Superficially, at least, C# and D are pretty similar, eg auto (var), foreach, lambdas, classes and structs. C# is more biased towards OO than D. Metaprogramming is significantly weaker in C#. This is probably the one area where I've wished for some of D's functionality. Reflection is all runtime. C# has some AST capabilities that D doesn't. This is probably the main area where I envy C# when using D. And C# has LINQ, which when combined with the last point is fricken awesome.
Re: dfmt options
2015-03-15 0:15 GMT+01:00 Brian Schott via Digitalmars-d digitalmars-d@puremagic.com: What am I missing? I suggest you fire a recent version of Visual Studio and go to tools / Options / Tet editor / C# (or C/C++) / Formatting. There you got a bunch of formatting options. Maybe not all of them are relevant, but that can give some good ideas. There can be an (almost) endless stream of possibility for formatting, especially if you throw in the comments (e.g. put the comment for enums at the EOL, or always comment using '/**'...). Personal request: enforce that every block has a set of parenthesis.
Re: dfmt options
On Saturday, 14 March 2015 at 23:15:35 UTC, Brian Schott wrote:
First, a disclaimer: I am an idiot for starting this thread.
Moving on...
I'm working on a list of configuration options for dfmt - a
formatter for D source code.
So far I have the following:
* Insert spaces between if, while, for, foreach, etc loops and
the (
* Allman vs One True Brace Style (Already supported by
commant-line switch)
* Operators at the end of the old line vs beginning of the new
line when wrapping long expressions.
* Insert space after the ) of a cast expression
* Make case and default match the indent level of the
enclosing switch
* Labels for loops always on their own line vs the same line as
the loop
* Labels outdented one level
* Label indentation matches the most recent switch
* Hard limit for line length
* Soft limit for line length
What am I missing?
Maybe nobody else does this, but I prefer to write switch cases
in an indented block style.
switch (expr)
{
case 0:
//Do stuff
end;
case 1 .. case 9:
//Do other stuff
end;
default:
//Do default stuff
}
In the same way, I indent attribute labels in classes/structs.
I'm positive almost nobody else does that, however, so it's
probably not an option you want to enable.
class Test
{
private:
//Methods, members
public:
//etc.
}
Re: Dgame revived
On Saturday, 14 March 2015 at 15:19:20 UTC, Namespace wrote: On Saturday, 14 March 2015 at 03:12:56 UTC, stewarth wrote: On Friday, 13 March 2015 at 14:23:27 UTC, Namespace wrote: On Friday, 13 March 2015 at 10:51:22 UTC, stewarth wrote: On Friday, 13 March 2015 at 08:31:28 UTC, Namespace wrote: The most of Dgame is ready, only the tutorials are missing to arrive to the release state. Is there anything you wanted absolutely in Dgame? A module, a tutorial? Since I removed the TileMap tutorial I may want to write an replacement how you could easily built one with Sprites. Any further ideas? At the end of this month I wanted to participate on One game a month (http://www.onegameamonth.com/). Mainly with C++ but I think it would be a good test for Dgame, if I would programm some games with it. And it could be helpfull to get more attention on D. Nice work :) I just tried on Arch Linux x86_64 and it worked out of the box using dub. Time to upgrade my Dgame projects !! Thanks, Stew How many do you have? Four in total, all half finished -- just the way I like them :-) I do intend to finish them off, I just need to find more the time between work and sleep... Cheers, Stew Even half finished, I would like to see them. http://dgame-dev.de/?page=show is also called Work in Progress ;) When I get something to a state that I'm comfortable sharing I'll let you know. The hardest part is the resources, graphics etc. My sprites are pretty embarrassing :) Cheers, Stew
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 23:47:24 UTC, Walter Bright wrote: On 3/14/2015 3:19 PM, deadalnix wrote: On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote: The point is, with a library abstraction the core language can be simplified. D's ability to create user defined literals largely ends the pressure to make more complicated and specialized core language literals. It makes it sounds like you don't know the spec about string literals. I know I don't know what you're driving at :-) That we have a large number of string literals, in the core of the language, many of which could probably be language construct.
[Issue 259] Comparing signed to unsigned does not generate an error
https://issues.dlang.org/show_bug.cgi?id=259 --- Comment #56 from Andrei Alexandrescu and...@erdani.com --- What's left to do about this? --
Re: const as default for variables
Const is the inconvenience of immutability without its benefit. That would be a poor default, IMO.
Re: A few notes on choosing between Go and D for a quick project
On 3/14/2015 8:41 PM, deadalnix wrote: On Saturday, 14 March 2015 at 23:47:24 UTC, Walter Bright wrote: On 3/14/2015 3:19 PM, deadalnix wrote: On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote: The point is, with a library abstraction the core language can be simplified. D's ability to create user defined literals largely ends the pressure to make more complicated and specialized core language literals. It makes it sounds like you don't know the spec about string literals. I know I don't know what you're driving at :-) That we have a large number of string literals, in the core of the language, many of which could probably be language construct. I haven't looked into it - anything in particular you have in mind? I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are.
Re: const as default for variables
On Sunday, 15 March 2015 at 05:08:54 UTC, Walter Bright wrote: On 3/14/2015 8:50 PM, deadalnix wrote: Const is the inconvenience of immutability without its benefit. That would be a poor default, IMO. It's utility is in self-documenting encapsulation. It also turns out that it offers optimization possibilities for ARC systems. You'll have to explain yourself, as there is nothing obvious here. I see how immutable can be leveraged to optimize, but I don't think const offers the same capabilities.
Re: dfmt options
On Sunday, 15 March 2015 at 00:51:30 UTC, Meta wrote:
Maybe nobody else does this, but I prefer to write switch cases
in an indented block style.
switch (expr)
{
case 0:
//Do stuff
end;
case 1 .. case 9:
//Do other stuff
end;
default:
//Do default stuff
}
In the same way, I indent attribute labels in classes/structs.
I'm positive almost nobody else does that, however, so it's
probably not an option you want to enable.
class Test
{
private:
//Methods, members
public:
//etc.
}
I do the same.
On actual topic : having look at Eclipse C++ codestyle options
may give many useful hints.
Re: A few notes on choosing between Go and D for a quick project
On Sunday, 15 March 2015 at 04:32:25 UTC, Walter Bright wrote:
That we have a large number of string literals, in the core of
the language,
many of which could probably be language construct.
I haven't looked into it - anything in particular you have in
mind?
Not one precisely, but I'm sure we don't need as many as we have.
, `, q, q{, r, x. I've never used several of theses and I'm
sure most people here would say the same.
I'd also prefer to get rid of /+ +/ comments, I thought they'd
be more useful than they are.
I use them all the time, and cringe whenever I code in something
else because i don't have them. Once you have /* comments */ in
some piece of code, you can't comment blocks without going
through hoops. that is very annoying./+ comments +/ are one of
the simple thing that makes coding in D much more pleasant.
Re: const as default for variables
On 3/14/2015 8:50 PM, deadalnix wrote: Const is the inconvenience of immutability without its benefit. That would be a poor default, IMO. It's utility is in self-documenting encapsulation. It also turns out that it offers optimization possibilities for ARC systems.
Re: A few notes on choosing between Go and D for a quick project
On 3/13/2015 2:20 PM, bearophile wrote:
something like a var keyword to denote mutable values,
Transitive const may make this problematic.
I don't understand, but perhaps you misunderstood me. I am talking about
variables. In strict mode they are constant by default. This means in this code
both x and y are immutable:
auto x = 10;
foreach (y; 0 .. 10) {}
So in strict mode if you want them mutable you need a new keyword like var:
var x = 10;
foreach (var y; 0 .. 10) {}
Given:
mutable int* p;
int* q = p;
q cannot be made immutable. But q can be made const.
static full tracking of memory ownership,
Makes the language significantly more complex.
You are probably right. But it also gives good things back to a system language.
In the last years I've seen that taking twice the time to write my code is a
good deal if later I can avoid wasting stressful hours searching and fixing
bugs. So now I am willing to pay a high price up front when I code to avoid some
bugs later. I have friends that have taken a look at Rust and have dismissed it
for being too much fussy and hard to get code to compile (despite probably with
practice the Rust rules should become quite simpler to follow), but Rust looks
like the right language for me and I'd like the same qualities in the language
that I like more (D). So in the end I don't know what's the best solution for D.
Rust has indeed done a good job selling people on the complexity of their
annotation system. But I think starting with 'return ref' and D's ability to do
inference we're actually in good shape with a far simpler system.
less implicit casts (because now we have the safe int(x) sytnax),
I think D does very well with implicit casts.
I am not sure of that. Implicit casts cause some troubles, you can see this if
you program for a while in a language with no or with very little implicit casts
like Haskell, and F#.
In D we have some implicit casts also because the cast(int)x syntax is
dangerous. But now we can write safe casts with the int(x) syntax, so there's
less need of naked implicit casts.
Again, too many casts can cause bugs.
I have used languages that did not have implicit casting (Pascal) and didn't
have a positive experience with it. It didn't detect a single actual bug, and
managed to be quite annoying.
Value Range Propagation is a big win.
Re: Deadcode: A code editor in D
On Friday, 13 March 2015 at 16:33:38 UTC, Kingsley wrote: 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 Could you put the code on github or somewhere so I can have play with it? I don't care what state the code is in or if stuff fully works or not - just want to have a go. I'm writing an intellij plugin for D https://github.com/kingsleyh/DLanguage and curious to see other approaches to editing D code. I will see if I can find some time this weekend to put it on github. /Jonas
Re: [NEEDING HELP] Translation of Ali Cehreli's book in French
On Saturday, 14 March 2015 at 08:38:06 UTC, Raphaël Jakse wrote: Le 13/03/2015 16:45, Olivier Pisano a écrit : What is the next chapter to need translation ? It should be const ref Parameters and const Member Functions but Scroph might want to translate it as it seems to be the following of his chapter. I don't know what he wants to do. So you could translate Constructor and Other Special Functions? Hum, I have just translated const ref Parameters and const Member Functions this week (it is the chapter I sent you on Thursday). I am going to do Constructor and Other Special Functions, then. :)
Re: A few notes on choosing between Go and D for a quick project
On Fri, 2015-03-13 at 07:55 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote: The removal of shared memory multi-threading in favour of using processes and channels should never be underestimated as a Really Good Thing™ that other native code languages (*) have failed to do anything about. Thus Go wins, others lose. That's a marketing success as well. Go didn't remove shared memory multi-threading, it just unrecommends it. That's quite unremarkable from a programming language design standpoint, but as discussed that's not always crucial for success. -- Andrei I think you need to show a bit of Go code that uses threads to be able to back up that claim. -- 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 Saturday, 14 March 2015 at 09:03:11 UTC, Russel Winder wrote: On Fri, 2015-03-13 at 07:55 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote: The removal of shared memory multi-threading in favour of using processes and channels should never be underestimated as a Really Good Thing™ that other native code languages (*) have failed to do anything about. Thus Go wins, others lose. That's a marketing success as well. Go didn't remove shared memory multi-threading, it just unrecommends it. That's quite unremarkable from a programming language design standpoint, but as discussed that's not always crucial for success. -- Andrei I think you need to show a bit of Go code that uses threads to be able to back up that claim. No, that is the classical prove that god do not exist trick. This is up to Go to prove it is safe. Hint: it isn't.
Re: A few notes on choosing between Go and D for a quick project
On Fri, Mar 13, 2015 at 08:12:15PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 3/13/15 6:32 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Mar 13, 2015 at 04:14:30PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 3/13/15 3:14 PM, Walter Bright wrote:
On 3/13/2015 12:01 PM, weaselcat wrote:
On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
On 3/13/2015 3:34 AM, bearophile wrote:
Strict mode is a D2 with immutable+@safe+pure by default,
Note that you can get this largely by starting a module with the
following:
immutable @safe pure:
As far as I'm aware, there's no way to mark functions impure this
way other than lexical location. Am I incorrect?
You are correct, which is why D also supports:
immutable @safe pure {
... nice declarations ...
}
... naughty declarations ...
The bottom line is we need a way to undo attributes. -- Andrei
Which people have been clamoring for, for a long time now.
That's why we need it! :o) -- Andrei
Yes, and it's about time it finally got acknowledged! :-P
T
--
Notwithstanding the eloquent discontent that you have just respectfully
expressed at length against my verbal capabilities, I am afraid that I must
unfortunately bring it to your attention that I am, in fact, NOT verbose.
[Issue 14223] TimSort algorithm is incorrect
https://issues.dlang.org/show_bug.cgi?id=14223 --- Comment #2 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/323b512596470227893f3682474db2b4df36a673 Fix Issue 14223 https://github.com/D-Programming-Language/phobos/commit/4abe95ef5b9f67ae072147befdda9200aa0c2061 Fix Issue 14223 https://github.com/D-Programming-Language/phobos/commit/35bf4918ccbb5e3e1cdaf38e84d1d19b5365045d Merge pull request #3029 from Xinok/issue_14223 Fix Issue 14223 - TimSort algorithm is incorrect --
Re: embedding Pyd in Windows program
On Saturday, 14 March 2015 at 00:28:59 UTC, Ellery Newcomer wrote: On Friday, 13 March 2015 at 19:05:59 UTC, Matt wrote: example code, see if I can figure it out, but if you can advise, that would be fantastic. Thank you for all the help so far, it's really been appreciated My penitence for not putting this information on readthedocs. I've tried the hello.d example from GitHub, and get the error message: Error: template instance py_eval!string template 'py_eval' is not defined Unfortunately, that's all I seem to get. Is py_eval not deprecated in 0.9.4? hmm. that's odd. are you trying to build with dub? the only examples that build with dub are in examples/dub. the rest use distutils. Yeah, dub is what I'm using. Actually, I made a mistake regarding the py_eval. I'm including the pyd modules in a module other than the one that has my main() function, so they weren't visible. I feel like a proper idiot for that one.. So I set up a separate project to test the samples exactly. The simple_embedded sample seems to work no problem. I haven't gotten round to trying the shared_embedded, yet, but I will do at some point. Does pyd have any documentation, or are we working from the source for understanding the functions?
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 23:10:21 UTC, Andrei Alexandrescu wrote: On 3/13/15 2:02 PM, Almighty Bob wrote: The language reference is pretty abysmal too. EG... ... The page on templates starts with scope and instantiation details. The examples at the start have alias parameters which aren't explained until half way down the page. The language reference is fine if arid. One shouldn't learn the language from its reference. It should be, however, complemented by tutorials. -- Andrei On the language reference: The D documentation as an introduction is readable, though large. Relative to that, the DLib documentation hurts. http://dlang.org/arrays.html http://dlang.org/phobos/std_array.html When I was new to PHP, I can tell you that the php.net/funcname method of learning was a big help. It redirected me to the appropriate manual page and manual pages had code snippets, often provided in the comments section. As an example, I want to do something random, and the PHP docs are much easier to understand. http://php.net/rand http://dlang.org/phobos/std_random.html -Charles
Re: A few notes on choosing between Go and D for a quick project
On Fri, 2015-03-13 at 20:12 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 3/13/15 5:54 PM, deadalnix wrote: On Saturday, 14 March 2015 at 00:34:35 UTC, Ziad Hatahet wrote: On Fri, Mar 13, 2015 at 6:45 AM, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: The removal of shared memory multi-threading in favour of using processes and channels should never be underestimated as a Really Good Thing™ that other native code languages (*) have failed to do anything about. Thus Go wins, others lose. Except that Go does not really remove shared memory multithreading; it is still possible to get data races (which is why they have a race detector). They provide channels, but nothing is preventing races other than convention. On the other hand, Rust (a native code language) offers a much superior solution, with compile-time enforcement of data sharing. Rust may indeed be superior to Go on this. It will be interesting to see if Rust, once formally released to world, makes an impression on the rise of Go. I certainly hope so, since writing Rust code is nicer than writing Go code. I suspect not. Go marketed itself as a better C (as C++ did originally), and got some Python folk and a lot of PHP folk to switch: Go's main traction is in the Internet, networking, Web applications arena despite claiming to be a systems programming language. Rust is pitching against C++ as D does. C++ folk appear to be locked-in in a way that means Rust and D need to rethink the pitch. How very true, but, by the time you run into data races, you are pretty much commited to go. Sad. Why? In any CSP-like system, it is possible to get deadlock, livelock and races. However debugging them is nigh on trivial compared to the effort required with shared-memory multi threading. PyCSP and Python-CSP as well as Go show this. I'm surprised Russel fell for it. -- Andrei Fell for what? -- 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 Fri, 2015-03-13 at 00:22 -0700, Walter Bright via Digitalmars-d wrote: On 3/12/2015 11:57 PM, Russel Winder via Digitalmars-d wrote: How about lining up some features for removal. Easier said than done. I've proposed a couple things for removal, but got a lot of pushback. Some things have been successfully removed: Pushback can be ignored, and indeed should in some cases. Java is going to come to this battle when primitive types finally get removed from the language. . octal literals C should be incinerated for the 0777 abomination. At least 0o777 can work reasonably. . 'bit' data type . builtin complex numbers Electronics folk love these. Many people use Python exactly for this type. . NCEG floating point comparison . typedef . local operators new delete C++, Fortran, and Java are big, complicated languages, that keep getting bigger and more complicated because of the obsession with backward compatibility. D is already a big, complicated language. If people like straighforward (not necessarily simple) languages, then the inference is quite easy. Has any language been successful at abandoning their user base (i.e. existing code)? Going from D1 to D2 nearly destroyed D. I'm not eager to try that again. The war is being played out in the Python 2/3 arena certainly. Interestingly though there are fewer and fewer Python 2 hold outs. Their holding out has made Python 3 change a little, and for the better in my view – even though I refuse to write any Python 2 specific code. -- 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: Dlang seems like java now,but why not let d more like C# Style?
On Saturday, 14 March 2015 at 09:59:05 UTC, dnewer wrote: yes,java is good lang,but i dont think it's better than c#,if no oracle or google support java will less and less. C# is a good and easy lang. i like C# . but,C# cant compiled to native code. So far, I have been searching for a language, like c # write efficiency, but more secure than that of c #, more efficient (runs), stronger (system-level, driving level) An other one is C# must rely on the CLR. but I prefer like Delphi that will need to be compiled into the exe or DLL. so!hope D Lang is a good Select!
Re: Dlang seems like java now,but why not let d more like C# Style?
dnewer: but,C# cant compiled to native code. Soon you will be able to compile C# natively. Bye, bearophile
Re: Post increment and decrement
What exactly is the downside of i++? Suppose the compiler doesn't lower it and I use the expression alone, what is the potential damage?
Re: [NEEDING HELP] Translation of Ali Cehreli's book in French
Le 14/03/2015 09:46, Olivier Pisano a écrit : On Saturday, 14 March 2015 at 08:38:06 UTC, Raphaël Jakse wrote: Le 13/03/2015 16:45, Olivier Pisano a écrit : What is the next chapter to need translation ? It should be const ref Parameters and const Member Functions but Scroph might want to translate it as it seems to be the following of his chapter. I don't know what he wants to do. So you could translate Constructor and Other Special Functions? Hum, I have just translated const ref Parameters and const Member Functions this week (it is the chapter I sent you on Thursday). I am going to do Constructor and Other Special Functions, then. :) Oh, sorry, I should have double checked that before I sent this. All right, mutex given on Constructor and Other Special Functions ;-).
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 08:40:53 UTC, Russel Winder wrote: On Fri, 2015-03-13 at 16:13 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 3/13/15 2:22 PM, Russel Winder via Digitalmars-d wrote: On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-d wrote: […] File(/tmp/a).byChunk(4096).joiner.startsWith(s) […] How do you mean conversely? Maybe you meant incidentally? -- Andrei In functional languages, each stage in the pipeline returns Option to avoid error handling. Go does not give you this facility as it refuses to allow activity without proper error checking. So if byChunk returns a failed read, functional language just carry on, Go would force the error check, D does… D throws an exception that you would catch with a try block(or scope(failure) )? I've never seen Go praised for its error handling, it is always the opposite. Go error handling is verbose and ugly. http://blog.golang.org/error-handling-and-go
Re: A few notes on choosing between Go and D for a quick project
Russel Winder: (*) IPython grew out of Python and become the de facto system, but was a mess structurally. IPython is splitting into IPython the original thing and Jupyter all the UI related stuff Jupyter looks like a nice idea and a nice project. I'd like to understand how Jupyter compared to Sage. Bye, bearophile
Dlang seems like java now,but why not let d more like C# Style?
yes,java is good lang,but i dont think it's better than c#,if no oracle or google support java will less and less. C# is a good and easy lang. i like C# . but,C# cant compiled to native code. So far, I have been searching for a language, like c # write efficiency, but more secure than that of c #, more efficient (runs), stronger (system-level, driving level)
Re: [NEEDING HELP] Translation of Ali Cehreli's book in French
Le 13/03/2015 16:45, Olivier Pisano a écrit : What is the next chapter to need translation ? It should be const ref Parameters and const Member Functions but Scroph might want to translate it as it seems to be the following of his chapter. I don't know what he wants to do. So you could translate Constructor and Other Special Functions?
Re: A few notes on choosing between Go and D for a quick project
On Fri, 2015-03-13 at 16:13 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 3/13/15 2:22 PM, Russel Winder via Digitalmars-d wrote: On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-d wrote: […] File(/tmp/a).byChunk(4096).joiner.startsWith(s) […] How do you mean conversely? Maybe you meant incidentally? -- Andrei In functional languages, each stage in the pipeline returns Option to avoid error handling. Go does not give you this facility as it refuses to allow activity without proper error checking. So if byChunk returns a failed read, functional language just carry on, Go would force the error check, D does… -- 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
[Issue 14283] New: [2.067-b4]: Spurious this is not an lvalue deprecation message for auto ref arguments
https://issues.dlang.org/show_bug.cgi?id=14283
Issue ID: 14283
Summary: [2.067-b4]: Spurious this is not an lvalue
deprecation message for auto ref arguments
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: slud...@outerproduct.org
auto ref should deduce this argument to non-ref to avoid a deprecation
message showing up for valid code. The original place where this was triggered
was for std.typecons.scoped, where all arguments are declared as auto ref.
---
class C {
void foo() {
bar(this);
}
}
void bar()(auto ref C) {}
---
(3): Deprecation: this is not an lvalue
--
Re: A few notes on choosing between Go and D for a quick project
On Sat, 2015-03-14 at 09:09 +, weaselcat via Digitalmars-d wrote: […] I've never seen Go praised for its error handling, it is always the opposite. Go error handling is verbose and ugly. http://blog.golang.org/error-handling-and-go Go's mechanism of error handling is for me a horrible regression to 1960's programming. However, the feedback from those who really have drunk the Kool-Aid is interesting: the tension between the way of working and number of error in released systems does appear to indicate that they may be getting many fewer errors. However some of the tortuous argumentation about how the coding of error is the right way forward does smack a bit of Stockholm Syndrome. -- 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 Fri, 2015-03-13 at 14:51 +, Chris via Digitalmars-d wrote: […] [1] The problem is that all these nice Python and R implementations are practically useless for real world applications. Too slow, too cumbersome, too many dependencies. It has to be rewritten anyway. (I'd be happy, if they used at least C.) I am not sure which real world you are living in, but I have Python code that executes computationally intensive codes at least as fast as C, C++, and Fortran. R is slow in comparison. Python code is generally easier to read and write than C, C++ and Fortran, so not cumbersome. Dependencies depends on what you want to use in any programming languages so all fail on that metric. No-one in 2015 should be writing any application in C; it is too low-level a language for the current state of programming. In the real world as I know it people use Python for masses of stuff and it does the job well. Statisticians use R. -- 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 Fri, 2015-03-13 at 07:59 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 3/13/15 7:34 AM, Russel Winder via Digitalmars-d wrote: […] It is not Python or R or Julia the language that people choose, it is the superstructure built on top. So for Python, it is Pandas, Matplotlib, SciPy, NumPy. And the ability to use ready made C, C++ and Fortran libraries. That's right. Offer solid value, and make learning the language just aftermath. Again, that's why I'm pushing for vibe. -- Andrei That's OK for its domain of event-driven systems, but there is much, much more. If D is to compete in the financial computing arena where Python and R currently rule, there needs to be all the libraries for doing time series analysis, and rendering them graphically. There also needs to be a workflow that fits the users of the domain. The market leader is currently Jupyter (*) in the finance places I have connection with. The point here is that these folk (and all the bioinformatics, and others using computers for modelling systems) need a highly interactive, stitched together code fragment, based system. 1960s edit-compile-run workflows do not work for these people. REPLs sort of work, but not well. Jupyter really gets these people moving. They are writing HTML/PDF documents with embedded, executable code. It is the 2015s version of literate programming. Except that they are writing about their domain, not about the code. What D should do is ensure that it can be a language usable from Jupyter? (*) IPython grew out of Python and become the de facto system, but was a mess structurally. IPython is splitting into IPython the original thing and Jupyter all the UI related stuff that grew on IPython but made it messy. The new structuring makes things better and allows Jupyter to be clearly not just a Python thing. So you can run R, Julia,… as well as Python as the code fragments. -- 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: Dlang seems like java now,but why not let d more like C# Style?
On Saturday, 14 March 2015 at 10:04:15 UTC, bearophile wrote: dnewer: but,C# cant compiled to native code. Soon you will be able to compile C# natively. Bye, bearophile i know some thing about .net native. but its too late.i dont think microsoft will rranslate all libiary to native. and even c# can be compile natively. i dont think C# will support to can be used to write a driver!
Re: Post increment and decrement
On Saturday, 14 March 2015 at 10:11:27 UTC, Casper Færgemand wrote: What exactly is the downside of i++? Suppose the compiler doesn't lower it and I use the expression alone, what is the potential damage? AFAIK, there's no guarantee in C/C++ that i++ will be optimized to ++i at all. i++ requires a temporary, this can be trivially optimized away in most cases but an overloaded post-increment can make this much more difficult an example is iterators in C++. Post increment requires you to make a copy of the iterator, increment the current one, and evaluate the copy. Pre-increment just requires you to increment the iterator then evaluate it.(This might not even be true anymore, compilers are pretty smart nowadays.) In D, I don't think it matters that much as already discussed. It's just good form, I believe.
[Issue 14225] [REG2.067a] GDB: error reading variable (string + dup)
https://issues.dlang.org/show_bug.cgi?id=14225 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Keywords||symdeb --
[Issue 14253] [REG2.067b3] std.traits.ParameterStorageClassTuple gives compiler errors when encountering 'return' functions
https://issues.dlang.org/show_bug.cgi?id=14253 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Targeting Vulkan and SPIR-V
On Friday, 13 March 2015 at 18:44:18 UTC, karl wrote: Spir-V may be producable from HLL tools, but that doesn't mean it's perfectly ok to use any HLL. Capability for HLL-to-spir is exposed mainly for syntax sugar and shallow precompile optimisations, but mostly to avoid vendor-specific HLL bugs that have plagued GLSL and HLSL (those billion d3dx_1503.dll on your system are bugfixes). Plus, to give the community access to one or several opensource HLL compilers that they can find issues with and submit for everyone to benefit. So, it's mostly to get a flawless opensource GLSL compiler. Dlang's strengths are simply not applicable directly. Though with a bit of work can actually be applied completely. (I've done them in/with our GLSL/backend compilers) - malloc. SpirV and such don't have malloc. Fix: Preallocate a big chunk of memory, and implement a massively-parallel allocator yourself (it should handle ~2000 requests to allocate per cycle, that's the gist of it). atomic_add on a memory location will help. If you don't want to preallocate too much, have a cpu thread poll while a gpu thread stalls (it should stall itself and 6 other threads) until the cpu allocates a new chunk for the heap and provides a base address. (hope the cpu thread responds quickly enough, or your gpu tasks will be mercilessly killed). - function-pointers, largely a no-no. Extensions might give you that capability, but implement as big switch-case tables. With the extensions, you will need to guarantee an arbitrary number (64) of threads all happened to call the same actual function. - stack. I don't know how to break it to you, there's no stack. Only around 256 dwords, that 8-200 threads get to allocate from. Your notion of a stack gets statically flattenized by the compilers. So, your whole program has e.g. 4 dwords to play around and have 64 things hide latency, or 64 dwords but only 4 threads to hide latency - and is 2-4x slower for rudimentary things (and utterly fail at latency hiding, becoming 50 times slower with memory-accesses), or 1 thread with 256 dwords, which is 8-16 times slower at rudimentary stuff and 50+ times slower if you access memory even if cached. Add a manually-managed programmable memory-stack, and your performance goes poof. - exceptions. A combined issue of the things above. Combine the limitations of function-pointers and stack, and I hope you get the point. Or well, how pointless the exercise to get Dlang as we know and love it on a gpu. A single-threaded javascript app on a cpu will beat it at performance on everything that's not trivial. The reason to use D for kernels / shaders would be for its metaprogramming, code-generation abilities and type-system (slices and structs in particular). Of course you wouldn't be allocating heap memory, using function pointers or exceptions. There's a still a lot that D has to offer without those. I regularly write thousands of lines of D in that subset. P.S. D is in pretty much the same boat as any other C-based language w.r.t. stack space. You have to be careful with the stack in OpenCL C, you would have to be careful with the stack in SPIR-D.
Re: A few notes on choosing between Go and D for a quick project
On Saturday, 14 March 2015 at 09:12:31 UTC, Russel Winder wrote: Why? In any CSP-like system, it is possible to get deadlock, livelock and races. However debugging them is nigh on trivial compared to the effort required with shared-memory multi threading. PyCSP and Python-CSP as well as Go show this. I am not sure if CSP alone is the main reason for why people use Go for micro services. I guess it is the combined focus on high concurrency, simplicity and stability that makes it suitable for the kind of things you would use a new language for: smaller projects with specific demands. I'm surprised Russel fell for it. -- Andrei Fell for what? Andrei doesn't grok that Go has an overall better infrastructure for writing high concurrency applications that are bottle necked by network traffic. D lacks: 1. stack protection for fibers 2. non-hogging GC 3. a simple language that makes it easy to read external library code 4. channels And that' only to get started competing, add infrastructure adoption and eco system and the competition is already lost. D+vibe.d is a nice offering, but not a winning horse if comes down to a race. Competing on Go's terms will not lead anywhere. D would be better off going for a free niche, like game servers, non-C++ game programming etc.
Re: A few notes on choosing between Go and D for a quick project
On Sat, 2015-03-14 at 09:44 +, deadalnix via Digitalmars-d wrote: […] No, that is the classical prove that god do not exist trick. This is up to Go to prove it is safe. Hint: it isn't. This could go on ad nauseam. It is up to C, C++, D, Rust, Fortran, Java, Python, Ruby, etc., etc. to prove they are safe. Hint: they aren't. The closest there is is Spark Ada, and that has problems. -- 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
