Re: Configuring DerelictGL3
Thanks for the help (and sorry for the slow reply, it took longer to get everything tested and configured than I would have liked... sorry if this is frowned upon on this forum...) I do have an odd bug, however, and I'm not sure how to go any further with it. So I'm using the standard process: DerelictGL3.load(); glContext = SDL_GL_CreateContext(sdlWindow); GLVersion glVersion = DerelictGL3.reload(); About 1/3 of the time, the program hangs on the 3rd line and never gets past it. Currently tracking whether admittedly odd things I'm doing with threads might be the culprit. I have a growing suspicion they might be. Looking forward to the BindBC release. I assume it's more or less intended to be a drop-in replacement for Derelict, with normal allowances for version-to-version updating, but more stable.
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: crash when using in struct constructor
On Wednesday, 18 July 2018 at 12:10:18 UTC, baz wrote:
Specs are clear : it's a global so it's evaluated at compile
time
(https://dlang.org/spec/declaration.html#global_static_init)
Example code should not compile.
Indeed. Inside a function it does actually work.
And ofcourse for
class Test {
List ls = 1;
}
it's going to make a static initializer which is then copied
during construction of Test, so that's never going to work with
the
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: SDLang-D v0.10.4 - Minor maintenance release
On 07/18/2018 01:57 PM, Anton Pastukhov wrote: On Monday, 16 July 2018 at 04:14:12 UTC, Nick Sabalausky (Abscissa) wrote: announce.sdl: == [...] http://sdl.ikayzo.org/ is down, so maybe remove links to it from sdlang.org? Yea, it has been for a looong time :( I keep hoping it'll come back, but I guess it doesn't look like that's going to happen.
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([0]) + *([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 `` 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 [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: Symmetry Autumn of Code
I've said, that if we get signatures, I'll build the damn thing myself. Signatures give a very lightweight vtable implementation while also giving conceptual representation of structs+classes. Which for an event loop, is a very desirable thing to have. But alas, I'm waiting on my named parameter DIP and seeing where that goes, before continuing work on signatures. Thanks for the clear explanations. Glad to know that you're on this. I hope the importance of your work for D's "competivity" will be truly recognized.
Re: SDLang-D v0.10.4 - Minor maintenance release
On Monday, 16 July 2018 at 04:14:12 UTC, Nick Sabalausky (Abscissa) wrote: announce.sdl: == [...] http://sdl.ikayzo.org/ is down, so maybe remove links to it from sdlang.org?
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
[Issue 19095] Static initiatization statements of an array appeared in different kind of scopes have inconsistent semantics
https://issues.dlang.org/show_bug.cgi?id=19095 --- Comment #3 from Basile B. --- (In reply to Basile B. from comment #2) > (In reply to Basile B. from comment #1) > > Not a bug as you say. And this is too different constructs > > Forgot to say but, the error you made is to think that the call to "foo()" > is eluded, i.e simplified to its return. In the foo() call you have an 'ArrayLiteral', which does not allow the freedom of of 'ArrayInitializer', for obvious reasons : when used in expressions the whole stuff is required, while in an initializer a special semantic can be applied since the type of the thing to stuff is (usually) known. --
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.
[Issue 19095] Static initiatization statements of an array appeared in different kind of scopes have inconsistent semantics
https://issues.dlang.org/show_bug.cgi?id=19095 --- Comment #2 from Basile B. --- (In reply to Basile B. from comment #1) > Not a bug as you say. And this is too different constructs Forgot to say but, the error you made is to think that the call to "foo()" is eluded, i.e simplified to its return. --
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.
[Issue 19096] New: [REG 2.061] Proper error messages are not shown for templates that go beyond two deep, wrongly says no template overload matches
https://issues.dlang.org/show_bug.cgi?id=19096
Issue ID: 19096
Summary: [REG 2.061] Proper error messages are not shown for
templates that go beyond two deep, wrongly says no
template overload matches
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: db...@joakim.fea.st
I ran into this when refactoring std.conv.parse in Phobos and mistakenly had a
variable shadowing another. Suddenly, ldc started telling me that none of the
11 overloads matched anymore, with no clue what I'd done wrong. I resorted to
cutting and pasting the parse() function into a test file and removing all
template arguments and constraints, after which the compiler pointed out the
shadowed variable.
I reduced that down to this code that shows the ins and outs:
```
import std.range.primitives, std.traits;
Target parse(Target, Source)(ref Source source)
if (isInputRange!Source && isSomeChar!(ElementType!Source) && !is(Source ==
enum) &&
isFloatingPoint!Target && !is(Target == enum))
{
bool anydigits = false;
version(broken)
{
if ( anydigits )
{
bool anydigits = true;
}
}
return 3.14;
}
template isExactSomeString(T)
{
enum isExactSomeString = isSomeString!T && !is(T == enum);
}
private T toImpl(T, S)(S value)
if (isInputRange!S && isSomeChar!(ElementEncodingType!S) &&
!isExactSomeString!T && is(typeof(parse!T(value
{
bool anydigits = false;
version(proper)
{
if ( anydigits )
{
bool anydigits = true;
}
}
return parse!T(value);
}
void main()
{
string foo = "3.14";
version(correct) parse!real(foo);
else toImpl!real(foo);
}
```
Ignoring all the version statements, this compiles fine with no shadowed
variables with dmd 2.081.1 for linux/x64. If there's a shadowed variable in the
toImpl() template called from main, enabled with `dmd -version=proper
shadow.d`, I get this useful error message:
frontend.d(32): Error: variable anydigits is shadowing variable
frontend.toImpl!(real, string).toImpl.anydigits
frontend.d(42): Error: template instance `frontend.toImpl!(real, string)` error
instantiating
However, if the shadowing problem goes two templates deep, enabled with `dmd
-version=broken shadow.d`, I get this weird error, it claims no overloads match
anymore:
frontend.d(42): Error: template frontend.toImpl cannot deduce function from
argument types !(real)(string), candidates are:
frontend.d(23):frontend.toImpl(T, S)(S value) if (isInputRange!S &&
isSomeChar!(ElementEncodingType!S) && !isExactSomeString!T &&
is(typeof(parse!T(value
If I call that broken parse() template directly, enabled with `dmd
-version=correct -version=broken shadow.d`, now I get a useful error again:
frontend.d(12): Error: variable anydigits is shadowing variable
frontend.parse!(real, string).parse.anydigits
frontend.d(41): Error: template instance `frontend.parse!(real, string)` error
instantiating
This demonstrates how the frontend is throwing away the right error messages
once templates start getting nested, which can be seen in the similar bug 9179
and bug 13340 also.
run.dlang.io says this actually used to work up till dmd 2.061:
https://run.dlang.io/is/DpqFeg
Working with templates gets very annoying if it starts to gag these error
messages. I'm not sure why it would do this: are there actually template
overloads where multiple functions might work, so it just chooses the one that
compiles? In this case, I think only one overload should match, so I want the
error message for that one.
--
[Issue 19095] Static initiatization statements of an array appeared in different kind of scopes have inconsistent semantics
https://issues.dlang.org/show_bug.cgi?id=19095 Basile B. changed: What|Removed |Added Status|NEW |RESOLVED CC||b2.t...@gmx.com Resolution|--- |INVALID --- Comment #1 from Basile B. --- Not a bug as you say. And this is too different constructs, not related to static initialization (which means that the title of the report is not correct btw), see https://dlang.org/spec/declaration.html#NonVoidInitializer ArrayInitializer int[2] ARR = [1]; // "[" -> left square so parse a "ArrayInitializer" ExpInitializer int[2] ARR_2 = foo(); // "f" -> ident char so parse a "ExpInitializer" ArrayInitializer is useful to make lookup tables, i.e you mostly want the default value but a particular value for a few cases. This cant be fixed, it's part of the language and it's used, notably, in the source code of the runtime for example. It would not be reasonable to force all entries to be initialized. --
[Issue 19094] Anchored section does not exist in std.uni.normalize phobos documentation
https://issues.dlang.org/show_bug.cgi?id=19094 ag0aep6g changed: What|Removed |Added Keywords||pull CC||ag0ae...@gmail.com Component|dlang.org |phobos Assignee|nob...@puremagic.com|ag0ae...@gmail.com --- Comment #1 from ag0aep6g --- https://github.com/dlang/phobos/pull/6637 --
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
[Issue 19092] __delete doesn't work with immutable
https://issues.dlang.org/show_bug.cgi?id=19092 Seb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
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) &&
[Issue 19095] New: Static initiatization statements of an array appeared in different kind of scopes have inconsistent semantics
https://issues.dlang.org/show_bug.cgi?id=19095
Issue ID: 19095
Summary: Static initiatization statements of an array appeared
in different kind of scopes have inconsistent
semantics
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: trivial
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: kub...@gmail.com
I think this is not a bug, but it seems like unnatural behavior.
---
auto foo()
{
return [1];
}
int[2] ARR = [1];
int[2] ARR_2 = foo(); // Error: mismatched array lengths, 2 and 1
void main()
{
assert(ARR == [1, 0]); // Success.
int[2]arr = [1]; // Error: mismatched array lengths, 2 and 1
}
---
--
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: HMAC and toHexString
On Wednesday, 18 July 2018 at 11:29:42 UTC, baz@dlang-community wrote: On Wednesday, 18 July 2018 at 11:22:36 UTC, Nicholas Wilson wrote: On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote: [...] Ahh, the joys of memory corruption. You've reached https://issues.dlang.org/show_bug.cgi?id=16519 maybe ? Not sure if it was that or some of the other memory corruption I was experiencing.
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: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 17 July 2018 at 22:10:52 UTC, jmh530 wrote: On Tuesday, 17 July 2018 at 16:39:48 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 15:55:03 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote: [...] I'm going to create an issue on Github. This is the output I get: [...] I solved that problem but now I have others. dpp is a good thing on paper but maybe not yet in practice. Echoing what Andrei and Walter say all the time, it's not going to get fixed without bug reports... I plan to report this...eventually.
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.
[Issue 19094] New: Anchored section does not exist in std.uni.normalize phobos documentation
https://issues.dlang.org/show_bug.cgi?id=19094 Issue ID: 19094 Summary: Anchored section does not exist in std.uni.normalize phobos documentation Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: timos...@gmail.com In the documentation of std.uni.normalize the anchor to #Normalization does not exist. https://dlang.org/phobos/std_uni.html#normalize Link to "normalization section" -> Does not exist: https://dlang.org/phobos/std_uni.html#Normalization --
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:
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: crash when using in struct constructor
On Wednesday, 18 July 2018 at 11:35:40 UTC, baz wrote: On Wednesday, 18 July 2018 at 11:27:33 UTC, baz@dlang-community wrote: On Monday, 16 July 2018 at 22:21:12 UTC, H. S. Teoh wrote: On Mon, Jul 16, 2018 at 10:08:34PM +, Eric via Digitalmars-d-learn wrote: [...] It's not illegal per se, but a very, very bad idea in general, because in D, structs are expected to be int-like POD values that can be freely copied/moved around by the compiler. More specifically, when structs are passed into functions or returned from functions, they may be moved around. Which means internal pointers will wind up being wrong. [...] Moving doesn't seem to be the issue here. Despite of the ICE, this code shouldn't compile, unless "" is allowed at compile-time. still with .init() trick this works, so im' not super sure... NVM the .init() trick. Specs are clear : it's a global so it's evaluated at compile time (https://dlang.org/spec/declaration.html#global_static_init) Example code should not compile.
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?
[Issue 9588] format prints context pointer for struct
https://issues.dlang.org/show_bug.cgi?id=9588 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #7 from Simen Kjaeraas --- Another option: __traits(identifier, S.tupleof[1]) returns "this". --
[Issue 19092] __delete doesn't work with immutable
https://issues.dlang.org/show_bug.cgi?id=19092 --- Comment #5 from Mike Franklin --- > The issue is that the compiler deprecated `delete` and offers `__delete`as an > alternative (with destroy/free as optional) and it doesn't work as advertised! `delete` was deprecated in favor of `destroy` and `free`ing functions. `__delete` was offered only as a last resort in case `destroy` was not possible. If you're reaching for `__delete` first, you are not using D as it was intended to be used and you are only going to create problems for yourself and for the maintainers of D. Please avoid it, if possible. --
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: crash when using in struct constructor
On Wednesday, 18 July 2018 at 11:27:33 UTC, baz@dlang-community wrote: On Monday, 16 July 2018 at 22:21:12 UTC, H. S. Teoh wrote: On Mon, Jul 16, 2018 at 10:08:34PM +, Eric via Digitalmars-d-learn wrote: [...] It's not illegal per se, but a very, very bad idea in general, because in D, structs are expected to be int-like POD values that can be freely copied/moved around by the compiler. More specifically, when structs are passed into functions or returned from functions, they may be moved around. Which means internal pointers will wind up being wrong. [...] Moving doesn't seem to be the issue here. Despite of the ICE, this code shouldn't compile, unless "" is allowed at compile-time. still with .init() trick this works, so im' not super sure...
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 11:22:36 UTC, Nicholas Wilson wrote: On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote: [...] Ahh, the joys of memory corruption. Yep, actually this one is a very common one. However, -dip1000 would warn you here ...
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: Why does templated interface function return something different than final function?
On Wednesday, 18 July 2018 at 11:09:12 UTC, Timoses wrote:
Why is the interface templated function not also returning the
class C toString return value "in C"??
interface iface
{
void toString(scope void delegate(const(char)[]) sink) const;
final string convert() inout
{
import std.conv;
// assert(std.conv.to!string(this) == "in C"); // fails!
return std.conv.to!string(this);
}
final string convert2() const
{
import std.conv;
assert(std.conv.to!string(this) == "in C");
return std.conv.to!string(this);
}
}
class C : iface
{
void toString(scope void delegate(const(char)[]) sink) const
{
sink("in C");
}
}
void main ()
{
iface i = new C();
import std.stdio;
writeln(i.convert); // "app.C"
writeln(i.convert2()); // "in C"
}
It seems like `inout` triggers some odd behaviour??
Sorry, I experimented a bit and forgot to change the topic to
something more fitting, e.g.
"Why does inout struct function return different results?"
Re: crash when using in struct constructor
On Monday, 16 July 2018 at 22:21:12 UTC, H. S. Teoh wrote: On Mon, Jul 16, 2018 at 10:08:34PM +, Eric via Digitalmars-d-learn wrote: [...] It's not illegal per se, but a very, very bad idea in general, because in D, structs are expected to be int-like POD values that can be freely copied/moved around by the compiler. More specifically, when structs are passed into functions or returned from functions, they may be moved around. Which means internal pointers will wind up being wrong. [...] Moving doesn't seem to be the issue here. Despite of the ICE, this code shouldn't compile, unless "" is allowed at compile-time.
[Issue 19093] New: 'cannot alias itself' when using a template instantiation in a template parameter
https://issues.dlang.org/show_bug.cgi?id=19093
Issue ID: 19093
Summary: 'cannot alias itself' when using a template
instantiation in a template parameter
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
alias Foo(T) = T;
struct Test(T, Foo!T t) {}
unittest {
Test!(int, 3) a;
}
foo.d(2): Error: alias T = T; cannot alias itself, use a qualified name to
create an overload set
--
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Tuesday, 17 July 2018 at 06:24:12 UTC, Simen Kjærås wrote:
That makes sense. The problem is F has a context pointer to the
main() block, since it's a non-static struct with methods
inside a block. It doesn't actually use the context pointer for
anything, so it possibly shouldn't have one, but it does, so we
have to work around it.
The fix is to mark F as static, or move it outside the main()
block.
--
Simen
Thanks for the explanation.
But why is a context pointer a problem? Is it problematic because
the context pointer to the main scope can not guarantee
`immutable`? E.g. if I happened to use data from main in a
function of the immutable struct then... well then what?
The struct would still be immutable, but what would prevent a
function from using non-immutable data?
E.g. I could do this
int gnumber = 3;
struct F
{
int i;
void fun() immutable
{
gnumber = 5;
}
}
void main ()
{
immutable F f = F();
f.fun;
}
I declared `fun()` to be an immutable function. So calling the
immutable struct function `F.fun()` changes a module scope int.
The same could be applied to local data of the main scope,
however the following fails:
void main ()
{
int mnumber = 3;
struct F
{
int i;
void fun() immutable
{
// Error: immutable function onlineapp.main.F.fun
cannot access mutable data mnumber
mnumber = 5;
}
}
immutable F f = F();
f.fun;
}
Is this connected why I can't implicitly convert a local struct
with a context pointer to immutable? What's the reason behind it?
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 11:22:36 UTC, Nicholas Wilson wrote: On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote: [...] Ahh, the joys of memory corruption. You've reached https://issues.dlang.org/show_bug.cgi?id=16519 maybe ?
[Issue 19092] __delete doesn't work with immutable
https://issues.dlang.org/show_bug.cgi?id=19092 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #4 from Seb --- > As a side note, this is not the first time I report issues related to > const/immutable not being properly tested for druntime functions (__equals > caused a regression for immutable AA), I think making sure > cost/immutable/shared are covered for generic code should be a top priority > when reviewing code. Aware of it, but sadly our review manpower isn't optimal at the moment and sometimes things slip through. However, any issue reported is certainly appreciated and (like here) we try to fix it ASAP. --
Re: Symmetry Autumn of Code
On 18/07/2018 10:53 PM, Ecstatic Coder wrote: On Wednesday, 18 July 2018 at 03:19:53 UTC, rikki cattermole wrote: On 18/07/2018 5:36 AM, Ecstatic Coder wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ I'd suggest adding the following to SAOC 2018 project proposals : 1/ adding a Go-like http module to the standard library 2/ adding Go-like async IO management to the standard library, i.e. fibers communicating through blocking channels Until we get an event loop in druntime, both of these options are off the table. Sad. Then I'd suggest to add the event loop implementation to SAOC 2018 too, because the absence of a default http module in D's standard library may have very good justifications, but I'm still convinced that it doesn't help when trying to "sell" it to modern developers, considering that nowadays MANY of the applications they will develop in a professional facility will have to integrate http code to access or update the company's data. I've said, that if we get signatures, I'll build the damn thing myself. Signatures give a very lightweight vtable implementation while also giving conceptual representation of structs+classes. Which for an event loop, is a very desirable thing to have. But alas, I'm waiting on my named parameter DIP and seeing where that goes, before continuing work on signatures.
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote: ... string key = "blahblahblah"; auto mac = hmac!SHA256(key.representation); string s = ...,t=...u=...,v=...; foreach(w;AliasSeq!(s,t,u,v)) mac.put(w.representation); ubyte[32] s = mac.finish; string sig = toHexString!(LetterCase.lower)(s); writeln(sig); // From what I understand Should print something like 41771e2d0d6c1cf7f442aa8547783ea5b126bfc15a4b354e94d0eaea2ab0fa1a // Actually prints something like x"31 36 39 33 39 32 38 31 62 38 31 62 36 36 62 63 63 34 63 36 36 61 62 32 34 37 64 32 64 34 61 00 78 2A 55 5B FF 7F 00 00 78 2A 55 5B FF 7F 00 00 E0 2A 55 5B FF 7F 00 00 08 2C 55 5B FF 7F 00 00"c Note the nuls and things like FF What am I doing wrong here? Ahh, the joys of memory corruption.
[Issue 19089] Compiler crash for using struct
https://issues.dlang.org/show_bug.cgi?id=19089 Basile B. changed: What|Removed |Added Keywords||CTFE CC||b2.t...@gmx.com --- Comment #1 from Basile B. --- "List l = 0;" is done at compile time. This shouldn't be allowed since there's a pointer operation. put "writeln();" in the ctor to see an evidence. --
[Issue 19092] __delete doesn't work with immutable
https://issues.dlang.org/show_bug.cgi?id=19092 --- Comment #3 from Seb --- An attempt at fixing __delete - https://github.com/dlang/druntime/pull/2253 @JinShil: I agree but unfortunately for a seamless deprecation of delete, __delete must be a full drop-in replacement. --
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
Why does templated interface function return something different than final function?
Why is the interface templated function not also returning the
class C toString return value "in C"??
interface iface
{
void toString(scope void delegate(const(char)[]) sink) const;
final string convert() inout
{
import std.conv;
// assert(std.conv.to!string(this) == "in C"); // fails!
return std.conv.to!string(this);
}
final string convert2() const
{
import std.conv;
assert(std.conv.to!string(this) == "in C");
return std.conv.to!string(this);
}
}
class C : iface
{
void toString(scope void delegate(const(char)[]) sink) const
{
sink("in C");
}
}
void main ()
{
iface i = new C();
import std.stdio;
writeln(i.convert); // "app.C"
writeln(i.convert2()); // "in C"
}
It seems like `inout` triggers some odd behaviour??
[Issue 19092] __delete doesn't work with immutable
https://issues.dlang.org/show_bug.cgi?id=19092 --- Comment #2 from Radu Racariu --- The problem here is not if `delete` or `__delete` are correct or not. The issue is that the compiler deprecated `delete` and offers `__delete`as an alternative (with destroy/free as optional) and it doesn't work as advertised! This is a very bad in terms of the overall perceived quality, I don't wanna go into the reasoning of why `__delete` was added (or kept), but we have it and it should work with all language constructs! As a side note, this is not the first time I report issues related to const/immutable not being properly tested for druntime functions (__equals caused a regression for immutable AA), I think making sure cost/immutable/shared are covered for generic code should be a top priority when reviewing code. --
Re: Symmetry Autumn of Code
On Wednesday, 18 July 2018 at 03:19:53 UTC, rikki cattermole wrote: On 18/07/2018 5:36 AM, Ecstatic Coder wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ I'd suggest adding the following to SAOC 2018 project proposals : 1/ adding a Go-like http module to the standard library 2/ adding Go-like async IO management to the standard library, i.e. fibers communicating through blocking channels Until we get an event loop in druntime, both of these options are off the table. Sad. Then I'd suggest to add the event loop implementation to SAOC 2018 too, because the absence of a default http module in D's standard library may have very good justifications, but I'm still convinced that it doesn't help when trying to "sell" it to modern developers, considering that nowadays MANY of the applications they will develop in a professional facility will have to integrate http code to access or update the company's data.
Re: Symmetry Autumn of Code
On Wednesday, 18 July 2018 at 10:35:04 UTC, Andre Pany wrote: Proposal: Multi IDE debugger support (for windows) [snip] This is a good idea too.
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Another proposal: Adding D support to gRPC I started to add D support to gRPC but paused it due to lack of knowledge and time. One solution would be to add a D wrapper to https://github.com/grpc/grpc/tree/master/src by making use of the C interface of gRPC (https://github.com/grpc/grpc/tree/master/include/grpc). As template e.g. C++ or python could be used (https://github.com/grpc/grpc/tree/master/src). Kind regards André
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote:
...
string key = "blahblahblah";
auto mac = hmac!SHA256(key.representation);
string s = ...,t=...u=...,v=...;
foreach(w;AliasSeq!(s,t,u,v))
mac.put(w.representation);
ubyte[32] s = mac.finish;
string sig = toHexString!(LetterCase.lower)(s);
writeln(sig);
// From what I understand Should print something like
41771e2d0d6c1cf7f442aa8547783ea5b126bfc15a4b354e94d0eaea2ab0fa1a
// Actually prints something like x"31 36 39 33 39 32 38 31 62
38 31 62 36 36 62 63 63 34 63 36 36 61 62 32 34 37 64 32 64 34
61 00 78 2A 55 5B FF 7F 00 00 78 2A 55 5B FF 7F 00 00 E0 2A 55
5B FF 7F 00 00 08 2C 55 5B FF 7F 00 00"c
Note the nuls and things like FF
What am I doing wrong here?
Don't know, what you mean. Works for me:
´´´
import std.stdio;
import std.digest.hmac;
import std.digest.sha;
import std.string;
import std.meta;
void main()
{
string key = "blahblahblah";
auto mac = hmac!SHA256(key.representation);
string s = "...",t="...", u="...",v="...";
foreach(w;AliasSeq!(s,t,u,v))
mac.put(w.representation);
ubyte[32] r = mac.finish;
r.toHexString!(LetterCase.lower).writeln;
}
´´´
output:
dc84632fc9b5d1f4b879d9aa021ae0d089e7f66a2fd2e824829cfceedbece729
[Issue 19092] __delete doesn't work with immutable
https://issues.dlang.org/show_bug.cgi?id=19092 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #1 from Mike Franklin --- In principle, yes, `__delete` should be a drop-in replacement for `delete`, but using `__delete` should be avoided unless all other options have failed. In fact, when `delete` was deprecated there was some resistance to creating `__delete`. In my opinion, all it does is encourage anti-patterns and technical debt, and I wish `__delete` was never created. What is the actual use case and why is `destroy` in combination with `free`ing functions not possible? --
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Proposal: Multi IDE debugger support (for windows) Mago, the debug engine used in VisualD, has also a tool called Mago-MI which has a GDB compatible interface. Therefore you can use on Windows Mago-MI as replacement for GDB. Several IDEs uses this feature to enable debugging with 1 code line for Windows/Linux/MacOS. It is used in experimental state in IntelliJ, also there is support in Visual Studio Code and of course DLangIDE for which it was originally built. There are several issues which could be addressed in Symmetry Autumn of Code: - Mago-MI is written in C++. This makes bug solving hard. Rewriting of Mago-MI to D might make sense. - While the installation of Mago-MI is easy if you want to debug OMF executables it is very hard if you want to debug COFF executables. You need another executable from Mago, you have to register DLLs via regserv and you manually have to create a registry entry. An installation procedure for installing Mago-MI would be great. - There are some bugs in Mago-MI / and DMD (wrong debug information) which makes debugging hard. (https://github.com/rainers/mago/issues/21, https://github.com/rainers/mago/issues/23). Also Mago-Mi misses features (https://github.com/rainers/mago/issues/14). There are more bugs but not investigated so far. - As Visual Studio Code is already is already a topic for DLang Foundation, using this as reference user of Mago-MI would make sense. While this proposal seems only windows related, the nature of Mago-Mi is to enable IDEs having 1 code line for debugging on Windows/Linux/MacOS. Therefore overall investing into this topic is good for all platforms. Kind regards André
Re: LDC 1.11.0 beta2
On Wednesday, 18 July 2018 at 00:47:49 UTC, Dennis wrote: This is really awesome! I tried the examples, is there any other documentation about it currently? I tried passing strings instead of numbers to the callback, but it passes the length as a number only. I doesn't work with char pointers either, I presume that's still WIP. Still, really exciting. Passing strings seems to be a PITA due to non-shared memory, see https://medium.com/@mbebenita/hello-world-in-webassembly-83951757775. This seems specific to the current wasm browser implementations though, or at the very least not specific to D or LDC, so you can look up existing Clang/Rust/... wasm tutorials/articles for more in-depth infos.
[Issue 19092] New: __delete doesn't work with immutable
https://issues.dlang.org/show_bug.cgi?id=19092
Issue ID: 19092
Summary: __delete doesn't work with immutable
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: blocker
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: radu.raca...@gmail.com
The following program
---
void main()
{
import core.memory : __delete;
immutable(int)[] x;
__delete(x);
}
---
Fails to compile
---
/dlang/dmd/linux/bin64/../../src/druntime/import/core/memory.d(1022): Error:
function core.memory.GC.free(void* p) is not callable using argument types
(immutable(int)*)
/dlang/dmd/linux/bin64/../../src/druntime/import/core/memory.d(1022):
cannot pass argument cast(immutable(int)*)x of type immutable(int)* to
parameter void* p
onlineapp.d(7): Error: template instance
`core.memory.__delete!(immutable(int)[])` error instantiating
---
If `__delete` is suppose to be an alternative to `delete` then it has to
support all use cases.
As this compiles (with the deprecation warning)
---
void main()
{
immutable(int)[] x;
delete x;
}
---
--
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.
Re: D:YAML 0.7.0
On Wednesday, 18 July 2018 at 07:28:02 UTC, baz@dlang-community wrote: - major performance gain when reading YAML files. The little story: YAML specifies that each associative-array-like data must be unique. The uniqueness before 0.7.0 was tested on insertion, leading to an obvious complexity issue. The trick used was to check only once at the end, i.e after reading a document and to throw in case uniqueness is not verified. The problem was detected by a guy who tried to load a data file for the EVE online game. It took 30 minutes (and billions of dynamic cast when comparing already loaded content...). Now loading the file takes less than 30 secs. For the win...
D:YAML 0.7.0
Since latest months a major work has been achieved, mostly by the member "Herringway". # New Features - completely usable in `@safe` code. - major performance gain when reading YAML files. - major performance gain when writing YAML files. - new outputrange-based document writer - Node.add now works with valueless nodes - added examples as subpackages - added a json conversion example - benchmark subpackage now prints detailed times # Removed Features - removes `dyaml.all`, `yaml` package modules # Fixes - fixes BOMs being written for UTF-8 documents https://github.com/dlang-community/D-YAML/releases/tag/v0.7.0 https://github.com/dlang-community/D-YAML https://code.dlang.org/packages/dyaml
[Issue 18901] [Visual D] fatal error C1905: Front-End and Back-End are not compatible (have to use the same processor)
https://issues.dlang.org/show_bug.cgi?id=18901 Rainer Schuetze changed: What|Removed |Added CC||robert.mue...@saphirion.com --- Comment #2 from Rainer Schuetze --- I still think that your VS installation is broken, but if you think it is ok, please provide an example project including the visuald project files. --
Re: Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....
On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer wrote: But it doesn't scale if you use OS processes, it's too heavyweight. Of course, it depends on the application. If you only need 100 concurrent connections, processes might be OK. I think you may have fallen for Microsoft FUD. In the Early Days of Windows Microsoft was appalling Bad at multiple processes Rather than fix their OS, they cranked up their Marketing machine and Hyped threads as "Light Weight Processes". Unixy land has had "COW" (Copy on Write) page handling for years and years and process creation and processes are light weight. There are very very few Good reasons for threads, but threads being "light weight processes" is definitely not one of them
