Re: std.experimental.collections.rcstring and its integration in Phobos
On Wednesday, 18 July 2018 at 12:03:02 UTC, Eugene Wissner wrote:
Therefore it shouldn't compile at all, but
rcstring("ä")[].split("|")
or
rcstring("ä").byCodePoint.split("|")
+1 to requiring an explicit byCodeUnit or whatever.
For every "obvious" way to interpret a string as a range, you can
find an application where the obvious code is surprisingly buggy.
(BTW, rcstring("ä").byCodePoint.split("|") is buggy for
characters made of multiple codepoints. Canonicalisation doesn't
fix it because many characters just don't have a single-codepoint
form.)
Re: std.experimental.collections.rcstring and its integration in Phobos
On Wednesday, 18 July 2018 at 12:10:04 UTC, Seb wrote:
On Wednesday, 18 July 2018 at 03:40:08 UTC, Jon Degenhardt [...]
and whether applications would use arrays and ranges of char
together with rcstring, or rcstring would be used for
everything.
That point is still open for discussion, but at the moment
rcstring isn't a range and the user has to declare what kind of
range he/she wants with e.g. `.by!char`
However, one current idea is that for some use cases (e.g.
comparison) it might not matter and an application could add
overloads for rcstrings.
Maybe I misunderstood but you mean that for comparisons the
encoding doesn't matter only right? But that does not preclude
normalization, e.g. unicode defines U+00F1 as equal to the
sequence U+006E U+0303 and that would work as long as they're
normalized (from what I understand at least) and regardless of
whether you compare char/wchar/dchars.
The current idea is to do the same this for Phobos - though I
have to say that I'm not really looking forward to adding 200
overloads to Phobos :/
Perhaps its too early for these questions, and the current
goal is simpler. For example, adding a meaningful collection
class that is @nogc, @safe and ref-counted that be used as a
proving ground for the newer memory management facilities
being developed.
That's the long-term goal of the collections project.
However, with rcstring being the first big use case for it, the
idea was to push rcstring forward and by that discover all
remaining issues with the Array class.
Also the interface of rcstring is rather contained (and doesn't
expose the underlying storage to the user), which allows us to
iterate over/improve upon the Array design.
Such simpler goals would be quite reasonable. What's got me
wondering about the larger questions are the comments about
ranges and autodecoding. If rcstring is intended as a vehicle
for general @nogc handling of character data and/or for
reducing the impact of autodecoding, then it makes sense to
consider from those perspectives.
Hehe, it's intended to solve both problems (auto-decoding by
default and @nogc) at the same time.
However, it looks like to me like there isn't a good solution
to the auto-decoding problem that is convenient to use for the
user and doesn't sacrifice on performance.
How about a compile time flag that can make things more
convenient:
auto str1 = latin1("literal");
rcstring!Latin1 latin1string(string str) {
return rcstring!Latin1(str);
}
auto str2 = utf8("åsm");
// ...
struct rcstring(Encoding = Unknown) {
ubyte[] data;
bool normalized = false;
static if (is(Encoding == Latin1)) {
// by char range interface implementation
} else if (is(Encoding == Utf8)) {
// byGrapheme range interface implementation?
} else {
// no range interface implementation
}
bool opEquals()(auto ref const S lhs) const {
static if (!is(Encoding == Latin1)) {
return data == lhs.data;
} else {
return normalized() == lhs.normalized()
}
}
}
And now most ranges will work correctly. And then some of the
algorithms that don't need to use byGrapheme but just need
normalized code points to work correctly can do that and that
seems like all the special handling you'll need inside range
algorithms?
Then:
readText("foo".latin1);
"ä".utf8.split.join("|");
??
Cheers,
- Ali
Re: opCmp / opEquals do not actually support partial orders
On Wednesday, 18 July 2018 at 15:13:24 UTC, rikki cattermole wrote: On 19/07/2018 3:03 AM, Ivan Kazmenko wrote: That's by DMD32 on Windows. (Sorry, my DMD64 broke after upgrading Visual Studio to 2017, and I failed to fix it right now. Anyway, it's not like x86_64 uses a different set of general purpose floating-point hardware, right?) Boy do I ever have some bad news for you! SSE for 64bit and x87 for 32bit, as per run.dlang.org. Wow, thanks! As per https://run.dlang.io/, it's fast for float and double, but slow for reals (which are 80 bits and don't fit into the fancy instructions you mention). Unfortunately, it fails to compile with -m32, but anyway, point taken. As an aside, learning something new after virtually every post is why I love the D forum/newsgroup. Ivan Kazmenko.
Re: newCTFE report July
On 07/18/2018 11:28 AM, Stefan Koch wrote: > 2. there was the problem of the IndexExp being unaware of being inside > an AddrExp which would cause it to first evaluate four[0] to 1, and then > trying to take the address of literal one (which is zero as the marker > for an invalid address). Without knowing much about the compiler, could that be solved by changing four[0] to a reference expression? Is there even such a concept in the compiler? How does the non-CTFE compilation deal with that case? Ali
Re: newCTFE report July
On Wed, Jul 18, 2018 at 07:18:52PM +, Stefan Koch via Digitalmars-d wrote: > On Wednesday, 18 July 2018 at 18:36:37 UTC, H. S. Teoh wrote: [...] > > What's your current estimate on when it will be production-ready? [...] > I am going to give the same conservative answer I gave a Dconf: 2020 Can't wait for 2020 to arrive! :-D T -- Doubt is a self-fulfilling prophecy.
Re: newCTFE report July
On Wednesday, 18 July 2018 at 18:36:37 UTC, H. S. Teoh wrote: On Wed, Jul 18, 2018 at 06:28:30PM +, Stefan Koch via Digitalmars-d wrote: [...] Good to hear that progress on newCTFE is still being made. What's your current estimate on when it will be production-ready? T I am going to give the same conservative answer I gave a Dconf: 2020
Re: CVu, Code Critique, and D
On Tue, 2018-06-19 at 19:22 +, Anton Fediushin via Digitalmars-d wrote: > On Tuesday, 19 June 2018 at 14:42:20 UTC, Russel Winder wrote: > > […] > > This is clearly getting well stuck in to the task. Can I > > suggest finishing this off and sending it to s...@accu.org > > I will try and do so. I can't see a reason to not give it a try. > I'd like more people to participate. Maybe then we'll see more D > in the Code Critique. I am just putting together a piece in answer to the original question, it would be great if you were able to submit something as well. 2018- 08-01 submission deadline. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: newCTFE report July
On Wed, Jul 18, 2018 at 06:28:30PM +, Stefan Koch via Digitalmars-d wrote: [...] Good to hear that progress on newCTFE is still being made. What's your current estimate on when it will be production-ready? T -- Democracy: The triumph of popularity over principle. -- C.Bond
newCTFE report July
Hi Guys, last month I did the work make this snippet compile and
execute correctly:
static immutable four = [1, 2, 3, 4];
int fn(int idx = 2)
{
int fn2(const int* x)
{
return x[idx];
}
return fn2(&four[0]) + *(&four[0]);
}
static assert(fn() == 4);
There where two major problems with this one.
1. There was the circular initialization-detected which would
object to referencing `&four` twice in the same expression.
2. there was the problem of the IndexExp being unaware of being
inside an AddrExp which would cause it to first evaluate four[0]
to 1, and then trying to take the address of literal one (which
is zero as the marker for an invalid address).
Fixing this involved adding a special case to how &x[y] is
handled.
This solution does complicate the internals of newCTFE a bit, and
I hope to simplify it once other blocking problems are out of the
way.
Re: DMD, Vibe.d, and Dub
On 2018-07-18 18:11, Martin Tschierschke wrote: Even if the needed libs are named different on different systems, it would be cool to collect the information what is needed in the dub.sdl/dub.json file. So directly at the beginning you get a hint what is missing. And how to fix it, especially if you use a system like Debian (/Ubuntu) I ran into the exactly same chain of error messages, fixing them with the help of others, and some search, this is not the most convenient experience if you start with vibe.d. I'm doing that with DStep [1]. It was quite annoying and a lot of work to write, but it works. [1] https://github.com/jacob-carlborg/dstep/blob/master/dub.json#L36 -- /Jacob Carlborg
Re: DMD, Vibe.d, and Dub
On Wed, Jul 18, 2018 at 07:08:32PM +0100, Russel Winder via Digitalmars-d wrote: > On Wed, 2018-07-18 at 17:45 +, Johannes Pfau via Digitalmars-d > wrote: > > Am Wed, 18 Jul 2018 13:29:00 +0100 schrieb Russel Winder: > […] > > > libssl installed but libssl-dev not. I can't quite see why the > > > linker ld needs the development files, it just needs the shared > > > objects to be present. > > > > Debian moved the lib*.so => lib*.so.123version symlinks into the > > -dev packages some time ago, so now you can't link without -dev > > packages. > > Not the smartest move imho > > I think I shall find it hard to discover a reason why you are wrong, > but clearly the Debian devs in charge managed to. [...] Having been using Debian for almost two decades, the impression I get is that generally -dev packages are required whenever you need to do anything related to compiling, which includes linking to the library. The only time you don't need -dev packages is when you're running an already-compiled executable that's already linked with the library (which is generally the case for end users who don't routinely compile & link programs, hence this particular way of dividing -dev vs. non-dev packages). T -- Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton
Re: std.experimental.collections.rcstring and its integration in Phobos
On 2018-07-18 13:37, Seb wrote:
The problem here is this would also lead to very confusing behavior for
newcomers, e.g.
```
"ä".split.join("|") == �|�
```
How about not giving access to operate on individual characters. If they
need to do that they should operate on an array of bytes. Too controversial?
--
/Jacob Carlborg
Re: DMD, Vibe.d, and Dub
On Wed, 2018-07-18 at 17:45 +, Johannes Pfau via Digitalmars-d wrote: > Am Wed, 18 Jul 2018 13:29:00 +0100 schrieb Russel Winder: > > > […] > > libssl installed but libssl-dev not. I can't quite see why the > > linker ld > > needs the development files, it just needs the shared objects to be > > present. > > Debian moved the lib*.so => lib*.so.123version symlinks into the > -dev > packages some time ago, so now you can't link without -dev packages. > Not > the smartest move imho I think I shall find it hard to discover a reason why you are wrong, but clearly the Debian devs in charge managed to. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: DMD, Vibe.d, and Dub
Am Wed, 18 Jul 2018 13:29:00 +0100 schrieb Russel Winder: > On Wed, 2018-07-18 at 11:41 +, Seb via Digitalmars-d wrote: >> On Wednesday, 18 July 2018 at 11:35:05 UTC, Russel Winder wrote: >> > On Tue, 2018-07-17 at 21:46 +, Radu via Digitalmars-d wrote: >> > > On Tuesday, 17 July 2018 at 18:55:07 UTC, Russel Winder wrote: >> > > > [...] >> > > >> > > Missing openssl libs? Try installing openssl-dev package. >> > >> > The Debian Sid openssl package is definitely installed. There doesn't >> > seem to be a separate openssl-dev package. >> >> It's called libssl-dev > > libssl installed but libssl-dev not. I can't quite see why the linker ld > needs the development files, it just needs the shared objects to be > present. Debian moved the lib*.so => lib*.so.123version symlinks into the -dev packages some time ago, so now you can't link without -dev packages. Not the smartest move imho -- Johannes
Re: opCmp / opEquals do not actually support partial orders
On Wed, Jul 18, 2018 at 11:30:21AM -0600, Jonathan M Davis via Digitalmars-d wrote: > On Tuesday, July 17, 2018 21:18:12 John Colvin via Digitalmars-d wrote: > > Just do what std.typecons.Proxy does and return float.nan for the > > incomparable case. > > Since when is that legal? I thought that it was required for opCmp to > return int. Certainly, the spec implies that it has to be int. The > fact that the compiler allows it seems like a bug, though if Phobos is > doing it, it wouldn't surprise me if Walter would choose to update the > spec rather than fixing the compiler. [...] Yeah, this is also a surprise to me. Is this a bug? I was under the impression that opCmp must return int. On the other hand, if opCmp is allowed to return a user-defined type, it would solve the problem in a neat way: just define a quaternary type that encapsulates the values -1, 0, 1, NaN, and have opCmp return the equivalent of NaN for non-comparable arguments. Then we could support partial orders correctly. But I have a hard time seeing this actually work in practice, because a user-defined return type for opCmp leads to recursion: in order to compare the return type against -1, 0, 1, etc., it would also need to implement opCmp itself. I'm almost certain this will cause the compiler to choke. :-D Not to mention opening up the possibility of ridiculous cases like having two user-defined types whose opCmp returns the other type, leading to infinite recursion. T -- Being able to learn is a great learning; being able to unlearn is a greater learning.
Re: opCmp / opEquals do not actually support partial orders
On Tuesday, July 17, 2018 21:18:12 John Colvin via Digitalmars-d wrote: > Just do what std.typecons.Proxy does and return float.nan for the > incomparable case. Since when is that legal? I thought that it was required for opCmp to return int. Certainly, the spec implies that it has to be int. The fact that the compiler allows it seems like a bug, though if Phobos is doing it, it wouldn't surprise me if Walter would choose to update the spec rather than fixing the compiler. - Jonathan M Davis
Re: DMD, Vibe.d, and Dub
On Wednesday, 18 July 2018 at 15:21:29 UTC, Russel Winder wrote: On Wed, 2018-07-18 at 14:20 +, Seb via Digitalmars-d wrote: On Wednesday, 18 July 2018 at 12:56:05 UTC, Russel Winder wrote: > [...] You have openssl 1.1 installed, but vibe.d tries to link with openssl 1.0 by default. See https://github.com/vibe-d/vibe.d#switching-between-openssl-versions tl;dr: use dub --override-config vibe-d:tls/openssl-1.1 I went for the: dependency "vibe-d:tls" version="*" subConfiguration "vibe-d:tls" "openssl-1.1" in the dub.sdl file. I now have a build. I believe 1.1 should be the default if available, falling back to 1.0, 0.9,… It would be very useful if dub would be able to check for missing libs. It seams stupid, that after successful compilation you get the linker error. Even if the needed libs are named different on different systems, it would be cool to collect the information what is needed in the dub.sdl/dub.json file. So directly at the beginning you get a hint what is missing. And how to fix it, especially if you use a system like Debian (/Ubuntu) I ran into the exactly same chain of error messages, fixing them with the help of others, and some search, this is not the most convenient experience if you start with vibe.d. Regards mt.
Re: DMD, Vibe.d, and Dub
On Wed, 2018-07-18 at 15:53 +, Seb via Digitalmars-d wrote: […] > > Of course, but it's not that easy, because dub doesn't support > such a detection. > However, we can hack it: > > https://github.com/vibe-d/vibe.d/pull/2190 Maybe this should be a requirement on Dub so as to avoid hacking? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: std.experimental.collections.rcstring and its integration in Phobos
On Wednesday, July 18, 2018 12:15:52 Seb via Digitalmars-d wrote:
> Well, the problem of it being a range of char is that this might
> lead to very confusing behavior, e.g.
>
> "ä".rcstring.split.join("|") == �|�
>
> So we probably shouldn't go this route either.
I don't know. I'm fine with it not being a range and leaving it up to the
programmer, but part of the point here is that the programmer needs to
understand Unicode well enough to be able to do the right thing in cases
like this or they're screwed anyway. And if strings (of any variety) operate
as ranges of code units by default, the fact that there's a problem when
someone screws it up is going to be a lot more obvious.
Forcing people to call a function like by!char or by!dchar still requires
that they deal with all of this. It just makes it explicit. And that's not
necessarily a bad idea, but if someone is going to be confused by something
like split splitting in the middle of code points, they're going to be in
trouble with the bu function anyway.
> The idea of adding overloads was to introduce a bit of
> user-convenience, s.t. they don't have to say
>
> readText("foo".rcstring.by!char)
>
> all the time.
The wouldn't be doing anything that verbose anyway. In that case, you'd just
pass the string literal. At most, they'd be doing something like
readText(str.by!char);
And of course, readText is definitely _not_ @nogc. But regardless, these are
functions that are designed to be generic and take ranges of characters
rather than strings, and adding overloads for specific types just because we
don't want to call the function to get a range over them seems like it's
going in totally the wrong direction. It means adding a lot of overloads,
and we already have quite a mess thanks to all of the special-casing that we
have to avoid auto-decoding without getting into adding yet another set of
overloads for rcstring. We've put in the effort to genericize these
functions and make many of these functions work with ranges of characters
rather than strings, and I really don't think that we should start adding
overloads for specific string types just because we don't want to treat them
as ranges directly.
I'd honestly rather see an rcstring type that was just treated as a range of
char than see us adding overloads for rcstring. That's what arrays of char
should have been treated as in the first place, and we already have to do
stuff like byCodeUnit for strings anyway, so having to do by!char or
by!dchar really doesn't seem like a big deal to me - especially if the
alternative is adding a bunch of overloads.
- Jonathan M Davis
Re: DMD, Vibe.d, and Dub
On Wednesday, 18 July 2018 at 15:21:29 UTC, Russel Winder wrote: On Wed, 2018-07-18 at 14:20 +, Seb via Digitalmars-d wrote: On Wednesday, 18 July 2018 at 12:56:05 UTC, Russel Winder wrote: > [...] You have openssl 1.1 installed, but vibe.d tries to link with openssl 1.0 by default. See https://github.com/vibe-d/vibe.d#switching-between-openssl-versions tl;dr: use dub --override-config vibe-d:tls/openssl-1.1 I went for the: dependency "vibe-d:tls" version="*" subConfiguration "vibe-d:tls" "openssl-1.1" in the dub.sdl file. I now have a build. I believe 1.1 should be the default if available, falling back to 1.0, 0.9,… Of course, but it's not that easy, because dub doesn't support such a detection. However, we can hack it: https://github.com/vibe-d/vibe.d/pull/2190
Re: DMD, Vibe.d, and Dub
On Wed, 2018-07-18 at 14:20 +, Seb via Digitalmars-d wrote: > On Wednesday, 18 July 2018 at 12:56:05 UTC, Russel Winder wrote: > > [...] > > You have openssl 1.1 installed, but vibe.d tries to link with > openssl 1.0 by default. > > See > https://github.com/vibe-d/vibe.d#switching-between-openssl-versions > > tl;dr: use > > dub --override-config vibe-d:tls/openssl-1.1 I went for the: dependency "vibe-d:tls" version="*" subConfiguration "vibe-d:tls" "openssl-1.1" in the dub.sdl file. I now have a build. I believe 1.1 should be the default if available, falling back to 1.0, 0.9,… -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: opCmp / opEquals do not actually support partial orders
On 19/07/2018 3:03 AM, Ivan Kazmenko wrote: That's by DMD32 on Windows. (Sorry, my DMD64 broke after upgrading Visual Studio to 2017, and I failed to fix it right now. Anyway, it's not like x86_64 uses a different set of general purpose floating-point hardware, right?) Boy do I ever have some bad news for you! SSE for 64bit and x87 for 32bit, as per run.dlang.org.
dlang.slack.com
tl;dr: send me a short ping (https://github.com/wilzbach) if you would like to join I know that there are many out there who don't like Slack (especially after they killed the IRC gateway), but a lot of the internal discussions still happens on Slack, so I just thought I mention it here on the NG for those who have never heard about it and still would like to join.
Re: DMD, Vibe.d, and Dub
On Wed, 2018-07-18 at 13:38 +, Timoses via Digitalmars-d wrote: > On Wednesday, 18 July 2018 at 12:56:05 UTC, Russel Winder wrote: > > > > > Package installed, now I get: > > > > /usr/bin/ld: > > ../../../../../.dub/packages/vibe-d-0.8.4/vibe- > > d/tls/.dub/build/openssl-debug-linux.posix-x86_64-ldc_2081- > > B4D8997CFF9906E4CA7C7DC4C81EF881/libvibe- > > d_tls.a(vibe.stream.openssl.o): in function > > `_D4vibe6stream7openssl14OpenSSLContext6__ctorMFNfEQBwQBu3tls14TLSC > > ontextKindEQCxQCvQBb10TLSVersionZ9__lambda3MFNbNeZv': > > [...] > > Perhaps this? > https://github.com/vibe-d/vibe.d/issues/2153 Indeed it is, but on Debian rather than (the inferior :-) Ubuntu. I'm with Sebastian Wilzbach on this, if 1.1 is available it should be used. https://github.com/vibe-d/vibe.d/issues/2053 https://github.com/vibe-d/vibe.d/pull/2137 -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: opCmp / opEquals do not actually support partial orders
On Wednesday, 18 July 2018 at 14:02:28 UTC, Dominikus Dittes
Scherkl wrote:
On Wednesday, 18 July 2018 at 13:12:05 UTC, Ivan Kazmenko wrote:
Leaving x uninitialized, or using floats, work about the same.
No, floats are a whole lot less slow.
Are they? Locally, I don't see much difference. Code:
-
import std.datetime.stopwatch, std.math, std.stdio;
immutable float limit = 10 ^^ 7;
void main () {
int s;
auto sw = StopWatch (AutoStart.yes);
auto start = sw.peek ();
for (float x = NaN (0), i = 0; i < limit; i++)
s += (i < x);
auto now = sw.peek ();
writeln (now - start, ", sum is ", s);
}
-
Result:
-
1 sec, 467 ms, 40 μs, and 6 hnsecs, sum is 0
-
Fluctuating within a few per cent, but very similar to version
with doubles.
That's by DMD32 on Windows. (Sorry, my DMD64 broke after
upgrading Visual Studio to 2017, and I failed to fix it right
now. Anyway, it's not like x86_64 uses a different set of
general purpose floating-point hardware, right?)
Ivan Kazmenko.
Re: DMD, Vibe.d, and Dub
On Wednesday, 18 July 2018 at 12:56:05 UTC, Russel Winder wrote: [...] You have openssl 1.1 installed, but vibe.d tries to link with openssl 1.0 by default. See https://github.com/vibe-d/vibe.d#switching-between-openssl-versions tl;dr: use dub --override-config vibe-d:tls/openssl-1.1
Re: std.experimental.collections.rcstring and its integration in Phobos
On Wednesday, 18 July 2018 at 11:56:39 UTC, Seb wrote: [snip] Yes, Array is a reference-counted Array, but it also has a reference-counted allocator. I see. Is it really a good idea to make the ownership/lifetime strategy part of the container? What happens when you want to make nogc collections for lists, trees, etc? You have to make multiple versions for unique/ref counted/some new strategy? I would think it is more generic to have it a separate wrapper that handles the ownership/lifetime strategy, like what exists in automem and C++'s smart pointers...though automem looks like it has a separate type for Unique_Array rather than including it in Unique...so I suppose that potentially has the same issue...
Re: opCmp / opEquals do not actually support partial orders
On Wednesday, 18 July 2018 at 13:12:05 UTC, Ivan Kazmenko wrote:
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote:
Just do what std.typecons.Proxy does and return float.nan for
the incomparable case.
Isn't it slow though on current processors? I just threw
together a test program.
Leaving x uninitialized, or using floats, work about the same.
No, floats are a whole lot less slow.
But I agree, I would still prefer to have a signed bool which
uses only 1 byte
and provide _much_ faster comparison to NaN. And I have created
one,
but as it is not supported by the language natively, it
internally has to use
float, so is not faster (or even slower):
/// signed boolean type (2bit), has the values neg (0b11), zero
(0b00), pos (0b01) and nan (0b10)
/// this is an extended boolean that split "true" into
positive/negative and "false" into zero/NaN
struct sbool
{
pure:
@safe:
@nogc:
nothrow:
enum { neg = 0b11, zero = 0b00, pos = 0b01, nan = 0b10 };
this(T)(const(T) x) if(isNumeric!T)
{
static if(is(Unqual!T == sbool))
val = x.val; /// pos -> 1, neg -> 3, zero -> 0, nan -> 2
else static if(is(Unqual!T == bool))
val = x ? pos : zero;
else static if(isUnsigned!T)
val = x.isInvalid ? nan : (x>0) ? pos : zero;
else // signed or safe signed
val = x.isInvalid ? nan : (x<0) ? neg : (x>0) ? pos :
zero;
}
T opCast(T)() const if(isNumeric!T)
{
static if(is(Unqual!T == sbool))
return this;
else static if(is(Unqual!T == bool))
return val&1; // pos and neg are mapped to true, zero
and NaN are mapped to false
else static if(isFloatingPoint!T)
return tsgn[val];
else
return val == nan ? invalid!T : cast(T)tsgn[val];
}
sbool opAssign(T)(const(T) x) if(isNumeric!T)
{
return this(x);
}
sbool opOpAssign(string op)(const sbool x) if(op == "+" || op
== "-" || op == "*" || op == "/" || op == "%")
{
static if(op == "+") // attention! pos+neg = neg+pos = nan
!!
val = tadd[val];
else static if(op == "-") // attention! pos-pos = neg-neg =
nan !!
val = tsub[val];
else static if(op == "*")
val = tmul[val];
else static if(op == "/")
val = tdiv[val];
else static if(op == "%")
val = trem[val];
val >>= x.val<<1;
val &= 3;
return this;
}
sbool opUnary(string op)() if(op == "++" || op == "--")
{
mixin(op~"val");
val &= 3;
return this;
}
sbool opUnary(string op)() const if(op == "+" || op == "-" ||
op == "~")
{
static if(op == "+") return this;
sbool r = this;
mixin("r.val = "~op~"r.val");
r.val &= 3;
return r;
}
sbool opBinary(string op)(const(sbool) x) const if(op == "+"
|| op == "-" || op == "*" || op == "/" || op == "%")
{
sbool r = this;
return mixin("r "~op~"= x");
}
Signed!T opBinary(string op, T)(const(T) x) const
if(isNumeric!T && op == "*")
{
static if(isUnsigned!T)
{
alias R = Signed!T;
if(val == nan || x.isInvalid) return invalid!R;
if(val == zero) return 0;
if(x > R.max) return invalid!R;
return (val == pos) ? R(x) : -R(x);
}
else // signed or float: return type is same as T
{
if(x.isInvalid) return x;
final switch(val)
{
case pos: return x;
case neg: return -x;
case zero: return 0;
case nan: return invalid!T;
}
}
}
Signed!T opBinaryRight(string op, T)(const(T) x) const
if(isNumeric!T && op == "*")
{
return opBinary!"*"(x);
}
private:
ubyte val = nan;
static immutable float[4] tsgn = [ 0.0f, 1.0f, float.init,
-1.0f ];
// composition tables 0: -1 N 1 0 1: -1 N 1
0 N: -1 N 1 0 -1: -1 N 1 0
static immutable ubyte[4] tadd = [ 0b_11_10_01_00,
0b_10_10_01_01, 0b_10_10_10_10, 0b_11_10_10_11 ];
static immutable ubyte[4] tsub = [ 0b_01_10_11_00,
0b_01_10_10_01, 0b_10_10_10_10, 0b_10_10_11_11 ];
static immutable ubyte[4] tmul = [ 0b_00_10_00_00,
0b_11_10_01_00, 0b_10_10_10_10, 0b_01_10_11_00 ];
static immutable ubyte[4] tdiv = [ 0b_00_10_00_10,
0b_11_10_01_10, 0b_10_10_10_10, 0b_01_10_11_10 ];
static immutable ubyte[4] trem = [ 0b_00_10_00_10,
0b_01_10_01_10, 0b_10_10_10_10, 0b_11_10_11_10 ];
// remainder table is designed so, that if you define
// quot = (abs(a)/abs(b)) * (sbool(a)/sbool(b));
// rem = (abs(a)%abs(b)) * (sbool(a)%sbool(b));
// then assert(a == quot*b + rem) holds for all (a,b) with
b != 0
}
unittest
{
byte quot, rem;
for(byte a = 127; a >= -127; --a)
{
for(byte b = 127; b >= -127; --b)
{
quot = cast(byte)( (abs(a)/abs(b)) * (sbool(a)/sbool(b))
);
rem = cast(byte)( (abs(a)%abs(b)) * (sbool(a)%sbool(b))
);
assert((b == 0 && isInvalid(quot) &&
Re: std.experimental.collections.rcstring and its integration in Phobos
On Wednesday, 18 July 2018 at 11:56:39 UTC, Seb wrote: [snip] I think part of the above design decision connects in with why rcstring stores the data as ubytes, even for wchar and dchar. Recent comments suggest that it is related to auto-decoding. Yes rcstring doesn't do any auto-decoding and hence stores its data as an ubyte array. My sense is that an rcstring that does not have auto-decoding, even if it requires more work to get working with phobos is a better solution over the long-run. What do you mean by this? Just that there are a lot of complaints about D's auto-decoding of strings. Not doing any auto-decoding seems like a good long-run design decision, even if it makes some things more difficult.
Re: DMD, Vibe.d, and Dub
On Wednesday, 18 July 2018 at 12:56:05 UTC, Russel Winder wrote: Package installed, now I get: /usr/bin/ld: ../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-ldc_2081-B4D8997CFF9906E4CA7C7DC4C81EF881/libvibe-d_tls.a(vibe.stream.openssl.o): in function `_D4vibe6stream7openssl14OpenSSLContext6__ctorMFNfEQBwQBu3tls14TLSContextKindEQCxQCvQBb10TLSVersionZ9__lambda3MFNbNeZv': [...] Perhaps this? https://github.com/vibe-d/vibe.d/issues/2153
Re: opCmp / opEquals do not actually support partial orders
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote:
Just do what std.typecons.Proxy does and return float.nan for
the incomparable case.
Isn't it slow though on current processors? I just threw
together a test program.
-
import std.datetime.stopwatch, std.math, std.stdio;
immutable double limit = 10 ^^ 7;
void main () {
int s;
auto sw = StopWatch (AutoStart.yes);
auto start = sw.peek ();
for (double x = NaN (0), i = 0; i < limit; i++)
s += (i < x);
auto now = sw.peek ();
writeln (now - start, ", sum is ", s);
}
-
Essentially, it compares a double x (initialized as a quiet NaN
with payload 0) to a numeric double i, ten million times.
Leaving x uninitialized, or using floats, work about the same.
And here is the result:
-
1 sec, 593 ms, 116 μs, and 3 hnsecs, sum is 0
-
So, for a comparison involving NaN, we can do only a few million
of them a second. Granted, my Core i7-2600K is more than 5 years
old already, but the situation is unlikely to get any better.
But that's still a couple orders of magnitude slower than normal
vs. normal floating-point comparison: try assigning some regular
number to x, then the test takes ~50ms.
As far as I know, rare floating-point operations (such as this,
or using subnormal numbers) are, or rather should be, treated as
exceptions. The hardware manufacturers neglect such rare
operations to fit a bit more efficiency in the more common ones
(or they are just lazy). As a result, the developers don't
overuse them.
Ivan Kazmenko.
Re: DMD, Vibe.d, and Dub
On Wed, 2018-07-18 at 11:41 +, Seb via Digitalmars-d wrote: > On Wednesday, 18 July 2018 at 11:35:05 UTC, Russel Winder wrote: > > On Tue, 2018-07-17 at 21:46 +, Radu via Digitalmars-d wrote: > > > On Tuesday, 17 July 2018 at 18:55:07 UTC, Russel Winder wrote: > > > > [...] > > > > > > Missing openssl libs? Try installing openssl-dev package. > > > > The Debian Sid openssl package is definitely installed. There > > doesn't seem to be a separate openssl-dev package. > > It's called libssl-dev Package installed, now I get: /usr/bin/ld: ../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-ldc_2081-B4D8997CFF9906E4CA7C7DC4C81EF881/libvibe-d_tls.a(vibe.stream.openssl.o): in function `_D4vibe6stream7openssl14OpenSSLContext6__ctorMFNfEQBwQBu3tls14TLSContextKindEQCxQCvQBb10TLSVersionZ9__lambda3MFNbNeZv': /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:470: undefined reference to `SSLv23_client_method' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:471: undefined reference to `SSLv23_client_method' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:475: undefined reference to `SSLv23_client_method' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:476: undefined reference to `SSLv23_client_method' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:483: undefined reference to `SSLv23_server_method' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:484: undefined reference to `SSLv23_server_method' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:486: undefined reference to `SSLv23_server_method' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:487: undefined reference to `SSLv23_server_method' /usr/bin/ld: ../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-ldc_2081-B4D8997CFF9906E4CA7C7DC4C81EF881/libvibe-d_tls.a(vibe.stream.openssl.o): in function `_D4vibe6stream7openssl14OpenSSLContext11setDHParamsMFNeAyaZv': /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:725: undefined reference to `get_rfc3526_prime_2048' /usr/bin/ld: ../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-ldc_2081-B4D8997CFF9906E4CA7C7DC4C81EF881/libvibe-d_tls.a(vibe.stream.openssl.o): in function `_D4vibe6stream7openssl25_sharedStaticCtor_L911_C1FZv': /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:914: undefined reference to `SSL_load_error_strings' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:915: undefined reference to `SSL_library_init' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:917: undefined reference to `CRYPTO_num_locks' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:925: undefined reference to `CRYPTO_set_id_callback' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:926: undefined reference to `CRYPTO_set_locking_callback' /usr/bin/ld: /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/vibe/stream/openssl.d:931: undefined reference to `SSL_get_ex_new_index' /usr/bin/ld: ../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/tls/.dub/build/openssl-debug-linux.posix-x86_64-ldc_2081-B4D8997CFF9906E4CA7C7DC4C81EF881/libvibe-d_tls.a(vibe.stream.openssl.o): in function `_D6deimos7openssl9safestack__T10SKM_sk_numTSQBqQBm6x509v315GENERAL_NAME_stZ__TQBwZQCaFNbPSQDkQDgQDb__T8STACK_OFTQCrZQoZi': /home/users/russel/Organisations/ACCU/CodeCritique/112/Original/../../../../../.dub/packages/openssl-1.1.6_1.0.1g/openssl/deimos/openssl/safestack.d:140: undefined reference to `sk_num' /usr/bin/ld: ../../../../../.dub/packages
Re: Error: only one main allowed. Previously found main at *
On Tuesday, 19 June 2018 at 17:16:28 UTC, Brian wrote: dmd latest version bug? ```sh source/bootstrap.d(4,6): Error: only one main allowed. Previously found main at /tmp/dub_test_root-ad0fb2e3-6be1-4ca8-9153-e4fdd5c1b191.d(10,12) dmd failed with exit code 1. ``` Build logs: https://travis-ci.org/huntlabs/hunt-skeleton/jobs/389884419#L480 Did you fix it? Compiles fine for me on dmd version 2.081.0 and 2.080.1. (https://github.com/huntlabs/hunt-skeleton)
Re: DMD, Vibe.d, and Dub
On Wed, 2018-07-18 at 11:41 +, Seb via Digitalmars-d wrote: > On Wednesday, 18 July 2018 at 11:35:05 UTC, Russel Winder wrote: > > On Tue, 2018-07-17 at 21:46 +, Radu via Digitalmars-d wrote: > > > On Tuesday, 17 July 2018 at 18:55:07 UTC, Russel Winder wrote: > > > > [...] > > > > > > Missing openssl libs? Try installing openssl-dev package. > > > > The Debian Sid openssl package is definitely installed. There > > doesn't seem to be a separate openssl-dev package. > > It's called libssl-dev libssl installed but libssl-dev not. I can't quite see why the linker ld needs the development files, it just needs the shared objects to be present. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 18:09:13 UTC, Jonathan M Davis wrote:
On Tuesday, July 17, 2018 17:28:19 Seb via Digitalmars-d wrote:
On Tuesday, 17 July 2018 at 16:58:37 UTC, Jonathan M Davis
wrote:
> [...]
Well, there are few cases where the range type doesn't matter
and one can simply compare bytes, e.g.
equal (e.g. "ä" == "ä" <=> [195, 164] == [195, 164])
commonPrefix
find
...
That effectively means treating rcstring as a range of char by
default rather than not treating it as a range by default. And
if we then do that only with functions that overload on
rcstring rather than making rcstring actually a range of char,
then why aren't we just treating it as a range of char in
general?
IMHO, the fact that so many alogorithms currently special-case
on arrays of characters is one reason that auto-decoding has
been a disaster, and adding a bunch of overloads for rcstring
is just compounding the problem. Algorithms should properly
support arbitrary ranges of characters, and then rcstring can
be passed to them by calling one of the functions on it to get
a range of code units, code points, or graphemes to get an
actual range - either that, or rcstring should default to being
a range of char. going halfway and making it work with some
functions via overloads really doesn't make sense.
Well, the problem of it being a range of char is that this might
lead to very confusing behavior, e.g.
"ä".rcstring.split.join("|") == �|�
So we probably shouldn't go this route either.
The idea of adding overloads was to introduce a bit of
user-convenience, s.t. they don't have to say
readText("foo".rcstring.by!char)
all the time.
You can still normalize with auto-decoding (the code units -
and thus code points - are in a specific order even when
encoded, and that order can be normalized), and really, anyone
who wants fully correct string comparisons needs to be
normalizing their strings. With that in mind, rcstring probably
should support normalization of its internal representation.
It currently doesn't support this out of the box, but it's a very
valid point and I added it to the list.
Re: std.experimental.collections.rcstring and its integration in Phobos
On Wednesday, 18 July 2018 at 03:40:08 UTC, Jon Degenhardt wrote:
On Tuesday, 17 July 2018 at 15:21:30 UTC, Seb wrote:
So we managed to revive the rcstring project and it's already
a PR for Phobos:
https://github.com/dlang/phobos/pull/6631 (still WIP though)
The current approach in short:
- uses the new @nogc, @safe and nothrow Array from the
collections library (check Eduardo's DConf18 talk)
- uses reference counting
- _no_ range by default (it needs an explicit
`.by!{d,w,}char`) (as in no auto-decoding by default)
[snip]
What do you think about this approach? Do you have a better
idea?
I don't know the goals/role rcstring is expected to play,
especially wrt existing string/character facilities. Perhaps
you could describe more?
Sorry for the brevity yesterday.
One of long-term pain point of D is that usage of string can't be
@nogc.
rcstring is intended to be a drop-in @nogc replacement for
everywhere where string is currently used (that's the idea, at
least).
Strings are central to many applications, so I'm wondering
about things like whether rcstring is intended as a replacement
for string that would be used by most new programs,
Yes, that's the long-term goal. An opt-in @nogc string class.
There's no plan to do sth. disruptive like replacing the `alias
string = immutable(char)[];` declaration in druntime. However, we
might move rcstring to druntime at some point, s.t. e.g.
Exceptions or asserts can use @nogc strings.
and whether applications would use arrays and ranges of char
together with rcstring, or rcstring would be used for
everything.
That point is still open for discussion, but at the moment
rcstring isn't a range and the user has to declare what kind of
range he/she wants with e.g. `.by!char`
However, one current idea is that for some use cases (e.g.
comparison) it might not matter and an application could add
overloads for rcstrings.
The current idea is to do the same this for Phobos - though I
have to say that I'm not really looking forward to adding 200
overloads to Phobos :/
Perhaps its too early for these questions, and the current goal
is simpler. For example, adding a meaningful collection class
that is @nogc, @safe and ref-counted that be used as a proving
ground for the newer memory management facilities being
developed.
That's the long-term goal of the collections project.
However, with rcstring being the first big use case for it, the
idea was to push rcstring forward and by that discover all
remaining issues with the Array class.
Also the interface of rcstring is rather contained (and doesn't
expose the underlying storage to the user), which allows us to
iterate over/improve upon the Array design.
Such simpler goals would be quite reasonable. What's got me
wondering about the larger questions are the comments about
ranges and autodecoding. If rcstring is intended as a vehicle
for general @nogc handling of character data and/or for
reducing the impact of autodecoding, then it makes sense to
consider from those perspectives.
Hehe, it's intended to solve both problems (auto-decoding by
default and @nogc) at the same time.
However, it looks like to me like there isn't a good solution to
the auto-decoding problem that is convenient to use for the user
and doesn't sacrifice on performance.
Re: std.experimental.collections.rcstring and its integration in Phobos
On Wednesday, 18 July 2018 at 11:37:33 UTC, Seb wrote:
On Tuesday, 17 July 2018 at 17:41:05 UTC, Jacob Carlborg wrote:
On 2018-07-17 17:21, Seb wrote:
- _no_ range by default (it needs an explicit
`.by!{d,w,}char`) (as in no auto-decoding by default)
What do you think about this approach? Do you have a better
idea?
I vote for .by!char to be the default.
The problem here is this would also lead to very confusing
behavior for newcomers, e.g.
```
"ä".split.join("|") == �|�
```
Therefore it shouldn't compile at all, but
rcstring("ä")[].split("|")
or
rcstring("ä").byCodePoint.split("|")
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 18:43:47 UTC, jmh530 wrote: On Tuesday, 17 July 2018 at 15:21:30 UTC, Seb wrote: So we managed to revive the rcstring project and it's already a PR for Phobos: [snip] I'm glad this is getting worked on. It feels like something that D has been working towards for a while. Unfortunately, I haven't (yet) watched the collections video at Dconf and don't see a presentation on the website. Because of that, I don't really understand some of the design decisions. For instance, I also don't really understand how RCIAllocator is different from the old IAllocator (the documentation could use some work, IMO). It looks like RCIAllocator is part of what drives the reference counting semantics, Well AFAICT the idea is that with RCIAllocator (or its convenience function allocatorObject) is that you can convert any allocator to a reference-counted one, e.g. RCIAllocator a = allocatorObject(Mallocator.instance); but it also looks like Array has some support for reference counting, like addRef, that invoke RCIAllocator somehow. But Array also has some support for gc_allocator as the default, so my cursory examination suggests that Array is not really intended to be an RCArray... Yes, Array is a reference-counted Array, but it also has a reference-counted allocator. So at that point I started wondering why not just have String as an alias of Array, akin to how D does it for dynamic arrays to strings currently. If there is stuff in rcstring now that isn't in Array, then that could be included in Array as a compile-time specialization for the relevant types (at the cost of bloating Array). And then leave it up to the user how to allocate. There's lots of stuff in rcstring related to better interoperability with existing strings. e.g. you just want `"foo".rcstring == "foo"` to work. I think part of the above design decision connects in with why rcstring stores the data as ubytes, even for wchar and dchar. Recent comments suggest that it is related to auto-decoding. Yes rcstring doesn't do any auto-decoding and hence stores its data as an ubyte array. My sense is that an rcstring that does not have auto-decoding, even if it requires more work to get working with phobos is a better solution over the long-run. What do you mean by this?
Re: DMD, Vibe.d, and Dub
On Wednesday, 18 July 2018 at 11:35:05 UTC, Russel Winder wrote: On Tue, 2018-07-17 at 21:46 +, Radu via Digitalmars-d wrote: On Tuesday, 17 July 2018 at 18:55:07 UTC, Russel Winder wrote: > [...] Missing openssl libs? Try installing openssl-dev package. The Debian Sid openssl package is definitely installed. There doesn't seem to be a separate openssl-dev package. It's called libssl-dev
Re: opCmp / opEquals do not actually support partial orders
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote: On Tuesday, 17 July 2018 at 18:21:26 UTC, H. S. Teoh wrote: But opCmp turns out to be a tarpit. Here's why: According to the original claim, it should also return 0, for "incomparable". However, this leads to problems: Indeed. And it doesn't make sense at all. Just do what std.typecons.Proxy does and return float.nan for the incomparable case. Yes, that's the only way. Having this 4th value of opCmp is necessary for may types. In fact opCmp() it practically the only place where I ever use the type "float", just to have the NaN. If I really need floatingpoint arithmetic, I always use real (or at least double). I would like to have a "signed boolean" type (with the values -1, 0, 1 and NaN) simply for all kind of sign operations. But ok, float is 32bit, and IEEE suggests a "half" type (16bit). As a "signed boolean" would need a byte anyway there is no too much to gain.
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 17:41:05 UTC, Jacob Carlborg wrote:
On 2018-07-17 17:21, Seb wrote:
- _no_ range by default (it needs an explicit
`.by!{d,w,}char`) (as in no auto-decoding by default)
What do you think about this approach? Do you have a better
idea?
I vote for .by!char to be the default.
The problem here is this would also lead to very confusing
behavior for newcomers, e.g.
```
"ä".split.join("|") == �|�
```
Re: DMD, Vibe.d, and Dub
On Tue, 2018-07-17 at 21:46 +, Radu via Digitalmars-d wrote: > On Tuesday, 17 July 2018 at 18:55:07 UTC, Russel Winder wrote: > > [...] > > Missing openssl libs? Try installing openssl-dev package. The Debian Sid openssl package is definitely installed. There doesn't seem to be a separate openssl-dev package. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: DMD, Vibe.d, and Dub
On Tue, 2018-07-17 at 20:04 +, kinke via Digitalmars-d wrote: > On Tuesday, 17 July 2018 at 19:39:32 UTC, Russel Winder wrote: > > It seems that the LDC 1.11 branch in the GitHub repository has > > the DMD 2.081.0 problem. > > If you're referring to branch merge-2.081, that one doesn't exist > anymore. master/beta2 are based on 2.081.1+ and should thus be > fixed. Ah, OK. I missed that. My script that updates repositories is not causing a Git failure, this is strange. I'll sort my repository out and rebuild. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 16:58:37 UTC, Jonathan M Davis wrote: If it's not a range by default, why would you expect _anything_ which operates on ranges to work with rcstring directly? IMHO, if it's not a range, then range-based functions shouldn't work with it, and I don't see how they even _can_ work with it unless you assume code units, or code points, or graphemes as the default. If it's designed to not be a range, then it should be up to the programmer to call the appropriate function on it to get the appropriate range type for a particular use case, in which case, you really shouldn't need to add much of any overloads for it. - Jonathan M Davis This makes sense for me too.
