Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote: On 3/6/18 2:30 PM, Martin Nowak wrote: On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: But if needed, you could have your dub package depend on a prior version. http://code.dlang.org/packages/stdx-allocator ;) This is the answer, vibe.d should depend on stdx-allocator. -Steve Vibe.d (and a lot of other projects) do depend on this package, see e.g. https://github.com/vibe-d/vibe.d/pull/1983 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.
Re: Release D 2.079.0
On 07/03/2018 2:54 PM, psychoticRabbit wrote: On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote: Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us? That's the day I stop using D. I do not, and will not, use dub. Full stop. Same goes for Rust ;-) Under such arrangement nobody is forcing you to use dub. We wouldn't break distribution or usage of dmd just because of changing a make file to dub. That's just silly.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote: Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us? That's the day I stop using D. I do not, and will not, use dub. Full stop. Same goes for Rust ;-)
Re: Release D 2.079.0
On Tue, Mar 06, 2018 at 08:50:37PM +, Jack Stouffer via Digitalmars-d-announce wrote: [...] > Also, if you'll allow me to have crazy ideas for a moment, one wonders > why we shouldn't just release Phobos itself through dub? Rust makes > people use their build tool, why not us? Please don't. I dread the day my daily dmd toolchain update script will have to depend on dub just to be able to build a working compiler. But personal preferences aside, one blocker to this is that dmd and phobos (as well as druntime) development often go in lockstep, and sometimes breaking transitions must be coordinated between them so that git master is always buildable. If dmd and phobos were separate repos, it would make this coordination much, much, more difficult. (Though, on second thoughts, that's not necessarily a bad thing, as it will force us to actually face these issues and make Phobos buildable with multiple compiler versions, which currently is not well supported, if it works at all, because of said interdependence. This would also force us to dogfood our release / deprecation processeses, which will allow us to notice problems early and to experience what end users would experience when transitioning between compiler versions. It *will* add more workload to an already thin Phobos dev team, though. So there's that.) T -- Why are you blatanly misspelling "blatant"? -- Branden Robinson
Re: Release D 2.079.0
On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote: I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila I don't think this is unusual even outside of D. At least Microsoft seems to be willing to break your build if it moves things forward. For example, there are projects that worked fine on MSVC 15.4 (VS2017), but broke if you installed the update to 15.5 (or auto-updated in Visual Studio). You can't test everything. A lot of the "regular" companies, that desire high stability, typically use very old compilers and just workaround the bugs they know. For a D example, I think Sociomantic was using D1 for a long time just because it was stable for them. And if you need stability, why would you update the compiler without local testing and reserving time to fix any issues?
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository. This allows selection of the dependency on std.experimental separate from phobos. It still would be an "official" dlang package, and might even be included in the distribution (the latest version anyway), and docs included on the website. But if needed, you could have your dub package depend on a prior version. The entire concept needs a reexamination IMO. I just checked the git history, and not one module has graduated from std.experimental to mainline Phobos since the idea's inception in 2014. While it's possible that none of the modules are ready, logger has been there for four years now. I was against changing how experimental is handled in the past, but I recently have started to rethink how we promote modules. Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us?
Re: Release D 2.079.0
On 3/6/18 2:30 PM, Martin Nowak wrote: On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: But if needed, you could have your dub package depend on a prior version. http://code.dlang.org/packages/stdx-allocator ;) This is the answer, vibe.d should depend on stdx-allocator. -Steve
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote: Can somebody explain how [0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore. [0] is runtime bounds-checked array.ptr is unchecked and might return an out-of-bounds pointer (to the first element)
Re: Release D 2.079.0
On Monday, 5 March 2018 at 16:18:11 UTC, Chris M. wrote: Good stuff. Still bothers me that we had to special case "throw new Exception();" in order to make it nogc. I can't think of any better ways right now Implementing EH for values (instead of class references) would have been a lot more complex. but I wish it was more explicit. Initially people always want more explicitness for new, not yet too well known, features, while later opting for terser syntax for commonly used things. Exceptions are supposed to be rare and deleting them directly after being catched seemed like a reasonable enough default to go with the specialization. After all it solves a huge problem, error handling in @nogc code. Maybe we'll find a better/cleaner solution when more of the language has been transitioned to @safe @nogc.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 11:10:49 UTC, Atila Neves wrote: The problem with that is I was waiting for 2.079.0 since it fixes a bug that prevented me from upgrading to any of the 2.078.x releases on Windows. I think 2.078 would make an excellent starting point for a LTS because of the important fixes that only made it to 2.079. If anyone is interested to backport fixes and maintain such a source-branch, please contact me.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository. Just showing that phobos is not the right place to develop modules/packages, also mir. IMO std.experimental provides little benefit over dub, but comes with many downsides. This allows selection of the dependency on std.experimental separate from phobos. You cannot link against diamond dependencies of different versions though, so we'd have to exclude it from libphobos and put it separately. It still would be an "official" dlang package, and might even be included in the distribution (the latest version anyway), and docs included on the website. Not sure why inclusion in distribution is often mentioned as such a thing. It's trivial and common to have separate libraries/dependencies in every language with a healthy ecosystem. But if needed, you could have your dub package depend on a prior version. http://code.dlang.org/packages/stdx-allocator ;)
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 17:38:52 UTC, H. S. Teoh wrote:
struct Container {
auto opSlice() const {
static struct Result {
private Container impl;
private int n; // internal mutable state
@property bool empty() { ... }
... // rest of range API
}
return Result(this);
}
}
That's definitely a know problem with ranges that hasn't yet been
solved.
The known workaround is to implement Range and ConstRange.
This idiom could prolly be encapsulated in a safe and generic
template type to avoid boilerplate.
If we had some covariant mechansim to implement sth. similar to
struct Range(T) if (is(T InoutT == inout))
{
inout(InoutT) opIndex(size_t i) inout;
}
that would be ideal, but that isn't exactly trivial.
I think we had a better issue for this topic, but here is one
ticket asking for this feat.
[9983 – inout type can not be used as a parameter for structure
template](https://issues.dlang.org/show_bug.cgi?id=9983)
Re: Article: Why Const Sucks
On Tuesday, March 06, 2018 19:06:25 Martin Nowak via Digitalmars-d-announce wrote: > On Tuesday, 6 March 2018 at 18:17:58 UTC, Jonathan M Davis wrote: > > I'm not actually convinced that killing auto-decoding is really > > much better. > > I don't think the problem is auto-decoding in string range > adapters, but repeated validation. > https://issues.dlang.org/show_bug.cgi?id=14519#c32 > If you know that sth. works on code units just use > .representation. > > There is the related annoyance when the user of a function > presumably knows to only deal with ASCII strings but algorithms > fail, e.g. splitter.popBack or binary search. This one is tricky > because broken unicode support is often rooted in ignoring it's > existence. Yes, using stuff like representation or byCodeUnit helps to work around the auto-decoding, but as long as it's there, you have to constantly work around it if you care about efficiency with strings and/or want to be able to retain the original string type where possible. At this point, I think that it's pretty clear that we wouldn't have it if we could do stuff from scratch, but of course, we can't do stuff from scratch, because that would break everything. - Jonathan M Davis
Re: Article: Why Const Sucks
On Tuesday, 6 March 2018 at 18:17:58 UTC, Jonathan M Davis wrote: I'm not actually convinced that killing auto-decoding is really much better. I don't think the problem is auto-decoding in string range adapters, but repeated validation. https://issues.dlang.org/show_bug.cgi?id=14519#c32 If you know that sth. works on code units just use .representation. There is the related annoyance when the user of a function presumably knows to only deal with ASCII strings but algorithms fail, e.g. splitter.popBack or binary search. This one is tricky because broken unicode support is often rooted in ignoring it's existence.
Re: mysql-native v2.1.0
On Tuesday, 6 March 2018 at 18:36:45 UTC, bauss wrote:
On Tuesday, 6 March 2018 at 18:31:08 UTC, bauss wrote:
On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky
(Abscissa) wrote:
[...]
I'm unsure how I'd go about implementing prepared statements
in a vibe.d application correctly.
[...]
Like more specifically do I still call lockConnection() on a
MySQLPool?
I think it would be easier to help me if I put some examples.
I just tried changing stuff and I can't seem to get it working.
I kept using lockConnection() as before, I assume it's the right
way.
Then I changed the way I retrieve prepared statements from:
auto prepared = prepare(connection, sql);
prepared.setArgs(params);
to:
auto prepared = connection.prepare(sql);
prepared.setArgs(params);
Then ex. for reading many entries:
From:
return prepared.querySet().map!((row)
{
auto model = new TModel;
model.row = row;
model.readModel();
return model;
});
To:
return connection.query(prepared).map!((row)
{
auto model = new TModel;
model.row = row;
model.readModel();
return model;
});
But it doesn't seem to work.
I get the following exception:
"Attempting to popFront an empty map" which I assume is because
the result is empty.
So what am I doing wrong in using prepared statements with the
new updates?
Re: Article: Why Const Sucks
On Tuesday, March 06, 2018 10:47:36 H. S. Teoh via Digitalmars-d-announce
wrote:
> On Tue, Mar 06, 2018 at 01:31:39PM -0500, Steven Schveighoffer via
Digitalmars-d-announce wrote:
> > On 3/6/18 10:39 AM, Jonathan M Davis wrote:
> > > Yeah. If you're dealing with generic code rather than a specific
> > > range type that you know is implicitly saved when copied, you have
> > > to use save so often that it's painful, and almost no one does it.
> > > e.g.
> > >
> > > equal(lhs.save, rhs.save)
> > >
> > > or
> > >
> > > immutable result = range.save.startsWith(needle.save);
> >
> > Yep. The most frustrating thing about .save to me is that .save is
> > nearly always implemented as:
> >
> > auto save() { return this; }
> >
> > This just screams "I really meant just copying".
>
> Yeah, and also:
>
> auto save() {
> auto copy = this;
> copy.blah = blah.dup;
> return this;
> }
>
> Which just screams "I'm really just a postblit in disguise".
That's exactly what it is. It's a postblit constructor that you have to call
manually and which works for classes and dynamic arrays in addition to
structs.
- Jonathan M Davis
Re: Article: Why Const Sucks
On Tue, Mar 06, 2018 at 01:31:39PM -0500, Steven Schveighoffer via
Digitalmars-d-announce wrote:
> On 3/6/18 10:39 AM, Jonathan M Davis wrote:
> > Yeah. If you're dealing with generic code rather than a specific
> > range type that you know is implicitly saved when copied, you have
> > to use save so often that it's painful, and almost no one does it.
> > e.g.
> >
> > equal(lhs.save, rhs.save)
> >
> > or
> >
> > immutable result = range.save.startsWith(needle.save);
>
> Yep. The most frustrating thing about .save to me is that .save is
> nearly always implemented as:
>
> auto save() { return this; }
>
> This just screams "I really meant just copying".
Yeah, and also:
auto save() {
auto copy = this;
copy.blah = blah.dup;
return this;
}
Which just screams "I'm really just a postblit in disguise".
T
--
This is not a sentence.
Re: mysql-native v2.1.0
On Tuesday, 6 March 2018 at 18:31:08 UTC, bauss wrote: On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote: [...] I'm unsure how I'd go about implementing prepared statements in a vibe.d application correctly. [...] Like more specifically do I still call lockConnection() on a MySQLPool?
Re: Article: Why Const Sucks
On 3/6/18 10:39 AM, Jonathan M Davis wrote:
Yeah. If you're dealing with generic code rather than a specific range type
that you know is implicitly saved when copied, you have to use save so often
that it's painful, and almost no one does it. e.g.
equal(lhs.save, rhs.save)
or
immutable result = range.save.startsWith(needle.save);
Yep. The most frustrating thing about .save to me is that .save is
nearly always implemented as:
auto save() { return this; }
This just screams "I really meant just copying".
-Steve
Re: Article: Why Const Sucks
On Tue, Mar 06, 2018 at 11:20:56AM -0700, Jonathan M Davis via Digitalmars-d-announce wrote: > On Tuesday, March 06, 2018 09:41:42 H. S. Teoh via Digitalmars-d-announce > wrote: > > As they say, hindsight is always 20/20. But it wasn't so easy to > > foresee the consequences at the time when the very concept of ranges > > was still brand new. > > Except that even worse, I'd argue that hindsight really isn't 20/20. > We can see a lot of the mistakes that were made, and if we were > starting from scratch or otherwise willing to break a lot of code, we > could change stuff like the range API based on the lessons learned. > But we'd probably still screw it up, because we wouldn't have the > experience with the new API to know where it was wrong. [...] Well, that means *hind*sight is still 20/20: we see where we went wrong, but *fore*sight is still blurry, because what we think is the solution to that wrong may not turn out to be a good solution later. :-D T -- Question authority. Don't ask why, just do it.
Re: Article: Why Const Sucks
On Tuesday, March 06, 2018 09:41:42 H. S. Teoh via Digitalmars-d-announce wrote: > As they say, hindsight is always 20/20. But it wasn't so easy to > foresee the consequences at the time when the very concept of ranges was > still brand new. Except that even worse, I'd argue that hindsight really isn't 20/20. We can see a lot of the mistakes that were made, and if we were starting from scratch or otherwise willing to break a lot of code, we could change stuff like the range API based on the lessons learned. But we'd probably still screw it up, because we wouldn't have the experience with the new API to know where it was wrong. Consider all of the stuff that was improved in D over C++ but which still has problems in D (like const). We build on experience to make the new stuff better and frequently lament that we didn't know better in the past, but we still make mistakes when we do new stuff or redesign old stuff. Frequently, the end result is better, but it's rarely perfect. - Jonathan M Davis
Re: Article: Why Const Sucks
On Tuesday, March 06, 2018 09:36:43 H. S. Teoh via Digitalmars-d-announce wrote: > Andrei has said before, and probably on more than one occasion, that if > he were to redesign ranges today, one of the things he would do > differently was to change the definition of forward range so that .save > is basically implicit on copying the range object, and non-forward input > ranges would just be reference / non-copyable types. > > But that boat has long sailed, and we just have to make do with what we > have today. Changing this now will literally break just about *every* D > program that uses ranges, which is breakage of an ecosystem-killing > magnitude that I can't even contemplate. I would much rather go with a > less intrusive breakage like killing autodecoding with fire, than with > something that will basically require me to rewrite practically every D > program I ever wrote. I'm not actually convinced that killing auto-decoding is really much better. As it stands, changing it would break a large percentage of string-based code, and the functions in question sit in std.range.primitives along with all of the other core range stuff such that I don't see how we can change them any more than we can change the basic range API. I would love to be proven wrong, but I don't know how we could change it at this point without code breakage that comes pretty close to the breakage that changing the range API would cause. - Jonathan M Davis
Re: Article: Why Const Sucks
On Mon, Mar 05, 2018 at 10:21:47PM -0500, Nick Sabalausky (Abscissa) via Digitalmars-d-announce wrote: > On 03/05/2018 12:38 PM, H. S. Teoh wrote: > > > > This broke the by-value assumption inherent in much of Phobos code, > > Wait, seriously? Phobos frequently passes ranges by value? I sincerely > hope that's only true for class-based ranges and forward-ranges (and > more specifically, only forward ranges where copying the range and > calling .save are designed to do the exact same thing). Otherwise, > that's really, *REALLY* bad since non-forward ranges *by definition* > cannot be duplicated. I think you misunderstood. :-D Passing ranges by value means passing the range itself, usually a struct, which is a value type. I did *not* say the *content* of ranges are *copied* -- that would be so horribly wrong that I would be thinking twice about using D for my projects. :-D [...] > The definition of "what is a forward/non-forward range" for > struct-based ranges should have been "is this() @disabled (non-forward > range), or is this() enabled *and* does the same thing as .save > (forward range)?" [...] Yeah, Andrei has admitted before that this is probably what he would do today, if he were given a second chance to design ranges. But at the time, the landscape of D was rather different, and certain language features didn't exist yet (sorry, can't recall exactly which off the top of my head), so he settled with the compromise that we have today. As they say, hindsight is always 20/20. But it wasn't so easy to foresee the consequences at the time when the very concept of ranges was still brand new. T -- What do you get if you drop a piano down a mineshaft? A flat minor.
Re: Article: Why Const Sucks
On Tue, Mar 06, 2018 at 08:39:41AM -0700, Jonathan M Davis via Digitalmars-d-announce wrote: [...] > Yeah. If you're dealing with generic code rather than a specific range > type that you know is implicitly saved when copied, you have to use > save so often that it's painful, and almost no one does it. e.g. > > equal(lhs.save, rhs.save) > > or > > immutable result = range.save.startsWith(needle.save); > > How well Phobos has done with this has improved over time as more and > better testing has been added (testing for reference type ranges is > probably the most critical to finding this particular problem), but I > doubt that Phobos has it right everywhere, and I'm sure that the > average programmer's code has tons of these problems. In my own code, I often run into subtle bugs that arise from ranges being unintentionally consumed because I forgot to call .save. So I tend to be extra careful about this. But yeah, it's so easy to miss unless your code actually uses ranges where it would make a difference. [...] > Ranges are wonderfully powerful, but they become a royal pain to get > right with truly generic code. And that's without getting into all of > the arguments about whether stuff like whether transitive fronts > should be allowed... I know we have disagreed on this before, but in my mind, it's very simple. Generic code should basically be written in such a way that it does the most making the least assumptions. Meaning, don't assume the return value of .front persists beyond the next .popFront, don't assume iterating the range won't consume it, etc.. It's just basic defensive programming. If the algorithm won't work without some of these assumptions, then make them explicit, either a part of the API, or clearly documented. IMNSHO, code that isn't written this way is just sloppy and a haven for hidden bugs. > Ranges are definitely one area where we could really use some redesign > to iron out some of the issues that we've found over time, but their > success makes them almost impossible to fix, because changing them > would break tons of code. But annoyingly, that's often what happens > when you implement a new idea. You simply don't have enough knowledge > about it ahead of time to avoid mistakes; those are easy enough to > make when you really know what you're doing, let alone with something > new. [...] Andrei has said before, and probably on more than one occasion, that if he were to redesign ranges today, one of the things he would do differently was to change the definition of forward range so that .save is basically implicit on copying the range object, and non-forward input ranges would just be reference / non-copyable types. But that boat has long sailed, and we just have to make do with what we have today. Changing this now will literally break just about *every* D program that uses ranges, which is breakage of an ecosystem-killing magnitude that I can't even contemplate. I would much rather go with a less intrusive breakage like killing autodecoding with fire, than with something that will basically require me to rewrite practically every D program I ever wrote. T -- "You know, maybe we don't *need* enemies." "Yeah, best friends are about all I can take." -- Calvin & Hobbes
Re: LDC 1.8.0
On Tuesday, 6 March 2018 at 16:54:59 UTC, Joakim wrote: [...] Nothing new, unfortunately, though you can follow progress here: https://github.com/ldc-developers/ldc/issues/2153 I plan to spend some time on it, but have been putting it off. Thank you!
Re: Article: Why Const Sucks
On Tuesday, 6 March 2018 at 15:39:41 UTC, Jonathan M Davis wrote: [snip] How well Phobos has done with this has improved over time as more and better testing has been added (testing for reference type ranges is probably the most critical to finding this particular problem), but I doubt that Phobos has it right everywhere, and I'm sure that the average programmer's code has tons of these problems. Code mostly just works because most code really isn't used with arbitrary ranges, and a large percentage of ranges implicitly save on copy. It's not that hard to get a piece of code working with a particular range or just a few similar range types. It's when it needs to work with _any_ range type that matches the template constraint that things start getting hairy, and without thorough testing, it simply doesn't happen unless the code is very simple and the programmer in question is very mindful of stuff like save (which most programmers aren't). And of course, since most testing is done with dynamic arrays, issues with other range types simply aren't found unless the programmer is really putting in the effort to do their due diligence. Someone could make a range testing library of sorts. Really just a variant packed with a bunch of different range types covering a variety of use cases. The user could import it in a version(unittest) block and then just loop through it and assert that the function works for all of them (would need some kind of variant full of what to compare it to for each type). Ranges are wonderfully powerful, but they become a royal pain to get right with truly generic code. And that's without getting into all of the arguments about whether stuff like whether transitive fronts should be allowed... Ranges are definitely one area where we could really use some redesign to iron out some of the issues that we've found over time, but their success makes them almost impossible to fix, because changing them would break tons of code. But annoyingly, that's often what happens when you implement a new idea. You simply don't have enough knowledge about it ahead of time to avoid mistakes; those are easy enough to make when you really know what you're doing, let alone with something new. - Jonathan M Davis There's probably value in writing up a retrospective of sorts on D's ranges. What works about the design, what are the limitations, and what could be improved (depending on the level of breakage considered acceptable). Even if D takes a long time to fix these issues, making the information more easily available to others outside the D community might be valuable.
Re: LDC 1.8.0
On Tuesday, 6 March 2018 at 15:44:14 UTC, Martin Tschierschke wrote: On Sunday, 4 March 2018 at 22:37:21 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce LDC 1.8. The highlights of this version in a nutshell: * Based on D 2.078.3. * New switch `-link-defaultlib-shared` to link against shared druntime/Phobos. * Plugins support, compatible with existing Clang plugins. * Support for LLVM IR-based PGO as alternative to existing (AST-based) PGO. * Basic support for LLVM XRay instrumentation. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.8.0 Thanks to all contributors! Cool! Thank you! https://wiki.dlang.org/Build_D_for_Android Says, that 64 Bit Android version is not ready yet, anything about this? It is not really necessary for me, but would be cool, because unfortunately I have a 64 bit Android phone. Nothing new, unfortunately, though you can follow progress here: https://github.com/ldc-developers/ldc/issues/2153 I plan to spend some time on it, but have been putting it off.
Re: Release D 2.079.0
On 3/6/18 11:13 AM, psychoticRabbit wrote: (I assume that int is meant to be size_t) Yes, I changed the uncommented one to auto after I realized, but not the commented one ;) -Steve
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 07:11:24 UTC, Jonathan M Davis wrote: That example actually should be perfectly @safe, because the array is null, and it's using writeln. Dereferencing null is @safe, because it segfaults and thus can't corrupt memory or access invalid memory. You obviously don't want it to happen, but it's @safe. Also, passing a pointer to writeln is fine, because it's just going to print the value, so that's @safe too, even if the pointer value is garbage. my point had nothing to do with writeln. my point was, that a RangeError exception may help save the day, but not when you use .ptr thankfully Steven gave a much better example to make the point clearer ;-) (I assume that int is meant to be size_t)
Re: LDC 1.8.0
On Sunday, 4 March 2018 at 22:37:21 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce LDC 1.8. The highlights of this version in a nutshell: * Based on D 2.078.3. * New switch `-link-defaultlib-shared` to link against shared druntime/Phobos. * Plugins support, compatible with existing Clang plugins. * Support for LLVM IR-based PGO as alternative to existing (AST-based) PGO. * Basic support for LLVM XRay instrumentation. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.8.0 Thanks to all contributors! Cool! Thank you! https://wiki.dlang.org/Build_D_for_Android Says, that 64 Bit Android version is not ready yet, anything about this? It is not really necessary for me, but would be cool, because unfortunately I have a 64 bit Android phone.
Re: Article: Why Const Sucks
On Tuesday, March 06, 2018 15:23:52 Adam D. Ruppe via Digitalmars-d-announce wrote: > On Tuesday, 6 March 2018 at 03:21:47 UTC, Nick Sabalausky > > (Abscissa) wrote: > > Wait, seriously? Phobos frequently passes ranges by value? > > You *should* pass most ranges by value, just like how you should > rarely use `ref T[]` or `T[]*`. Ranges, like slices, are > typically already small references to some other container. > > Where Phobos effs it up is not follow its own rules on range.save > in most cases... Jonathan talked about this at dconf IIRC in 2015. Yeah. If you're dealing with generic code rather than a specific range type that you know is implicitly saved when copied, you have to use save so often that it's painful, and almost no one does it. e.g. equal(lhs.save, rhs.save) or immutable result = range.save.startsWith(needle.save); How well Phobos has done with this has improved over time as more and better testing has been added (testing for reference type ranges is probably the most critical to finding this particular problem), but I doubt that Phobos has it right everywhere, and I'm sure that the average programmer's code has tons of these problems. Code mostly just works because most code really isn't used with arbitrary ranges, and a large percentage of ranges implicitly save on copy. It's not that hard to get a piece of code working with a particular range or just a few similar range types. It's when it needs to work with _any_ range type that matches the template constraint that things start getting hairy, and without thorough testing, it simply doesn't happen unless the code is very simple and the programmer in question is very mindful of stuff like save (which most programmers aren't). And of course, since most testing is done with dynamic arrays, issues with other range types simply aren't found unless the programmer is really putting in the effort to do their due diligence. Ranges are wonderfully powerful, but they become a royal pain to get right with truly generic code. And that's without getting into all of the arguments about whether stuff like whether transitive fronts should be allowed... Ranges are definitely one area where we could really use some redesign to iron out some of the issues that we've found over time, but their success makes them almost impossible to fix, because changing them would break tons of code. But annoyingly, that's often what happens when you implement a new idea. You simply don't have enough knowledge about it ahead of time to avoid mistakes; those are easy enough to make when you really know what you're doing, let alone with something new. - Jonathan M Davis
Re: Article: Why Const Sucks
On Tuesday, 6 March 2018 at 03:21:47 UTC, Nick Sabalausky (Abscissa) wrote: Wait, seriously? Phobos frequently passes ranges by value? You *should* pass most ranges by value, just like how you should rarely use `ref T[]` or `T[]*`. Ranges, like slices, are typically already small references to some other container. Where Phobos effs it up is not follow its own rules on range.save in most cases... Jonathan talked about this at dconf IIRC in 2015. The definition of "what is a forward/non-forward range" for struct-based ranges should have been "is this() @disabled (non-forward range), or is this() enabled *and* does the same thing as .save (forward range)?" yeah.
Re: Hamburg meets D
On Tuesday, 6 March 2018 at 01:46:26 UTC, Mike Parker wrote: On Monday, 5 March 2018 at 19:40:12 UTC, Stephan wrote: Hello fellow Dlers, thanks to last years DConf some German D developers agreed to meet for drinks in Hamburg. What time? To get this thread on the first page for a long time, we do not provide every info at once :-)
Re: Article: Why Const Sucks
On Tuesday, 6 March 2018 at 10:02:10 UTC, Radu wrote: On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis Spot on article, and touches some of my pain points when working with const/immutable structs. Recently I tried to create a ref-counted immutable struct, oh boi... This later use case is of tremendous value for safe concurrent code that's @nogc. Unfortunately I couldn't find a way to make it work efficiently and in the same time not look like a disgusting hack. I suspect a possible solution is to allow immutable(const) postblit overloads as well as immutable dtors that will act as an escape hatch for unsafe work and in the same time provide hints that you are operating on an immutable(const) this. AFAIK this is a solved problem. Dicebot (not sure if he's still around) had initially proposed it: store the reference count just before the immutable piece of memory. | ref count |object/struct| In fact, Andrei added a new allocator to std.experimental.allocator to support this: https://dlang.org/library/std/experimental/allocator/building_blocks/affix_allocator/affix_allocator.prefix.html
Re: LDC 1.8.0
On Tuesday, 6 March 2018 at 14:06:54 UTC, Mike Parker wrote: On Sunday, 4 March 2018 at 22:37:21 UTC, kinke wrote: Thanks to all contributors! And thanks to Johan Engelen and Joakim for putting together an announcement for the blog! https://dlang.org/blog/2018/03/06/ldc-1-8-0-released/ Reddit: https://www.reddit.com/r/programming/comments/82f9wk/ldcthe_llvmbased_d_compiler180_released/ Great blog post. LDC has a lot more options than DMD for tuning things and I feel like I'm not so knowledgeable on some of them.
Re: LDC 1.8.0
On Sunday, 4 March 2018 at 22:37:21 UTC, kinke wrote: Thanks to all contributors! And thanks to Johan Engelen and Joakim for putting together an announcement for the blog! https://dlang.org/blog/2018/03/06/ldc-1-8-0-released/ Reddit: https://www.reddit.com/r/programming/comments/82f9wk/ldcthe_llvmbased_d_compiler180_released/
Re: Release D 2.079.0
On 3/6/18 2:11 AM, Jonathan M Davis wrote:
On Tuesday, March 06, 2018 05:34:39 psychoticRabbit via Digitalmars-d-
announce wrote:
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:
Can somebody explain how [0] is more safe than array.ptr?
Just want to understand why second statement isn't allowed in
safe anymore.
int[] a;
writeln([0]); // good - runtime produces a
core.exception.RangeError
//writeln(arr.ptr); // what do you think will happen here?
That example actually should be perfectly @safe, because the array is null,
and it's using writeln. Dereferencing null is @safe, because it segfaults
and thus can't corrupt memory or access invalid memory. You obviously don't
want it to happen, but it's @safe. Also, passing a pointer to writeln is
fine, because it's just going to print the value, so that's @safe too, even
if the pointer value is garbage.
Yeah, a better example:
struct S
{
size_t[1] x;
int *bad;
}
void foo() @safe
{
S s;
auto arr = s.x[$ .. $];
// int *p = [0]; // would throw range error
auto p = arr.ptr; // this now points at bad
*p = 0xdeadbeef;
*s.bad = 5; // oops
}
-Steve
Re: Article: Why Const Sucks
On Tuesday, 6 March 2018 at 12:05:26 UTC, Dukc wrote: I think we have a bug here. I believe postblits should behave like constructors in both events. https://issues.dlang.org/show_bug.cgi?id=18561
Re: Article: Why Const Sucks
On 3/6/18 1:49 AM, Jonathan M Davis wrote: Regardless, I doubt that the design of ranges is going to be changed at this point given the amount of code that would break as a result, and these sort of changes are not backwards compatible. I sometimes think we would be better off to drop InputRange, and base everything on the assumption that it can be copied (where isInputRange is renamed to isForwardRange, and `save` goes away). Then you could use @disable postblit to mimic what InputRange would have been. I've never seen the point of having classes be ranges. -Steve
Re: Article: Why Const Sucks
On Tuesday, 6 March 2018 at 11:03:24 UTC, Nemanja Boric wrote: title = title.dup;// doesn't work anymore Strange! You're right it does not when the type declares a member as const, yet: On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote (in the article): And if an object is const or immutable, then that's all of the members. ...does not prevent the postblit from working whenthe object is declared const by user. I think we have a bug here. I believe postblits should behave like constructors in both events.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 06:53:30 UTC, Adam Wilson wrote: On 3/5/18 15:40, Atila Neves wrote: On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote: On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote: On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: [...] Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila https://github.com/vibe-d/vibe.d/issues/2058 It's great that there's an issue for vibe. This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org. It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver! I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0. I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila May I make a recommendation? Only upgrade to the 2.0xx.2[.3] releases. You'll have to wait a month or so for the latest features, but by then the important packages will have been upgraded and the regressions (mostly) worked out. It's kind of like the old saying about Microsoft software. "Never use the first version of anything". If we treat the .0 releases as "v1" then it fits. :) The problem with that is I was waiting for 2.079.0 since it fixes a bug that prevented me from upgrading to any of the 2.078.x releases on Windows. And then there's the fact that the last time I had issues upgrading gcc or clang was... never. I'm more than ok with compiler upgrades breaking my code when it was wrong in the 1st place, or with language updates breaking code but making the situation better as a whole. That's not what's been happening to me with the last few versions. Atila
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 00:08:33 UTC, psychoticRabbit wrote: On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote: I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila Fair enough. Doing better is always a good thing to aim for. But really, who use something 'just released' in production? This is beside the point. Anyone who hears about vibe.d and goes to download the compiler to try it out will fail to get it to compile with the official instructions on how to do so. It's hard enough to convince people to adopt a new programming language when everything works as intended. Atila
Re: Article: Why Const Sucks
On Tuesday, 6 March 2018 at 10:49:48 UTC, Dukc wrote:
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote
(in the article):
The problem is that the entire object must be fully
initialized before
the body of the postblit constructor is run. That means that
any member
variables which are const or immutable are stuck at whatever
they were in
the original object, because it would violate the type system
to mutate them. And if an object is const or immutable, then
that's all of the members.
I think we have a misunderstanding here. According to that,
this would not compile (imports left out):
struct placeAtWorldMap
{ char[] title;
int[2] coordsMicroDeg;
this(this)
{ title = title.dup;
}
}
void main()
{ char[] title = "London bridge".dup;
const place = placeAtWorldMap(title, [51_508_038, -87_693]);
const samePlace = place;
"falling down ".copy(title);
place.title.writeln; // falling down
samePlace.title.writeln; // London bridge
readln;
}
...but it compiles and correctly runs, and I'm happy about that.
Quote from the article:
. That means that any member
variables which are const or immutable are stuck at whatever
they were in
the original object, because it would violate the type system
to mutate them
Meaning that if you declare your `title` member `const char[]
title`, you can't change it in the postblit, but you could set it
in the constructor.
```
import std.array;
import std.stdio;
import std.algorithm;
struct placeAtWorldMap
{ const char[] title;
int[2] coordsMicroDeg;
this(char[] name)
{
this.title = name.idup; // you can assign const
members here
}
this(char[] name, int[2] coords)
{
this.title = name;
this.coordsMicroDeg = coords;
}
this(this)
{// title = title.dup;// doesn't work anymore
}
}
void main()
{ char[] title = "London bridge".dup;
const place = placeAtWorldMap(title, [51_508_038, -87_693]);
const newPlace = placeAtWorldMap("Big Ben".dup);
const samePlace = place;
"falling down ".copy(title);
place.title.writeln; // falling down
samePlace.title.writeln; // London bridge
newPlace.title.writeln; // Big Ben
}
```
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote
(in the article):
The problem is that the entire object must be fully initialized
before
the body of the postblit constructor is run. That means that
any member
variables which are const or immutable are stuck at whatever
they were in
the original object, because it would violate the type system
to mutate them. And if an object is const or immutable, then
that's all of the members.
I think we have a misunderstanding here. According to that, this
would not compile (imports left out):
struct placeAtWorldMap
{ char[] title;
int[2] coordsMicroDeg;
this(this)
{ title = title.dup;
}
}
void main()
{ char[] title = "London bridge".dup;
const place = placeAtWorldMap(title, [51_508_038, -87_693]);
const samePlace = place;
"falling down ".copy(title);
place.title.writeln; // falling down
samePlace.title.writeln; // London bridge
readln;
}
...but it compiles and correctly runs, and I'm happy about that.
Re: mysql-native v2.1.0
On Tuesday, 6 March 2018 at 07:39:00 UTC, aberba wrote: On Tuesday, 6 March 2018 at 04:31:42 UTC, Nick Sabalausky (Abscissa) wrote: [...] I'm not opposed to it being added, but I'm not aware of what benefit it would provide that would big enough to make it a priority. Also, AFAIK, vibe doesn't offer socket support like it does TCP, so vibe users would loose out on the automatic yield-on-io that's a cornerstone of vibe's concurrency design. UNIX sockets provide a way to securely connect in an enclosed/isolated environment without exposing connection externally. This is used in my company in our microservice infrastructure on Google Cloud: we connect to our db instance using a proxy and its the recommended approach in microservices. Its a very common security practice. The default approach on Google Cloud. I would do the same for any db I want to prevent external access to. If vibe.d doesn't support it then its missing a big piece of a puzzle. Having sockets would be better, but you may configure your mysql to allow only local connects. So external requests are blocked. https://dba.stackexchange.com/questions/72142/how-do-i-allow-remote-mysql-access-to-all-users Look at the first answer to set the right privileges for your environment. Additionally blocking the mysql port 3306 (beside many others) from outside the network would make sense.
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis Spot on article, and touches some of my pain points when working with const/immutable structs. Recently I tried to create a ref-counted immutable struct, oh boi... This later use case is of tremendous value for safe concurrent code that's @nogc. Unfortunately I couldn't find a way to make it work efficiently and in the same time not look like a disgusting hack. I suspect a possible solution is to allow immutable(const) postblit overloads as well as immutable dtors that will act as an escape hatch for unsafe work and in the same time provide hints that you are operating on an immutable(const) this.
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 13:59:02 UTC, Adam D. Ruppe wrote: On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: And then, of course, like you said "don't use it" is the solution to most of the const system's flaws anyway which seems to be the case with a lot of D's add-on qualifiers. +1 The worst part of those add-on qualifiers is that the official gospel is that they are useful when in reality you HAVE to avoid them to be productive.
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis Its amazing how typed languages, in this case const, forces you to think in mutation but with an exception. I wonder the real world SOLE benefit of using const compared to mutable-immutable style. Its either mutable or immutable. Exception could only available by casting immutable to mutable. I feels this const thing is a theoretical problem. One can overcome practically with code style discipline. At a point, const becomes just a decoration; something people use prematurely (YAGNI). It must feel like sleeping on your bed with sharp knives hanging at the top such that they can fall on you anything: when comparing code in a typed language to an untyped one. That's a potential cause of premature use of certain type attributes. By the way, Jonathan, you should really consider writing a book with such deep insights your have. Especially the way you explain things.
