gmane.comp.lang.d.general

Best XML Library

Meta — 2013-05-23T22:22:24

I'm thinking of starting on a small XMPP-based messaging client 
and server, which would necessitate quite an extensive use of 
XML. Since Tango is no longer being maintained, and Vibe.d 
doesn't support XML (as far as I know), what would be the best 
option for XML capabilities?

D on next-gen consoles and for game development

Brad Anderson — 2013-05-23T18:13:16

While there hasn't been anything official, I think it's a safe 
bet to say that D is being used for a major title, Remedy's 
Quantum Break, featured prominently during the announcement of 
Xbox One. Quantum Break doesn't come out until 2014 so the 
timeline seems about right (Remedy doesn't appear to work on more 
than one game at a time from what I can tell).


That's pretty huge news.


Now I'm wondering what can be done to foster this newly acquired 
credibility in games.  By far the biggest issue I hear about when 
it comes to people working on games in D is the garbage 
collector.  You can work around the GC without too much 
difficulty as Manu's experience shared in his DConf talk shows 
but a lot of people new to D don't know how to do that.  We could 
also use some tools and guides to help people identify and avoid 
GC use when necessary.

< at >nogc comes to mind (I believe Andrei mentioned it during one of 
the talks released). [1][2]

Johannes Pfau's work in progress -vgc command line option [3] 
would be another great tool that would help people identify GC 
allocations.  This or something similar could also be used to 
document throughout phobos when GC allocations can happen (and 
help eliminate it where it makes sense to).

There was a lot of interesting stuff in Benjamin Thaut's article 
about GC versus manual memory management in a game [4] and the 
discussion about it on the forums [5].  A lot of this collective 
knowledge built up on manual memory management techniques 
specific to D should probably be formalized and added to the 
official documentation.  There is a Memory Management [6] page in 
the documentation but it appears to be rather dated at this point 
and not particularly applicable to modern D2 (no mention of 
emplace or scoped and it talks about using delete and scope 
classes).

Game development is one place D can really get a foothold but all 
too often the GC is held over D's head because people taking 
their first look at D don't know how to avoid using it and often 
don't realize you can avoid using it entirely. This is easily the 
most common issue raised by newcomers to D with a C or C++ 
background that I see in the #d IRC channel (many of which are 
interested in game dev but concerned the GC will kill their 
game's performance).


1: http://d.puremagic.com/issues/show_bug.cgi?id=5219
2: http://wiki.dlang.org/DIP18
3: https://github.com/D-Programming-Language/dmd/pull/1886
4: http://3d.benjamin-thaut.de/?p=20#more-20
5: http://forum.dlang.org/post/k27bh7$t7f$1< at >digitalmars.com
6: http://dlang.org/memory.html

std.concurrency doesn't like structs, classes?

=?UTF-8?B?Ikx1w61z?=.Marques — 2013-05-23T17:57:48

Hi,

Has anyone tried the example from std.concurrency, but changing 
the int to an (immutable) struct or class? When I did that it 
failed with "Owner terminated". When I added a Variant to the 
receive() list, to try and fix that, I got an assertion failure 
(but the receive() handler was called).

Luís

Nightly Builds and Better Download Package

nazriel — 2013-05-23T17:32:41

Greetings.

1) Are there any plans in introducing Nightly Builds of 
DMD-master?
2) Are there any plans in splitting DMD release package for 
different OS versions? I really don't need those Windows, MacOSX, 
FreeBSD binaries while downloading DMD for my Linux box

Best regards,
Damian Ziemba

immutable ctors, immutable members, and TDPL

Steven Schveighoffer — 2013-05-23T15:41:29

An interesting subject is being debated by some of the heavy hitters of D  
on the latest beta on the announce NG.

However, I have found that there is an inconsistency in TDPL that needs to  
be addressed.

Forgetting the controversy currently brewing, we have the following  
current situation:

struct S
{
    immutable int x;
    this(int n)
    {
       x = n;
       int y = x;
       x = 0;
    }
}

This compiles, and shows that one can use an immutable, and then the  
immutable can be changed.  This is no good, for obvious reasons.

TDPL does not specifically address this issue (from what I can find via  
manual search), but it does talk about immutable constructors.  It's  
prescription is for immutable constructors to be prohibited from reading  
any members, and prohibited from calling any functions with 'this' as a  
parameter.  You are allowed to write the members as many times as you  
want.  The idea is if you can't read the data, it can't be inconsistent.

Note that this mechanism is not currently implemented in the compiler.

I thought "great, let's apply the same technique here".  But we have a  
problem.  It would be too restrictive to say you can't call another member  
function or any other function in a *normal* ctor, just because you  
declared an immutable member.  An immutable member is generally set once  
and then read from then on.

I think both mechanisms (protecting immutable members in the ctor, and  
protecting all members in an immutable ctor) should be consistent.  I  
think the 'no calling any functions' restriction is to restrictive to  
apply to normal ctors.

My leaning is to re-define how immutable ctors and normal ctors that can  
initialize immutable members should behave.  The immutability should be  
applied on the first read of the member, or calling a member  
function/passing 'this' somewhere.  Some flow analysis is required for  
this, but we can be pretty conservative about it.  There aren't too many  
use cases for this stuff anyway.

What do you think?

-Steve

Example for creating multiple signals?

Gary Willoughby — 2013-05-23T15:22:05

I'm just looking at the signals example here: 
http://dlang.org/phobos/std_signals.html#.Signal where it says 
"Different signals can be added to a class by naming the 
mixins.". Has anyone got an example of this please? I'd like to 
have a class raise different signals if possible.

D stability testing framework

Joseph Rushton Wakeling — 2013-05-23T14:30:16

Hello all,

Having listened to Andrei and Walter's Q&A and read some of the discussion
surrounding it, an idea occurred to me.

How about leveraging the selection of 3rd-party D code out there to provide a
testing framework for D's stability as a language?

The framework would pull in a specified version of dmd, druntime and Phobos, and
build them; and then using those, attempt to pull in and build a selection of
3rd-party libraries and to run test code those libraries would provide.  It
would then report the number of build failures and runtime/unittest failures and
try to classify them according to whether they are due to a change in the
_language_, a change in the runtime, or a change in Phobos.

The idea would be to get reliable statistics on what breaking changes are
causing what degree of pain (and why) for D users.  Currently we have arguments
over how stable the language is and what kind of breakages are or aren't
acceptable.  With a good enough selection of 3rd-party code, it might be
possible to quantify the prospective impact of a change.

Ideally the test code could be provided simply by providing a list of git
repositories and branches to test.  A practical stumbling block might be
different build systems etc., so it might be necessary to have some kind of
standardized build system the testing framework could expect (e.g. a testbuild.d
script, just as some libraries currently provide a build.d script).

The goal would be to provide mutual benefit for the D language and providers of
public test code -- patches to D, druntime or Phobos could be tested to see the
extent of breakage they cause, providers of test code could get automated early
warning that a change to the D frontend, druntime or Phobos is going to impact
their project (and a framework to test patches designed to cope with those
breaking changes).  It should also be possible to run the testing framework on
one's personal machine (so for example, downstream users could test their code
against latest-off-GitHub versions of dmd, druntime and Phobos without having to
make their code publicly available).

I don't know if this idea is practical in reality -- it might be difficult to
distinguish between breakages caused by changes to D and breakages caused by
other problems such as incorrect testbuild scripts, etc.  It's also cheeky as I
definitely don't have the knowhow or time to do this myself.  But I thought I'd
throw it out there to see if it's an idea worth pursuing by someone.

Best wishes,

    -- Joe

AA: How to lose a class

David — 2013-05-23T09:30:51

http://dpaste.dzfl.pl/9172bed3

If mutable keys are allowed in AAs, then why don't they work and why
isn't that documentated? The docs imply this should work, but it
obviously doesn't.

Code:


import std.stdio;

< at >trusted nothrow void printHash(hash_t h) {
try { writefln("Called hashing func: %s", h); } catch(Exception e) {}
}

class Key{
hash_t hash;

this(size_t hash) {
this.hash = hash;
}

override hash_t toHash() const {
printHash(this.hash);
return hash;
}

override bool opEquals(Object o) const {
Key k = cast(Key)o;
if(k is null) {
return false;
}

return hash == k.hash;
}

override int opCmp(Object o) const {
Key k = cast(Key)o;
if(k is null) {
return -1;
}

if(k.hash < hash) {
return -1;
} else if(k.hash == hash) {
return 0;
} else {
return 1;
}
}
}

void main() {
int[Key] aa;

Key k1 = new Key(10);

aa[k1] = 3;
writeln(aa[new Key(10)]);

k1.hash = 5;
writeln((new Key(5)) in aa);
writeln((new Key(10)) in aa);
writeln(k1 in aa);

}

ddox based reference on dlang.org

Brad Anderson — 2013-05-23T00:52:44

Whatever happened to the plan of getting Sönke Ludwig's ddox 
generated documentation up on dlang.org?

http://vibed.org/temp/d-programming-language.org/phobos/std/algorithm.html

I see there are pull requests to add it:

https://github.com/D-Programming-Language/dlang.org/pull/267
https://github.com/D-Programming-Language/tools/pull/43

I can't immediately tell if they are ready to pull or not.  
Better documentation was one of the main criticisms I've gleaned 
from the DConf videos released thus far so any improvements in 
this area should probably get merged sooner than later.

(I'm personally looking forward to the day I can stop explaining 
to confused people that the link to the remove function in 
std.algorithm is actually taking you to an unrelated enum)

How are D atomics? [was: Low-Lock Singletons In D]

Steven Schveighoffer — 2013-05-23T00:17:34

On Tue, 07 May 2013 15:58:34 -0400, Dmitry Olshansky  
<dmitry.olsh< at >gmail.com> wrote:



I finally got around to watching this.  Absolutely mind-blowing, and a  
very very good talk.  This is what I would point people at, although it is  
a bit long (and necessarily so).  Didn't seem like it took 3 hours :)

I take back all my arguments regarding the previous discussion, they were  
all wrong, along with my concept of the "issues" with out-of-order  
reads/writes.  I really like how Herb explains that it doesn't really  
matter where the re-ordering happens, to the coder, it's all the same (as  
if the source code is reordered), and how you can't ever really reason  
about code if it has races.

Is D prepared to do (or does it do?) the same things that C/C++11 does  
with atomics?  It seems it is a necessity.  The docs on core.atomic are,  
well, actually missing: http://dlang.org/phobos/core_atomic.html

-Steve

From CppNow 2013

bearophile — 2013-05-22T21:11:02

Among the CppNow 2013 slide packs I have found two interesting 
things:

https://github.com/boostcon/cppnow_presentations_2013

----------------------

One is from "Concepts Lite: Constraining Templates with 
Predicates" by Andrew Suttoon, Bjarne Stroustrup et al:

https://github.com/boostcon/cppnow_presentations_2013/blob/master/thu/concepts-lite.pdf?raw=true

This is a D version of C++13 code that uses Concepts Lite:

void sort(C)(C cont) if (SortableContainer!C) {}

They suggest to allow a syntax like this, usable when the 
template constraint has only one argument:

void sort(SortableContainer cont) {}

It's handy especially for lambdas:

(Regular x) => x == y;


If you have two or more types, they must be the same (if you 
don't want this, you have to use the normal longer syntax):

void foo(isRandomAccessRange a,
          isRandomAccessRange b) {
     static assert(is(typeof(a) == typeof(b))); // true.
}


The total number of concepts they define is quite small:

Equality_comparable
Totally_ordered
Regular
Function
Predicate
Relation
Input_iterator
Forward_iterator
Bidirectional_iterator
Sortable

----------------------

The other nice thing I've seen is here:

"Dynamic, Recursive, Heterogeneous Types in Statically-Typed 
Languages" by Richard Saunders, Clinton Jeffery:

https://github.com/boostcon/cppnow_presentations_2013/blob/master/fri/DynRec.pdf?raw=true

They define Tab, Val and little else that allows them to offer a 
dynamic data structure as similar as possible to the Python dicts:

# Python
d = {'a':1, 'b':2.2, 'c':[1,2.2,'three']}
v = int(d['c'][0])
v +=3
d['c'][2] = v


The C++ syntax they use:

Tab d="{'a':1,'b':2.2,'c':[1,2.2,'three']}";
int v = d("c")(0);
v += 3;
d["c"][2] = v;


Another example in C++:

Tab t = "{'a':{'nest':1}}";
cout << t["a"]["nest"] << endl;
t["a"]["nest"] = 17;

Bye,
bearophile

can "Run" the examples on http://dlang.org/changelog.html

dennis luehring — 2013-05-22T14:04:48

first the normal page appears, then after some ms a page refresh occurse 
(which adds the "Run" feature) - but i only get syntax errors from Run

What has happened to "-vgc" pull request?

Dicebot — 2013-05-22T09:12:37

subj

I remember seeing one in dmd pull request list but can't find it 
now.

C++ parser

IgorStepanov — 2013-05-22T08:05:04

Is there someone free C++ parser? I want to create simple util to 
converting C++ headers to D like htod, but I want, if it 
possible, to dont write C++ parser. Any ideas?

Have the mailing lists stopped working?

2013-05-22T05:23:49

I've not received new posts for about 12 hours, but can see on 
forum.dlang.org that new stuff has been posted. I even signed up 
to a new mailing list here to check, and got no confirmation 
email.

std.uni vs std.unicode and beyond?

Dmitry Olshansky — 2013-05-21T12:51:01

The pitch by deadalnix:

I strongly push into renaming it to std.unicode . As said in the other 
thread : uni can be unicode, but also unique, union, unit, uniform, 
unix, unijambist, whatever.

When theses pile up in a large library, this is more and more difficult 
to rely on intuition/autocompletion and much more on programmer's 
memory. It mean that it takes longer to learn the whole library.


My reservations:

If the chief benefit of renaming is aesthetics then I'd rather pass.
This kind of knee-jerk changes made on basis of "a good time to try to 
push a better name" just don't belong in design of library/package 
structure. Yeah, I know nobody is going to say "package structure" 
looking at Phobos.

If we make it a part of restructuring std.* that is long overdue then 
I'm fine as long as package structure is well thought out as a whole. 
Changing it now before adopting a package structure risks the 2nd change 
and another set of arguments for keeping things as is.

Let's continue discussion here and not in voting thread.

The best video to introduce D

Regan Heath — 2013-05-21T11:23:40

I have a friend, he has heard of D (from me) a fair bit over the years but  
never had reason to look into it.  He works at a company which has a  
culture of showing tech videos during lunch.  So.. I want the best  
introduction to D video that we have, which will fit in a lunch hour..  
anyone?

R

Decreasing time between dmd releases: release early and oftenincremental versions rather than large changes

Timothee Cour — 2013-05-21T10:02:55

Instead of trying to cram as many new features / bug fixes into the next
dmd release (thereby delaying the release), why not make the release
process more incremental and frequent (eg like google chrome).
That would reduce time to market of new features and bug fixes and prevent
people from having to use workarounds for stuff that has already been
implemented but not yet shipped in the yet to come release.

The only thing that should delay a release should be regressions.

As for debated or incomplete features, instead of delaying the release,
they should use an experimental inclusion in phobos to have early community
feedback, see one proposal (among others) here:
http://forum.dlang.org/thread/mailman.807.1365776844.4724.digitalmars-d< at >puremagic.com?page=3#post-mailman.828.1365866403.4724.digitalmars-d:40puremagic.com

new DIP41: dmd/rdmd command line overhaul.

Timothee Cour — 2013-05-21T09:44:46

Abstract:
This DIP seeks to improve dmd and rdmd's command line flags, to make it
more self-consistent and consistent with other tools (including other D
compilers), more expandable, avoid existing corner cases, and better
interact with other tools such as rdmd. It also proposes new flags and
proposes a simple deprecation path to follow.

Link:
http://wiki.dlang.org/DIP41

External lib unittests: they're killin me!

Nick Sabalausky — 2013-05-21T01:52:51

Y'know what we need? This compiler flag:

   -unittest=pagkage.name.*

Damn near every codebase in D uses "unittest{}" sections. Obviously
that's good.

But it's also bad:

I cannot flip on unittests for my project (where "I" and "my" can be
substituted with the name of any D user) without *also* flipping on
unittests for every source-library used, transitively. Unless the lib
versions-out their unittests with "version(Unittest_MyLibXXX)"...And
none of them do. (well, mostly)

This *can* be fine, *when*:

- They're all fast.

- Their sum doesn't make DMD's memory usage go kabloom.

- They all have all their prereqs already setup (sometimes the need for
  some configuration isn't easily avoidable, example: setting up a DB
  user/login).

- And none of them have any failures...on the *exact*
  OS/arch/compiler/compiler-version combination that I happen to be
  using. Oh, and the exact versions of any other dependent libs.

We could say "Let's just recommend good style is to version out your
unittest blocks". But that's programming by convention: All it takes is
one lib not playing ball, or one unittest in one lib that just happened
to forget it, and then the poor user is back to "ad-hoc patching"-land.
And it's boiler-plate, anyway.

So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi running
out the door)

support UFCS with fully qualified function names (was in"digitalmars.D.learn")

Timothee Cour — 2013-05-21T01:28:15

(I've re-posting here upon request from bearophile, who seems to like it :)
)

I'd like to be able to use UFCS with fully qualified function names.

A typical use case is to disambiguate , as in the following case:

import std.path;
import std.string;
void main(){
    //Error: std.path.join()(const(char)[] p1, const(char)[] p2, const(char[
])[] more...) at ... conflicts with std.string.join at ...
    auto a="".join("\n");
    //what I'd like to have:
    auto a="".(std.path.join)("\n");
}

note: the fact that std.path.join!().join is deprecated is irrelevant to
this discussion.

Any chance this could be supported?

benefits:
avoids breaking UFCS chains