Re: Andrei's list of barriers to D adoption

On Friday, June 10, 2016 02:38:28 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Thursday, 9 June 2016 at 21:54:05 UTC, Jack Stouffer wrote: > > On Thursday, 9 June 2016 at 21:46:28 UTC, Walter Bright wrote: > >> Programming is a mix of engineering and craft. There are > >> people who do

Where are the solutions for the exercises of the dlang tour???

I've been trying to solve the exercise of the caesar encryption for practicing with arrays with no luck. I'm new to D Thanks for your help. :D

[Issue 2659] Remove the comma operator

https://issues.dlang.org/show_bug.cgi?id=2659 --- Comment #13 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/058c5a301fb3942e01446a60381d5e935ab91ec7 Fix Issue 2659 - Deprecate using the result of comma

Re: Andrei's list of barriers to D adoption

On Thursday, 9 June 2016 at 21:54:05 UTC, Jack Stouffer wrote: On Thursday, 9 June 2016 at 21:46:28 UTC, Walter Bright wrote: Programming is a mix of engineering and craft. There are people who do research into programming theory, and those are computer scientists. I'm not one of them. Andrei

Re: Optimizations and performance

On Thursday, 9 June 2016 at 17:19:36 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 16:14:08 UTC, Ola Fosheim Grøstad wrote: C++ would destroy the competition on almost any performance benchmark implemented by a group of competent C++ programmers. How can it win over assembler? By language

Re: shared Mutex?

On Thursday, 9 June 2016 at 20:53:38 UTC, tcak wrote: (cast()mx).lock(); I was told casting away shared when there are still references to it is a bad idea. Like, the Mutex object might get corrupted if the garbage collector tries to move it while another thread is using it. So

Re: stretto...@tutanota.com

On Thursday, 9 June 2016 at 22:19:33 UTC, Stretto wrote: I have some class like class bar { } class foo : bar { bar[] stuff; } and have another class class dong : bar { int x; } Now sometimes stuff will contain dong's, but I cannot access its members it without a cast.

[Issue 16151] duplicate symbol _D4core4sync5mutex5Mutex12MonitorProxy6__initZ in:

https://issues.dlang.org/show_bug.cgi?id=16151 Timothee Cour changed: What|Removed |Added CC|

[Issue 16151] New: duplicate symbol _D4core4sync5mutex5Mutex12MonitorProxy6__initZ in:

https://issues.dlang.org/show_bug.cgi?id=16151 Issue ID: 16151 Summary: duplicate symbol _D4core4sync5mutex5Mutex12MonitorProxy6__initZ in: Product: D Version: D2 Hardware: x86 OS: Mac OS X

Re: The Problem With DIPs

On 6/9/2016 5:10 PM, deadalnix wrote: It is not clear where to comment to begin with. There's a space in the table for a link to n.g. discussion.

Re: I implemented delegates in D

2016-06-10 1:20 GMT+02:00 maik klein via Digitalmars-d < digitalmars-d@puremagic.com>: > But that means that the closure will be allocated on the stack right? What > happens when I send it with > http://dpldocs.info/experimental-docs/std.concurrency.send.html > > Will it copy the function or will

Re: The Problem With DIPs

On Thursday, 9 June 2016 at 21:34:00 UTC, Walter Bright wrote: On 6/9/2016 4:49 AM, Jacob Carlborg wrote: The problem with the DIP's is that, by definition, it's something that needs your or Andrei's approval. Therefore it's not possible to leave it completely for someone else to deal with.

Re: stretto...@tutanota.com

Ultimately what I want to do is access a member foo.Dongs[i]; Where Dongs is essentially a "view" in to the Bars array and only accesses types of type Dong. It seems one can't do both an override on a name("Dongs") and an index on the overridden name(`[i]`)? It is not appropriate to use

Re: I implemented delegates in D

On Thursday, 9 June 2016 at 21:02:26 UTC, maik klein wrote: I am currently writing a task system and I have this case where I want to send a delegate to a different thread but this delegate also captures a variable. I use this to implement a "future". Now as far as I know this delegate will

Re: Beta release DUB 1.0.0-beta.1

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote: DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support for single-file packages, which can be used to write shebang-style scripts on Posix systems: [...] I've barely started using D, but dub works like a charm and

Re: I implemented delegates in D

On Thursday, 9 June 2016 at 22:06:24 UTC, Mathias Lang wrote: To avoid the delegate being GC allocated, use `scope foo = (int i) { ... }` at call site. You can also make your function signature as `void func(scope void delegate() dg)` in which case it won't allocate if you pass a literal

[Issue 16150] New: Rework overview of D's features page

https://issues.dlang.org/show_bug.cgi?id=16150 Issue ID: 16150 Summary: Rework overview of D's features page Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement

Re: I implemented delegates in D

It's even part of DMD testsuite: https://github.com/dlang/dmd/blob/38c1bad2f41ad8e6bc7c08deae26e30c9c7d7704/test/runnable/nogc.d#L20 At DConf, Dicebot mention that he had some problems in the past and it doesn't work in some places. The Weka people seemed to have similar experience. I did some

stretto...@tutanota.com

I have some class like class bar { } class foo : bar { bar[] stuff; } and have another class class dong : bar { int x; } Now sometimes stuff will contain dong's, but I cannot access its members it without a cast. fooo.stuff[0].x // invalid because bar doesn't contain x; Hence,

Re: I implemented delegates in D

On 6/9/16 6:06 PM, Mathias Lang via Digitalmars-d wrote: To avoid the delegate being GC allocated, use `scope foo = (int i) { ... }` at call site. Is that true? At one point in D's past, this ONLY worked if you passed a delegate to a function accepting a scope delegate. Maybe it's been fixed.

Re: I implemented delegates in D

To avoid the delegate being GC allocated, use `scope foo = (int i) { ... }` at call site. You can also make your function signature as `void func(scope void delegate() dg)` in which case it won't allocate if you pass a literal directly. 2016-06-09 23:57 GMT+02:00 maik klein via Digitalmars-d <

Re: Parse File at compile time, but not embedded

On Tuesday, 7 June 2016 at 22:09:58 UTC, Alex Parrill wrote: On Monday, 6 June 2016 at 21:57:20 UTC, Pie? wrote: On Monday, 6 June 2016 at 21:31:32 UTC, Alex Parrill wrote: [...] Not necessarily, You chased that rabbit quite far! The data your reading could contain sensitive information

Re: D's memory-hungry templates

On Thursday, 9 June 2016 at 14:46:12 UTC, tsbockman wrote: Ultimately, I believe it was a mistake for D to implement a separate, inferior programming language just for templates. However, it is too late to change that now (at least for D2), so I will offer some suggestions as to how memory

Re: I implemented delegates in D

On Thursday, 9 June 2016 at 21:32:33 UTC, Alex Parrill wrote: On Thursday, 9 June 2016 at 21:02:26 UTC, maik klein wrote: Has this been done before? Well, yes, the entire point of delegates is to be able to capture variables (as opposed to function pointers, which cannot). auto

Re: Andrei's list of barriers to D adoption

On Thursday, 9 June 2016 at 21:46:28 UTC, Walter Bright wrote: Programming is a mix of engineering and craft. There are people who do research into programming theory, and those are computer scientists. I'm not one of them. Andrei is. Unfortunately, the term "software engineer" is a LOT less

Re: Andrei's list of barriers to D adoption

On 6/9/2016 1:38 PM, Jack Stouffer wrote: On Thursday, 9 June 2016 at 18:02:05 UTC, deadalnix wrote: You are a scientist, so try to measure. GC generally improves throughput at the cost of latency. As a side note, I always found it funny that programmers call themselves "computer scientists"

Re: Andrei's list of barriers to D adoption

On 6/9/2016 9:44 AM, Yura wrote: 4) The C language is well tested and rock solid stable. However, if you encounter a potential bug in D, I am not sure how long would it take to fix. Thanks for taking the time to post here. Yes, there are bugs in D. Having dealt with buggy compilers from every

Re: The Problem With DIPs

On 6/9/2016 6:54 AM, Kagamin wrote: On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote: A DIP not being dealt with does not mean it is a bad idea. It pretty much means we just aren't ready to deal with it at the moment. It's time may not have come yet. But it's not going away, it'll

Re: Andrei's list of barriers to D adoption

On Thursday, 9 June 2016 at 20:38:30 UTC, Jack Stouffer wrote: On Thursday, 9 June 2016 at 18:02:05 UTC, deadalnix wrote: You are a scientist, so try to measure. GC generally improves throughput at the cost of latency. As a side note, I always found it funny that programmers call themselves

Re: The Problem With DIPs

On 6/9/2016 4:49 AM, Jacob Carlborg wrote: The problem with the DIP's is that, by definition, it's something that needs your or Andrei's approval. Therefore it's not possible to leave it completely for someone else to deal with. That doesn't stop anyone from commenting on them, offering

Re: I implemented delegates in D

On Thursday, 9 June 2016 at 21:02:26 UTC, maik klein wrote: Has this been done before? Well, yes, the entire point of delegates is to be able to capture variables (as opposed to function pointers, which cannot). auto createADelegate(int captured) { return (int a) => captured + a; }

Formated string with assert inside template constraints?

is it supposed to work? normally it works e.g. assert(0, "some\nstring"); prints: some string but if you do it inside a template constraint like this: void someTemp(T)(T t) if(isCallable!T.call!((b){assert(b, "some\nstring");})) { } it prints: some\x0astring

[Issue 15768] std.stdio.trustedStdout accesses __gshared data without synchronization.

https://issues.dlang.org/show_bug.cgi?id=15768 Jack Stouffer changed: What|Removed |Added CC||j...@jackstouffer.com

I implemented delegates in D

I am currently writing a task system and I have this case where I want to send a delegate to a different thread but this delegate also captures a variable. I use this to implement a "future". Now as far as I know this delegate will allocate GC memory and I just wanted to avoid that, just for

Re: shared Mutex?

On 6/9/16 2:31 PM, cy wrote: Is core.sync.mutex.Mutex even usable in D anymore? It seems every mutex that wasn't shared would be part of thread local data, so two threads locking on the same mutex would actually be locking separate mutexes. Yes, but this is because Mutex existed way before

Re: shared Mutex?

On Thursday, 9 June 2016 at 18:31:16 UTC, cy wrote: I was thinking of using threads in a D program (ignores unearthly wailing) and I need 1 thread for each unique string resource (database connection info). So I did this: shared BackgroundDB[string] back; I don't see any way to make less

Re: Beta release DUB 1.0.0-beta.1

On 6/9/16 4:37 PM, Sönke Ludwig wrote: Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer: On 6/8/16 2:45 PM, Sönke Ludwig wrote: (...) Apart from what I've already mentioned in my first reply to Jacob, I think there is nothing else that couldn't be solved in either case. "It's still

Re: Andrei's list of barriers to D adoption

On Thursday, 9 June 2016 at 18:02:05 UTC, deadalnix wrote: You are a scientist, so try to measure. GC generally improves throughput at the cost of latency. As a side note, I always found it funny that programmers call themselves "computer scientists" while many write a lot of their programs

Re: Beta release DUB 1.0.0-beta.1

Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer: On 6/8/16 2:45 PM, Sönke Ludwig wrote: > (...) Apart from what I've already mentioned in my first reply to Jacob, I think there is nothing else that couldn't be solved in either case. "It's still possible to put something else in front of

Re: D's memory-hungry templates

On Thursday, 9 June 2016 at 14:46:12 UTC, tsbockman wrote: While working on a small PR (https://github.com/dlang/phobos/pull/4420), I noticed that D's template computation system has horrific memory consumption (as well as being very slow). [...] I run into the same issues with

Re: LDC+Dub+Vibe.d work on SmartOS 64bit now

On Thursday, 9 June 2016 at 14:25:07 UTC, Joakim wrote: On Thursday, 9 June 2016 at 12:48:24 UTC, Alexandr Basko wrote: On Wednesday, 8 June 2016 at 13:30:26 UTC, Alexandr Basko wrote: [...] Some tests failed. More than that, they walked to the core.sync.semaphore test and frozen on it (no

[Issue 16149] New: foreach_reverse can't handle index variable of type int

https://issues.dlang.org/show_bug.cgi?id=16149 Issue ID: 16149 Summary: foreach_reverse can't handle index variable of type int Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

Re: Parse File at compile time, but not embedded

On Tuesday, 7 June 2016 at 22:09:58 UTC, Alex Parrill wrote: Accessing a SQL server at compile time seems like a huge abuse of CTFE (and I'm pretty sure it's impossible at the moment). Why do I need to install and set up a MySQL database in order to build your software? Presumably you

Re: Constraining template with function signature

The other way is better, but since you asked... On Wednesday, 8 June 2016 at 01:42:55 UTC, Carl Vogel wrote: Now, I can use something like isCallable std.traits to make sure the predicate is a Callable, and there are various function traits in the module that I could combine with `is` clauses

Re: Pointer problems, changing for no reasons

I can't help but notice that loadModel is not a static member function, yet you don't seem to call it with a Model object in your "get" function. Also have a look at std.typecons.RefCounted if you want reference counted data..

Re: Optimizations and performance

On Thursday, 9 June 2016 at 18:09:44 UTC, Jack Stouffer wrote: And then people can look at the C++ code and say to themselves "Is this something that I am capable of or want to write", the answer being most of the time, no. Sure, it is largely and increasingly becoming an experts language...

Re: Fibers under the hood

On Thursday, 9 June 2016 at 16:13:21 UTC, Jonathan Marler wrote: I don't see that documentation anywhere on that page. https://issues.dlang.org/show_bug.cgi?id=16148

Re: Optimizations and performance

On Thursday, 9 June 2016 at 10:00:17 UTC, Ola Fosheim Grøstad wrote: On Thursday, 9 June 2016 at 07:26:16 UTC, poliklosio wrote: First of all, there is not much point optimizing the language for people who are capable of optimizing everything to the extreme themselves. D already has as much

[Issue 16148] New: The Fibers specifics should be included in the core.thread docs

https://issues.dlang.org/show_bug.cgi?id=16148 Issue ID: 16148 Summary: The Fibers specifics should be included in the core.thread docs Product: D Version: D2 Hardware: All OS: All Status: NEW

Re: std.experimental.checkedint is ready for comments!

On Tuesday, 7 June 2016 at 08:50:07 UTC, Robert burner Schadek wrote: ... I left my commentary in the PR. Overall it looks pretty good design wise, and I would totally vote for it's inclusion in Phobos.

shared Mutex?

I was thinking of using threads in a D program (ignores unearthly wailing) and I need 1 thread for each unique string resource (database connection info). So I did this: shared BackgroundDB[string] back; I don't see any way to make less data shared there. If it weren't shared, it would be

Re: Optimizations and performance

On Thursday, 9 June 2016 at 17:19:36 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 16:14:08 UTC, Ola Fosheim Grøstad wrote: C++ would destroy the competition on almost any performance benchmark implemented by a group of competent C++ programmers. How can it win over assembler? Also what's

Re: Optimizations and performance

On Thursday, 9 June 2016 at 16:14:08 UTC, Ola Fosheim Grøstad wrote: C++ would destroy the competition on almost any performance benchmark implemented by a group of competent C++ programmers. Ok, so it will win, as it should then. And then people can look at the C++ code and say to themselves

Re: Andrei's list of barriers to D adoption

On Thursday, 9 June 2016 at 16:44:23 UTC, Yura wrote: 5) Garbage collector - it will slow my number crunching down. You are a scientist, so try to measure. GC generally improves throughput at the cost of latency.

Re: Optimizations and performance

On Thursday, 9 June 2016 at 17:36:28 UTC, Wyatt wrote: On Thursday, 9 June 2016 at 16:47:28 UTC, Kagamin wrote: A language optimized for performance of spontaneous code written by newbies, who never learned the language and don't use best practices? Could you stop pretending to completely

Re: Optimizations and performance

On Thursday, 9 June 2016 at 16:47:28 UTC, Kagamin wrote: A language optimized for performance of spontaneous code written by newbies, who never learned the language and don't use best practices? Could you stop pretending to completely misunderstand the point? -Wyatt

Re: Interest in Paris area D meetups?

On Thursday, 9 June 2016 at 16:27:41 UTC, Claude wrote: On Thursday, 9 June 2016 at 09:11:05 UTC, Guillaume Chatelet wrote: Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00? Ok, great! FYI my email address:

Re: Recursive SymbolNames solved.

On 09.06.2016 11:02, Johan Engelen wrote: On Thursday, 9 June 2016 at 04:58:45 UTC, Stefan Koch wrote: On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote: Hi, I solved the issue. PR is coming shortly. Solution is as follows: Keep a list of already visited symbols in the mangler.

Re: Optimizations and performance

On Thursday, 9 June 2016 at 16:14:08 UTC, Ola Fosheim Grøstad wrote: C++ would destroy the competition on almost any performance benchmark implemented by a group of competent C++ programmers. How can it win over assembler? Also what's about cost/benefit ratio?

Re: Optimizations and performance

On Thursday, 9 June 2016 at 15:16:34 UTC, Wyatt wrote: The point is this sort of language benchmark should use normal code. The sort of code that people who've never heard of Haskell would write. If it's a "fast" language, "ordinary-looking" code should be fast. If being fast requires

Re: Andrei's list of barriers to D adoption

On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote: Andrei posted this on another thread. I felt it deserved its own thread. It's very important. - I go to conferences. Train and consult at large companies.

Re: Improving style of error pages of this website

On Thursday, 9 June 2016 at 13:33:43 UTC, Jack Stouffer wrote: On Thursday, 9 June 2016 at 13:10:45 UTC, nbro wrote: 1. Error pages are not styled for the tour (http://tour.dlang.org/). So, for example, if instead of writing the following currently valid URL "http://tour.dlang.org/; I type

Re: Interest in Paris area D meetups?

On Thursday, 9 June 2016 at 09:11:05 UTC, Guillaume Chatelet wrote: Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00? Ok, great!

[Issue 16147] Provide shiny 404 error pages

https://issues.dlang.org/show_bug.cgi?id=16147 greensunn...@gmail.com changed: What|Removed |Added Summary|Provide nshiny 404 error|Provide shiny 404 error

[Issue 16147] New: Provide nshiny 404 error pages

https://issues.dlang.org/show_bug.cgi?id=16147 Issue ID: 16147 Summary: Provide nshiny 404 error pages Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority:

Re: Optimizations and performance

On Thursday, 9 June 2016 at 15:57:02 UTC, Dave wrote: But not give to much information about the language. All ordinary imperative languages are equal in theoretical performance. No point in trying to "benchmark" languages. You always benchmark compiler (and runtime) + hardware. For

Re: Fibers under the hood

On Thursday, 9 June 2016 at 11:45:01 UTC, Andrew Edwards wrote: On 6/9/16 2:15 PM, Jonathan Marler wrote: On Thursday, 9 June 2016 at 05:07:33 UTC, Nikolay wrote: On Thursday, 9 June 2016 at 04:57:30 UTC, Jonathan Marler wrote: I've googled and searched through the forums but haven't found

Re: Optimizations and performance

On Thursday, 9 June 2016 at 15:58:05 UTC, Jack Stouffer wrote: On Thursday, 9 June 2016 at 15:44:04 UTC, Ola Fosheim Grøstad wrote: Otherwise people would benchmark numpy instead of Python etc. While it's not a one-to-one analogy due to the fact that Appender is in Phobos, I think it would

Re: Optimizations and performance

All of this goes back to knowing what you are truly benchmarking.

Re: Optimizations and performance

On Thursday, 9 June 2016 at 15:44:04 UTC, Ola Fosheim Grøstad wrote: Otherwise people would benchmark numpy instead of Python etc. While it's not a one-to-one analogy due to the fact that Appender is in Phobos, I think it would be totally reasonable to benchmark numpy instead of Python.

Re: Optimizations and performance

On Thursday, 9 June 2016 at 15:44:04 UTC, Ola Fosheim Grøstad wrote: On Thursday, 9 June 2016 at 14:16:08 UTC, Jack Stouffer wrote: Appender!string is a great example, as it's easy to add and it almost always results in measurable speed increases. You can see how one simple change using D

Re: Optimizations and performance

On Thursday, 9 June 2016 at 15:16:34 UTC, Wyatt wrote: On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote: But it is the point of benchmarking So it's not "languages should be fast by default", but "benchmarks should be fast by

Re: Optimizations and performance

On Thursday, 9 June 2016 at 14:16:08 UTC, Jack Stouffer wrote: Appender!string is a great example, as it's easy to add and it almost always results in measurable speed increases. You can see how one simple change using D features can make your program 5% faster. Every language has idiomatic

Re: Optimizations and performance

On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote: But it is the point of benchmarking So it's not "languages should be fast by default", but "benchmarks should be fast by default"? Well, _this_ took some weird leaps from what I

D's memory-hungry templates

While working on a small PR (https://github.com/dlang/phobos/pull/4420), I noticed that D's template computation system has horrific memory consumption (as well as being very slow). I believe there are several reasons for this: 1) All template instantiations are memoized, even if they're

Re: Optimizations and performance

On Thursday, 9 June 2016 at 14:16:08 UTC, Jack Stouffer wrote: On Thursday, 9 June 2016 at 13:32:14 UTC, Dave wrote: [...] I agree with your general point, but what I find most useful about benchmarks is the ability to find the lower bound of performance without resorting to inline asm or

Re: a lambda with arguments has type void?

On 06/09/16 07:20, cy via Digitalmars-d-learn wrote: > Like this is why it doesn't really make sense: > > import std.stdio; > > auto foo(Callable)(Callable c) { > return c(42); > } > > auto foo2(alias c)() { > return c(42); > } > > void main() { > // this works, when you know it's an int

Re: LDC+Dub+Vibe.d work on SmartOS 64bit now

On Thursday, 9 June 2016 at 12:48:24 UTC, Alexandr Basko wrote: On Wednesday, 8 June 2016 at 13:30:26 UTC, Alexandr Basko wrote: [...] Some tests failed. More than that, they walked to the core.sync.semaphore test and frozen on it (no more resources are eating by OS from last evening:

Re: Optimizations and performance

On Thursday, 9 June 2016 at 13:32:14 UTC, Dave wrote: I think you can trust benchmark. I think the bigger key is understanding what you are truly benchmarking. I agree with your general point, but what I find most useful about benchmarks is the ability to find the lower bound of performance

Re: Optimizations and performance

On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote: But it is the point of benchmarking So it's not "languages should be fast by default", but "benchmarks should be fast by default"? Also, the last I checked, one of D's selling

Re: Optimizations and performance

On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote: But it is the point of benchmarking So it's not "languages should be fast by default", but "benchmarks should be fast by default"? No. It's languages should be fast by default if

Re: Optimizations and performance

On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote: But it is the point of benchmarking So it's not "languages should be fast by default", but "benchmarks should be fast by default"?

Re: The Problem With DIPs

On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote: A DIP not being dealt with does not mean it is a bad idea. It pretty much means we just aren't ready to deal with it at the moment. It's time may not have come yet. But it's not going away, it'll still be there when needed. I've

Re: Optimizations and performance

On Thursday, 9 June 2016 at 13:48:36 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 12:16:25 UTC, Wyatt wrote: On Thursday, 9 June 2016 at 01:46:45 UTC, Dave wrote: Languages should be fast by default. This. 4,000,000,000% this. If the naïve cases are bad, they're bad and trying to

Re: Optimizations and performance

On Thursday, 9 June 2016 at 12:16:25 UTC, Wyatt wrote: On Thursday, 9 June 2016 at 01:46:45 UTC, Dave wrote: Languages should be fast by default. This. 4,000,000,000% this. If the naïve cases are bad, they're bad and trying to pretend that doesn't matter is some insidious denial. Sure,

Re: Improving style of error pages of this website

On Thursday, 9 June 2016 at 13:10:45 UTC, nbro wrote: 1. Error pages are not styled for the tour (http://tour.dlang.org/). So, for example, if instead of writing the following currently valid URL "http://tour.dlang.org/; I type "http://tour.dlang.org//;, it gives me a "ugly" 404 error page.

Re: Optimizations and performance

On Thursday, 9 June 2016 at 00:25:28 UTC, Seb wrote: On Wednesday, 8 June 2016 at 22:32:49 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote: D definitely needs some optimizations, I mean look at its benchmarks compared to other languages:

Re: Improving style of error pages of this website

FYI, the newsgroups can be accessed at [1] and the mailing lists at [2]. [1] news://www.digitalmars.com/digitalmars/D [2] http://lists.puremagic.com/cgi-bin/mailman/listinfo/digitalmars-d

Re: Version identifier for PS4

On Thursday, 9 June 2016 at 13:16:58 UTC, Steven Schveighoffer wrote: On 6/9/16 9:09 AM, Markus Pursche wrote: On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: [...] As the "author"(?) of that pull request I would love to get a discussion going. PS4 vs Orbis vs

Re: Improving style of error pages of this website

On Thursday, 9 June 2016 at 13:10:45 UTC, nbro wrote: 2. Forums, like this one, could definitely be improved by adding markdown as a markup language to edit and style posts. There should also be the possibility to edit already posted questions and answers, and the edit as well as the

Re: Improving style of error pages of this website

Another issue that may exist is that there's no notification and also subscription system that would tell you about news regarding a post (but not just necessarily a post) where you're involved because you had subscribed to it... Never mind regarding the subscription.

Re: Version identifier for PS4

On 6/9/16 9:09 AM, Markus Pursche wrote: On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: On 10/06/2016 12:30 AM, Johan Engelen wrote: Hi all, PR 5850 is proposing to add a predefined (reserved) version identifier for the PS4 OS: "PS4" [1]. Thanks for your comment

Re: Improving style of error pages of this website

On Thursday, 9 June 2016 at 13:10:45 UTC, nbro wrote: Hi! I've just read this post: https://dlang.org/blog/index.php/author/dblogadmin/ and I've a few suggestions to improve this website: 1. Error pages are not styled for the tour (http://tour.dlang.org/). So, for example, if instead of

Re: Version identifier for PS4

On Thursday, 9 June 2016 at 13:09:01 UTC, Johan Engelen wrote: On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: "PS4" is really quite short. "PlayStation4" would be far better that way it isn't an acronym. Nice suggestion. I don't know about similarities between

Improving style of error pages of this website

Hi! I've just read this post: https://dlang.org/blog/index.php/author/dblogadmin/ and I've a few suggestions to improve this website: 1. Error pages are not styled for the tour (http://tour.dlang.org/). So, for example, if instead of writing the following currently valid URL

Re: Version identifier for PS4

On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: On 10/06/2016 12:30 AM, Johan Engelen wrote: Hi all, PR 5850 is proposing to add a predefined (reserved) version identifier for the PS4 OS: "PS4" [1]. Thanks for your comment (preferably with an alternative suggestion in

Re: Version identifier for PS4

On Thursday, 9 June 2016 at 12:38:51 UTC, rikki cattermole wrote: "PS4" is really quite short. "PlayStation4" would be far better that way it isn't an acronym. Nice suggestion. I don't know about similarities between PlayStation versions, but how about "PlayStation", with 'sub' version

Re: Beta release DUB 1.0.0-beta.1

On 6/8/16 2:45 PM, Sönke Ludwig wrote: Am 08.06.2016 um 16:58 schrieb Steven Schveighoffer: I agree with Jacob. A comment is a comment. Well, there are normal comments, doc comments and now DUB recipe comments. But at least if doc comments serve as an analogy, those are possible with all

Re: LDC+Dub+Vibe.d work on SmartOS 64bit now

On Wednesday, 8 June 2016 at 13:30:26 UTC, Alexandr Basko wrote: On Wednesday, 8 June 2016 at 11:30:50 UTC, Joakim wrote: On Wednesday, 8 June 2016 at 10:06:00 UTC, Oleg Nykytenko wrote: On Wednesday, 8 June 2016 at 08:43:59 UTC, Joakim wrote: [...] We haven't run library's tests. What

Re: Version identifier for PS4

On 10/06/2016 12:30 AM, Johan Engelen wrote: Hi all, PR 5850 is proposing to add a predefined (reserved) version identifier for the PS4 OS: "PS4" [1]. Thanks for your comment (preferably with an alternative suggestion in case you don't like "PS4"). Thanks, Johan [1]

  1   2   >