Re: Release D 2.069.0
On 11/09/2015 07:08 PM, Dicebot wrote: > More common practice is to declare such dependencies as optional though. I made a ticket https://issues.dlang.org/show_bug.cgi?id=15308. Simply changing https://github.com/D-Programming-Language/installer/blob/41fb25ce5e5ff2c14728f490ee4579ac49bb989a/linux/dmd_rpm.sh#L266 doesn't work b/c the rpmtool from debian used to build the rpm packages doesn't support Recommends.
Re: 2.069.0 Installation problem with .exe for Windows
On 11/04/2015 10:05 AM, Mike James wrote: > Copied here for extra visibility... > > Hi. > > There seems to be an install problem with the .exe version for > Windows. The installer removes the old DMD then doesn't install > the 2.069.0 version. In the task manager it's still running at > 50% CPU time. It fails on Windows Vista and Windows 7. Could some try and verify that this installer fixes the issue. I wasn't able to reproduce the issue myself. https://dlang.dawg.eu/downloads/dmd.2.069.0~fix15824/
Re: 2.069.0 Installation problem with .exe for Windows
On Wednesday, 4 November 2015 at 09:05:07 UTC, Mike James wrote: Regards, -- Could anyone help us to reproduce the issue?https://issues.dlang.org/show_bug.cgi?id=15284
Re: Release D 2.069.0
On Wednesday, 4 November 2015 at 17:52:23 UTC, Dmitry Olshansky wrote: If host machine is x64 bit windows try setting large address aware bit on the executable (there are tools to do that IRC), would allow it to eat up to ~4 gigs. We're already doing that since quite a while. https://github.com/D-Programming-Language/dmd/commit/172b55d22bd4a144d889c3fa8d9279d8e0a0ce1c
Re: Release D 2.069.0
On 11/04/2015 10:01 AM, deadalnix wrote: > > Bonus question: how soon can we expect travis to pick up the new version ? I updated http://ftp.digitalmars.com/LATEST now and added that step to http://wiki.dlang.org/DMD_Release_Building.
Re: Release D 2.069.0
On 11/04/2015 10:01 AM, Suliman wrote: >> Regards, >> -- > > Same problem. It's likely related to this fix which now let's the installer wait on the uninstaller to finish. https://github.com/D-Programming-Language/installer/commit/526f35495cdc615b26b65d73fa7b4aa0477b1d12 Did anything go wrong with the uninstall?
Release D 2.069.0
Glad to announce D 2.069.0. http://dlang.org/download.html http://downloads.dlang.org/releases/2.x/2.069.0/ This is the first release with a self-hosted dmd compiler and comes with even more rangified phobos functions, std.experimental.allocator, and many other improvements. See the changelog for more details. http://dlang.org/changelog/2.069.0.html -Martin
Re: D 2.068.2 test runner for Android ARM, please test and report results from your Android device
On 11/01/2015 10:50 AM, Joakim wrote: > http://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org Nice works for me as well (Galaxy S3 on cm-12.1 (5.1.1)). Would be nice to run this as automated test on an Android Emulator.
Re: Release Candidate D 2.069.0-rc2
On 10/31/2015 01:00 PM, BBasile wrote: > > Despite of what I had say previously I've encountered another "inliner" > bug today that looks like a regression. I don't know what's the 2.069 > ETA but I'm not sure to be able to file a bugzilla entry quickly. Please just file ticket with whatever you have (e.g. project x fails with ...). We can reduce the code ourself or might already recognize the issue. Regarding the ETA, we're already overdue by 2 weeks. -Martin
Re: Safe reference counting cannot be implemented as a library
On 10/27/2015 12:41 PM, Andrei Alexandrescu wrote:
> It follows that if we want safe reference counting, there must be
> language support for it. One possibility is to attach an attribute to
> the class definition:
>
> @safe @rc class Widget {
> ...
> }
Let's think about this more clearly before we bake a monolithic feature
for a single problem into the language.
A few thoughts:
- @rc and @noescape are orthogonal
while @rc requires @noescape the latter could
be useful for other purposes
- If the compiler knows a reference has a limited lifetime
it could check for @noescape making most of RC implementable
in a library.
struct RC
{
Object get() return; // lifetime of Object is bound to RC, compiler
could check any function called on Object for @noescape
}
- I'm not a fan of adding yet another attribute but as inference support
is currently limited it seems we'd need an explicit attribute for
public APIs.
Re: Safe reference counting cannot be implemented as a library
On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote: > Unrelated, and a foreshadowing of the discussion on the lifetime mailing > list: the compiler has ample opportunity to fuse incs/decs together, so > the signatures of these functions is: > > void opInc(uint delta); > void opDec(uint delta); Any hint/numbers showing that this is actually useful? Implementing such a cross statement optimization is quite some work. If this occurs often enough (in particular for shared classes with atomic ref counting) it might be worth the effort.
Re: Safe reference counting cannot be implemented as a library
On 11/01/2015 09:51 PM, Martin Nowak wrote: > Any hint/numbers showing that this is actually useful? Also doesn't a good backend optimizer already fuse writes?
Re: Release Candidate D 2.069.0-rc1
On 10/27/2015 08:53 AM, Rainer Schuetze wrote: > Sorry for being a little late with these: Thanks, the fix will be in the final release. http://dlang.org/changelog/2.069.0.html#link-against-vs2015.
Re: Fastest JSON parser in the world is a D project
On Tuesday, 27 October 2015 at 13:14:36 UTC, wobbles wrote: How can `coordinates` member be known at compile-time when the input argument is a run-time string? I suspect through the opDispatch operator overload. http://dlang.org/operatoroverloading.html#dispatch Yikes, this is such an anti-pattern. https://github.com/rejectedsoftware/vibe.d/issues/634
scod - a clean and lightweight theme for ddox
Available as dub package: http://code.dlang.org/packages/scod Example: http://martinnowak.github.io/bloom/bloom.html We're currently working on dub integration of other doc generation tools (https://github.com/D-Programming-Language/dub/pull/702), for the time being you can use scod like so. https://github.com/MartinNowak/bloom/blob/6bd4f3ada2d5a6b436a99493ad17112fb8111681/travis.sh#L19 -Martin
Re: Heroku Buildpack for D
On Monday, 26 October 2015 at 13:22:21 UTC, Andre wrote: Great work. I think it worths to only extract the necessary files. -> linux/lib64/* -> linux/bin64/* -> object.d (maybe also others from runtime) Did that, and also cleaned the local .dub folder.
Heroku Buildpack for D
I wrote a buildpack for Heroku to easily deploy D apps. The script is based on the Travis-CI build script, so you can select the same compilers (using a .d-compiler file) and get the same DC/DMD env vars. https://github.com/MartinNowak/heroku-buildpack-d
Re: LDC 0.16.0 has been released!
On Thursday, 22 October 2015 at 19:00:07 UTC, Kai Nacke wrote: Hi everyone, LDC 0.16.0, the LLVM-based D compiler, is available for download! Great job and impressive bugfix list. Could someone please update https://ldc-developers.github.io/LATEST. -Martin
Re: Beta D 2.069.0-b2
On 10/17/2015 09:05 PM, Marco Leise wrote: > Oh wait, false alert. That was a relic from older days. My > build script placed a dummy dmd.conf there. > > I do seem to get problems with ldc2-0.16.0: Are you using something befor 0.16.0-beta2, b/c I thought the problem was resolved. https://github.com/D-Programming-Language/dmd/pull/5025#issuecomment-142143727
Re: Fastest JSON parser in the world is a D project
On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote: - Data size limited by available contiguous virtual memory Mmaping files for sequential reading is a very debatable choice, b/c the common use case is to read a file once. You should at least compare the numbers w/ drop_caches between each run. https://github.com/mleise/fast/blob/69923d5a69f67c21a37e5e2469fc34d60c9ec3e1/source/fast/json.d#L1441
Re: Beta D 2.069.0-b2
On Friday, 16 October 2015 at 12:14:09 UTC, ponce wrote: What changed in the backend? http://dlang.org/changelog/2.069.0.html#backend-improvements
Re: Beta D 2.069.0-b2
On 10/14/2015 08:09 PM, Brian Schott wrote: > > Is there any reason that these fixes won't be merged for 2.069? Please target the stable branch when fixing something. Also tagging as 2.069 milestone helps (can you actually tag that yourself?). I don't examine PRs before branching or tagging a version and only take what has been finished. The dates are announced early enough to plan ahead, but it'll prolly take a few more cycles until everyone has the next release in mind. -Martin
Re: Beta D 2.069.0-b1
On Saturday, 10 October 2015 at 01:27:09 UTC, Jonathan M Davis wrote: Regardless, what we pretty much need to do with @property at some point is make is that it's used to make it so that a single pair of parens operate on the return value rather than the function even if we don't do anything else with @property Right, ideally a @proptery function can perfectly replace a variable, but practically calling the return value seems far fetched. What would you use that for, a handwritten interface struct with function pointers made read-only using @property? To me the whole property discussion looks like one of those endless debates about an insignificant detail. Scala and Ruby seem to do well with sloppy parens. With the introduction of UFCS it became clear that nobody likes byLine().array().sort().release(), and even less rng.release.sort().array().front. For some functions it's really hard to decide whether or not something is a property, e.g. for me Range.save is an action/function not a property. So for me using @property appears to waste time making pointless decisions.
Re: Beta D 2.069.0-b1
On Saturday, 10 October 2015 at 02:15:14 UTC, Adam D. Ruppe wrote:
On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak
wrote:
What would you use that for, a handwritten interface struct
with function pointers made read-only using @property?
var a = var.emptyObject; // works today
a.prop = { do_stuff; }; // works today
a.prop(); // useless no op
a.prop()(); // this is needed
That one case alone is all I care about @property for.
That's what I meant, weird use-case, at best it's a callback
better/setter.
I've never written such code, but even if you would, the 2 pairs
of parens are only a tiny problem for generic code, nothing to
warrant the invasive language feature @property is.
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote: Is it DDMD based release? Yes.
Re: Beta D 2.069.0-b1
On 10/08/2015 11:36 AM, lobo wrote: > > Is there any info on the benchmarking between DDMD and DMD? Still on the todo list to decide whether we need to use gdc to build ddmd. https://trello.com/c/OT6jlFNa/85-rebench-ddmd-vs-dmd-compiler-speed
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana wrote: Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 2.068.2? The last released compiler, we don't have any bootstrap method (using a small C++ compiler or so).
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 14:59:15 UTC, Jack Stouffer wrote: I think it should be mentioned in the change log the substantial improvements that were made to the docs since last release. After over 30 PRs were merged for improving the docs, they are WAY better than the 2.068 docs. Sure, just add it to the changelog. https://github.com/D-Programming-Language/dlang.org/pull/1118
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 12:48:48 UTC, Adam D. Ruppe wrote: On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote: Does that mean @property has no effect anymore ? @property never actually worked anyway. It is still my hope that it will be correctly implemented some day though I think http://wiki.dlang.org/DIP23 reflects the most accurate roadmap for @property, basically being permissive w.r.t. parens. And who really cares whether it's rng.popFront or rng.popFront()?
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 20:59:57 UTC, NVolcz wrote: The changelog links to: http://dlang.org/phobos/std_experimental_allocator.html which returns 404 for me. I remember seeing discussions about versioning the docs. What happened to that? Fixed by now.
Beta D 2.069.0-b1
First beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin
Re: D and microservices
On Wednesday, 7 October 2015 at 19:58:55 UTC, Ola Fosheim Grøstad wrote: If C++17 does stackless coroutines right then it probably will surpass both Go and D in terms of memory locality, initialization performance and memory usage; and therefore throughput as well. We might be able to reuse the existing delegate capture mechanism to create continuations. Then await would "simply" rewrite the rest of the body as delegate, similar to how the foreach body can be transformed into a delegate. There is some use-case for HPC code where stackless coroutines make a huge differences (used with a work stealing scheduler), for basic networking code it will only be a small difference.
Re: Go 1.5
On Tuesday, 29 September 2015 at 08:09:39 UTC, Ola Fosheim Grøstad wrote: But doesn't that imply a full scan when you are scanning for common types that live on leaf nodes in the graph? Yes, if you want to collect a very common type, you'd need to scan many types. But using typed allocations you can also predict where to find a lot of garbage, so you collect strings when you can collect a lot of them.
Re: Go, D, and the GC
On Friday, 2 October 2015 at 11:27:12 UTC, Tourist wrote: I know that it has the reputation of being of the simplest kind. Haven't looked at the code actually (and I wouldn't understand much even if I did). Go has a very simple GC itself. It's concurrent, so it trades low latency against performance (write-barriers) and throughput. We wouldn't want to force everybody to use write-barriers, but you can avoid creating garbage in D much easier (e.g. map) and we're improving support for deterministic memory management. So while we keep on improving D's GC as well, GC performance is less of a problem in D b/c you have a smaller GC heap.
Re: Go 1.5
On 09/24/2015 03:49 AM, Ola Fosheim Grøstad wrote: > On Thursday, 24 September 2015 at 00:08:18 UTC, Martin Nowak wrote: >> The key to a low latency/high throughput GC is being able to >> incrementally collect the heap. There is a very interesting paper that >> uses the type system to perform incremental collections. >> >> http://forum.dlang.org/post/mcqr3s$cmf$1...@digitalmars.com > > I haven't read the paper, but how does this solve collecting things like > strings, or other "leaf types" when you use separate compilation units? We'd use runtime typeinfo. > The easy thing to do is to use GC locally (like for a fiber) and use > move semantics for moving objects from one locality to the other > (between fibers). Though it's challenging to efficiently manage all the GC structures for a small scope. Doing this per thread is a proven technology (see https://trello.com/c/K7HrSnwo/28-thread-cache-for-gc).
Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX
On Thursday, 17 September 2015 at 21:13:46 UTC, bitwise wrote: The op shouldn't have to actually modify druntime in this case. He shouldn't have to replace "_dyld_register_func_for_add_image". Now that you guys digged in the dyld implementation, did anyone find a solution to use the callback mechanism and still support unloading of libraries? Pinning libraries is only a hacky workaround. Let's please continue the discussion in Bugzilla. https://issues.dlang.org/show_bug.cgi?id=15060#c4
Re: Is there a smart way to process a range of range by front ?
On Wednesday, 23 September 2015 at 21:30:37 UTC, BBasile wrote:
auto interleave(RoR)(RoR r)
{
return r.transposed.join;
If you use joiner it will even be lazy and avoid the allocation.
Re: Go 1.5
On 09/18/2015 09:26 PM, Rory wrote: > The new GC in Go 1.5 seems interesting. What they say about is certainly > interesting. > > http://blog.golang.org/go15gc > > "To create a garbage collector for the next decade, we turned to an > algorithm from decades ago. Go's new garbage collector is a concurrent, > tri-color, mark-sweep collector, an idea first proposed by Dijkstra in > 1978." A concurrent collector for sure reduces latency but lowers the throughput and also steals memory bandwidth from your program. It also requires write-barriers and we decided against them b/c they slow down every program by ~5%. Though it might be somehow possible to make them optional only for the people using a concurrent GC. The key to a low latency/high throughput GC is being able to incrementally collect the heap. There is a very interesting paper that uses the type system to perform incremental collections. http://forum.dlang.org/post/mcqr3s$cmf$1...@digitalmars.com
Release D 2.068.2
Glad to announce D 2.068.2. http://downloads.dlang.org/releases/2.x/2.068.2/ This point release fixes a few regressions 2.068.1, see the changelog for more details. http://dlang.org/changelog/2.068.2.html -Martin
Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX
On Thursday, 17 September 2015 at 21:13:46 UTC, bitwise wrote: He can simply create a second empty callback in VSTPluginMain which will pin his library: Yikes, pinning the library is really ugly hack around the actual issue. Anyone has an idea how to use the crappy dyld API w/o crashing on unload? If nothing helps we could try to add init/fini calls to binaries like we do w/ ELF.
Re: Release D 2.068.1
On Tuesday, 15 September 2015 at 08:39:43 UTC, John Colvin wrote: Where is the VERSION file documented? Why does it need manual intervention only for patch releases and pre-releases? We should prolly remove the manually updated VERSION file. The other build scripts update the file or pass VERSION=bla to make.
Re: Operator overloading or alternatives to expression templates
On 09/14/2015 03:47 PM, Sebastiaan Koppe wrote:
>
> In our last project we took the following approach:
>
> `auto q = query.builder!Person.age!">"(20).name("Peter");`
Interesting idea.
Beta D 2.068.2-b2
The second beta for the 2.068.2 point release fixes an regression with destroy that could result in a memory leak [¹]. http://downloads.dlang.org/pre-releases/2.x/2.068.2/ -Martin [¹]: https://issues.dlang.org/show_bug.cgi?id=15044
Re: Release D 2.068.1
On Monday, 14 September 2015 at 20:14:45 UTC, Jack Stouffer wrote: On Monday, 14 September 2015 at 17:51:59 UTC, Martin Nowak wrote: What platform are you on? I'm on OS X, using the homebrew version of DMD. And homebrew is telling me that I have 2.068.1 installed Well I guess it's a bug in the homebrew script then. Nobody is setting the VERSION file and there is no git repo to query. https://github.com/Homebrew/homebrew/blob/f8b0ff3ef63e60a1da17ec8d8e68d949b1cebc27/Library/Formula/dmd.rb#L50
Re: Release D 2.068.1
On Thursday, 10 September 2015 at 17:46:53 UTC, Jack Stouffer wrote: Well, it's a little too late, but the compiler outputs the wrong version: $ dmd --version DMD64 D Compiler v2.068 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright It does work for me and the build seems fine as well. https://github.com/D-Programming-Language/installer/blob/c6f8648e56ca58e1cad65a441e2d765ca96f1da0/create_dmd_release/build_all.d#L345 What platform are you on?
Re: Operator overloading or alternatives to expression templates
On 09/13/2015 03:15 PM, Jack Stouffer wrote: > > I know that this effect is much harder to create in a explicitly and > strongly typed language, but I just wanted to show a real world example > of how these could be used to great effect. But it is doable in D, and even better it's possible to optimize the queries b/c we can know in advance what fields are used. http://dpaste.dzfl.pl/cd375ac594cf
Re: std.experimental.testing formal review
On 09/11/2015 01:27 PM, Atila Neves wrote: >> How about Fuzz-tests, randomize input for test on each run? > > Like QuickCheck? Robert has something for that. There is also https://github.com/MartinNowak/qcheck for that.
Re: Operator overloading or alternatives to expression templates
On 09/13/2015 05:03 AM, Andrei Alexandrescu wrote:
> Yah, understood. Problem here is the approach is bound to run into walls
> at every few steps. Say you fix the comparisons to work. Then you have
> operators such as LIKE that are necessary yet not representable in D. So
> more tricks are in order. This is what I've seen with ET in C++ - an
> endless collection of tricks to achieve modest outcomes at enormous costs.
But this is not an argument to rule out `opBinary!"<"`.
To summarize the arguments.
- logical indexing x[x < 20]
e.g. opBinary!"<" returns a bit mask to select entries of a large vector
- faster comparison
struct Foo
{
size_t id;
int opCmp(Foo rhs)
{
if (id < rhs.id) return -1;
if (id == rhs.id) return 0;
else return 1;
}
bool opBinary(string s:"<")(Foo rhs)
{
return id < rhs.id;
}
}
Sorting a million Foos w/ random ids is 37.5% slower with opCmp.
foos.sort!((a, b) => a.opBinary!"<"(b))(); // 104ms
foos.sort!((a, b) => a < b)(); // 143ms
- expression templates
I'm well aware of the limitations, but still think it will work out
nicely for an ORM b/c there is precedence in other language, e.g. Rails'
(ActiveRecord) query syntax.
- language regularization
It's surprising to find these "arbitrary" language limitations.
The non-predictability of what's possible has always been a huge issue
for me with C++, i.e. you come up with an idea, spend 4 hours
implementing it only to find out that the small detail x isn't feasible.
Re: Operator overloading or alternatives to expression templates
On 09/13/2015 11:00 AM, Sönke Ludwig wrote:
> I had played around with some ideas for a similar project, but didn't
> find a really satisfying solution:
> https://github.com/rejectedsoftware/dotter/blob/11ec72325e76c3329a58545526940c1df5328a2d/source/dotter/orm.d#L320
Yeah, that doesn't look too nice.
I think db.get!Author.where!(a => a.books.count > 10) is very powerful
b/c you can easily use relations for querying.
struct Author
{
@hasMany // relation in SQL or nested in MongoDB
Book[] books;
}
Re: Operator overloading or alternatives to expression templates
On 09/13/2015 07:16 PM, Daniel N wrote:
>
> Could you try this?
>
> int opCmp(Foo rhs)
> {
> return (id > rhs.id) - (id < rhs.id);
> }
That's not the point, opCmp requires twice as many comparisons as needed
for <. If they are more expansive, e.g. string comparison, your trick
won't work.
Re: dmd codegen improvements
On 09/13/2015 07:30 PM, BBasile wrote: > It seems that since the Pentium I, ENTER is always slower. But i don't > know if it's used as a kind of optimization for the binary size. > Actually before using DMD I had **never** seen an ENTER. https://github.com/D-Programming-Language/dmd/pull/5073
Re: dmd codegen improvements
On 09/13/2015 08:45 PM, BBasile wrote: > Yeah, that was fast. With the hope it'll be approved. If only it wasn't for me to do this...
Re: Interesting user mistake
On 09/03/2015 06:46 PM, Andrei Alexandrescu wrote: > http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang > > > The gist of it is the user wrote =+ instead of +=. I wonder if we should > disallow during tokenization the sequence "=", "+", whitespace. Surely > it's not a formatting anyone would aim for, but instead a misspelling of > +=. > > > Andrei https://github.com/D-Programming-Language/dmd/pull/5072
Re: Operator overloading or alternatives to expression templates
On Friday, 11 September 2015 at 23:47:42 UTC, Andrei Alexandrescu wrote: 1. Use lambdas, which seem to already do what you want: db.get!Person.filter!(p => p.age > 21 && p.name == "Peter") The way this'd go, the db.get!Person() call returns an input range of Person. Presumably introspection is being used to bind fields in the query such as "age" and "name" to static field names in struct Person. Then good old std.algorithm.filter takes care of the rest. I'm instantiating the lambda with a fake p to capture the expression so I can translate it to whatever SQL, MongoDB, columnar db is used. 2. If you want to embed real SQL into D, use string-based DSLs. Strings don't capture context, aren't typechecked, and require a complex CTFE parser. db.get!Person.where!"age > 21 & name = ?"(name);
Re: Operator overloading or alternatives to expression templates
On Friday, 11 September 2015 at 23:19:54 UTC, Timon Gehr wrote: Does anyone have a different idea how to make a nice query language? db.get!Person.where!(p => p.age > 21 && p.name == "Peter") You could give up on operator syntax. That's what I did in the prototype, p.age.gt(21), but it's somewhat ugly.
Operator overloading or alternatives to expression templates
I find the reasons for turining down my ER a bit moot. [Issue 14593 – operator overloading can't be used with expression templates](https://issues.dlang.org/show_bug.cgi?id=14593) AFAIK expression templates are the primary choice tom implement SIMD and matrix libraries. And I still have [this idea](http://dpaste.dzfl.pl/cd375ac594cf) of implementing a nice query language for ORMs. D currently doesn't allow to override some operators like < <= > >= && || !=. At least the comparison operators are really limiting, e.g. it's not possible to efficiently implement logical indexing. vec[vec < 15], vec[vec == 15], vec[(vec != 15) & (vec > 10)] Also opCmp is less efficient to implement than opBinary!"<" for many types. Generally any good implementation of an algorithm should only require a less operator, not a full ordering opCmp. The short circuit operators && and || have a special semantic and can't be easily, but there is & and | so it's not really required. Now expression templates make an awful DSL when being used to create a HTML formatter, but when the original semantic of the operators is preserved they are really powerful b/c the compiler already handles typechecking, operator precedence, and captures variables. Does anyone have a different idea how to make a nice query language? db.get!Person.where!(p => p.age > 21 && p.name == "Peter")
Re: Compile all-of-dub?
On 09/11/2015 01:37 PM, ZombineDev wrote: > On Wednesday, 9 September 2015 at 08:26:59 UTC, qznc wrote: >> ... > > https://github.com/MartinNowak/project_tester Right, please contribute.
Re: Compile all-of-dub?
On 09/09/2015 10:26 AM, qznc wrote: > The Rust people have this Crater [0,1] tool, which essentially builds > all Rust libraries with two compiler versions and compares for regressions. I recently created a Jenkins project so that I can easily test many projects with a particular DPL version or against PRs. https://github.com/MartinNowak/project_tester It's still much better when the actual author of a library tests the latest beta, and beta are always available via Travis-CI.
Re: module std.stream is deprecated - Will be removed by phobos version 2.070
On 09/11/2015 11:47 PM, Daniel N wrote: > maybe if it was moved to DUB, it wouldn't be that disruptive? Yes, please add it to http://code.dlang.org/packages/undead at least.
Re: Beta D 2.068.2-b1
On Thursday, 10 September 2015 at 08:12:19 UTC, anonymous wrote: I tested a vibe.d project and got lots of linker errors starting with ../../.dub/packages/vibe-d-0.7.24/libvibe-d.a(libevent2_38e3_5d7.o): In Funktion `_D4vibe4core7drivers9libevent215Libevent2Driver6__ctorMFNbC4vibe4core6driver10DriverCoreZC4vibe4core7drivers9libevent215Libevent2Driver': [path]../../.dub/packages/vibe-d-0.7.24/source/vibe/core/drivers/libevent2.d:97: Nicht definierter Verweis auf `event_set_mem_functions' You're not linking against libevent here? Maybe missing libevent-dev or some issue with dub?
Re: Beta D 2.068.2-b1
On Thursday, 10 September 2015 at 17:14:03 UTC, anonymous wrote: After uninstalling dmd 2.068 andinstalling the .deb package instead of downloading+extracting the tar.xz everything works fine! The tar.xz package should work as well.
Re: Release D 2.068.1
On Thursday, 10 September 2015 at 18:27:08 UTC, Steven Schveighoffer wrote: I think we can fix this. Looks like the version string is generated on build, and has no effect on the code at all. -Steve Will check what went wrong there. https://trello.com/c/k6TFqHgY/89-check-version-number-of-compiler
Beta D 2.068.2-b1
Due to a regression in 2.068.1 we'll directly follow up with an unplanned point release 2.068.2. This is the beta for that point release. http://downloads.dlang.org/pre-releases/2.x/2.068.2/ Please test any of your code against this beta to help finding bugs. https://issues.dlang.org/ -Martin
Re: Release D 2.068.1
On 09/07/2015 12:21 PM, anonymous wrote: > Trying to download the 7z Windows file gives me a 403. > > http://downloads.dlang.org/releases/2015/dmd.2.068.1.windows.7z Thanks, I just fixed it. The aws client failed to upload that file and it was hard to notice in the log output.
Release D 2.068.1
Glad to announce D 2.068.1. http://downloads.dlang.org/releases/2.x/2.068.1/ This point release comes with many regression and bug fixes over 2.068.0, see the changelog for more details. http://dlang.org/changelog.html#2.068.1 -Martin
Beta D 2.068.1-b2
First beta for the 2.068.1 point release (we skipped -b1 due to a bug). http://downloads.dlang.org/pre-releases/2.x/2.068.1/ http://ftp.digitalmars.com/ Also available on Travis-CI as dmd-2.068.1-b2. This beta comes with plent dmd and a few druntime, phobos, and installer fixes. https://github.com/D-Programming-Language/dmd/compare/v2.068.0...v2.068.1-b2 https://github.com/D-Programming-Language/druntime/compare/v2.068.0...v2.068.1-b2 https://github.com/D-Programming-Language/phobos/compare/v2.068.0...v2.068.1-b2 https://github.com/D-Programming-Language/installer/compare/v2.068.0...v2.068.1-b2 Please report any bugs at https://issues.dlang.org. -Martin
Re: D jwtd library propagated on jwt.io
On Tuesday, 25 August 2015 at 13:14:31 UTC, tchaloupka wrote: Maybe unnoticed by the community, but thanks to Oleh (olehlong) D is visible as one of implementations of Json web token library on http://jwt.io/. Great, adding D support to a project is very helpful to grow our ecosystem and a good way to increase D's visibility.
Re: dpaste web site
On Wednesday, 26 August 2015 at 05:54:44 UTC, nazriel wrote: On Thursday, 20 August 2015 at 20:28:48 UTC, Steven Schveighoffer wrote: dpaste.dzfl.pl is severely out of date. Who maintains this and can we get it updated? It's going to start hurting us pretty severely if we use it as our go-to site for pasting compiled-and-run d snippets, but it's only at version 2.065. -Steve I will work on it. Should be fixed before weekend. I will also open source dpaste frontend and backend so such problems can be avoided in the future. Nice Got a little bit behind with D related stuff and auto-updates of DMD stopped working for some reason. There is an API now to get the latest version. http://ftp.digitalmars.com/LATEST And you can get the necessary package generically via http://downloads.dlang.org/releases/2.x/$LATEST/dmd.$LATEST.linux.zip.
Re: std.data.json formal review
On Saturday, 22 August 2015 at 13:41:49 UTC, Sönke Ludwig wrote: There is more than the actual call to validate(), such as writing tests and making sure the surroundings work, adjusting the interface and writing documentation. It's not *that* much work, but nonetheless wasted work. I also still think that this hasn't been a bad idea at all. Because it speeds up the most important use case, parsing JSON from a non-memory source that has not yet been validated. I also very much like the idea of making it a programming error to have invalid UTF stored in a string, i.e. forcing the validation to happen before the cast from bytes to chars. Also see utf/unicode should only be validated once https://issues.dlang.org/show_bug.cgi?id=14919 If combining lexing and validation is faster (why?) then a ubyte consuming interface should be available, though why couldn't it be done by adding a lazy ubyte-char validator range to std.utf. In any case during lexing we should avoid autodecoding of narrow strings for redundant validation.
Re: std.data.json formal review
On 08/18/2015 12:21 AM, Andrei Alexandrescu wrote: * All new stuff should go in std.experimental. I assume stdx would change to that, should this work be merged. Though stdx (or better std.x) would have been a prettier and more exciting name for std.experimental to begin with.
Re: Trying to compile weather program
On Sunday, 23 August 2015 at 09:54:37 UTC, Tony wrote: auto loc = getJSON(ipinfo.io/)[loc] .str.split(,); BTW, the IP location doesn't work too reliably, if someone knows a better alternative...
Re: Trying to compile weather program
On Tuesday, 25 August 2015 at 05:27:16 UTC, Tony wrote: I happened to notice that among my libcurl*s libcurl-gnutls.so.3 libcurl-gnutls.so.4 libcurl-gnutls.so.4.3.0 libcurl.so.3 libcurl.so.4 libcurl.so.4.3.0 none were just libcurl.so. So I made a link for libcurl.so to the latest version and now I am getting the same link errors I got after downloading the -dev version. So apparently my can't find -lcurl was because I didn't have a non-versioned libcurl.so available as it went away when I created one Yes, it's not particularly trivial to use libcurl currently, but thankfully all the libcurl complications will be gone in about 6 weeks with 2.069.0. https://github.com/D-Programming-Language/phobos/pull/3009 (and there was probably one created by the -dev download). Yes, the -dev packages come with unversioned symlinks and a pkg-config file (try `pkg-config --libs libcurl`).
Re: std.data.json formal review
On 08/25/2015 09:03 AM, Sönke Ludwig wrote: The performance benefit comes from the fact that almost all of JSON is a subset of ASCII, so that lexing the input will implicitly validate it as correct UTF. The only places where actual UTF sequences can occur is in string literals outside of escape sequences. Depending on the type of document, that can result is a lot less conditionals compared to a full validation of the input. I see, then we should indeed exploit this fact and offer lexing of ubyte[]-ish ranges.
Re: Runtime error in code on main page
On 08/25/2015 12:06 PM, Adrian wrote: Jesus Christ, I'm just a passerby who noticed something in passing; sorry I didn't have the incentive to file a bug report. Thanks for letting us know.
Re: Moving forward with work on the D language and foundation
On 08/24/2015 08:42 PM, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. Thank you for this very respectable decision. Let's all work on making this a great decision. -Martin
Re: Runtime error in code on main page
On 08/25/2015 08:30 AM, immu wrote: I also get an error when I hit Run for the D is like ... program. Error message: Unable to fork: Cannot allocate memory Not sure, but might be a restriction of dpaste. Just a guess, maybe b/c curl creates threads internally.
Re: std.data.json formal review
Will try to convert a piece of code I wrote a few days ago. https://github.com/MartinNowak/rabbitmq-munin/blob/48c3e7451dec0dcb2b6dccbb9b4230b224e2e647/src/app.d Right now working with json for trivial stuff is a pain.
Re: D-Day for DMD is today!
On 08/23/2015 06:35 PM, Nick Sabalausky wrote: I haven't worked with the conversion tool before. How is this part done? It's the exact command below that line, we've incorporated that into the makefile.
Re: D-Day for DMD is today!
On 08/23/2015 07:08 PM, Martin Nowak wrote: On 08/23/2015 06:35 PM, Nick Sabalausky wrote: I haven't worked with the conversion tool before. How is this part done? It's the exact command below that line, we've incorporated that into the makefile. In case it doesn't work b/c you added a new symbol, you need to updated magicport.json during the rebase. https://github.com/MartinNowak/dmd/blob/9907cf65091f1c378c4955b7b5ee8287c17ae879/src/magicport.json
Re: dmd codegen improvements
On 08/18/2015 10:28 PM, Walter Bright wrote: On 8/18/2015 12:38 PM, deadalnix wrote: And honestly, there is no way DMD can catch up. I find your lack of faith disturbing. I don't doubt we can catch up, and it might be worth for the very low hanging fruit. But our real problem isn't the backend but the amount of bugs and small ecosystem when compared with other languages like go, scala, swift, or even rust. This is a simple matter of priorities. Whether or not D succeeds won't depend on SETcc vs. SBB, but it does depend on us delivering the most useful ecosystem. It's so much more important to move forward with https://trello.com/c/YoAFvV5n/6-313-314 or https://trello.com/c/1dQh4gxm/35-drop-property, or improve backtraces https://trello.com/c/FbuWfpVE/54-backtraces-with-line-numbers, no matter how much these codegen inefficiencies tickle your ambition. -Martin
Re: D-Day for DMD is today!
On 08/23/2015 08:48 AM, Iain Buclaw via Digitalmars-d-announce wrote: It should do with whatever is in master at least. But until I'm able to release new binaries, there is at least new TravisCI integration testing of PRs that test building ddmd with ldc and gdc. But it currently fails. https://travis-ci.org/D-Programming-Language/dmd/builds/76838751 https://travis-ci.org/D-Programming-Language/dmd/jobs/76838753#L287
Re: D-Day for DMD is today!
On 08/23/2015 11:09 AM, Dicebot wrote: Great! Daniel, does that mean that I can remove DDMD testing job from my CI? :) I think so.
Re: Object.factory() and exe file size bloat
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote: The solution seems straightforward - only have Object.factory be able to instantiate classes marked as 'export'. This only makes sense anyway. The export seems to be an arbitrary rule (and export is really broken currently). Let's just use every class that is linked into the binary (e.g. weakly referencing them), then it'll naturally work with all linker functionalities. This doesn't only affect Object.factory but also ModuleInfo.localClasses. I'd suggest we first add a new internal array of weakly linked classes, turn localClasses into an opApply function or range so it automatically skips null classes (weakly undefined), then change Object.factory to only load weakly linked classes. For an intermediate time we can keep the old array and print a deprecation warning in Object.factory when a class would no longer be available. https://github.com/D-Programming-Language/dmd/pull/4638
Re: Object.factory() and exe file size bloat
On Friday, 21 August 2015 at 13:47:49 UTC, Andrei Alexandrescu wrote: Thanks for this list. I think these need to be fixed (by replacing indirect-calls-based code with templates) regardless of where we go with TypeInfo. There's a fair amount of druntime code that suffers from being written before templates or in avoidance thereof. -- Andrei Yes, it's a major pain and a source for many incorrect attributes.
Re: D-Day for DMD is today!
On 08/23/2015 07:22 AM, Rikki Cattermole wrote: Now lets hope the next stage is smooth in the transition. Here is a small guide on how to update a PR. https://github.com/D-Programming-Language/dmd/pull/4922#issuecomment-133776696
Re: Problem with dmd 2.068 Win 32
On Tuesday, 11 August 2015 at 15:04:29 UTC, MGW wrote: Hi! My project has an error link: Error 42: Symbol Undefined _D6object9Exception6__ctorMFNaNbNfAyaAyakC6object9ThrowableZC9Exception On dmd 2.067.* everything gathered without mistakes. Where to look for a mistake? Try ddemangle (part of the distribution). ddemangle _D6object9Exception6__ctorMFNaNbNfAyaAyakC6object9ThrowableZC9Exception - pure nothrow @safe Exception object.Exception.__ctor(immutable(char)[], immutable(char)[], uint, object.Throwable) In the current release @nogc was added. https://github.com/D-Programming-Language/druntime/blob/v2.068.0/src/object.d#L1614 You either have a wrong import paths (check which dmd.conf is used with 'dmd -v non_existent') or a stable object_.di file.
Release D 2.068.0
Glad to announce D 2.068.0. http://downloads.dlang.org/releases/2.x/2.068.0/ This release comes with many rangified phobos functions, 2 new GC profilers, a new AA implementation, and countless further improvements and fixes. See the changelog for more details. http://dlang.org/changelog.html#2.068.0 -Martin
Re: line numbers for linux exception traces
On 08/06/2015 05:32 PM, Colin wrote: I wonder how difficult implementing this in the compiler would be? Obviously cant use external tools... I also opened an ER to collect some ideas for nicer backtraces. https://issues.dlang.org/show_bug.cgi?id=14885
Re: line numbers for linux exception traces
On 08/06/2015 05:32 PM, Colin wrote: I wonder how difficult implementing this in the compiler would be? Obviously cant use external tools... It's not too complex to implement in the *runtime*. The code already exists, someone just needs to remove the phobos dependencies. https://github.com/yazd/elf-d
Re: line numbers for linux exception traces
On 08/07/2015 08:00 PM, Martin Nowak wrote: On 08/06/2015 05:32 PM, Colin wrote: Here is that card in our backlog btw. https://trello.com/c/FbuWfpVE/13-backtraces-with-line-numbers
Re: Changelog
On Wednesday, 5 August 2015 at 23:38:22 UTC, Brian Schott wrote: On Wednesday, 5 August 2015 at 20:57:49 UTC, anonymous wrote: getUDAs and getSymbolsByUDA don't seem to have made it, so they're correctly commented out for now. That's annoying. Those three were meant to go together. It is unfortunate, should we drop hasUDA out of stable? This is exactly what I meant with incomplete features in the first spring review. http://forum.dlang.org/post/559e73b4.7020...@dawg.eu http://forum.dlang.org/post/559fd901.1090...@dawg.eu
Re: casting away const and then mutating
On Friday, 24 July 2015 at 21:12:57 UTC, Jonathan M Davis wrote: Yeah. That needs to be fixed. As I understand it, it's feasible without any language improvements, but it's horrific. Jonathan Crapuchettes talked at one point about doing it at EMSI (and how hard it was). The last time I tried it, I ran into problems with recursive template definitions, though static if can probably solve those. Regardless, the situation with it is ugly and not well understood, even if there is a solution, and ideally, we'd find a way to implement it that was a lot easier and cleaner. Without that, almost no one is going to be doing it - probably even if there's an article on dlang.org explaining how - simply because of how annoying it is to do. Please open a Bugzilla issue to keep track of this and raise awareness. If we're going to need a language feature we need to start collecting arguments, and maybe someone can still come up with a clean solution. It's an important issue b/c it affects every container range.
Changelog
On 08/05/2015 01:57 AM, Martin Nowak wrote: Release Candidate for 2.068.0 To make this a successful release we need to work on the changelog, so that the rest of the world can know what we actually did. Right now it only contains a few entries and the ugly bug list. http://dlang.org/changelog.html Here are lists of PRs that still need a changelog entry. https://github.com/D-Programming-Language/dmd/pulls?q=label%3Achangelog_v2.068+is%3Aclosed https://github.com/D-Programming-Language/druntime/pulls?q=label%3Achangelog_v2.068+is%3Aclosed https://github.com/D-Programming-Language/phobos/pulls?q=label%3Achangelog_v2.068+is%3Aclosed Please add the 'pending changelog' tag once you're working on an entry to avoid double efforts. Changes need to go into the stable branch of dlang.org. https://github.com/D-Programming-Language/dlang.org/blob/stable/changelog.dd Also we need to go through the list of PRs and tag them with changelog_v2.068 if anything noticeable was merged. If everbody does it for his own PRs we're done very fast. https://github.com/D-Programming-Language/dmd/pulls?q=merged%3A%3E%3D2015-03-24 https://github.com/D-Programming-Language/druntime/pulls?q=merged%3A%3E%3D2015-03-24 https://github.com/D-Programming-Language/phobos/pulls?q=merged%3A%3E%3D2015-03-24 To get a list of only your PRs merged into phobos, select the author. https://github.com/D-Programming-Language/phobos/pulls?q=merged%3A%3E%3D2015-03-24+author%3AMartinNowak https://trello.com/c/iY3PYSeQ/37-changelog-changelog-changelog -Martin
Re: line numbers for linux exception traces
On Wednesday, 5 August 2015 at 15:57:46 UTC, Adam D. Ruppe wrote: If you just download this little file: http://arsdnet.net/dcode/linetrace.d and add it to your build, when compiling in debug mode, it will translate the addresses into line numbers (by simply piping out to addr2line on the command line) No modification to your program is required. There already is http://code.dlang.org/packages/backtrace-d. And there exists even an ELF based backtrace, but I'm still waiting for someone to polish it for druntime. https://issues.dlang.org/show_bug.cgi?id=11870
Re: Changelog
On 08/05/2015 09:04 PM, Brian Schott wrote: Where does that changelog come from? I made some pull requests against a file that I thought was the changelog to document some Phobos changes that got merged, but now I don't see it on dlang.org. https://github.com/D-Programming-Language/dlang.org/pull/1028/files https://github.com/D-Programming-Language/dlang.org/pull/1027/files I picked the hasUDA part into stable [¹] and updated master [²] and the website [³] [¹]: https://github.com/D-Programming-Language/dlang.org/commit/867733ebc390bef969342ee7f4dcf3e6a7218da8 [²]: https://github.com/D-Programming-Language/dlang.org/commit/c56a592cf804999e9edf7f43b6318351b94aed0d [³]: http://dlang.org/changelog.html
Re: Release Candidate D 2.068.0-rc1
On Wednesday, 5 August 2015 at 00:42:46 UTC, Ali Çehreli wrote: This always gets me: Don't forget to refresh the browser page to see the the new entries (rc1). Yes, that's a trap. I tweaked the cache control for the current beta's page, will do that the next time right away to resolve this.
Release Candidate D 2.068.0-rc1
Release Candidate for 2.068.0 http://downloads.dlang.org/pre-releases/2.x/2.068.0/ http://ftp.digitalmars.com/ We fixed the remaining issues. https://github.com/D-Programming-Language/dmd/compare/v2.068.0-b2...v2.068.0-rc1 https://github.com/D-Programming-Language/druntime/compare/v2.068.0-b2...v2.068.0-rc1 https://github.com/D-Programming-Language/phobos/compare/v2.068.0-b2...v2.068.0-rc1 https://github.com/D-Programming-Language/installer/compare/v2.068.0-b2...v2.068.0-rc1 Unless any new issue pops up, we'll make the release on friday. -Martin
Re: Beta D 2.068.0-b2
On 08/02/2015 11:20 AM, Rainer Schuetze wrote: Unfortunately, that does not help a lot because Microsoft changed their C runtime quite a bit to make it more compliant to C99. This causes unresolved symbols when linking phobos. You think we can work that out soon enough? https://issues.dlang.org/show_bug.cgi?id=14849#c7 It seems that we need to link to a certain flavor of the runtime.
Re: Beta D 2.068.0-b2
On Friday, 31 July 2015 at 17:56:23 UTC, Kelet wrote: Hi Gerald, MonoTime is the replacement for TickDuration and it's initialized from the runtime initialization function (rt_init). This is because the GC and others may need time functionality. Thanks, filed as https://issues.dlang.org/show_bug.cgi?id=14863.
Re: Beta D 2.068.0-b1
On Sunday, 26 July 2015 at 12:00:09 UTC, Martin Nowak wrote: Could someone please try the fix https://issues.dlang.org/show_bug.cgi?id=14801#c2. Please try again, we updated the fix. https://issues.dlang.org/show_bug.cgi?id=14801#c11
