date:20140528


On 5/28/2014 5:20 PM, ed wrote:

a) a workshop for new D users with entry-level talks and maybe even hands-on
sessions (would require attendees bring a laptop)


We did that for Dconf 2013; having a "tutorial day" preceding the conference. 
There wasn't enough interest in it, so we cancelled it.


If there is enough interest next year, we can certainly hold it.

Re: DConf Recommendation

2014-05-28 Thread ed via Digitalmars-d


On Wednesday, 28 May 2014 at 21:05:13 UTC, Chris Williams wrote:
My first day at DConf, during lunch, I ended up sitting next to 
the CTO/CEO of a startup company that was considering D as 
their language of choice. He commented to me, and which makes 
sense to me, that the format of the conference wasn't very well 
geared to people who are just interested in figuring out what 
the language is like and how to get started with it.


His recommendation was to offer two tracks over two days 
(instead of one over three), whith one track focussing on 
things like how to get a development environment set up on 
different platforms, how to debug, overview of language 
features, etc. That way a CTO or other interested party could 
use the conference as a way to evaluate the language for use at 
their companies.


I also got the sense that he was hiring, should anyone be 
interested. Apakau.com


Does it have to split the entire DConf? What if a half-day was 
set aside for two streams:


a) a workshop for new D users with entry-level talks and maybe 
even hands-on sessions (would require attendees bring a laptop)


b) A set of very technical low-level language talks for hardcore 
D language developers.


If there are not enough for a) people are less likely to mind 
because it is only a half-day with the alternative listening to 
interesting D talks anyway.


Cheers,
ed

Re: D Language Version 3


On Wednesday, 28 May 2014 at 22:48:22 UTC, Jonathan M Davis via
Digitalmars-d wrote:


That's interesting :D

Re: Some @nogc text conversion in Phobos?


On Wednesday, 28 May 2014 at 23:27:34 UTC, bearophile wrote:

This is currently accepted code:


void main() {
import std.array: appender;
import std.format: formattedWrite;

auto writer = appender!string;
formattedWrite(writer, "%s is the ultimate %s.", 42, 
"answer");

assert(writer.data == "42 is the ultimate answer.");
}



But there are problems caused by formatting for exception error 
messages:

https://d.puremagic.com/issues/show_bug.cgi?id=12768


An example of the problem:

class UTFException : Exception
{
...
pure @safe
this(string msg, size_t index, string file = __FILE__, 
size_t line = __LINE__, Throwable next = null) {

import std.string;
super(msg ~ format(" (at index %s)", index), file, 
line, next);

}


Because of that several Phobos functions can't be @nogc.

So is it a good idea to add to Phobos a function similar to 
this?



void main() pure nothrow @safe @nogc {
import std.format: bufferText;

immutable n = 42;
immutable s = "answer";
char[100] buf;
const Nullable!(char[]) result =
buf.bufferText(n, " is the ultimate ", s);
assert(result.get == "42 is the ultimate answer.");
}



That should allow (in theory) code like:

class UTFException : Exception
{
...
pure @safe @nogc
this(in char[] msg, string file = __FILE__, size_t line = 
__LINE__, Throwable next = null) {

super(msg, file, line, next);
}

...

char[100] buf;
const msg = buf.bufferText("Invalid UTF-8 sequence (at index ", 
i, ')');

if (mgs.isNull)
new UTFException("Invalid UTF-8 sequence")...
else
new UTFException(msg.get)...



A problem left is that the ctor of Exception is not yet @pure 
@nothrow @safe @nogc.


Bye,
bearophile


IMHO something like this is better:

class MyException : Exception
{
private char[20] index_buff; // should be enough for 
size_t.max


this(string msg, size_t index, string file = __FILE__, size_t 
line = __LINE__, Throwable next = null)

{
super(msg, file, line, next);
// in-place conversion of size_t to char[]
}

void toString(void delegate(const(char)[]) sink) const
{
sink(msg);
sink(" (at index ");
sink(index_buff);
sink(")");
}
}

Benefits: no arbitrary message length limit, no string 
construction unless toString is actually called.

Re: DConf Recommendation


On Wednesday, 28 May 2014 at 23:16:58 UTC, deadalnix wrote:

On Wednesday, 28 May 2014 at 22:04:47 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
Personally I think there were too many talks *per day*, it was 
hard not
getting tired and all the talks were extremely interesting. 
But I
understand that it's hard for people to take more free days 
for dconf alone.




Yup, at the end of the 3 days, I was like "What happened to my
brain !"


I was like "wtf has happened to my brain _and_ voice" ;)

Kind of like the idea of more public / advertising oriented 
conference but we don't have that many "casual" visitors IMHO. 
And all those bleeding edge hackers that I have seen during those 
3 days will definitely become bored if we try to add more "howto" 
stuff to main program.

Some @nogc text conversion in Phobos?

2014-05-28 Thread bearophile via Digitalmars-d


This is currently accepted code:


void main() {
import std.array: appender;
import std.format: formattedWrite;

auto writer = appender!string;
formattedWrite(writer, "%s is the ultimate %s.", 42, 
"answer");

assert(writer.data == "42 is the ultimate answer.");
}



But there are problems caused by formatting for exception error 
messages:

https://d.puremagic.com/issues/show_bug.cgi?id=12768


An example of the problem:

class UTFException : Exception
{
...
pure @safe
this(string msg, size_t index, string file = __FILE__, size_t 
line = __LINE__, Throwable next = null) {

import std.string;
super(msg ~ format(" (at index %s)", index), file, line, 
next);

}


Because of that several Phobos functions can't be @nogc.

So is it a good idea to add to Phobos a function similar to this?


void main() pure nothrow @safe @nogc {
import std.format: bufferText;

immutable n = 42;
immutable s = "answer";
char[100] buf;
const Nullable!(char[]) result =
buf.bufferText(n, " is the ultimate ", s);
assert(result.get == "42 is the ultimate answer.");
}



That should allow (in theory) code like:

class UTFException : Exception
{
...
pure @safe @nogc
this(in char[] msg, string file = __FILE__, size_t line = 
__LINE__, Throwable next = null) {

super(msg, file, line, next);
}

...

char[100] buf;
const msg = buf.bufferText("Invalid UTF-8 sequence (at index ", 
i, ')');

if (mgs.isNull)
new UTFException("Invalid UTF-8 sequence")...
else
new UTFException(msg.get)...



A problem left is that the ctor of Exception is not yet @pure 
@nothrow @safe @nogc.


Bye,
bearophile

Re: DConf Recommendation


On 5/28/2014 4:16 PM, deadalnix wrote:

I guess this is a good sign. I mean, some people are traveling
from far away, and it cost a lot.


The reason Dconf was 3 days was to make it worthwhile for people traveling some 
distance to get there. 2 days is fine for a domestic conference, but 3 days is 
needed for an international one. 1 day is best for a purely local one.

Re: D affects others


On Wednesday, 28 May 2014 at 21:22:36 UTC, Walter Bright wrote:

On 5/28/2014 1:49 PM, deadalnix wrote:

It is probably a good idea to provide such escape in a safe
interface somewhere in the library, no ?


If anyone wants to design such a module, please do so.


i have to say i'm not sure what people actually want :D I'll end
up putting something together the day i need it, for sure.

Re: DConf Recommendation


On Wednesday, 28 May 2014 at 22:04:47 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
Personally I think there were too many talks *per day*, it was 
hard not
getting tired and all the talks were extremely interesting. But 
I
understand that it's hard for people to take more free days for 
dconf alone.




Yup, at the end of the 3 days, I was like "What happened to my
brain !"

I guess this is a good sign. I mean, some people are traveling
from far away, and it cost a lot.

Re: std.benchmark

2014-05-28 Thread Jonathan M Davis via Digitalmars-d

On Wed, 28 May 2014 17:20:22 +
TheFlyingFiddle via Digitalmars-d  wrote:

> If i am not mistaken, parts of std.benchmark moved into
> std.datetime. After this work on std.benchmark stopped.

You're mistaken. Those were always in std.datetime. Rather, they were moving
into std.benchmark (which is arguably a better place for them). And I expect
that they well be moved into std.benchmark at some point in the future, but
std.benchmark ran into some difficult technical problems that have yet to be
sorted out (hence why it hasn't been completed yet).

I talked with Andrei brielfy about it at dconf (because I want to move those
functions out of std.datetime), and he's interesting in finishing it, but
those technical issues need to be sorted out first.

- Jonathan M Davis

Re: D Language Version 3

2014-05-28 Thread Jonathan M Davis via Digitalmars-d

On Wed, 28 May 2014 08:41:43 +
Don via Digitalmars-d  wrote:

> On Wednesday, 28 May 2014 at 03:25:28 UTC, Suminda Dharmasena
> wrote:
> > Hi,
> >
> > D2 has been out for a while. Looking to see what the roadmap is
> > like towards D3?
> >
> > Suminda
>
> No, it has not been out for a while. I would even say that it's
> not out yet!
> It still doesn't exist yet in the same way as D1.
>
> D1 was a clearly defined snapshot of the language at a particular
> moment in time.
> The feature list is unchanged since D1.014, except for array
> operations which were finally implemented in D1.034. It reached
> release 1.076 just with bugfixes, ie there were 61 bugfix
> releases.
>
> D2 is the ongoing language development, and we still don't have a
> stability branch more recent than the D1 branch. Almost every
> release has contained a new feature, and I can't see that
> stopping anytime soon.

Not to mention, there probably aren't even all that many places that we'd
change the language in a non-backwards compatible way even if we could start
from scratch (and even in those places, we might not change them in D3,
because it would make porting from D2 to D3 much riskier). By no means is D2
perfect, but for the most part, I think that we can either fix the problems
with it without resorting to D3, or we'd end up having similar problems in D3
anyway.

Regardless, we need to make D2 a success before we even consider considering
creating something like D3. And there may never be a D3. That's a question that

really shouldn't be up for discussion for years yet.

- Jonathan M Davis

Re: DConf Recommendation

2014-05-28 Thread Chris Williams via Digitalmars-d

On Wednesday, 28 May 2014 at 22:04:47 UTC, Andrej Mitrovic via 
Digitalmars-d wrote:
Personally I think there were too many talks *per day*, it was 
hard not
getting tired and all the talks were extremely interesting. But 
I
understand that it's hard for people to take more free days for 
dconf alone.


I suspect that for a power D user, keeping awake through a "How 
to set up Visual D" step-through would be pretty impossible.


If only one person like the guy I mentioned is going to show up, 
then to Walter's point, there's not much value in providing such 
a session in the conference. But maybe next year advertize an 
"intro to D" class that will be on the first day if there's 
enough interest, and then make people choose between "interested" 
or "not interested" when they register.

Re: D affects others

2014-05-28 Thread w0rp via Digitalmars-d


On Wednesday, 28 May 2014 at 18:08:42 UTC, Walter Bright wrote:

On 5/28/2014 1:49 AM, Russel Winder via Digitalmars-d wrote:
Also, D's approach does not support lazy evaluation, caches of 
all sorts

etc, that we think are crucial in application software.


Yes, that's so-called "logical const". This has come up several 
times here, and many have argued strongly to support it.


My view is that logical const is not mechanically checkable, 
and therefore is a convention. D's const'ness is about 
guarantees, not conventions.


Of course, D offers an escape from anything. You can do logical 
constness by using unsafe casts, but the onus is then on you to 
get it right.


I'm a big fan of D's const, and strong static checking is one of 
the reasons I picked up D a while ago. I think putting a little 
violation of the type system to accomplish something you really, 
really need, say in a @trusted function, is a good way to do 
things. Most of the time, you don't *really* need to do those 
things.

Re: DConf Recommendation

2014-05-28 Thread Andrej Mitrovic via Digitalmars-d

Personally I think there were too many talks *per day*, it was hard not
getting tired and all the talks were extremely interesting. But I
understand that it's hard for people to take more free days for dconf alone.

On Wednesday, May 28, 2014, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 5/28/2014 2:05 PM, Chris Williams wrote:
>>
>> His recommendation was to offer two tracks over two days (instead of one
over
>> three), whith one track focussing on things like how to get a development
>> environment set up on different platforms, how to debug, overview of
language
>> features, etc. That way a CTO or other interested party could use the
conference
>> as a way to evaluate the language for use at their companies.
>
> We'd love to do multiple tracks, but the conference would need to get
larger first.
>

Re: D affects others


On 5/28/2014 1:49 PM, deadalnix wrote:

It is probably a good idea to provide such escape in a safe
interface somewhere in the library, no ?


If anyone wants to design such a module, please do so.

Re: D affects others


On Wednesday, 28 May 2014 at 20:49:31 UTC, deadalnix wrote:

It is probably a good idea to provide such escape in a safe
interface somewhere in the library, no ?


I am not sure it is possible to design such module so that it 
will be both sufficiently generic and reliably type safe. Can be 
an interesting challenge though.

Re: DConf Recommendation


On 5/28/2014 2:05 PM, Chris Williams wrote:

His recommendation was to offer two tracks over two days (instead of one over
three), whith one track focussing on things like how to get a development
environment set up on different platforms, how to debug, overview of language
features, etc. That way a CTO or other interested party could use the conference
as a way to evaluate the language for use at their companies.


We'd love to do multiple tracks, but the conference would need to get larger 
first.

DConf Recommendation

2014-05-28 Thread Chris Williams via Digitalmars-d

My first day at DConf, during lunch, I ended up sitting next to 
the CTO/CEO of a startup company that was considering D as their 
language of choice. He commented to me, and which makes sense to 
me, that the format of the conference wasn't very well geared to 
people who are just interested in figuring out what the language 
is like and how to get started with it.


His recommendation was to offer two tracks over two days (instead 
of one over three), whith one track focussing on things like how 
to get a development environment set up on different platforms, 
how to debug, overview of language features, etc. That way a CTO 
or other interested party could use the conference as a way to 
evaluate the language for use at their companies.


I also got the sense that he was hiring, should anyone be 
interested. Apakau.com

Re: D affects others


On Wednesday, 28 May 2014 at 18:08:42 UTC, Walter Bright wrote:

On 5/28/2014 1:49 AM, Russel Winder via Digitalmars-d wrote:
Also, D's approach does not support lazy evaluation, caches of 
all sorts

etc, that we think are crucial in application software.


Yes, that's so-called "logical const". This has come up several 
times here, and many have argued strongly to support it.


My view is that logical const is not mechanically checkable, 
and therefore is a convention. D's const'ness is about 
guarantees, not conventions.


Of course, D offers an escape from anything. You can do logical 
constness by using unsafe casts, but the onus is then on you to 
get it right.


It is probably a good idea to provide such escape in a safe
interface somewhere in the library, no ?

Re: Fixing More Warnings in DMD?

2014-05-28 Thread Nordlöw

Some of those warnings are not generated by D compiler (like 
unused variables and labels, unused arguments, signed/unsigned 
comparisons, etc), so better to catch and fix them before 
porting the code to D.


I completely agree.

/Per

Re: -nofloat flag => should we destroy it?

2014-05-28 Thread Qox via Digitalmars-d

if you say so... (and god spoke "there will be light"...and there 
was light)


I just mean, if you restrict users to some subset of 
possibilities they will never be easily able to explore the wider 
space of the set/superset...

Re: std.benchmark

On Wed, 2014-05-28 at 17:33 +0100, Russel Winder wrote:
[…]
> Instead of wallowing in the backwaters of non-Phobosity, it should
> become a module accessible independently via a DVCS (presumably Git),
> and Dub? (though I will be using SCons) such that people can amend,
> extend and send in pull requests.

On the grounds of "do, don't just talk", I have created
https://github.com/russel/D_Benchmark initialized with a copy of
https://github.com/andralex/phobos/blob/benchmark/std/benchmark.d.
Anyone interested in evolving this, please feel free to clone and send
in pull requests.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: System level language, GC, allocation and typeinfo

2014-05-28 Thread Qox via Digitalmars-d

or maybe a branch/sub-set, GC-free, version of D arrays and 
classes.


thumbs up for that. Everytime when i do OS-level or other 
programming in D, where i can't/won't have GC i can't have 
arrays/classes. One possibility is to hack the library but it 
either leaks memory(because you can't free it easily) or it looks 
bad on the allocation side.


what i mean with allocation side:


Memory.setObject("FOO@42")
foobar[] xy = a.dup;


it esentially labels the allocated memory (with .dup) so it can 
be freed later... and it just is effectivly like a non-GC'ed 
malloc...


I would like some optional parameters for the non-GC allocations 
like



foobar[] xy = a.dup(myAllocator, 42);


(dup grabs the memory from myAllocator and passes arguments). 
Same for new like good old GC does.


Ofcourse type information and the construction of more 
complicated objects is a problem.

Re: D affects others


On 5/28/2014 1:49 AM, Russel Winder via Digitalmars-d wrote:

Also, D's approach does not support lazy evaluation, caches of all sorts
etc, that we think are crucial in application software.


Yes, that's so-called "logical const". This has come up several times here, and 
many have argued strongly to support it.


My view is that logical const is not mechanically checkable, and therefore is a 
convention. D's const'ness is about guarantees, not conventions.


Of course, D offers an escape from anything. You can do logical constness by 
using unsafe casts, but the onus is then on you to get it right.

Re: Voldemort declarations inside structs with ctor initialization

2014-05-28 Thread monarch_dodra via Digitalmars-d


On Tuesday, 27 May 2014 at 14:55:33 UTC, Luís Marques wrote:
BTW 2, is `this(int = 0)' the best workaround (still?) for the 
fact that I want the ctor to be called, even if it doesn't 
really require any parameter?


AFAIK, no, since "Foo()" will actually do nothing. "this(Arg = 
dummy)" is actually useless, unless you manually call "__ctor", 
so I strongly advise against that.

Re: New pointer type for GC

2014-05-28 Thread via Digitalmars-d


On Wednesday, 28 May 2014 at 17:39:21 UTC, Dicebot wrote:
Get this into upstream and you will have dozens unhappy about 
updating for their code. It is never that simple.


It doesn't have to be in upstream. It could be an experimental 
compiler implemented in pure D. I would back that, if Etienne is 
willing.


There is a need for a strong typed language that can compile both 
to asm.js, PNACL and to machine language. I doubt that the 
current incarnation of D is suitable, so a reduced set of D with 
better GC/malloc support and tight codegen for small downloads 
would be welcome for interactive apps.


I agree with you that D2 won't get this, but that does not 
prevent someone from creating D-.

Re: New pointer type for GC

2014-05-28 Thread via Digitalmars-d


On Wednesday, 28 May 2014 at 17:27:20 UTC, Dicebot wrote:
Adding GC pointer type does not enable anything that you can't 
do write now for high-level applications and does not help at 
all low-level applications. It is niche solution.


A niche solution is fine by me. Etienne has expressed interest in 
creating a D to asm.js converter. Now, maybe the current D is not 
suitable for that, but perhaps a dialect of D would be. I could 
back that. That makes two who are interested. Add 2-3 more people 
and we could have a train going to a station that is niche… but 
productive.

Re: New pointer type for GC

On Wednesday, 28 May 2014 at 17:35:18 UTC, Ola Fosheim Grøstad 
wrote:

On Wednesday, 28 May 2014 at 17:27:20 UTC, Dicebot wrote:
Adding GC pointer type does not enable anything that you can't 
do write now for high-level applications and does not help at 
all low-level applications. It is niche solution.


A niche solution is fine by me. Etienne has expressed interest 
in creating a D to asm.js converter. Now, maybe the current D 
is not suitable for that, but perhaps a dialect of D would be. 
I could back that. That makes two who are interested. Add 2-3 
more people and we could have a train going to a station that 
is niche… but productive.


Get this into upstream and you will have dozens unhappy about 
updating for their code. It is never that simple.

Re: New pointer type for GC

2014-05-28 Thread Bastiaan Veelo via Digitalmars-d


On Tuesday, 27 May 2014 at 16:47:38 UTC, Etienne wrote:
You're right, it's obviously easier to keep it as the same 
pointer syntax but hijack the stdlib malloc functions to 
forcibly go through the GC.


If the GC controls everything, you can keep the info in 8 byte 
pointers.


- The GC always returns an libc-incompatible pointer value
- Dereferencing should call the resolver from the GC to process 
it with the libc-compatible value (possibly just removing the 
last couple bytes)
- Sending a pointer through extern(C) should call the sanitizer 
which resolves the real pointer through the GC and sends that
- The last bytes of a pointer would contain thread ID for 
void** and poolID for void*

- This would only work on x64 platforms


This would also help implementing weak references, am I right? 
Which then come in handy when improving std.signals?


Bastiaan.

Re: std.benchmark


On Wednesday, 28 May 2014 at 16:33:13 UTC, Russel Winder via
Digitalmars-d wrote:
On Wed, 2014-05-28 at 15:54 +, Joakim via Digitalmars-d 
wrote:

[…]
A google search turns up a long review thread a couple years 
ago:


http://forum.dlang.org/thread/mailman.73.1347916419.5162.digitalmar...@puremagic.com


A somewhat depressing thread.

Looks like it was remanded for further fixes, it shows as a 
"work in progress" in the review queue:


http://wiki.dlang.org/Review_Queue


Given there has been no activity in over 2 years, I guess it is 
deemed a

dead duck in it's current form/place.

Instead of wallowing in the backwaters of non-Phobosity, it 
should
become a module accessible independently via a DVCS (presumably 
Git),
and Dub? (though I will be using SCons) such that people can 
amend,

extend and send in pull requests.


I'd love to see Andrei comment about it to either update its
status or remove from review queue.

Re: New pointer type for GC

On Wednesday, 28 May 2014 at 17:21:18 UTC, Ola Fosheim Grøstad 
wrote:

On Wednesday, 28 May 2014 at 14:16:56 UTC, Dicebot wrote:

Big language change which does not fix any fundamental issue.


Having a GC pointer type + several other mechanisms could 
reduce the amount of scanned memory to a level where it slips 
below the "pain threshold" for interactive apps. That's a 
fundamental issue for anything that is not batch.


No this is simply annoying problem. We are unlikely to break 
anything to fix annoyances (even huge ones).


Fundamental issues in my opinion are those that result in type 
system holes or make certain common/desired code impossible 
without resorting to lot of assembly magic. Or areas that are 
complicated beyond explainable.


Adding GC pointer type does not enable anything that you can't do 
write now for high-level applications and does not help at all 
low-level applications. It is niche solution.

Re: New pointer type for GC

2014-05-28 Thread via Digitalmars-d


On Wednesday, 28 May 2014 at 14:16:56 UTC, Dicebot wrote:

Big language change which does not fix any fundamental issue.


Having a GC pointer type + several other mechanisms could reduce 
the amount of scanned memory to a level where it slips below the 
"pain threshold" for interactive apps. That's a fundamental issue 
for anything that is not batch.

Re: std.benchmark

2014-05-28 Thread TheFlyingFiddle via Digitalmars-d


On Wednesday, 28 May 2014 at 16:33:13 UTC, Russel Winder via
Digitalmars-d wrote:
On Wed, 2014-05-28 at 15:54 +, Joakim via Digitalmars-d 
wrote:

[…]
A google search turns up a long review thread a couple years 
ago:


http://forum.dlang.org/thread/mailman.73.1347916419.5162.digitalmar...@puremagic.com


A somewhat depressing thread.

Looks like it was remanded for further fixes, it shows as a 
"work in progress" in the review queue:


http://wiki.dlang.org/Review_Queue


Given there has been no activity in over 2 years, I guess it is 
deemed a

dead duck in it's current form/place.

Instead of wallowing in the backwaters of non-Phobosity, it 
should
become a module accessible independently via a DVCS (presumably 
Git),
and Dub? (though I will be using SCons) such that people can 
amend,

extend and send in pull requests.


If i am not mistaken, parts of std.benchmark moved into
std.datetime. After this work on std.benchmark stopped.

Re: Optional arguments/parameters


On Wednesday, 28 May 2014 at 17:11:09 UTC, Ary Borenszweig wrote:
But there is a 'this' in that place (it's not a static 
function).


Should I file this as a bug?


I can't find exact place in spec but AFAIK default arguments in D 
are evaluated in context of call scope, same as in C. Could have 
detected the problem earlier with better error message though.

Re: Optional arguments/parameters

2014-05-28 Thread Ary Borenszweig via Digitalmars-d


On 5/28/14, 8:54 AM, Wanderer wrote:

Java misses this feature badly, forcing programmers to copy-paste
bloated code (constructor A calls constructor B with fewer arguments,
constructor B calls constructor C etc, same thing with methods). Please
tell me, does D support this feature?

int myNiceFunc(double a, double b=0, int c=0) {...}

auto n = myNiceFunc(100);


Regarding this, is this supposed to work?

---
import std.stdio;

class Foo {
  int bar() {
return 1;
  }

  int foo(int x = bar()) {
return x;
  }
}

void main() {
  new Foo().foo();
}
---

I get:

coco.d(8): Error: need 'this' to access member bar

But there is a 'this' in that place (it's not a static function).

Should I file this as a bug?

Re: D affects others

On Wed, 2014-05-28 at 16:31 +, Wanderer via Digitalmars-d wrote:
> It's very hard to keep up-to-date with all these successors to 
> Java. Every half a year a new language appears, and it's always 
> "better than all previous". :-(

I am not sure which languages you are thinking of here, there really are
not that many languages seriously proposed in the Java-verse. cf.
http://en.wikipedia.org/wiki/List_of_JVM_languages

Of course in academia everyone involved in programming language research
has to propose a couple of new languages a year to get funding. A very
sad system and state of affairs.

> D's const feature is nice and clear. But what made me "fall in 
> love" with D, is 'immutable' modifier. No inner mutable pieces 
> possible, no need to copy defensively (or copy at all), no risk 
> of data corruption, no matter how complex your data is. Very 
> clever idea.

We definitely like immutable :-)

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: Thanks for a great DConf

2014-05-28 Thread Brad Anderson via Digitalmars-d


On Wednesday, 28 May 2014 at 14:14:40 UTC, Dicebot wrote:


It was really funny to observe output of DFeed during the 
conference by the way - PR merges, issue comments and casual 
hacking have never stopped. I am somewhat surprised no one has 
managed to create a pull request right in the middle of own 
talk ;)


I remember looking over upon seeing DFeed announce Martin had 
merged a pull request and noticing he wasn't even at his computer 
and was instead off talking to people. I'd already suspected 
Kenji of actually being a group of developers operating under a 
single name so my conspiracy theory just widened. Turns out I had 
simply been trolled by auto-merge.

Re: OT: but maybe still interesting - runtime c++ compilation


On Wednesday, 28 May 2014 at 15:15:38 UTC, dennis luehring wrote:

Am 28.05.2014 16:32, schrieb Byron Heads:

Would love to have this for vibe.d


for what use case?


Diet templates

NEW COMPUTER THREAD (unlock*764%

2014-05-28 Thread sucka hater via Digitalmars-d


alpha(-beta 2589 J BETA



__charlie 898O^432

#143% igloo bega0r 13^* 985%2#$zero

Re: D affects others

2014-05-28 Thread Wanderer via Digitalmars-d

It's very hard to keep up-to-date with all these successors to 
Java. Every half a year a new language appears, and it's always 
"better than all previous". :-(


D's const feature is nice and clear. But what made me "fall in 
love" with D, is 'immutable' modifier. No inner mutable pieces 
possible, no need to copy defensively (or copy at all), no risk 
of data corruption, no matter how complex your data is. Very 
clever idea.

Re: std.benchmark

On Wed, 2014-05-28 at 15:54 +, Joakim via Digitalmars-d wrote:
[…]
> A google search turns up a long review thread a couple years ago:
> 
> http://forum.dlang.org/thread/mailman.73.1347916419.5162.digitalmar...@puremagic.com

A somewhat depressing thread.

> Looks like it was remanded for further fixes, it shows as a "work 
> in progress" in the review queue:
> 
> http://wiki.dlang.org/Review_Queue

Given there has been no activity in over 2 years, I guess it is deemed a
dead duck in it's current form/place.

Instead of wallowing in the backwaters of non-Phobosity, it should
become a module accessible independently via a DVCS (presumably Git),
and Dub? (though I will be using SCons) such that people can amend,
extend and send in pull requests.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: RedBlackTree thin wrapper initialization

2014-05-28 Thread Rene Zwanenburg via Digitalmars-d

On Wednesday, 28 May 2014 at 09:37:55 UTC, Edwin van Leeuwen 
wrote:
Thank you for the reply. Does this mean I should never 
initialize classes/objects like that or is it more specific to 
RBT?


It's the same for any class.


I guess structs have the same problem with classes/objects?


That's right.

That makes struct that hold objects quite awkward to use, since 
you can't define a default constructor for structs.


struct S
{
auto tree = new RedBlackTree!string();
}


There is a workaround for struct default construction. First let 
me describe the way D initialization works:


Every type, built in or user defined, has an init value. For ints 
this is 0, floats NaN, and so on. User defined types have their 
init value stored in the corresponding TypeInfo, for example [0], 
[1].


When initializing a value type the space is already reserved, 
either on the stack or on the heap inside a dynamic array. All 
the runtime does is memcpy the init value of that type to the 
right location.


When new-ing a class the GC first allocates some space on the 
heap. Then it copies the init value to that location, just like 
with a value type. Finally it calls a constructor on the newly 
allocated object.


When declaring a field in your struct or class and assign a 
default value to it, it ends up in the init value for your type. 
For example:


class C
{
  int i = uniform(0, 10); // Uniform random number
}

The generated random value will end up in C's init value and thus 
be the same for every instance. Generating the number in a 
constructor will of course result in a fresh random number for 
every instance.


The reason initialization works this way is, as I understand it, 
both safety and speed. The memcpy will never fail, so if you 
successfully allocated the space for something it will _always_ 
be properly initialized. And since the init value of everything 
is known at compile time the init values of composite types 
contain the init values of all contained fields. In other words, 
no matter how complex your type, it will always be initialized 
with a single memcpy.


Now, a workaround for struct default constructors is to use 
static opCall:


struct S
{
  int i;

  @disable this(); // Disable default initialization. See the 
comment in [1]


  private this(int i)
  {
this.i = i;
  }

  static auto opCall()
  {
return S(uniform(0, 10));
  }
}

void main()
{
  S s; // Should not compile. No init value for S
  auto s = S(); // Calls S.opCall
}

I hope my ramblings make it a bit more clear what is happening 
instead of confusing the hell out of you ;). I didn't try any of 
this code so there may be some typos.



[0]https://github.com/D-Programming-Language/druntime/blob/master/src/object_.d#L844
[1] 
https://github.com/D-Programming-Language/druntime/blob/master/src/object_.d#L1060

Re: Dev. Collaboration

On Tuesday, 27 May 2014 at 06:47:21 UTC, simendsjo wrote:

On 05/27/2014 02:12 AM, chuck wrote:
Would anyone be interested in a collaboration forum? I am
thinking of
starting one on Proboards to aid in development/collaboration
between
developers on D and libraries/bindings. Reading through the
posts, I
have seen that several people have created small projects that
do the
same thing (I have seen multiple for MySql alone, none of
which has

really gained true traction).

So here is what I propose:
1) The forum will be host different aspects of development
(Database/bindings, Phobos development, networking tools,
etc.).

2) Form dev. committees to fill the most useful tasks in the
group of
choice. For example, focusing on doing one thing quickly and
sustainably
rather than burning out creating a project alone that will be
difficult

to maintain afterwords.

3) This should help increase the number of code examples,
increasing the
visibility of D to anyone interested. Hopefully, this will
also increase

the community.

I think it's a great idea - DETF (D Engineering Task Force).
For this to succeed, I think connecting to existing
communication
channels is very important. This means NNTP/mailing list,
github,

auto-tester, dub, wiki (with DIPS) etc etc.
Setting up some new PHP forums will only split the community.

I like Andrej initiative much more
(http://forum.dlang.org/post/mailman.726.1400095941.2907.digitalmars-d-annou...@puremagic.com).
Self-organized smaller groups of developers focused on specific
domains of application.

Re: Optional arguments/parameters

2014-05-28 Thread Wanderer via Digitalmars-d


On Wednesday, 28 May 2014 at 13:01:52 UTC, bearophile wrote:

Wanderer:


Please tell me, does D support this feature?


You can answer by yourself similar questions online here:
http://dpaste.dzfl.pl/

Bye,
bearophile


Thanks! :-)

Re: Voldemort declarations inside structs with ctor initialization

2014-05-28 Thread Idan Arye via Digitalmars-d


On Wednesday, 28 May 2014 at 14:06:38 UTC, Meta wrote:
What I meant to say by "allocate a closure" is that variables 
in the stack frame that the delegate has a pointer to are moved 
to the heap when they go out of scope. I believe this implies 
GC allocation, but I'm not 100% sure. If that *were* the case, 
then you can see that marking the delegate as @nogc would mean 
that code such as your example would fail to compile.


They probably work that way in C++ and Java, but that's not how 
closures work in D. Take a look at the this example: 
http://dpaste.dzfl.pl/69c7298b5a12


If you try to run it `foo()` will print different values each 
time, but `bar()` will always print 0. The reason is that `bar` 
returns a delegate.


`foo` uses the standard call stack to conform to the C/++ ABI, 
but `bar` uses a different type of call stack - one that's 
implemented with a linked list. That way, when `bar` finishes, 
it's stack frame's memory will not get overwritten by the next 
function call, and the delegate can safely hold a pointer to it 
and use it directly.


Now, that doesn't mean there is no GCed memory allocations 
involved. The stack frame is allocated and GCed, and the delegate 
object itself is allocated and GCed. But at any rate - these 
things happen *before* the delegate is called, so the delegate 
itself is @nogc.


Also, take a look at `baz`. It prints a value for EBP, so it uses 
the C/C++ ABI, but it clearly uses a delegate with a "closure". 
I'm not sure if it can be called a closure, since it doesn't hold 
a pointer to the stack(it doesn't have to), but at any rate - its 
clear that it can't be body-hashed.



The lambdas in my example don't allocate any memory when you 
*run* them.


I'm not completely sure whether they will or they won't... But 
I'm pretty sure that this modified example will:


auto foo()
{
int a;

return () => is(typeof(a) : char);
}

void main()
{
writeln(foo()());
}


The example as a whole allocates memory, but the delegate itself 
doesn't. A memory is allocated for the delegate when it's 
created, but when you run the delegate no memory needs to be 
allocated so the delegate is @nogc.



At any rate, a delegate without a closure is either a 
`function`(which can be body-hashed without any problem) or a 
method(which doesn't need body-hashing), so having the @nogc 
restriction would be pointless even if @nogc prevented 
closures.


How is this restriction pointless if it means that delegates 
that couldn't be hashed before due to their context can now be 
hashed?


OK, I retract that statement. I did farther checking and it turns 
out that functions can also refer to the context as long as that 
reference is static. That means that the no-closure restriction 
can be useful, but it also means that the restriction must also 
be applied to function lambdas.

Re: std.benchmark

2014-05-28 Thread Joakim via Digitalmars-d

On Wednesday, 28 May 2014 at 15:44:22 UTC, Russel Winder via 
Digitalmars-d wrote:
Although I should have known about it long ago, I have only 
just become
aware of Andrei's std.benchmark, which appears in his fork of 
Phobos,
but not in real Phobos. Is there an intention it should be in 
Phobos, or

is it intended to be a separate thing?

For me a benchmark framework should be outputting means, 
standard
deviations, and degrees of freedom of the timing of the 
function under
test. However the documentation comments of the std.benchmark 
module in
Andrei's repository only talk about a time and a relationship 
between a
group of related tests. So for me what is there is a great 
start but not

enough to be really useful.

Is anyone working on this? Is there an intention to make this 
part of

Phobos?

Hopefully I am not blundering into a quagmire raising this.


A google search turns up a long review thread a couple years ago:

http://forum.dlang.org/thread/mailman.73.1347916419.5162.digitalmar...@puremagic.com

Looks like it was remanded for further fixes, it shows as a "work 
in progress" in the review queue:


http://wiki.dlang.org/Review_Queue

std.benchmark

Although I should have known about it long ago, I have only just become
aware of Andrei's std.benchmark, which appears in his fork of Phobos,
but not in real Phobos. Is there an intention it should be in Phobos, or
is it intended to be a separate thing?

For me a benchmark framework should be outputting means, standard
deviations, and degrees of freedom of the timing of the function under
test. However the documentation comments of the std.benchmark module in
Andrei's repository only talk about a time and a relationship between a
group of related tests. So for me what is there is a great start but not
enough to be really useful.

Is anyone working on this? Is there an intention to make this part of
Phobos?  

Hopefully I am not blundering into a quagmire raising this.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: Fixing More Warnings in DMD?

2014-05-28 Thread bearophile via Digitalmars-d


Dicebot:

I don't think it is worth spending too much time on it because 
of ongoing DDMD transition which will make many of those issues 
obsolete.


Some of those warnings are not generated by D compiler (like 
unused variables and labels, unused arguments, signed/unsigned 
comparisons, etc), so better to catch and fix them before porting 
the code to D.


Bye,
bearophile

Re: OT: but maybe still interesting - runtime c++ compilation

2014-05-28 Thread dennis luehring via Digitalmars-d


Am 28.05.2014 16:32, schrieb Byron Heads:

Would love to have this for vibe.d


for what use case?

Re: Fixing More Warnings in DMD?


On Monday, 26 May 2014 at 20:58:22 UTC, Nordlöw wrote:

I've recent fixed a few warnings in D here:

https://github.com/D-Programming-Language/dmd/pull/3543

At the end of the thread I asked:

Should I continue fixing GLUE, BACK and ROOT or focus on 
remaining warnings in DMD?


but Walter has not responded so I'm asking it here once again.

Comments anyone?


I don't think it is worth spending too much time on it because of 
ongoing DDMD transition which will make many of those issues 
obsolete.

Re: OT: but maybe still interesting - runtime c++ compilation

2014-05-28 Thread Byron Heads via Digitalmars-d


On 2014-05-28 10:22:07 +, dennis luehring said:

could be a nice next step for D if "D compiler as a library" comes 
someday available


http://runtimecompiledcplusplus.blogspot.co.uk/

from the blog:

Runtime Compiled C++ is in Kythera, the AI behind Star Citizen.

Video: RCC++ at the 2012 Develop Conference
http://vimeo.com/85934969

and it seems that the Crytek and Unreal Guys are also playing in this field


Would love to have this for vibe.d

Re: New pointer type for GC

Big language change which does not fix any fundamental issue. I 
think at stage of language development it is better to not even 
discuss those ;)

Re: Thanks for a great DConf

On Saturday, 24 May 2014 at 15:26:30 UTC, Joseph Rushton Wakeling 
via Digitalmars-d wrote:

Hello all,

Just to say a big thank you to everyone speaking and involved 
in the organization of DConf this year.  It was fantastic to be 
able to follow the conference via livestreaming (as much as 
timezones allowed:-), and the ideas and projects on display 
were full of excitement and inspiration.


Here's looking forward to another great year of D and even more 
exciting projects at next year's conference!


Best wishes,

-- Joe


Still can't believe I was there, feels like a dream :) Being able 
to corner Andrei and Walter and keep asking questions until you 
actually understand the answer is priceless. And Facebook has 
organized everything almost perfectly in my opinion, can't 
imagine any single thing that could have been done better.


It was really funny to observe output of DFeed during the 
conference by the way - PR merges, issue comments and casual 
hacking have never stopped. I am somewhat surprised no one has 
managed to create a pull request right in the middle of own talk 
;)

Re: Voldemort declarations inside structs with ctor initialization

2014-05-28 Thread Meta via Digitalmars-d


On Wednesday, 28 May 2014 at 06:20:29 UTC, Idan Arye wrote:
From what I know(don't know how it is implemented in D. I know 
it doesn't work that way in languages that emulate closures 
like C++ and Java) delegates don't "allocate a closure" - 
rather, they use a the callstack frame that was already 
allocated by the function as a closure. While it's true that 
they have to save a reference to that frame, there is no 
separately GCed memory for saving that reference - it's stored 
in the fat pointer together with the function pointer.


What I meant to say by "allocate a closure" is that variables in 
the stack frame that the delegate has a pointer to are moved to 
the heap when they go out of scope. I believe this implies GC 
allocation, but I'm not 100% sure. If that *were* the case, then 
you can see that marking the delegate as @nogc would mean that 
code such as your example would fail to compile.



The lambdas in my example don't allocate any memory when you 
*run* them.


I'm not completely sure whether they will or they won't... But 
I'm pretty sure that this modified example will:


auto foo()
{
int a;

return () => is(typeof(a) : char);
}

void main()
{
writeln(foo()());
}


At any rate, a delegate without a closure is either a 
`function`(which can be body-hashed without any problem) or a 
method(which doesn't need body-hashing), so having the @nogc 
restriction would be pointless even if @nogc prevented closures.


How is this restriction pointless if it means that delegates that 
couldn't be hashed before due to their context can now be hashed?

Re: Optional arguments/parameters

2014-05-28 Thread bearophile via Digitalmars-d


Wanderer:


Please tell me, does D support this feature?


You can answer by yourself similar questions online here:
http://dpaste.dzfl.pl/

Bye,
bearophile

Re: Optional arguments/parameters

2014-05-28 Thread Rene Zwanenburg via Digitalmars-d


On Wednesday, 28 May 2014 at 11:57:51 UTC, Namespace wrote:

On Wednesday, 28 May 2014 at 11:54:30 UTC, Wanderer wrote:
Java misses this feature badly, forcing programmers to 
copy-paste bloated code (constructor A calls constructor B 
with fewer arguments, constructor B calls constructor C etc, 
same thing with methods). Please tell me, does D support this 
feature?


int myNiceFunc(double a, double b=0, int c=0) {...}

auto n = myNiceFunc(100);


Default parameters? Of course. Every good language does that. :)


No named parameters though:


int myNiceFunc(double a, double b=0, int c=0) {...}

auto n = myNiceFunc(100, c: 5); // Doesn't work

Re: Optional arguments/parameters

2014-05-28 Thread Namespace via Digitalmars-d


On Wednesday, 28 May 2014 at 11:54:30 UTC, Wanderer wrote:
Java misses this feature badly, forcing programmers to 
copy-paste bloated code (constructor A calls constructor B with 
fewer arguments, constructor B calls constructor C etc, same 
thing with methods). Please tell me, does D support this 
feature?


int myNiceFunc(double a, double b=0, int c=0) {...}

auto n = myNiceFunc(100);


Default parameters? Of course. Every good language does that. :)

Optional arguments/parameters

2014-05-28 Thread Wanderer via Digitalmars-d

Java misses this feature badly, forcing programmers to copy-paste 
bloated code (constructor A calls constructor B with fewer 
arguments, constructor B calls constructor C etc, same thing with 
methods). Please tell me, does D support this feature?


int myNiceFunc(double a, double b=0, int c=0) {...}

auto n = myNiceFunc(100);

Re: std.stream replacement

2014-05-28 Thread Tero via Digitalmars-d

While waiting for the new stream I wrote myself a stream for file 
io only.

http://dpaste.dzfl.pl/bc470f96b357

Hope it helps your work somehow. Maybe at least the unittests are 
helpful?

Re: OT: but maybe still interesting - runtime c++ compilation

2014-05-28 Thread dennis luehring via Digitalmars-d


example from a simulation project

a runtime-configured (0-6)-axis cinematics system able to bring axis to 
an given position or calculates back to axis positions for simulation 
purpose


so the interface is target/current-reached-position and axis.positions

currently done by using virtuals, can maybe optimized further - but 
definitily not at compile-time

OT: but maybe still interesting - runtime c++ compilation

2014-05-28 Thread dennis luehring via Digitalmars-d

could be a nice next step for D if "D compiler as a library" comes 
someday available


http://runtimecompiledcplusplus.blogspot.co.uk/

from the blog:

Runtime Compiled C++ is in Kythera, the AI behind Star Citizen.

Video: RCC++ at the 2012 Develop Conference
http://vimeo.com/85934969

and it seems that the Crytek and Unreal Guys are also playing in this field

Re: New opportunities for D => ASM.js

2014-05-28 Thread Joakim via Digitalmars-d

On Friday, 16 May 2014 at 19:28:26 UTC, H. S. Teoh via 
Digitalmars-d wrote:
On Fri, May 16, 2014 at 02:52:43PM -0400, Nick Sabalausky via 
Digitalmars-d wrote:

But then using it as a GUI engine and software platform is like
abusing Latex or PDF to make software run inside Acrobat 
Viewer. All

the effort, bloat and compromises...and for what point?


No software is feature-complete until it can read email. :-)

Today I skimmed over the PDF spec... and was horrified to 
discover that
I had been living in a fool's paradise, thinking that it was 
only a
passive *document* format. Turns out that it is yet another of 
those
document format turned Turing-complete messes. With its own 
embedded

flavor of Javascript, even. (And obviously, it's gratuitously
incompatible with "standard" JS). With the ability to attach 
files.
(Huh, what?! I thought PDF was *the* attachment... nope, not 
only it can
contain executable JS code, which is just a repetition of that 
security
nightmare that is Outlook + ActiveX, it can also encapsulate an 
entire
directory structure within itself. Yep. No bloatware here, move 
along.)

PDFs can also embed *movies*. (!!!)

So basically, you can create an entire interactive website 
inside a
single PDF file, complete with scripting, movies, embedded 
subfiles
(basically a self-contained directory structure aka URL tree). 
It would
utterly suck, of course, given that probably only crappy Adobe 
bloatware
would be able to interpret the resulting mess. But you could do 
it. And
obviously somebody *has* done it, since otherwise where did all 
these
features come from? One of these days, somebody's gonna 
reinvent the

browser inside a PDF file...
Heh, this recently came up in a good article about how broken 
software security is:


https://medium.com/message/81e5f33a24e1#493c-7acd71bf4c69

Re: RedBlackTree thin wrapper initialization

2014-05-28 Thread Chris via Digitalmars-d


On Wednesday, 28 May 2014 at 08:49:42 UTC, Rene Zwanenburg wrote:

On Wednesday, 28 May 2014 at 08:37:14 UTC, Chris wrote:

On Wednesday, 28 May 2014 at 07:13:37 UTC, BlackEdder wrote:
I'm trying to write a thin wrapper around redblacktree, but 
it seems every object of the class shares the same copy of 
redblacktree. Am I doing something wrong or is this a bug.


Minimal code example:

import std.array;
import std.container;
import std.stdio;

class A {
  auto tree = new RedBlackTree!string();
}

unittest {
  auto a = new A();
  a.tree.insert( "a" );
  auto b = new A();
  writeln( "Should be empty, but is: ", b.tree.array );
  writeln( "Should be empty, but has length: ", b.tree.length 
);

}

Which results in the following output:
$ rdmd -unittest rbt.d
Should be empty, but is: ["a"]
Should be empty, but has length: 1


I'm using dmd 2.0.65.


Have you tried

class A {
 RedBlackTree!(string) tree;
 this() {
   tree = new RedBlackTree!string();
 }
}

Maybe in your implementation all instances of class A share 
the same underlying instance RedBlackTree, or class 
RedBlackTree was designed as a singleton (which would seem odd 
to me).


PS This question would be better suited for the "D learn" 
forum.


Ninja'd ;)

Also, if you want to avoid repeating long type names an alias 
can help:


class A
{
  alias TreeType = RedBlackTree!string;

  TreeType tree;

  // etc etc.
}

In this case it isn't too bad but some template instantiations 
can get fairly long.


Tell me about it, I'm in the process of alias'ing my template 
types, cos I've really long type instantiations now like


type = Type!(Type2!(Type3!(int, string), string))();

Re: RedBlackTree thin wrapper initialization

2014-05-28 Thread Edwin van Leeuwen via Digitalmars-d


On Wednesday, 28 May 2014 at 08:46:30 UTC, Rene Zwanenburg wrote:


The problem is the initialization of A.tree. Short answer, move 
it to a constructor and it should work.


Now what I think is going on: default values for member fields 
must be known at compile time. This is why structs can do 
something like


struct S
{
  int i = 5;
}

while they're not allowed to define a default constructor.

So it appears the tree is instantiated at compile time and 
stored somewhere, and the reference to that instance is used as 
the default value for A.tree. I didn't know this was possible 
to do with reference type members, and perhaps it should be 
disallowed. This is highly counter intuitive behavior esp. for 
people coming from Java.


Thank you for the reply. Does this mean I should never initialize 
classes/objects like that or is it more specific to RBT?


I guess structs have the same problem with classes/objects? That 
makes struct that hold objects quite awkward to use, since you 
can't define a default constructor for structs.


struct S
{
auto tree = new RedBlackTree!string();
}



PS Sorry for not posting this to the learn forum.

Re: Dev. Collaboration

2014-05-28 Thread Dejan Lekic via Digitalmars-d


On Tuesday, 27 May 2014 at 00:12:59 UTC, chuck wrote:
Would anyone be interested in a collaboration forum? I am 
thinking of starting one on Proboards to aid in 
development/collaboration between developers on D and 
libraries/bindings. Reading through the posts, I have seen that 
several people have created small projects that do the same 
thing (I have seen multiple for MySql alone, none of which has 
really gained true traction).


So here is what I propose:
1) The forum will be host different aspects of development 
(Database/bindings, Phobos development, networking tools, etc.).


2) Form dev. committees to fill the most useful tasks in the 
group of choice. For example, focusing on doing one thing 
quickly and sustainably rather than burning out creating a 
project alone that will be difficult to maintain afterwords.


3) This should help increase the number of code examples, 
increasing the visibility of D to anyone interested. Hopefully, 
this will also increase the community.


Did you for a second think about possibility that 
http://forum.dlang.org admins will help and create discussion 
groups for this purpose HERE, on THIS very forum!? Having another 
forum is a BAD idea, and it will probably fail. Nobody wants to 
deal with zillion forums. One is enough.

Re: D Language Version 3

2014-05-28 Thread Dejan Lekic via Digitalmars-d

On Wednesday, 28 May 2014 at 03:25:28 UTC, Suminda Dharmasena 
wrote:

Hi,

D2 has been out for a while. Looking to see what the roadmap is 
like towards D3?


Suminda


FYI there is no stable version of D2. There are still many grey
areas and there are yet to come possible radical changes to come
(like final-by-default for an example).

However, it may be a good idea to have a list of things that are
commonly postponed for D3 ocassionally. You are free to go
through NG threads, and compile this list. We have
http://wiki.dlang.org - perfect place for that.

Re: RedBlackTree thin wrapper initialization

2014-05-28 Thread Rene Zwanenburg via Digitalmars-d


On Wednesday, 28 May 2014 at 08:37:14 UTC, Chris wrote:

On Wednesday, 28 May 2014 at 07:13:37 UTC, BlackEdder wrote:
I'm trying to write a thin wrapper around redblacktree, but it 
seems every object of the class shares the same copy of 
redblacktree. Am I doing something wrong or is this a bug.


Minimal code example:

import std.array;
import std.container;
import std.stdio;

class A {
   auto tree = new RedBlackTree!string();
}

unittest {
   auto a = new A();
   a.tree.insert( "a" );
   auto b = new A();
   writeln( "Should be empty, but is: ", b.tree.array );
   writeln( "Should be empty, but has length: ", b.tree.length 
);

}

Which results in the following output:
$ rdmd -unittest rbt.d
Should be empty, but is: ["a"]
Should be empty, but has length: 1


I'm using dmd 2.0.65.


Have you tried

class A {
  RedBlackTree!(string) tree;
  this() {
tree = new RedBlackTree!string();
  }
}

Maybe in your implementation all instances of class A share the 
same underlying instance RedBlackTree, or class RedBlackTree 
was designed as a singleton (which would seem odd to me).


PS This question would be better suited for the "D learn" forum.


Ninja'd ;)

Also, if you want to avoid repeating long type names an alias can 
help:


class A
{
  alias TreeType = RedBlackTree!string;

  TreeType tree;

  // etc etc.
}

In this case it isn't too bad but some template instantiations 
can get fairly long.

Re: RedBlackTree thin wrapper initialization

2014-05-28 Thread Rene Zwanenburg via Digitalmars-d


On Wednesday, 28 May 2014 at 07:13:37 UTC, BlackEdder wrote:
I'm trying to write a thin wrapper around redblacktree, but it 
seems every object of the class shares the same copy of 
redblacktree. Am I doing something wrong or is this a bug.


Minimal code example:

import std.array;
import std.container;
import std.stdio;

class A {
auto tree = new RedBlackTree!string();
}

unittest {
auto a = new A();
a.tree.insert( "a" );
auto b = new A();
writeln( "Should be empty, but is: ", b.tree.array );
writeln( "Should be empty, but has length: ", b.tree.length 
);

}

Which results in the following output:
$ rdmd -unittest rbt.d
Should be empty, but is: ["a"]
Should be empty, but has length: 1


I'm using dmd 2.0.65.


The problem is the initialization of A.tree. Short answer, move 
it to a constructor and it should work.


Now what I think is going on: default values for member fields 
must be known at compile time. This is why structs can do 
something like


struct S
{
  int i = 5;
}

while they're not allowed to define a default constructor.

So it appears the tree is instantiated at compile time and stored 
somewhere, and the reference to that instance is used as the 
default value for A.tree. I didn't know this was possible to do 
with reference type members, and perhaps it should be disallowed. 
This is highly counter intuitive behavior esp. for people coming 
from Java.

D affects others