A curated list of links related to D (github/awesome D)
Maybe interesting (hoping it is not too redundant with the links here) https://github.com/zhaopuming/awesome-d Vincent
Unable To Install Debian Package on Deepin Linux (Debian Jessie)
It seems that /usr/bin/dman is currently used by deepin-manual. Is there anyway to get around this? Link to the screenshot: https://1drv.ms/i/s!AtF769jLRRhO61Of6g3ZIBl8uZAk
Re: an extremely naive question regarding synchronized...
On 11/15/16 3:05 PM, Kapps wrote: Keep in mind, this is only slow for such a large amount of calls. If you're calling this only a hundred times a second, then who cares if it's slower. After all, with GDC we were looking at 1 billion calls in 21 seconds. That's 47,000 calls per *millisecond*. This is the wrong way to look at it. If you are calling it from one thread, then 100 times/second is no problem. If you have 100 threads calling it 100 times a second, you have killed any performance gained by using threads in the first place. The reason lock-free singletons are so attractive is because of the allowance of multiple threads to use it at the same time without contention. It's why years of "slightly wrong" advice on singletons has been out there, and why this solution is so amazing in its simplicity. -Steve
Re: an extremely naive question regarding synchronized...
On Monday, 14 November 2016 at 17:43:37 UTC, WhatMeWorry wrote:
I was reading this fasciniating article:
https://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/
And to quote a section of it:
-
static MySingleton get() {
synchronized {
if (instance_ is null) {
instance_ = new MySingleton;
}
}
return instance_;
}
Now, if Thread 1 calls get(), it has a chance to finish
instantiating instance_ and storing a reference to it before
Thread 2 checks whether instance_ is null. There’s only one
problem with this: It comes at a huge performance cost
(benchmarks forthcoming). Entering a synchronized block is
expensive.
-
Why is the synchronized block so expensive? Isn't it just
doing one conditional and a new command? Again, to my naive
way of thinking, this seems like a very small blocking window.
And the graph shows 1B get() calls. I assume B stands for
billion. What use case would require so many gets?
Thanks.
Keep in mind, this is only slow for such a large amount of calls.
If you're calling this only a hundred times a second, then who
cares if it's slower. After all, with GDC we were looking at 1
billion calls in 21 seconds. That's 47,000 calls per
*millisecond*.
Re: The return of std.algorithm.find
On 11/15/16 4:43 AM, RazvanN wrote: The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]? A sorted range provides better mechanisms to find values as members of SortedRange. Don't use find(assumeSorted(...)), as it's still a linear search. -Steve
vibed ssl stream and SSL_CTX_set_default_verify_paths
Hello,
Sorry if this is FAQ, or any other way stupid question, e.t.c.
I have to configure vibe.d tlsstream to verify remote certificate.
Please correct me if I'm wrong -- here is part of my code to
request certificate verification:
auto sslctx = createTLSContext(TLSContextKind.client);
sslctx.useTrustedCertificateFile("/opt/local/etc/openssl/cert.pem");
sslctx.peerValidationMode = TLSPeerValidationMode.trustedCert;
auto _stream = createTLSStream(_conn, sslctx, host);
the problem here is call to useTrustedCertificateFile. At compile
time I do not know place of cert authority file, and this
location can also be unknown for program user even if there is a
way to configure it during program start.
libopenssl provide call SSL_CTX_set_default_verify_paths(ctx) -
which configure default (already known to library code) location
of ca certs distributed with openssl.
Is there any way for vibed sslctx to configure CA cert path "by
default value"?
Thanks for your responce!
Re: The return of std.algorithm.find
On Tuesday, 15 November 2016 at 09:50:40 UTC, RazvanN wrote: On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote: The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]? The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6, 7]), 4). And the result is the whole range [1, 2, 4, 5, 6, 7]. Are you sure you don't want filter ?
Re: The return of std.algorithm.find
15.11.2016 12:50, RazvanN пишет: On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote: The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]? The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6, 7]), 4). And the result is the whole range [1, 2, 4, 5, 6, 7]. IIRC find!"a <= b" will return the first element that is less or equal to needle, so this will be the whole range. To find all elements of SortedRange that are less or equal to needle you need to use SortedRange.lowerBound http://dlang.org/phobos/std_range.html#.SortedRange.lowerBound
Re: The return of std.algorithm.find
On 11/15/2016 01:50 AM, drug wrote:
15.11.2016 12:48, drug пишет:
15.11.2016 12:43, RazvanN пишет:
The find function which receives an input haystack and a needle returns
the haystack advanced to the first occurrence of the needle. For normal
ranges this is fine, but for
sorted ranges (aka SortedRange) it is a bit odd. For example:
find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This
is in terms with the general policy of the find function, but is weird.
Since we know the range is sorted, shouldn't the result be [1, 2, 4]?
I don't think so. You could use findSplit, it returns three ranges [1,
2], [4], [5, 6, 7].
See also SortedRange.trisect
Indeed. This is what I was typing:
import std.stdio;
import std.range;
void main() {
auto r = assumeSorted([1, 2, 4, 5, 6, 7]);
auto found = r.trisect(4);
auto desired = chain(found[0], found[1]);
writeln(desired);
}
Prints
[1, 2, 4]
Ali
Re: The return of std.algorithm.find
15.11.2016 12:48, drug пишет: 15.11.2016 12:43, RazvanN пишет: The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]? I don't think so. You could use findSplit, it returns three ranges [1, 2], [4], [5, 6, 7]. See also SortedRange.trisect
Re: The return of std.algorithm.find
On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote: The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]? The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6, 7]), 4). And the result is the whole range [1, 2, 4, 5, 6, 7].
Re: The return of std.algorithm.find
15.11.2016 12:43, RazvanN пишет: The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]? I don't think so. You could use findSplit, it returns three ranges [1, 2], [4], [5, 6, 7].
The return of std.algorithm.find
The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]?
