On Tue, Dec 02, 2014 at 01:03:12AM +, Tobias Pankrath via
Digitalmars-d-learn wrote:
> >
> >Phobos git HEAD has a new range adaptor called groupBy that does what
> >you want:
> >
> > assert([1,1,2,2,2,3,4,4].groupBy!((a)=>a).equal(
> > [[1,1], [2,2,2], [3], [4,4]]
> > ))
>
Phobos git HEAD has a new range adaptor called groupBy that
does what
you want:
assert([1,1,2,2,2,3,4,4].groupBy!((a)=>a).equal(
[[1,1], [2,2,2], [3], [4,4]]
))
T
Thanks! I wonder if this works with all input ranges. As I see
it, every implementation will ha
On Monday, 1 December 2014 at 20:23:00 UTC, Suliman wrote:
Could anybody explain why there is opinion that stack is fast
and the heap is slow. All of them are located in the same
memory. So the access time should be equal.
Yes, the problem is that if you load from a memory area (of 64
bytes)
On Mon, Dec 01, 2014 at 08:22:59PM +, Suliman via Digitalmars-d-learn wrote:
> Could anybody explain why there is opinion that stack is fast and the
> heap is slow. All of them are located in the same memory. So the
> access time should be equal.
That may be true 15 years ago, it's not true to
On 12/1/14 3:22 PM, Suliman wrote:
Could anybody explain why there is opinion that stack is fast and the
heap is slow. All of them are located in the same memory. So the access
time should be equal.
Measure it :)
But short answer is twofold:
1. stack is usually hot in the local processor cach
Suliman:
Could anybody explain why there is opinion that stack is fast
and the heap is slow. All of them are located in the same
memory. So the access time should be equal.
Often the access speed is not exactly the same, because the stack
memory is usually hotter, this means it's more often
On Mon, 01 Dec 2014 20:22:59 +
Suliman via Digitalmars-d-learn
wrote:
> Could anybody explain why there is opinion that stack is fast and
> the heap is slow. All of them are located in the same memory. So
> the access time should be equal.
could anybody explain why there is opinion that mon
Could anybody explain why there is opinion that stack is fast and
the heap is slow. All of them are located in the same memory. So
the access time should be equal.
On 12/01/2014 12:06 AM, WhatMeWorry wrote:
Wow. This is great stuff! And diagrams are always appreciated. You
should write a book.
Agreed!
H. S. Teoh, should I translate this post for the Turkish audience or
should I wait for an article version of it first? ;) We can even reddit
it then...
My guess is that you have to use HTTPS for CONNECT and that you
have to have credentials for it. (?)
Ali
dlang.org should work on HTTP, but not HTTPS.
Also I do not think that when I connect to HTTPS I should have
any credentials. It's mostly like issue with curl...
On 12/01/2014 10:25 AM, Suliman wrote:
> why:
> string link = "dlang.org";
> writeln(connect(link));
>
> cause crash:
(To be pedantic: An unhandled exception is not a crash. ;) )
>
std.net.curl.CurlException@C:\DMD\dmd2\windows\bin\..\..\src\phobos\std\net\curl
>
> .d(779): HTTP r
On Mon, Dec 01, 2014 at 06:37:13PM +, Tobias Pankrath via
Digitalmars-d-learn wrote:
> Basically I need std.algorithm.uniq or std.algorithm.group, but
> instead of a single element or an element and a number I want ranges
> that each contain consecutive elements considered equal.
>
> Example:
Basically I need std.algorithm.uniq or std.algorithm.group, but
instead of a single element or an element and a number I want
ranges that each contain consecutive elements considered equal.
Example: [1,1, 2,2,2,3,4,4] -> [1, 1], [2,2,2], [3], [4,4].
Let's call this uniqRange. This way std.algo
Big thanks Ali!
Only the small last question:
why:
string link = "dlang.org";
writeln(connect(link));
cause crash:
std.net.curl.CurlException@C:\DMD\dmd2\windows\bin\..\..\src\phobos\std\net\curl
.d(779): HTTP request returned status code 400
0x00404263
0x00402
On Monday, 1 December 2014 at 12:17:46 UTC, Arjan wrote:
On Sunday, 30 November 2014 at 16:26:53 UTC, Joseph Rushton
Wakeling via Digitalmars-d-learn wrote:
On 30/11/14 13:21, Arjan via Digitalmars-d-learn wrote:
Hi!
D noob here.
I'm trying to call this function from the GSL lib:
Out of curio
On Sunday, 30 November 2014 at 16:26:53 UTC, Joseph Rushton
Wakeling via Digitalmars-d-learn wrote:
On 30/11/14 13:21, Arjan via Digitalmars-d-learn wrote:
Hi!
D noob here.
I'm trying to call this function from the GSL lib:
Out of curiosity (since your question has already been
answered), wha
H. S. Teoh:
you *can* allocate by-value
types on the heap, e.g., `MyStruct* ptr = new MyStruct(...)`.
But it's rare to want to do that; usually if you need to do
that, you should just use a class instead.
If I create data structures that contain many pointers, like some
kinds of trees, I us
On 11/30/2014 10:38 PM, Suliman wrote:
> Am I right understand all exception are derived from "assertThrown"
> http://dlang.org/phobos/std_exception.html
No, all exceptions are derived from Throwable. It has two descendants:
- Error, representing conditions that are irrecoverable, and
- Except
Wow. This is great stuff! And diagrams are always appreciated.
You should write a book. I'm off to play with emplace.
19 matches
Mail list logo