Re: Coedit 1 gold released
On 2015-06-11 11:51, Brian Schott wrote: Would it? Coedit is written in Pascal. Really? I had no idea. I just assumed it was written in D. If it's written in Pascal then there's no excuses [1] :) Anyway, it wouldn't hurt :) [1] http://wiki.freepascal.org/FPC_PasCocoa -- /Jacob Carlborg
Re: Shortest way to allocate an array and initialize it with a specific value.
On Thursday, 11 June 2015 at 07:57:47 UTC, Per Nordlöw wrote:
On Wednesday, 10 June 2015 at 22:03:52 UTC, Ali Çehreli wrote:
Another option:
void main()
{
auto a2 = new ubyte[5];
But this causes an extra zero-initialization of a2.
a2[] = 0xAA;// -- Assign to all elements
Is
auto a2 = value.repeat(size).array;
better in this regard?
Yes, it uses `uninitializedArray()` if the length is known (which
it is for `repeat()`):
https://github.com/D-Programming-Language/phobos/blob/master/std/array.d#L111
Re: Encapsulate return value in scoped
On Thu, 11 Jun 2015 09:01:04 + Yuxuan Shui via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: A x = scoped!A(10); use auto x = scoped!A(10);
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 10:17:26 UTC, Ola Fosheim Grøstad wrote: People here often request features you can only ask for after years of programming experience. This shows that there is a lot of experience in the D community. Without experience D wouldn't be where it is, having only limited resources. Language designers that design more than one language tend to make smaller and tighter languages as they gain design experience and get better at delegating nice-to-have-but-not-essential-features to libraries. Then brainfuck wins.
Re: What is D's minimum requirements on Mac?
Whee, $99/year.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 07:08:02 UTC, Ola Fosheim Grøstad wrote: On Thursday, 11 June 2015 at 03:04:50 UTC, Rikki Cattermole wrote: The biggest difference between the D community in general and other communities is actually quite simple. Experience. Indeed! The world has never seen a more experienced collection of freshmen language designers. Theory does not apply. Rust and Go are doomed. Now, now. It is true that bad and frustrating experience with other languages drove me (and probably others) to D. D is open to suggestions, while other languages still live by the one size fits all mentality. std.allocator is a good example of trying to offer a variety of different memory models. What's wrong with that? People here often request features you can only ask for after years of programming experience. This shows that there is a lot of experience in the D community. Without experience D wouldn't be where it is, having only limited resources. That's right. As mentioned we accept bugs, we accept issues. Submit and accept, no regrets. Discuss them at length and fix them when a good solution is found. A ground breaking GC will emerge from the synthesis of the unsurpassable number of endless GC debates. That is the sanctimony of meritocracy. A non-breaking solution will eventually be found. Time is no issue in such an important matter. We just wait and a solution will emerge, through discussions based on pure experience. Not only that but we look for problems to fix. This is the mentality of a good software engineer. One who doesn't care about their own pride or ego but genuinely wants to make good code. This community is the UNICEF of programming. We are all meek and humble individuals, divine servants of humanity. Just trying to create the best tool possible for our own daily tasks. People in these forums all express gratitude when they are on the loosing end of a technical debate. Nobody go silent or resort to rhetorical excesses. Ever. We are all grateful for being proven wrong, because that is how we become better programmers. But we keep coming back. So it cannot be that bad ;) In a lot of ways this makes us the best developers on the planet. It would explain a lot, including how other language communities snob us yet we look at them for ideas. Indeed, we never snob anyone, and they all snob us. Especially the ignorant C++ community that never mentions us. Because this hurts some people. The D crowd doesn't snob other languages, in fact, people here often point at features of other languages saying Da', can I have this, pleze?. All most of us do is to point out the strengths of D when ever the occasion arises, trying to convince people to at least give it a try. Of course it can be annoying when D is snobbed at while its features are being ripped. Talking about UNICEF, feel free to be a humble servant of humani-D. The more the merrier!
Re: Daily downloads in decline
On Wednesday, 10 June 2015 at 17:04:56 UTC, Dennis Ritchie wrote: It seems to me that many still do not understand what the Rust :) Many have not seen Lisp, so they think that Rust is something innovative. At least from the syndrome of angle brackets and other syntactic shaluhi its developers are not disposed of, but only made matters worse. This language is not better than the same C++. I have seen and used lisp, still I think that Rust is innovative. Namely the combination of very good typesystem, best to date (because fully compiler-verified) resource management and AST macros is innovative. But what I like the most about is that it wasn't created in a stike of genius by a guy in a basement, but instead by continuous refinement of many ideas with strong desire to keep the language small and consistent.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 09:14:00 UTC, Chris wrote: Now, now. It is true that bad and frustrating experience with other languages drove me (and probably others) to D. Suggesting that a language like D is based on experience in comparison to Go is... not right... given the experienced language designers behind Go. If experience is key, then Go wins. People here often request features you can only ask for after years of programming experience. This shows that there is a lot of experience in the D community. Without experience D wouldn't be where it is, having only limited resources. Language designers that design more than one language tend to make smaller and tighter languages as they gain design experience and get better at delegating nice-to-have-but-not-essential-features to libraries. Features have a higher cost than initial implementation. Walter has been more open to feature suggestions than many other designers, and implemented them in a timely fashion, that is true. And that can be both a good thing and a bad thing, but obviously engaging and fun from a community point of view. The process around Go is very closed. So not fun. Rust is inbetween. Just trying to create the best tool possible for our own daily tasks. Just like everybody else? But we keep coming back. So it cannot be that bad ;) ;o) Indeed, we never snob anyone, and they all snob us. Especially the ignorant C++ community that never mentions us. Because this hurts some people. The D crowd doesn't snob other languages, in fact, people here often point at features of I see jabs at other languages, especially the ones that is stealing attention from D: Rust, Go, C++… I guess it is all natural, but it can be perceived as envy by outsiders, and there is no advantage to it. I really wish people would stop complaining about other languages having the same features as D without giving credit. It is impossible to figure out exactly where ideas from features come from, but most features predate even C++ if being first is the main point. The hard part about designing an imperative language is not the individual features, the palette is given. The hard part is turning it into beautiful whole that is greater than the sum of the parts. And that is important, but difficult (or impossible) to achieve. It is kinda like music, I sometimes create a melody that I feel I have heard something similar to, but I cannot pin it down to anything specific. So phrases of the melody might be things I have picked up. However, if we go for novelty the roots for musical elements might go 300 years back or more. Far beyond my knowledge horizon. A month ago I made a poptune-sketch I kinda find catchy, but familiar. But which tune is it familiar to? Who should I credit? Maybe you can help me out? https://soundcloud.com/bambinella/anad-dreamer-sketch
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 07:11:33 UTC, rsw0x wrote: actually making a good GC for D is difficult because the only type of barrier you can use it hardware protection faults. The performance dropoff isn't _that_ bad from what I've read in various papers. I should have an article up in a few weeks detailing my summer research project on this. That sounds like an interesting project! I think it is possible to modify the language slightly and make (to me) acceptable restrictions on where GC is allowed to get better performance. Still, I am sure you will be able to find some new opportunities in your research project. I am looking forward to see what you come up with.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 10:52:08 UTC, weaselcat wrote: heavily disagree honestly. Ken Thompson - B? Rob Pike - Limbo? Joking? Not your kind of experience? But still experience... So there is a limit to how far experience can take you. Anyway, language designers that do multiple languages on their own accord appears to stay within the same paradigm. Kind of like an artist trying to perfect the aesthetics of their original piece. So if you don't like the original, you'll probably not like the sequel either...
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 10:17:26 UTC, Ola Fosheim Grøstad wrote: On Thursday, 11 June 2015 at 09:14:00 UTC, Chris wrote: Now, now. It is true that bad and frustrating experience with other languages drove me (and probably others) to D. Suggesting that a language like D is based on experience in comparison to Go is... not right... given the experienced language designers behind Go. If experience is key, then Go wins. People here often request features you can only ask for after years of programming experience. This shows that there is a lot of experience in the D community. Without experience D wouldn't be where it is, having only limited resources. Language designers that design more than one language tend to make smaller and tighter languages as they gain design experience and get better at delegating nice-to-have-but-not-essential-features to libraries. Features have a higher cost than initial implementation. Walter has been more open to feature suggestions than many other designers, and implemented them in a timely fashion, that is true. And that can be both a good thing and a bad thing, but obviously engaging and fun from a community point of view. The process around Go is very closed. So not fun. Rust is inbetween. Just trying to create the best tool possible for our own daily tasks. Just like everybody else? But we keep coming back. So it cannot be that bad ;) ;o) Indeed, we never snob anyone, and they all snob us. Especially the ignorant C++ community that never mentions us. Because this hurts some people. The D crowd doesn't snob other languages, in fact, people here often point at features of I see jabs at other languages, especially the ones that is stealing attention from D: Rust, Go, C++… I guess it is all natural, but it can be perceived as envy by outsiders, and there is no advantage to it. I really wish people would stop complaining about other languages having the same features as D without giving credit. It is impossible to figure out exactly where ideas from features come from, but most features predate even C++ if being first is the main point. The hard part about designing an imperative language is not the individual features, the palette is given. The hard part is turning it into beautiful whole that is greater than the sum of the parts. And that is important, but difficult (or impossible) to achieve. It is kinda like music, I sometimes create a melody that I feel I have heard something similar to, but I cannot pin it down to anything specific. So phrases of the melody might be things I have picked up. However, if we go for novelty the roots for musical elements might go 300 years back or more. Far beyond my knowledge horizon. A month ago I made a poptune-sketch I kinda find catchy, but familiar. But which tune is it familiar to? Who should I credit? Maybe you can help me out? https://soundcloud.com/bambinella/anad-dreamer-sketch I have the same problem when composing. Some things sound vaguely familiar but I cannot put my finger on it. Usually I don't follow an idea that somehow sounds familiar. In your case, the song reminds me of: Wouldn't It Be Good - Nik Kershaw https://www.youtube.com/watch?v=AYMAtbq0bjY (God, I'm so old!) :-)
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 10:52:06 UTC, Chris wrote: vaguely familiar but I cannot put my finger on it. Usually I don't follow an idea that somehow sounds familiar. Well, in this case it might sound familiar to me because it is based manipulated sample of another tune I made... But I cannot know for sure ;) In your case, the song reminds me of: Wouldn't It Be Good - Nik Kershaw https://www.youtube.com/watch?v=AYMAtbq0bjY (God, I'm so old!) :-) That's not all that old... (hrmph!) But I don't see the resemblance so it's not from there, if it is from anywhere outside my own head.
Encapsulate return value in scoped
Is there a way to encapsulate return value into scoped?
Say I have a function that returns a new object:
X new_x(T t...) {
//Super complex input processing
return new X(something);
}
And I want to encapsulate the result using scoped, is that
possible? Can I just do:
return scoped!X(something).
?
If I understand correctly, the data will be blitted, but the
destructor will be called, so the returned object will be in
invalid state.
[Issue 14683] New: atomicop comparison returntype incorrect
https://issues.dlang.org/show_bug.cgi?id=14683 Issue ID: 14683 Summary: atomicop comparison returntype incorrect Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: minor Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: r9shacklef...@gmail.com for example, atomicOp!(integer, integer) returns a type of integer that's either 0 or 1. Shouldn't it return a boolean? --
Re: Encapsulate return value in scoped
On Thursday, 11 June 2015 at 08:48:22 UTC, Yuxuan Shui wrote:
Is there a way to encapsulate return value into scoped?
Say I have a function that returns a new object:
X new_x(T t...) {
//Super complex input processing
return new X(something);
}
And I want to encapsulate the result using scoped, is that
possible? Can I just do:
return scoped!X(something).
?
If I understand correctly, the data will be blitted, but the
destructor will be called, so the returned object will be in
invalid state.
It's even weirder than I thought, this:
import std.stdio,
std.typecons;
class A {
int b;
~this() {
writeln(Des);
}
this(int x) {
b=x;
writeln(Cons);
}
}
auto x() {
A x = scoped!A(10);
writeln(x.b);
writeln(Return x);
return x;
}
void main() {
auto tx = x();
writeln(Return main);
}
Produce output:
Cons
Des
0
Return x
Return main
Which I totally don't understand.
Re: Coedit 1 gold released
On Thursday, 11 June 2015 at 06:28:08 UTC, Jacob Carlborg wrote: On 2015-06-10 08:57, Andrei Alexandrescu wrote: I can haz OSX pliz pliz ok thx bye -- Andrei Having D/Objective-C merged [1] would make it a lot easier. [1] https://github.com/D-Programming-Language/dmd/pull/4321 +1000
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
I really wish people would stop complaining about other languages having the same features as D without giving credit. It is impossible to figure out exactly where ideas from features come from, but most features predate even C++ if being first is the main point. Hear, hear, is it so unlikely that one footstep should fall in the footprint of another? The hard part about designing an imperative language is not the individual features, the palette is given. The hard part is turning it into beautiful whole that is greater than the sum of the parts. And that is important, but difficult (or impossible) to achieve. This is it. Great languages (IMO) have condensed their features down to the smallest set of orthogonal features that they could manage. This makes the language easier to reason about, to share code, to maintain code, to learn, to read code, even writing it is often easier! Right now I feel that D is growing in 'features' and corner cases beyond the point where I want to explore it's depths. It's gone from a swim in the bay into crossing the Channel. I always think about Herb Sutters Guru of the Week column and how it made me think ugh - too many oddities to learn. I could be wrong and I hope I am. It's quite a nice twist that the thread discussing which language is better branched into what version of English is the right one - as if such a thing is meaningful. Arguing about definitions and terminology is surely such a useless diversion.
Re: Shortest way to allocate an array and initialize it with a specific value.
On Thursday, 11 June 2015 at 08:33:46 UTC, Daniel Kozák wrote:
On Wed, 10 Jun 2015 20:22:17 +
Adel Mamin via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
ubyte[5] a = 0xAA; // Fine. Five 0xAA bytes.
auto a2 = new ubyte[5]; // Fine. Five 0 bytes.
Now, let's say, I want to allocate an array of a size, derived
at run time, and initialize it to some non-zero value at the
same time. What would be the shortest way of doing it?
import std.stdio;
struct Ubyte(ubyte defval) {
ubyte v = defval;
alias v this;
}
void main() {
auto a2 = new Ubyte!(0xAA)[5];
writeln(a2);
}
I like this one :-)
Re: foreach with a default range
On Thursday, 11 June 2015 at 08:24:25 UTC, Dmitry Olshansky wrote:
On 11-Jun-2015 11:18, w0rp wrote:
A thought just came to me. When I'm implementing foreach for a
container, I'm left with the choice of using a range for a
container or
opApply. I've found often that I prefer the ranges, as it's
easy for me
to write a range that satisfies @nogc @safe pure nothrow, etc.
This is
because the ranges don't call delegates which are less
restrictive,
which opApply does.
I've been thinking about how you would implement opApply so
that it
could allow you to run @system code while the iteration itself
is @safe,
but then I had another idea. Could we allow foreach to look
for a method
(UFCS include) for producing a default range for an object,
from a
function named 'range'?
In short this...
foreach(elem; container) {}
Could be transformed into this.
foreach(elem; container.range()) {}
Already works. Just define opSlice for container that returns a
range and then:
foreach(elem; container) {}
is lowered to:
foreach(elem; container[]) {}
Ah! I did not know that. I shall use that in future.
Re: Daily downloads in decline
On Wednesday, 10 June 2015 at 22:01:22 UTC, Dennis Ritchie wrote: No bounds checking of arrays. Huh? Whatever gave you that impression? Well, if Rust created for huge projects, why these macros? I fear that macros are simply not needed in C-family languages. The macros help in D? Write unbearable code? :D They're a lot cleaner than C's macros. AFAIK, Rust's writef() equivalent is implemented with them.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 19:57:15 UTC, Russel Winder wrote: Please note, OED (which is the definition of the English language As Tofu Ninja said, a dictionary only (partly) reflects the current usage of a language. Look up the word sophisticated and you'll find out that it had a different meaning in the 1920s. In fact, dictionaries invariably lag behind and as soon as a new version is published it's already out of date. Also, do not forget that those who create and revise dictionaries are not representative of all speakers. They will typically be part of an elite that defines the language in terms of their own belief system. Most certainly so in Great Britain. whatever any USA upstarts may try to pretend) I shouldn't really comment on this cultural snobbery. However, different linguistic communities have different linguistic realities. The English spoken in the US, Ireland or Scotland is not the same as in England. The linguistic reality for a speaker in Liverpool is not the same as for a speaker in London. But who cares, English is beyond the grasp of Oxford now. You only have yourselves to blame, nobody asked you to go and spread the language all over the globe. is gearing up to define they as both singular and plural, thus at a stroke solving all the he/she, she/he, (s)he, it faffing. On Wed, 2015-06-10 at 19:05 +, via Digitalmars-d wrote: On Wednesday, 10 June 2015 at 18:41:56 UTC, Adam D. Ruppe wrote: That's actually a good idea, you might not have noticed it, but I rarely use he alone as a general term and I notice it when other people do. Little things like this in language can make a difference in people's feelings and cause discomfort in the environment. Sure, follow your own ethics, but that won't work in an international environment as a rule without coming off as censorship. You cannot force people globally to follow a local culture. I also try to cut down on the term you as a general term since people might think I mean them personally. At some point you just have question intent if there is a misunderstanding, rather than control every expression or else everything becomes it: A bad programmer create bugs when it edits its files And if people force you to write it, it is quite reasonable to wonder what else they strongly object to so you better just stay silent. I really do try to cut down on the term you?
Re: Coedit 1 gold released
On Thursday, 11 June 2015 at 06:28:08 UTC, Jacob Carlborg wrote: On 2015-06-10 08:57, Andrei Alexandrescu wrote: I can haz OSX pliz pliz ok thx bye -- Andrei Having D/Objective-C merged [1] would make it a lot easier. [1] https://github.com/D-Programming-Language/dmd/pull/4321 Would it? Coedit is written in Pascal.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 10:17:26 UTC, Ola Fosheim Grøstad wrote: On Thursday, 11 June 2015 at 09:14:00 UTC, Chris wrote: Now, now. It is true that bad and frustrating experience with other languages drove me (and probably others) to D. Suggesting that a language like D is based on experience in comparison to Go is... not right... given the experienced language designers behind Go. If experience is key, then Go wins. heavily disagree honestly. Ken Thompson - B? Rob Pike - Limbo? Joking?
Re: What is D's minimum requirements on Mac?
On Wednesday, 10 June 2015 at 18:55:27 UTC, Adam D. Ruppe wrote: I'm still tempted to grab a used Mac so I can port my display stuff to Cocoa and test it, but Macs are outrageously expensive and I hate them, so want to spend as little as possible. What does dmd minimally require on a mac? If I got like a 10.5 would that work? i'm considering something like http://www.amazon.com/Apple-MB138LL-Intel-Drive-Combo/dp/B0006HU49Y/ref=sr_1_5?ie=UTF8qid=1433962021sr=8-5keywords=used+mac+mini You can try to register as a developer: https://developer.apple.com/programs/ and get beta versions of OSX and install them on virtual box. Not sure how much it costs.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 11:20:12 UTC, Kagamin wrote: Then brainfuck wins. Always.
Re: Daily downloads in decline
On Thursday, 11 June 2015 at 08:54:54 UTC, Marc Schütz wrote: On Wednesday, 10 June 2015 at 22:01:22 UTC, Dennis Ritchie wrote: No bounds checking of arrays. Huh? Whatever gave you that impression? Well, if Rust created for huge projects, why these macros? I fear that macros are simply not needed in C-family languages. The macros help in D? Write unbearable code? :D They're a lot cleaner than C's macros. AFAIK, Rust's writef() equivalent is implemented with them. Rust's macros make me wish mixins weren't so ugly to use, or we had proper AST macros.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote: Another backwards annotation is nothrow. I don't really care if something doesn't throw, I care when it throws, because then I have to do something (or my program may crash unexpectedly). I recently debugged such no crash bug: the code decided that the program shouldn't crash and caught exception and silenced it, the program indeed didn't crash, but misbehaved. It was a critical bug, which blew into the face of the customer, there was nothing in the log, we had to connect to the customer's database and debugged with catching first chance exceptions. What we should do if we had no access to the customer's database? If the code wouldn't catch the exception, the application would crash and we would have an entry in the log and debugged it quickly. That's how nothrow works in practice.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 10/06/2015 12:38, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: I think Rust has an advantage over Go in the name Mozilla alone, they are more idealistic than Google. Agreed. In concrete terms, Mozilla is a non-profit, whereas Google is not. Google can easily drop (or reduce) support for Go if it doesn't serve whatever business goal they want. Or alternatively they might not be interested in evolving Go (or Go's toolchain) in directions that are useful for other people, but have little value for their business or technical goals. Mozilla may see in their heart the will to develop a language such as Rust in part for the benefit of the programming community in general. Even if they don't, and they remain mainly concerned with Servo/browser development, if Rust's core goals are of developing large-scale programs, with strong static checking / verification (safeness), and being able to write highly optimized/fast programs - then that is already a project vision that can make the language highly successful. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Shortest way to allocate an array and initialize it with a specific value.
On Thu, 11 Jun 2015 11:43:25 +
via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Thursday, 11 June 2015 at 08:33:46 UTC, Daniel Kozák wrote:
On Wed, 10 Jun 2015 20:22:17 +
Adel Mamin via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
ubyte[5] a = 0xAA; // Fine. Five 0xAA bytes.
auto a2 = new ubyte[5]; // Fine. Five 0 bytes.
Now, let's say, I want to allocate an array of a size, derived
at run time, and initialize it to some non-zero value at the
same time. What would be the shortest way of doing it?
import std.stdio;
struct Ubyte(ubyte defval) {
ubyte v = defval;
alias v this;
}
void main() {
auto a2 = new Ubyte!(0xAA)[5];
writeln(a2);
}
I like this one :-)
small enhancment:
struct Ubyte(ubyte defval = 0)
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 09:14:00 UTC, Chris wrote: Because this hurts some people. The D crowd doesn't snob other languages, in fact, people here often point at features of other languages saying Da', can I have this, pleze?. http://forum.dlang.org/thread/mki78k$6k5$1...@digitalmars.com?page=8#post-cnprllcbxwinzclvwtib:40forum.dlang.org
[Issue 14682] [REG2.037] Incorrect interpretation of ~ []
https://issues.dlang.org/show_bug.cgi?id=14682 --- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com --- I think it should be fixed, because if you want to append [], you can do so explicitly, but if you want to append an empty array, there is no convenient syntax for it. I ran into it with the following code: run([make, -f, makeFileName, all, kindle, pdf, verbatim, LATEST= ~ latest, ] ~ (config.noDateTime ? [NODATETIME=nodatetime.ddoc] : []) ~ [ ], sourceDir); Here I wanted to make an array element conditionally present, so I used: ] ~ (cond ? [elem] : []) ~ [ inside an array literal. The problem is that this line's meaning changes on whether it is the last line in the array literal or not. --
Re: Automatic documentation builds
On 6/11/15 7:04 AM, Steven Schveighoffer wrote: On 6/11/15 8:21 AM, Vladimir Panteleev wrote: I've put together a CI system of sorts that builds the documentation for all pull requests. Hopefully this should avoid the dlang.org build breaking again in the future. It integrates with GitHub as well, and on repositories covered by Brad's auto-tester, will create a second status for the documentation. The whole thing is Digger-powered, so uses the same code as Digger and http://digger.k3.1azy.net/trend/. Sample page: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/31744d2fb90cf25ef1778f52ef640abc56c494c2/ Source code: https://github.com/CyberShadow/DAutoTest Cool fact: When you request a built file (e.g. a .html page), it'll fetch the data directly from the Git cache repository, through a named pipe (bypassing disk) connected to a long-living Git process. This is also done transparently for included resources (images, CSS etc.) On a PR I was doing for ddoc, the old and new seem to be reversed: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/6d3c95ecc5422ae1d5bd6f3308da78b733175ba7/ While randomly browsing through for a PR to see this magic on, I ran across an error page: http://dtest.thecybershadow.net/artifact/website-9bbe7b16aaa20f28b879722609308a024a12ae52-005ef14643f10a0919ace4bd80bcfa44/web/library-prerelease/std/range/merge.html I get it when I click on the New link for merge.html on this page: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/82878d02c06ec112663fd953e78d541dda69a38e/ I believe that, like Steven says, the Old and New links are reversed (since the diff shows that merge.html to be new in this PR but the new page shows up under the Old link), and perhaps the tool should better handle added/deleted files. In any case this is a seriously awesome tool!
[Issue 14675] template specialization for T: T* and T: T[] has issues with IFTI
https://issues.dlang.org/show_bug.cgi?id=14675 --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com --- Well, if T: T* isn't going to be removed, and we cannot use IFTI with it, we should at least update the documentation. The documentation doesn't seem accurate, since specializations do not disqualify IFTI obviously. There is definitely room to add docs to template specialization. I'll see if I can update the docs to guide people away from making these mistakes. (In reply to Kenji Hara from comment #1) It takes one place in template parameter list. When a template argument is _explicitly given_ on the position, it will deduce the parameter T, by matching the argument to the form `T*`. That's the point. Even if you explicitly give template argument, T is always deduced. This doesn't make a whole lot of sense, because in most cases, when you EXPLICITLY specify a template parameter, you are specifying the parameter on the left of the colon, and it only matches the specialization if it matches the pattern on the right: foo(T : ulong)(T t) foo(T : U*, U)(T t) foo!int(1)); // T == int foo!(int *)(null); // T == int * But in this case, the instantiation doesn't specify T, it specifies, well, I don't know *what* it specifies! foo(T : T*)(T *) foo!(int *)(null); // T == int So you CAN'T specify T directly, and you can't access the parameter you DID specify directly. I feel like it's shorthand for this: foo(U : T*, T)(U *t) But U isn't actually listed or accessible. BTW, the above has the same issue with IFTI. I think this is an anti-pattern that should always be avoided. And I think that the T* and T[] forms are the only specializations that fall under this pattern. Is there any other time you can explicitly instantiate a template, but the parameter you explicitly pass is not used for the actual parameter? --
Re: Automatic documentation builds
On 6/11/15 8:21 AM, Vladimir Panteleev wrote: I've put together a CI system of sorts that builds the documentation for all pull requests. Hopefully this should avoid the dlang.org build breaking again in the future. It integrates with GitHub as well, and on repositories covered by Brad's auto-tester, will create a second status for the documentation. The whole thing is Digger-powered, so uses the same code as Digger and http://digger.k3.1azy.net/trend/. Sample page: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/31744d2fb90cf25ef1778f52ef640abc56c494c2/ Source code: https://github.com/CyberShadow/DAutoTest Cool fact: When you request a built file (e.g. a .html page), it'll fetch the data directly from the Git cache repository, through a named pipe (bypassing disk) connected to a long-living Git process. This is also done transparently for included resources (images, CSS etc.) On a PR I was doing for ddoc, the old and new seem to be reversed: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/6d3c95ecc5422ae1d5bd6f3308da78b733175ba7/ -Steve
Re: Python's features, which requires D
On Saturday, 23 May 2015 at 10:58:33 UTC, Kagamin wrote:
On Saturday, 23 May 2015 at 02:36:14 UTC, Dennis Ritchie wrote:
For example, the code in Python looks quite natural:
a = [[int(j) for j in input().split()] for i in range(n)]
About D-code, I can not say:
auto a = stdin
.byLine
.map!(l = l.splitter.map!(to!int).array)
.take(n);
Well, list comprehension is built into language in python (and
not in D), such level of support is definitely more streamlined.
Yes, but D is also possible to create a strong inclusion of list
comprehensions. Here's the proof:
https://github.com/pplantinga/delight
Probably the coolest feature in Delight is list comprehensions.
Delight uses functions in std.algorithm to generate an iterable
range. The syntax is similar to Python's. See the last two
lines of the code above for an example.
print { i * 2 for i in 0 .. 5 where i ^ 2 less than 5 }
# prints [0, 2, 4]
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 6/10/15 6:43 PM, Tofu Ninja wrote: On Thursday, 11 June 2015 at 01:30:08 UTC, weaselcat wrote: 'he' has been a gender neutral pronoun for centuries, and as far as I'm aware this has its roots in latin using 'man'(vir?) as a gender neutral pronoun. I am just saying that personally it sounds odd to me to use it that way and I don't hear people use it that way either. In gender neutral contexts where you don't know the gender I almost always say/hear they/their. Maybe he losing its gender neutrality is a recent thing, I don't know. Maybe its just a thing with mid-westerners? It does appear to be a recent thing, if you trust Wikipedia: http://en.wikipedia.org/wiki/Gender-specific_and_gender-neutral_pronouns#Generic_he Also the earlier section on Historical and dialectal gender-neutral pronouns is interesting: maybe we can start using a or yo as pronouns.
[Issue 14289] WindowsException should not attempt to parse code 0
https://issues.dlang.org/show_bug.cgi?id=14289 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14288] std.windows.registry should use std.windows.syserror
https://issues.dlang.org/show_bug.cgi?id=14288 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/3024e3d3be066a055031264ad4381c6117c3425d fix Issue 14288 - std.windows.registry should use std.windows.syserror --
Re: Daily downloads in decline
On Thursday, 11 June 2015 at 13:35:25 UTC, QAston wrote: For me simple templates + simple macros are clearer than complicated templates + ctfe + mixins. There are tradeoffs there, with ctfe being an optimization at the expense of build time. On the other hand dmd is much much faster than the Rust compiler which doesn't do ctfe. all three D compilers are faster than rustc, it's honestly very slow and was one of my major gripes with rust - I get distracted easily and like short build times : )
[Issue 14682] [REG2.037] Incorrect interpretation of ~ []
https://issues.dlang.org/show_bug.cgi?id=14682 --- Comment #7 from Kenji Hara k.hara...@gmail.com --- (In reply to Vladimir Panteleev from comment #5) I think it should be fixed, because if you want to append [], you can do so explicitly, but if you want to append an empty array, there is no convenient syntax for it. What you want is: define `[]` as a representation of identity element (http://en.wikipedia.org/wiki/Identity_element) for arbitrary concat operation? Hmm, probably I can agree it's necessary thing. --
[Issue 14681] Add a way to specify a file import's contents on the command line
https://issues.dlang.org/show_bug.cgi?id=14681 --- Comment #2 from Kenji Hara k.hara...@gmail.com --- The ':' prefix allows the compiler to tell apart import paths and key/value pairs. I think it's not good. Indeed in most platform `:` cannot be in file name, but it actually depends on the external file system. Is there more better syntax for the named import string? --
Re: dub : multiple dmd instances
On Thursday, 11 June 2015 at 14:07:10 UTC, weaselcat wrote: On Thursday, 11 June 2015 at 14:01:12 UTC, Temtaime wrote: Hi all ! I wonder why there's no option to tell dub split files into groups of equal size and then run N instances of dmd ? I think it can greatly reduce compile time. dub options are a bit hidden. dub build --help --build-mode=VALUE Specifies the way the compiler and linker are invoked. Valid values: separate (default), allAtOnce, singleFile --parallelRuns multiple compiler instances in parallel, if possible. After rereading your question, that actually isn't exactly what you were asking for. Sorry for the noise, I need my coffee.
Re: Daily downloads in decline
On Thursday, 11 June 2015 at 13:35:25 UTC, QAston wrote: It's a matter of taste and I won't advocate for Rust on D forums. It is not required. But it would be nice if you could post a topic in DLearn like this just about Rust :) http://forum.dlang.org/thread/ujatnyfraqahrmfok...@forum.dlang.org Syntax doesn't bother me at all as long as it's consistent and in both D and Rust it is. For me, the syntax is very important. I want my code could understand everything, not just programmers superclass. It's no secret that many people avoid encounters with Lisp because of its syntax. For me simple templates + simple macros are clearer than complicated templates + ctfe + mixins. Yes, probably, it's hard to disagree. There are tradeoffs there, with ctfe being an optimization at the expense of build time. On the other hand dmd is much much faster than the Rust compiler which doesn't do ctfe. Yes, but LDC will overtake the Rust compiler and without CTFE. In addition, the compiler Rust also based on LLVM. So to compare DMD and Rust compiler does not make sense.
dub : multiple dmd instances
Hi all ! I wonder why there's no option to tell dub split files into groups of equal size and then run N instances of dmd ? I think it can greatly reduce compile time.
Re: dub : multiple dmd instances
On Thursday, 11 June 2015 at 14:01:12 UTC, Temtaime wrote: Hi all ! I wonder why there's no option to tell dub split files into groups of equal size and then run N instances of dmd ? I think it can greatly reduce compile time. dub options are a bit hidden. dub build --help --build-mode=VALUE Specifies the way the compiler and linker are invoked. Valid values: separate (default), allAtOnce, singleFile --parallelRuns multiple compiler instances in parallel, if possible.
[Issue 14682] [REG2.037] Incorrect interpretation of ~ []
https://issues.dlang.org/show_bug.cgi?id=14682 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #6 from Steven Schveighoffer schvei...@yahoo.com --- Could you do: (config.noDateTime ? [NODATETIME=nodatetime.ddoc] : string[].init) Ugly I know :) I agree the usage is surprising. And actually, it's not the same as appending , because is not null, whereas [] is. --
[Issue 14684] New: Circular import cases Must be imported as FileName error
https://issues.dlang.org/show_bug.cgi?id=14684 Issue ID: 14684 Summary: Circular import cases Must be imported as FileName error Product: D Version: D2 Hardware: x86_64 OS: Mac OS X Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: sigurdbergsv...@gmail.com Created attachment 1527 -- https://issues.dlang.org/attachment.cgi?id=1527action=edit Minimalistic example I have a structure src |- main.d |- RootClass.d |- MyPackage/ |- PackagedClass.d If I add an import in *RootClass* to *myPackage.PackagedClass*, it's fine. If I remove that import, and an import to *PackagedClass* to *RootClass*, it fine. But with both, I get an error form DMD saying: ../src/RootClass.d(1): Error: module PackagedClass from file ../src/myPackage/PackagedClass.d must be imported with 'import PackagedClass;' I'v included a minimalistic example. While creating the example I noticed that this issue did not appear if both *RootClass* and *PackagedClass* was in the same directory/package. --
Re: Daily downloads in decline
On Thursday, 11 June 2015 at 13:16:13 UTC, Dennis Ritchie wrote: Do templates Rust is better than D? Those are considerably less powerful: - can only have type arguments - no variadic argument list support - no arbitrary condition constraints (thus only partial duck typing support) On the other hand they have one important advantage: all type arguments must comply to one or more trairs and thus bodies of generics are checked before institation. You are only allowed to call methods and operations of generic arguments that are defined in relevan trait. This is huge win for code hygiene compared to D. Any sort of more advanced meta-programming things can only be done via AST macros which is currently the biggest downside in my eyes when it comes to features. Though quite some people like that.
Re: Shortest way to allocate an array and initialize it with a specific value.
On 6/11/15 7:51 AM, Daniel Kozák via Digitalmars-d-learn wrote:
On Thu, 11 Jun 2015 11:43:25 +
via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Thursday, 11 June 2015 at 08:33:46 UTC, Daniel Kozák wrote:
On Wed, 10 Jun 2015 20:22:17 +
Adel Mamin via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
ubyte[5] a = 0xAA; // Fine. Five 0xAA bytes.
auto a2 = new ubyte[5]; // Fine. Five 0 bytes.
Now, let's say, I want to allocate an array of a size, derived
at run time, and initialize it to some non-zero value at the
same time. What would be the shortest way of doing it?
import std.stdio;
struct Ubyte(ubyte defval) {
ubyte v = defval;
alias v this;
}
void main() {
auto a2 = new Ubyte!(0xAA)[5];
writeln(a2);
}
I like this one :-)
small enhancment:
struct Ubyte(ubyte defval = 0)
import std.typecons;
alias Ubyte(ubyte defval = 0) = Typedef!(ubyte, defval);
I personally like the range solution the best, it has the most flexibility.
-Steve
[Issue 14675] template specialization for T: T* and T: T[] has issues with IFTI
https://issues.dlang.org/show_bug.cgi?id=14675 --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Steven Schveighoffer from comment #2) I feel like it's shorthand for this: foo(U : T*, T)(U *t) But U isn't actually listed or accessible. BTW, the above has the same issue with IFTI. gah, wish I could edit. That should read: foo(U : T*, T)(T *t) --
Re: Encapsulate return value in scoped
On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák wrote: On Thu, 11 Jun 2015 09:01:04 + Yuxuan Shui via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: A x = scoped!A(10); use auto x = scoped!A(10); Thanks! Curious question, why doesn't compiler reject this code?
Re: Encapsulate return value in scoped
On 6/11/15 1:28 PM, Yuxuan Shui wrote: On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák wrote: On Thu, 11 Jun 2015 09:01:04 + Yuxuan Shui via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: A x = scoped!A(10); use auto x = scoped!A(10); Thanks! Curious question, why doesn't compiler reject this code? Because scoped!A implicitly casts to A. -Steve
Re: Encapsulate return value in scoped
On Thursday, 11 June 2015 at 17:34:56 UTC, Steven Schveighoffer wrote: On 6/11/15 1:28 PM, Yuxuan Shui wrote: On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák wrote: On Thu, 11 Jun 2015 09:01:04 + Yuxuan Shui via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: A x = scoped!A(10); use auto x = scoped!A(10); Thanks! Curious question, why doesn't compiler reject this code? Because scoped!A implicitly casts to A. -Steve Thanks! I just found that out myself. Learned 'alias this' in the process.
Re: Encapsulate return value in scoped
On 06/11/2015 11:43 AM, Yuxuan Shui wrote: On Thursday, 11 June 2015 at 17:34:56 UTC, Steven Schveighoffer wrote: On 6/11/15 1:28 PM, Yuxuan Shui wrote: On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák wrote: On Thu, 11 Jun 2015 09:01:04 + Yuxuan Shui via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: A x = scoped!A(10); use auto x = scoped!A(10); Thanks! Curious question, why doesn't compiler reject this code? Because scoped!A implicitly casts to A. -Steve Thanks! I just found that out myself. Learned 'alias this' in the process. Shameless plug: :) http://ddili.org/ders/d.en/destroy.html#ix_destroy.scoped This issue is explained at the end of that section. Ali
Re: Encapsulate return value in scoped
On Thursday, 11 June 2015 at 19:23:49 UTC, Ali Çehreli wrote: On 06/11/2015 11:43 AM, Yuxuan Shui wrote: On Thursday, 11 June 2015 at 17:34:56 UTC, Steven Schveighoffer wrote: On 6/11/15 1:28 PM, Yuxuan Shui wrote: On Thursday, 11 June 2015 at 09:11:47 UTC, Daniel Kozák wrote: On Thu, 11 Jun 2015 09:01:04 + Yuxuan Shui via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: A x = scoped!A(10); use auto x = scoped!A(10); Thanks! Curious question, why doesn't compiler reject this code? Because scoped!A implicitly casts to A. -Steve Thanks! I just found that out myself. Learned 'alias this' in the process. Shameless plug: :) http://ddili.org/ders/d.en/destroy.html#ix_destroy.scoped This issue is explained at the end of that section. Ali Can you explain more about why the destructor is not called when returning a struct? Can't seem to find it in the document.
Reading array of integers readln performance issues
Hi; To learn D better and challanging myself I am tring code computation's with D. There is a question which is about reading a line of integer which consist of 20 elements. My solution fails because Time limit exceeded, I thought it is because of my algorithm first. I realize time limit is exceeded even before my algorithm starts while reading line of integers. I understand this by giving a wrong answer to question after readln statement. I did that to get a wrong answer error but my code still get a Time limit exceed error because readln takes very long time. Can I achieve something faster than code below? auto peopleMoney = stdin.readln().split().map!(a = to!int(a)).array(); if (peopleMoney.length == 20) writeln(:(); Regards Erdem Ps: I do not want to bore you with long code, but I am sending link to whole program anyway if anyone need. http://codeforces.com/contest/549/submission/11537206
.sizeof dynamically allocated array
import std.stdio;
void main()
{
ubyte[] a1 = new ubyte[65];
ubyte[65] a2;
writeln(a1.sizeof = , a1.sizeof); // prints 16
writeln(a2.sizeof = , a2.sizeof); // prints 65
}
Why a1.sizeof is 16?
Re: .sizeof dynamically allocated array
On Thursday, 11 June 2015 at 20:09:38 UTC, Adel Mamin wrote: Why a1.sizeof is 16? sizeof is tied to *type*, not a variable. (I kinda wish a1.sizeof was prohibited, forcing you to say typeof(a1).sizeof so it is clear but whatever). A dynamic array's size is the length variable plus the pointer variable. A static array's size is the content itself. If you want the size of the content in bytes, best way is to do (cast(ubyte[]) a1[]).length or somethign like that - use the length property instead of sizeof.
Re: .sizeof dynamically allocated array
On Thursday, 11 June 2015 at 20:09:38 UTC, Adel Mamin wrote:
import std.stdio;
void main()
{
ubyte[] a1 = new ubyte[65];
ubyte[65] a2;
writeln(a1.sizeof = , a1.sizeof); // prints 16
writeln(a2.sizeof = , a2.sizeof); // prints 65
}
Why a1.sizeof is 16?
ubyte[] is a slice, which is actually a struct. It's more or less
the same as:
struct Slice(T)
{
T* ptr;
size_t length;
}
So sizeof returns the size of the struct, not the size of the
data that its ptr member points to.
ubyte[65] is a static array, which is just a big block of data on
the stack. That's why it returns the expected value for sizeof.
To create a slice of a static array, use the slice operator:
writeln(sizeof(a2[])); //Prints 16
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 06/11/2015 06:52 AM, Chris wrote: In your case, the song reminds me of: Wouldn't It Be Good - Nik Kershaw https://www.youtube.com/watch?v=AYMAtbq0bjY (God, I'm so old!) :-) Oh man, that takes me back. 80's had the best pop music, IMHO. Miss that stuff. Although, I still have trouble accepting anything from that decade as old, but maybe that just dates me too ;)
Re: Daily downloads in decline
On Thursday, 11 June 2015 at 15:03:39 UTC, Dicebot wrote:
Those are considerably less powerful:
- can only have type arguments
- no variadic argument list support
- no arbitrary condition constraints (thus only partial duck
typing support)
On the other hand they have one important advantage: all type
arguments must comply to one or more trairs and thus bodies of
generics are checked before institation. You are only allowed
to call methods and operations of generic arguments that are
defined in relevan trait. This is huge win for code hygiene
compared to D.
Any sort of more advanced meta-programming things can only be
done via AST macros which is currently the biggest downside in
my eyes when it comes to features. Though quite some people
like that.
The fact that there is no support variadiс arguments, it is
really negative.
It is possible that Walter and Andrei against macro because of
this:
macro_rules! o_O {
(
$(
$x:expr; [ $( $y:expr ),* ]
);*
) = {
[ $($( $x + $y ),*),* ]
}
}
fn main() {
let a: [i32]
= o_O!(10; [1, 2, 3];
20; [4, 5, 6]);
assert_eq!(a, [11, 12, 13, 24, 25, 26]);
}
It looks disgusting! ;)
Re: Daily downloads in decline
On Thursday, 11 June 2015 at 15:08:48 UTC, Dicebot wrote: My experience of explaining those concepts to other people indicates otherwise. D templates and mixins are dirty but also very simple concepts that pretty much any new programmers gets quickly and intuitively, learning how to do more complicated magic in a small steps. I totally agree with that, because I checked it on myself. I am a long time did not understand C++ templates, but I pretty quickly realized templates D, which helped me to fully understand the templates C++. As it turned out, I'm not the only one :)
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 06/11/2015 07:31 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Thursday, 11 June 2015 at 11:20:12 UTC, Kagamin wrote: Then brainfuck wins. Always. It *is* very fun to implement. I'm more partial to this one though: https://esolangs.org/wiki/Fuckfuck And then there's http://compsoc.dur.ac.uk/whitespace/
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 06/11/2015 07:37 AM, Bruno Medeiros wrote: On 10/06/2015 12:38, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: I think Rust has an advantage over Go in the name Mozilla alone, they are more idealistic than Google. Agreed. In concrete terms, Mozilla is a non-profit, whereas Google is not. Google can easily drop (or reduce) support for Go if it doesn't serve whatever business goal they want. Or alternatively they might not be interested in evolving Go (or Go's toolchain) in directions that are useful for other people, but have little value for their business or technical goals. Well, Mozilla's really a for-profit owned by a non-profit, which is a little weird. In any case, Mozilla's demonstrated enough times in their history that they're not particularly worried about alienating and ignoring big groups of users. (Heck, they don't even try to promote their products as customizable anymore.) Of course, whether this will actually translate into similar issues with Rust remains to be seen. Hopefully they'll be more reasonable with Rust.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 13:21:27 UTC, Dave wrote: Exceptions are not meant to force handling errors at he source. This attitude is why so many exceptions go unhandled at the upper layers. When you have a top level that calls a function that calls 50 other functions, each that throw a handful or more different exceptions, it's unreasonable to expect the upper layer coder to account for all of them. In fact, in practice they usually don't until bugs arise. This is provably bad practice. I'd rather have an exception unhandled at the top level than discarded at a middle level. Much easier to debug when you get a proper stack trace. Also, the top level handling can be very generic if it's purpose is not to solve the problem but to log it and to allow to use to continue using the other parts of the program as much as possible. If you want to force handling errors at the source they should be part of the return type. Again what errors are worth throwing as exceptions in your paradigm? Which ones are worth returning? This separation is very arbitrary for my taste. Exceptions are for when something went wrong. Returned errors are for when the function can't do what you asked it to do, but that doesn't mean that something went wrong. For example, if you try to write to a file and fail that's an exception, because something went wrong(e.g. - not enough disk space, or a permissions problem). But if you have a function that parses a string to a number and you call it with a non-numeric string - that doesn't necessarily mean that something went wrong. Maybe I don't expect all strings to be convertible to numbers, and instead of parsing each string twice(once for validation and once for the actual conversion) I prefer to just convert and rely on the conversion function to tell me if it's not a number? Note that doesn't mean that every time a function returns an error it's not a problem - they can indicate problems, the point is that it's not up to the callee to decide, it's up to the caller. The conversion function doesn't know if I'm parsing a YAML file and if field value is not a number that just means it's a string, or if I'm parsing my own custom file format and if something specific is not a number that means the file is corrupted. In the latter case, I can convert the returned error to exception(the returned error's type should have a method that returns the underlying result if it's OK and if there was an error raises an exception), but it's the caller's decision, not the callee. Exceptions are not hard fails. They can be if they go unaccounted for (depending on the language/environment). Java has the infamous, NullPointerException that plagues Java applications. C# has the NullReferenceException. Even if they go unaccounted for, you still get a nice stack trace that helps you debug them. Maybe we have different definitions for hard fail... It doesn't really guarantee the functions not annotated as throwing won't crash Combined with other guarantees (such as immutability, thread local storage, safe memory management, side-effect free code, no recursion, etc), you can make a reasonable guarantee about the safety of your code. And a superhero cape, combined with an airplane, airplane fuel and flight school, allow you to fly in the air. Not really sure how to parse this...Doesn't seem like you have any good argument against what I said. Again I said you can make a *reasonable* guarantee. And I am not alone here. If you look at Rust, it really does illustrate a trend that functional programming has been pushing for a long time. Provable guarantees. Problems are very rarely unique. There are a core set of things that happen frequently that cause problems. And these things are easily recognizable by compilers. You can't prevent everything, but you can prevent a good deal of the obvious stuff. This is just an extension of that mindset. So it is not really that outlandish. It is the other restrictions(without getting into a discussion about each and every restriction in the list) that make the code safer - nothrow doesn't really contribute IMO. Without the nothrow, you cannot guarantee it won't cause problems with unhandled errors ;) Seems like a nice guarantee to me. I would at least like this option, because library writers often try to write in an idiomatic way (and I tend to use the most reputable libraries I can find), which gives you some guarantees. The guarantee would be better served by default IMHO though. Even with no throw you can't guarantee a function won't cause problems with unhandled errors - unless you use a very strict definition of handling errors, that include discarding them or crashing the program. nothrow can only guarantee the function won't expose any problems you can use the exceptions mechanism to debug or deal with - not very useful, considering how easy it is to convert an error
Re: DIP80: phobos additions
On 6/11/15 5:17 AM, Steven Schveighoffer wrote: On 6/11/15 4:15 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Wednesday, 10 June 2015 at 20:31:52 UTC, Steven Schveighoffer wrote: OK, thanks for the explanation. I'd do it the other way around: Flag!threadlocal, since we should be safe by default. `RefCounted!T` is also thread-local by default, only `shared(RefCounted!T)` needs to use atomic operations. I may have misunderstood Andrei. We can't just use a flag to fix this problem, all allocations are in danger of races (even thread-local ones). But maybe he meant *after* we fix the GC we could add a flag? I'm not sure. Yes, we definitely need to fix the GC. -- Andrei
Re: Daily downloads in decline
On 6/11/15 9:33 AM, Dennis Ritchie wrote:
On Thursday, 11 June 2015 at 15:03:39 UTC, Dicebot wrote:
Those are considerably less powerful:
- can only have type arguments
- no variadic argument list support
- no arbitrary condition constraints (thus only partial duck typing
support)
On the other hand they have one important advantage: all type
arguments must comply to one or more trairs and thus bodies of
generics are checked before institation. You are only allowed to call
methods and operations of generic arguments that are defined in
relevan trait. This is huge win for code hygiene compared to D.
Any sort of more advanced meta-programming things can only be done via
AST macros which is currently the biggest downside in my eyes when it
comes to features. Though quite some people like that.
The fact that there is no support variadiс arguments, it is really
negative.
It is possible that Walter and Andrei against macro because of this:
macro_rules! o_O {
(
$(
$x:expr; [ $( $y:expr ),* ]
);*
) = {
[ $($( $x + $y ),*),* ]
}
}
fn main() {
let a: [i32]
= o_O!(10; [1, 2, 3];
20; [4, 5, 6]);
assert_eq!(a, [11, 12, 13, 24, 25, 26]);
}
It looks disgusting! ;)
Is that actual Rust code that compiles and runs? -- Andrei
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 16:49:15 UTC, Nick Sabalausky wrote: On 06/11/2015 07:31 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Thursday, 11 June 2015 at 11:20:12 UTC, Kagamin wrote: Then brainfuck wins. Always. It *is* very fun to implement. I'm more partial to this one though: https://esolangs.org/wiki/Fuckfuck And then there's http://compsoc.dur.ac.uk/whitespace/ https://esolangs.org/wiki/Emoticon I think it would be nice to have a language that used smileys for exceptions. if error then :-D
Re: Daily downloads in decline
On Thursday, 11 June 2015 at 17:41:49 UTC, Andrei Alexandrescu
wrote:
It is possible that Walter and Andrei against macro because of
this:
macro_rules! o_O {
(
$(
$x:expr; [ $( $y:expr ),* ]
);*
) = {
[ $($( $x + $y ),*),* ]
}
}
fn main() {
let a: [i32]
= o_O!(10; [1, 2, 3];
20; [4, 5, 6]);
assert_eq!(a, [11, 12, 13, 24, 25, 26]);
}
It looks disgusting! ;)
Is that actual Rust code that compiles and runs? -- Andrei
Yes, this code is working. I took it here:
https://doc.rust-lang.org/stable/book/macros.html#repetition
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 17:42:48 UTC, Ola Fosheim Grøstad wrote: On Thursday, 11 June 2015 at 16:49:15 UTC, Nick Sabalausky wrote: On 06/11/2015 07:31 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Thursday, 11 June 2015 at 11:20:12 UTC, Kagamin wrote: Then brainfuck wins. Always. It *is* very fun to implement. I'm more partial to this one though: https://esolangs.org/wiki/Fuckfuck And then there's http://compsoc.dur.ac.uk/whitespace/ https://esolangs.org/wiki/Emoticon I think it would be nice to have a language that used smileys for exceptions. if error then :-D https://gist.github.com/sprain/be75c6c456146b272178
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 17:45:32 UTC, weaselcat wrote: https://gist.github.com/sprain/be75c6c456146b272178 Ah, that's awsome! Instead of using true and false you get to use thumbs-up and thumbs-down...
Re: Right after allocators: containers or database connectivity?
On 06/09/2015 01:53 PM, Jacob Carlborg wrote: I vote for databases. I also vote for an interface that is independent of ODBC, but ODBC could be one of the drivers that implements this interface. I know that there's a native implementation of the MySQL protocol on code.dlang.org. This is kind of my thought, too. I haven't felt constrained by the lack of containers beyond what's built-in. And if I do, I can look into dcollections. It's arguably an optimization issue anyway. YES, Granted, algorithmic optimization is THE BIGGEST optimization by far, but aside from maybe big data domains it doesn't actually enable you to do things you just plain couldn't do at all otherwise. Databases, OTOH, are something where you either can do it, or you just plain CAN'T. And with D it's currently a bit more on the can't side, especially if you don't want your app tied to just one DBMS. And unlike containers, the state of D databases actually HAS been an issue for me. That said, tossing an ODBC wrapper in phobos doesn't really solve the DB issue. It would certainly be GOOD to have a good ODBC lib for D, no doubt, but: 1. There is apparently question as to whether it belongs in Phobos. 2. There's also question about async I/O. A *LOT* of DB users are also going to be Vibe.d users, so we cannot afford to have problems in this area. Perhaps what we need to look at is getting Vibe's async I/O (or at least some low-level portion of it, if that even makes sense?) into Phobos somehow? 3. As useful as ODBC may be, it still doesn't eliminate the need for direct drivers. 4. What's REALLY needed regarding DBs is a good, well-designed low-level interface capable of handling both ODBC and individual drivers. ORMs should be something separate, built on top of this later. This low-level part might either include NoSQL (if reasonable to do so) or leave NoSQL up to a separate interface (if need be).
Re: Right after allocators: containers or database connectivity?
On 6/11/15 10:59 AM, Nick Sabalausky wrote: 2. There's also question about async I/O. A *LOT* of DB users are also going to be Vibe.d users, so we cannot afford to have problems in this area. Perhaps what we need to look at is getting Vibe's async I/O (or at least some low-level portion of it, if that even makes sense?) into Phobos somehow? BTW I'm unclear about the ODBC async support on OSX and Linux, and Internet searches are not making that crystal clear. Does anyone know? -- Andrei
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
Exceptions are for when something went wrong. Returned errors are for when the function can't do what you asked it to do, but that doesn't mean that something went wrong. You seem to be implying this as a fact, when traditionally this is not how things are done. For example, if you try to write to a file and fail that's an exception, because something went wrong(e.g. - not enough disk Agreed. Traditionally handled with an exception. But if you have a function that parses a string to a number and you call it with a non-numeric string - that doesn't necessarily mean that something went wrong. Maybe I don't expect all strings to be convertible to numbers, and instead of parsing each string twice(once for validation and once for the actual conversion) I prefer to just convert and rely on the conversion function to tell me if it's not a number? Disagree. Traditionally also handled by throwing exceptions. C# throws a Format exception if a parse fails. Java throws...a ParseException. Just for some real-world examples. Note that doesn't mean that every time a function returns an error it's not a problem - they can indicate problems, the point is that it's not up to the callee to decide, it's up to the caller. The conversion function doesn't know if I'm parsing a YAML file and if field value is not a number that just means it's a string, or if I'm parsing my own custom file format and if something specific is not a number that means the file is corrupted. In a lot of C/C++ code a lot of functions just inform you that it failed. Sometimes they push it onto an error queue you can check. Sometimes they throw exceptions. Sometimes the return is an error code itself. But you very rarely see them return an error code AND throw an exception or push on an error queue. If they do they are being redundant. In the latter case, I can convert the returned error to exception(the returned error's type should have a method that returns the underlying result if it's OK and if there was an error raises an exception), but it's the caller's decision, not the callee. The implementer makes the decision on how errors are communicated.The caller has no control over the mechanism minus editing their code. Exceptions are not hard fails. They can be if they go unaccounted for (depending on the language/environment). Java has the infamous, NullPointerException that plagues Java applications. C# has the NullReferenceException. Even if they go unaccounted for, you still get a nice stack trace that helps you debug them. You still would. This is not being debated. However, programmers seem to forget their code is often for customers. They care more that their program just crashed. Very rarely are the exceptions in forms where they can go you know what would fix this?. No. They write a defect up and send it to the company that made the product. Maybe we have different definitions for hard fail... A crash? Or abrupt termination of an entire execution stack? Often unnecessarily? Even with no throw you can't guarantee a function won't cause problems with unhandled errors - unless you use a very strict definition of handling errors, that include discarding them or crashing the program. A very strict definition of handling errors is EXACTLY what I am advocating for. You should be able to do what you want. But when you do something naughty or potentially disruptive, you should inform others. nothrow can only guarantee the function won't expose any problems That's a solid guarantee. I'd advocate that so much I might even go as far as suggesting it as a default ;) If you insist on forcing developers to handle exceptions close to the source, or to explicitly pass them on, I guess it can be useful let them know what it is that they are require to handle/pass on. Exactly. Still, I don't think it's a good idea to needlessly burden people just so you could provide them with the tool to better handle that burden. I am not sure any *real* burden is here. People should be doing this in the form of documentation anyhow. However, if it's part of the definition, the work on documenting a function or type becomes easier. Because functionally they have an idea of what is needed by the language's definition and the header of the function or type. It has panics, which are different from exceptions in that you can't catch them(unless it's from another thread), but close in their usage to what I have in mind when referring to exceptions - they don't allow you to go on with what you where trying to do, but allow you to debug the problem and/or back down from it gracefully. I know very little about Rust. I only recently encountered a discussion about RAII where one of the developers said Rust has RAII but no exceptions. That is the only reason why I commented about anything regarding Rust with any certainty. It's not a matter of preferences, just like choosing between int and float is not a
Re: [OT] Modules dropped out of C++17
On Thursday, 11 June 2015 at 12:33:55 UTC, Steven Schveighoffer wrote: On 6/10/15 8:52 AM, John Colvin wrote: On Tuesday, 9 June 2015 at 17:43:18 UTC, Steven Schveighoffer wrote: On 6/9/15 4:06 AM, Brian Schott wrote: On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. If anybody was wondering why DCD doesn't support UFCS, this is the answer. I can't find a way to make it fast, useful, or compact in terms of memory use. I can't see how a UFCS lookup is any slower than a normal function lookup. It's just a rewrite. i.e.: a.foo 1. try finding member foo on type a. 2. try finding function foo a. If found, find overload that will take a. What happens as you type: foo(a ??? how is it any different? One problem is that any auto-complete list becomes completely unmanageable. OK, I see the problem. When you type 'a.' then if you put up the list of members and UFCS functions available, then that list may be huge (and possibly filled with useless calls). That definitely is an issue. However, I think DCD should still support that option. A UI for an ide could be: 1. Lookup members, add to the list a UFCS... button at the bottom. 2. When user clicks on that button, re-query DCD for all functions that take the object as the first parameter, then fill in that list. 3. If user continues to type in a UFCS method, and that doesn't match any members, the autocomplete should start looking for functions that start with that text. It would be a shame if DCD doesn't show you functions like arr.empty. However, does DCD support querying a function's parameters when it's a UFCS function? That should at least be manageable. -Steve The funny thing is, one of selling points of C++'s version of UFCS is making it easier for the tools to give useful hints. Personally, I find UFCS and ranges to be the most enticing features of D, allowing me to think of the flow of the data, instead of wondering where the hell does the ) go. Better templates, true immutables, mixins (though ugly), ctfe static if are also appreciated. Modules? Sure, nice to have, but they don't make the top 5 list for me. Why? Call it the Stockholm Syndrome, but most C++ users simply got used to header incurred problems and know to use PIMPL and avoid changing core headers. Though maybe my projects aren't sufficiently large.
Re: Right after allocators: containers or database connectivity?
I’m actively working on the low level interface and I’m making good progress. My goal is to have a high quality interface definition with working reference drivers for top tier databases. The current references drivers are ODBC, sqlite, mysql, and Oracle. I think it’s important to support ODBC since it covers all bases, but I agree that ODBC alone is not sufficient. The main reason is that most application developers coming from other stacks will be expecting direct drivers and are not likely to be happy dealing with the added complications of ODBC. However, I think both are achievable in the near term under a common interface. On the async question, the native interfaces are traditionally synchronous and that’s my initial focus. I will need to look at which native interfaces actually support it and see how that can be mapped into the generic interface, but synchronous needs to be supported. There is a known issue with RefCounted that needs to be addressed. There is a apparently a race condition with the reference counter when RefCounted is within a class. Nearly all of the types in my design are ref counted structs and there are use cases for embedding those objects in classes. There was discussion at the conference on this and I believe the preferred solution is for the GC have some thread affinity on collection.
Re: Daily downloads in decline
On 6/11/2015 8:03 AM, Dicebot wrote:
On the other hand they have one important advantage: all type arguments must
comply to one or more trairs and thus bodies of generics are checked before
institation. You are only allowed to call methods and operations of generic
arguments that are defined in relevan trait. This is huge win for code hygiene
compared to D.
On the other hand, generic bodies in D can inquire if various additional traits
are available, and then adapt:
struct S(R) if (isInputRange!R)
{
...
static if (isForwardRange!R)
{
R save()
{
auto result = this;
result.r = r.save;
return result;
}
}
...
}
This kind of thing is used extensively in Phobos generics.
Re: Automatic documentation builds
On Thursday, 11 June 2015 at 13:12:17 UTC, Steven Schveighoffer wrote: On 6/11/15 9:04 AM, John Colvin wrote: it doesn't seem to have triggered/finished yet for that one, but older pulls have a link in them Yeah, hah! I seemed to have picked the only one that doesn't :) It was the siren of seeing DDOC: in the title that drew me to it :P Vladimir, this isn't a bug is it? The order in which it picks PRs to test is a bit naive, I'll have to tweak it a bit I guess. Right now it goes through each D component, and for it goes through all open PRs. This takes a few hours. If a PR has been added after it grabbed the PR list, it won't get to it until the next iteration.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 11:40:55 UTC, Abdulhaq wrote: It's quite a nice twist that the thread discussing which language is better branched into what version of English is the right one - as if such a thing is meaningful. Arguing about definitions and terminology is surely such a useless diversion. The irony is strong...
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 18:17:01 UTC, Dave wrote: Disagree. Traditionally also handled by throwing exceptions. C# throws a Format exception if a parse fails. https://msdn.microsoft.com/en-us/library/f02979c7%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/bb299639%28v=vs.110%29.aspx
[Issue 11370] core.simd segfault
https://issues.dlang.org/show_bug.cgi?id=11370 Maxim Fomin maxim-fo...@outlook.com changed: What|Removed |Added Status|NEW |RESOLVED CC||maxim-fo...@outlook.com Resolution|--- |WORKSFORME --- Comment #4 from Maxim Fomin maxim-fo...@outlook.com --- Cannot reproduce on git head. --
[Issue 13628] Error: immutable method S.~this is not callable using a mutable object and vice versa
https://issues.dlang.org/show_bug.cgi?id=13628 Maxim Fomin maxim-fo...@outlook.com changed: What|Removed |Added Status|NEW |RESOLVED CC||maxim-fo...@outlook.com Resolution|--- |INVALID --- Comment #2 from Maxim Fomin maxim-fo...@outlook.com --- It is by design. You must make destructor immutable to call it for immutable object. Closed as invalid. --
[Issue 14685] New: Silent incorrect behavior with enforce and custom exception
https://issues.dlang.org/show_bug.cgi?id=14685
Issue ID: 14685
Summary: Silent incorrect behavior with enforce and custom
exception
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: regression
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
Today, I wrote the following code:
/// test.d //
import std.exception;
class NotFoundException : Exception
{
this() { super(Not found); }
}
void main()
{
enforce!NotFoundException(false);
}
/
It compiles fine, but does not actually throw anything.
This seems to be a regression, as previously it did not compile.
Introduced in https://github.com/D-Programming-Language/phobos/pull/2288
--
[Issue 13628] Error: immutable method S.~this is not callable using a mutable object and vice versa
https://issues.dlang.org/show_bug.cgi?id=13628 --- Comment #3 from Marco Leise marco.le...@gmx.de --- You can't just close this without further discussion. That is disrespectful given the three questions I had refer to my failed attempts at doing what you propose as a solution. --
Re: DIP80: phobos additions
On 6/11/15 4:15 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Wednesday, 10 June 2015 at 20:31:52 UTC, Steven Schveighoffer wrote: OK, thanks for the explanation. I'd do it the other way around: Flag!threadlocal, since we should be safe by default. `RefCounted!T` is also thread-local by default, only `shared(RefCounted!T)` needs to use atomic operations. I may have misunderstood Andrei. We can't just use a flag to fix this problem, all allocations are in danger of races (even thread-local ones). But maybe he meant *after* we fix the GC we could add a flag? I'm not sure. A flag at this point would be a band-aid fix, allowing one to optimize if one knows that his code never puts RefCounted instances on the heap. Hard to prove... -Steve
Re: foreach with a default range
On 6/11/15 4:24 AM, Dmitry Olshansky wrote:
Already works. Just define opSlice for container that returns a range
and then:
foreach(elem; container) {}
is lowered to:
foreach(elem; container[]) {}
I think you want to do opIndex which takes no parameters. opSlice is no
longer supposed to be used that way (though it still works for backwards
compatibility).
-Steve
Automatic documentation builds
I've put together a CI system of sorts that builds the documentation for all pull requests. Hopefully this should avoid the dlang.org build breaking again in the future. It integrates with GitHub as well, and on repositories covered by Brad's auto-tester, will create a second status for the documentation. The whole thing is Digger-powered, so uses the same code as Digger and http://digger.k3.1azy.net/trend/. Sample page: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/31744d2fb90cf25ef1778f52ef640abc56c494c2/ Source code: https://github.com/CyberShadow/DAutoTest Cool fact: When you request a built file (e.g. a .html page), it'll fetch the data directly from the Git cache repository, through a named pipe (bypassing disk) connected to a long-living Git process. This is also done transparently for included resources (images, CSS etc.)
Re: Automatic documentation builds
On 6/11/15 8:21 AM, Vladimir Panteleev wrote: I've put together a CI system of sorts that builds the documentation for all pull requests. Hopefully this should avoid the dlang.org build breaking again in the future. It integrates with GitHub as well, and on repositories covered by Brad's auto-tester, will create a second status for the documentation. The whole thing is Digger-powered, so uses the same code as Digger and http://digger.k3.1azy.net/trend/. Sample page: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/31744d2fb90cf25ef1778f52ef640abc56c494c2/ Source code: https://github.com/CyberShadow/DAutoTest Cool fact: When you request a built file (e.g. a .html page), it'll fetch the data directly from the Git cache repository, through a named pipe (bypassing disk) connected to a long-living Git process. This is also done transparently for included resources (images, CSS etc.) This sounds really cool! So given I have a PR, for example, https://github.com/D-Programming-Language/druntime/pull/1301 How do I find the ddoc build for it? -Steve
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
It seems to be a controversial subject: https://github.com/D-Programming-Language/phobos/pull/1090#issuecomment-12737986 As the topic has been argued for the past 50 years. No one ever agrees on the best way to handle errors. But I think most of this is because programmers tend to be the most stubborn and unchanging type of folks in the world. They often care that they look right. Not that they are right ;) Exceptions are not meant to force handling errors at he source. This attitude is why so many exceptions go unhandled at the upper layers. When you have a top level that calls a function that calls 50 other functions, each that throw a handful or more different exceptions, it's unreasonable to expect the upper layer coder to account for all of them. In fact, in practice they usually don't until bugs arise. This is provably bad practice. If you want to force handling errors at the source they should be part of the return type. Again what errors are worth throwing as exceptions in your paradigm? Which ones are worth returning? This separation is very arbitrary for my taste. Exceptions are not hard fails. They can be if they go unaccounted for (depending on the language/environment). Java has the infamous, NullPointerException that plagues Java applications. C# has the NullReferenceException. You don't have to crash the entire program just fail the action the user was trying to do and display a nice error message with whatever information you can and want to provide to the user. Even if you don't handle them, they provide information useful for debugging. Not gonna disagree there. It doesn't really guarantee the functions not annotated as throwing won't crash Combined with other guarantees (such as immutability, thread local storage, safe memory management, side-effect free code, no recursion, etc), you can make a reasonable guarantee about the safety of your code. And a superhero cape, combined with an airplane, airplane fuel and flight school, allow you to fly in the air. Not really sure how to parse this...Doesn't seem like you have any good argument against what I said. Again I said you can make a *reasonable* guarantee. And I am not alone here. If you look at Rust, it really does illustrate a trend that functional programming has been pushing for a long time. Provable guarantees. Problems are very rarely unique. There are a core set of things that happen frequently that cause problems. And these things are easily recognizable by compilers. You can't prevent everything, but you can prevent a good deal of the obvious stuff. This is just an extension of that mindset. So it is not really that outlandish. It is the other restrictions(without getting into a discussion about each and every restriction in the list) that make the code safer - nothrow doesn't really contribute IMO. Without the nothrow, you cannot guarantee it won't cause problems with unhandled errors ;) Seems like a nice guarantee to me. I would at least like this option, because library writers often try to write in an idiomatic way (and I tend to use the most reputable libraries I can find), which gives you some guarantees. The guarantee would be better served by default IMHO though. Having a 'throw' keyword is also useful for IDE's. Anybody that has used Visual Studio and C# will tell you a nice feature is that Visual Studio can tell you what exceptions get thrown when calling a method (very useful). C# does it in a different way, but a 'throw' keyword would actually help scanners figure this out very trivially as well as programmers just reading the header of a function. Scala and Rust seem to maintain both paradigms just fine. It's actually beneficial to have both - you have to acknowledge return-type-based exceptions, and you can always bypass them by turning them to exceptions, which are good for logging and debugging. I do not believe Rust has exceptions. I don't mind a language having multiple ways to handle errors. Seeing how its a topic no one ever is on the same page about, it's actually a wise design decision. But you don't often see library writers mixing them for consistency purposes. It's just easier for people to learn your library when you have one error handling scheme. It's usually encountered only where two libraries written by different vendors have to interact in application code. If exception handling is enforced, they can only be bypassed by converting them to errors or crashes, which are much less nice than exceptions when it comes to debugging, logging and cleanup. Exceptions have many benefits. They have many disadvantages too. They are often very slow on the exceptional path, which occur more frequently than most admit. Writing code that acknowledges that this code can fail due to an exception somewhere else does not count as ignoring it. You could not handle it all the way up the chain (at the cost of adding something to a
[Issue 14289] WindowsException should not attempt to parse code 0
https://issues.dlang.org/show_bug.cgi?id=14289 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/a2102aa66c2145a4dfe2ec2dfd1c171530d2e3a7 fix Issue 14289 - WindowsException should not attempt to parse code 0 --
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 11:40:55 UTC, Abdulhaq wrote: Hear, hear, is it so unlikely that one footstep should fall in the footprint of another? We all stand on the shoulders of giants, etc. This is it. Great languages (IMO) have condensed their features down to the smallest set of orthogonal features that they could manage. This makes the language easier to reason about, to share code, to maintain code, to learn, to read code, even writing it is often easier! Right now I feel that D is growing in 'features' and corner cases beyond the point where I want to explore it's depths. It's gone from a swim in the bay into crossing the Channel. I always think about Herb Sutters Guru of the Week column and how it made me think ugh - too many oddities to learn. I could be wrong and I hope I am. Aye. I think what I totally dislike about C++ is that I cannot hold the whole language in my head. It is unthinkable that I could just type in a C++ program using the full feature set and compile it with no complaints from the compiler and quite a bit of head-scratching to figure out why it won't take code that looks sensible. Corner cases is a major reason for increased cognitive load. Even javascript gives me that feeling, caused by the odd weird non-intuitive flaws that makes such a simple language not so simple after all. We'll see what happens when DMD is translated to D and refactored. Maybe someone creates an experimental D3 from it to see if it can be made a bit more orthogonal. I think that could be an important move. It's quite a nice twist that the thread discussing which language is better branched into what version of English is the right one - as if such a thing is meaningful. As a norwegian I can't make up my mind as to whether I should write color or colour. I suspect it will be taken as some kind of political statement. Hey, I am neutral! I use color in source code and colour in writing. :)
Re: Automatic documentation builds
On 12/06/2015 12:21 a.m., Vladimir Panteleev wrote: I've put together a CI system of sorts that builds the documentation for all pull requests. Hopefully this should avoid the dlang.org build breaking again in the future. It integrates with GitHub as well, and on repositories covered by Brad's auto-tester, will create a second status for the documentation. The whole thing is Digger-powered, so uses the same code as Digger and http://digger.k3.1azy.net/trend/. Sample page: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/31744d2fb90cf25ef1778f52ef640abc56c494c2/ Source code: https://github.com/CyberShadow/DAutoTest Cool fact: When you request a built file (e.g. a .html page), it'll fetch the data directly from the Git cache repository, through a named pipe (bypassing disk) connected to a long-living Git process. This is also done transparently for included resources (images, CSS etc.) So for a PR it puts up a URL on the request? Because this would be pretty awesome in that context!
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 12:11:49 UTC, Ola Fosheim Grøstad wrote: As a norwegian I can't make up my mind as to whether I should write color or colour. I suspect it will be taken as some kind of political statement. Hey, I am neutral! I use color in source code and colour in writing. :) As an Englishman I used to rail against the USA-ification of the language but now I've learnt to bite the bullet and actually follow the same rule as yourself. Saves a lot of indigestion :-)
Re: Right after allocators: containers or database connectivity?
On 6/9/15 6:05 PM, Jonathan M Davis wrote: On Tuesday, 9 June 2015 at 18:49:04 UTC, Brad Anderson wrote: We also have map in the form of RedBlackTree. I think you might be able to use RedBlackTree for a set too but I haven't tried it. You can, but it's a bit of a pain, because you have to keep passing it a tuple where the value gets ignored. We really need a wrapper around it to make it cleaner. Map is a pain. Set is not. The apparatus around RedBlackTree in dcollections to turn it into a map is non-trivial, and is worthy of having in std.container. TreeSet, however, was pretty much straight mapping to implementation calls. -Steve
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
I should also mention that D has essentially enabled this philosophy that I am speaking about concerning errors by using the 'scope' keyword. I believe handling errors with scope literally translates to try\catch blocks behind the scenes. I also believe this is an encouraged way of dealing with errors in D.
[Issue 14664] missing pages / broken links
https://issues.dlang.org/show_bug.cgi?id=14664 --- Comment #3 from John Colvin john.loughran.col...@gmail.com --- (In reply to Vladimir Panteleev from comment #2) (In reply to John Colvin from comment #0) It's linked from http://dlang.org/phobos-prerelease/index.html but is 404. What is? Whoops, I forgot that was the title of the bug before i changed it. std.windows.charset is linked from index.html but the link is dead --
Re: Automatic documentation builds
On 12/06/2015 12:28 a.m., Vladimir Panteleev wrote: On Thursday, 11 June 2015 at 12:27:29 UTC, Rikki Cattermole wrote: So for a PR it puts up a URL on the request? Because this would be pretty awesome in that context! Yes, just click Details at the bottom of the PR page to go to the test result page. Cool just tested it out! Small thoughts, have some goto links e.g. phobos prerelease. It'll make it slightly easier to move around. Otherwise I'm very impressed.
Re: Automatic documentation builds
On 12/06/2015 12:44 a.m., Steven Schveighoffer wrote: On 6/11/15 8:21 AM, Vladimir Panteleev wrote: I've put together a CI system of sorts that builds the documentation for all pull requests. Hopefully this should avoid the dlang.org build breaking again in the future. It integrates with GitHub as well, and on repositories covered by Brad's auto-tester, will create a second status for the documentation. The whole thing is Digger-powered, so uses the same code as Digger and http://digger.k3.1azy.net/trend/. Sample page: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/31744d2fb90cf25ef1778f52ef640abc56c494c2/ Source code: https://github.com/CyberShadow/DAutoTest Cool fact: When you request a built file (e.g. a .html page), it'll fetch the data directly from the Git cache repository, through a named pipe (bypassing disk) connected to a long-living Git process. This is also done transparently for included resources (images, CSS etc.) This sounds really cool! So given I have a PR, for example, https://github.com/D-Programming-Language/druntime/pull/1301 How do I find the ddoc build for it? -Steve Doesn't look like it has yet been added. Phobos works.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
D is really unique in the sense that it's open enough for people not to feel that they have to role their own. D also has enough features to satisfy many different users, although - and this is often forgotten - you don't _have_ to use them all. People like Go and Rust, because it tells them exactly what to do. D doesn't, they have to think for themselves, and a lot of people hate that, which is sad, because having loads of things to choose from makes you think more about your code and software design in general and it makes you a better programmer/coder/architect. Thinking like that is fine when you work on your own, but when you're in a large team and working on a large code base the prospect of trying to grok a dozen different coding approaches using different feature sets of some uber language is entirely unappealing and best avoided.
Re: Automatic documentation builds
On Thursday, 11 June 2015 at 12:44:32 UTC, Steven Schveighoffer wrote: On 6/11/15 8:21 AM, Vladimir Panteleev wrote: [...] This sounds really cool! So given I have a PR, for example, https://github.com/D-Programming-Language/druntime/pull/1301 How do I find the ddoc build for it? -Steve it doesn't seem to have triggered/finished yet for that one, but older pulls have a link in them
