Re: The liabilities of binding rvalues to ref

[Jonathan M Davis]

On Sunday, May 05, 2013 01:49:42 Andrei Alexandrescu wrote:
> There may be other important patterns to address at the core, please
> chime in. I consider (1) above easy to tackle, which leaves us with at
> least (2). My opinion is that any proposal for binding rvalues to ref
> must offer a compelling story about these patterns.

Another case is when you want to distinguish between lvalues and rvalues.  In 
fact, IIRC this came up in Ali's dconf talk. He had an opAssign which swapped 
guts with its argument when it was an rvalue (since it was known to be a 
temporary) and did a more normal assignment when it was an lvalue. You might 
still be able to do that if ref accepts rvalues (because the non-ref overload 
would be preferred in the rvalue case, and the ref overload would be preferred 
in the lvalue case), but I suspect that that would be incredibly error-prone - 
especially when there are multiple arguments to the function.

So, whatever solution we go with needs to allow us to reasonably overload on 
refness when we want to while still being able to have functions which accept 
both lvalues and rvalues by reference.

- Jonathan M Davis

Re: Rvalue references - The resolution

[Jonathan M Davis]

On Sunday, May 05, 2013 06:10:34 David Nadlinger wrote:
> On Sunday, 5 May 2013 at 02:36:45 UTC, Jonathan M Davis wrote:
> > Don was complaining that one reason that moving
> > to D2 at Sociomantic looks unappealing in spite of the benefits
> > is the fact
> > that they're going to have to add so many extra annotations to
> > their code.
> 
> When did he mention that?

It was during dinner Friday night when he and Manu were discussing stuff in D 
that was problematic for companies like the ones that they work for. You were 
far enough down the table that you wouldn't have heard.

> If I had noticed, I would have been
> interested in a closer rationale, as D2's extra annotations are
> pretty much opt-in only, even more so if you are using your own
> library anyway.

True, they're opt-in, but it's also true that we generally consider it good 
style to use them as much as possible, which tends to mean using them all over 
the place - to the point that it starts seeming very odd that @safe and pure 
aren't the default, particularly when @system code is generally supposed to be 
the minority of your program, and very few functions should need to access 
global state. The two reasons that they don't get used way more in Phobos is 
because it uses templates so heavily, and because some basic stuff that gets 
used all over the place isn't pure yet even though it's supposed to be.

I'm sure that Don could answer about his concerns better than I could, but I 
think that it pretty much came down to the fact that D2 had a bunch of new 
attributes that they then had to worry about, many of which more or less only 
provide theoretical benefits which may or may not materialize at some point in 
the future.

For instance, optimizations with pure don't really happen all that often. 
There just aren't enough cases where the arguments are immutable (or 
implicitly convertible to immutable) for it to apply frequently, and IIRC, 
optimizations are only applied within the same statement, meaning that when 
they _are_ applied, they don't generally remove many function calls. The 
compiler doesn't even try and optimize across multiple lines within the same 
function (since that would require flow analysis) let alone memoize the result 
(which it probably shouldn't be doing anyway, since that would require storing 
the result somewhere, but it's the sort of thing that people often think of 
with pure).

Now, I argued that pure's primary benefit isn't really in optimizations but 
rather in the fact that it guarantees that your code isn't accessing global 
state, but there's still the general concern that there's a lot of new 
attributes to worry about, whether you choose to use them or not. I don't 
think that it was a deal-breaker for Don or anything like that, but it was one 
of his concerns and one more item on the list of things that makes it more 
costly for them to move to D2, even if it alone doesn't necessarily add a huge 
cost.

- Jonathan M Davis

Re: Rvalue references - The resolution

[Tove]

On Sunday, 5 May 2013 at 07:22:06 UTC, Jonathan M Davis wrote:
Now, I argued that pure's primary benefit isn't really in 
optimizations but
rather in the fact that it guarantees that your code isn't 
accessing global
state, but there's still the general concern that there's a lot 
of new
attributes to worry about, whether you choose to use them or 
not. I don't
think that it was a deal-breaker for Don or anything like that, 
but it was one
of his concerns and one more item on the list of things that 
makes it more
costly for them to move to D2, even if it alone doesn't 
necessarily add a huge

cost.

- Jonathan M Davis


Assuming:
1. functioning attribute inference
2. attributes are expanded in the *.di file

Then, it would be trivial to create a tool which, upon request, 
merges "a defined set of attributes" back to the original d 
source file, this would reduce some of the burden and with full 
IDE integration even more so.

Re: Rvalue references - The resolution

[Jacob Carlborg]

On 2013-05-04 20:33, Walter Bright wrote:


These checks would be omitted if the -noboundscheck compiler switch was 
provided.


Perhaps a new flag for this.

--
/Jacob Carlborg

Re: Rvalue references - The resolution

[Dicebot]

On Sunday, 5 May 2013 at 09:26:54 UTC, Jacob Carlborg wrote:

On 2013-05-04 20:33, Walter Bright wrote:

These checks would be omitted if the -noboundscheck compiler 
switch was provided.


Perhaps a new flag for this.


Or just rename it in more general -noruntimesafetychecks

Welcome home from dconf

[Iain Buclaw]

Well,  I'm back home safely and I hope everyone else at dconf had 
a pleasant journey home.


To follow up on a point I made during one of the many discussions 
and debates at aloft, I think it's great that this has sparked 
many mini projects in full speed ahead - auto tester integration 
with gdc/ldc;  migrating D front end to D.   However we don't 
need a conference to get this sort of burst of activity of going. 
 And I imagine with some efforts (migrating D front end,  for 
instance) will require more discussions outside of the ML to keep 
it moving and iron out issues that can't be resolved through the 
ML.


For this I am available on Skype, and would be willing to show up 
in any conference calls (monthly, or quarterly) to keep this 
effort, and others going.


Thoughts?


Regards
Iain.

Re: The liabilities of binding rvalues to ref

[Peter Alexander]

Is there any intention to address the issue of the lvalue-ness of 
"this"? In C++, *this is always an lvalue, even if the member 
function was called with an rvalue, leading to situations like 
this:


struct Number
{
void fix() { if (isnan(x)) x = 0; }
double x;
}

class Collection(T) {
  ref T opIndex(size_t i) { ... }
  ...
}

void fixAll(Collection!Number c) {
  foreach (i; 0 .. c.length) {
c[i].fix();
  }
}


Here, if Collection changes to return by non-ref then the fix() 
call is still valid, silently doing nothing of value. Analogous 
code in C++ is allowed as well.


Do we intend to fix this as well? I suspect there are use cases 
where such calls are useful, but I can't think of any right now.

Re: Rvalue references - The resolution

[Michel Fortin]

On 2013-05-04 18:33:10 +, Walter Bright  said:


Runtime Detection

There are still a few cases that the compiler cannot statically detect. 
For these a runtime check is inserted, which compares the returned ref 
pointer to see if it lies within the stack frame of the exiting 
function, and if it does, halts the program. The cost will be a couple 
of CMP instructions and an LEA. These checks would be omitted if the 
-noboundscheck compiler switch was provided.


I just want to note that this has the effect of making any kind of heap 
allocation not done by the GC unsafe. For instance, if you have a 
container struct that allocates using malloc/realloc and that container 
gives access to its elements by reference then you're screwed (it can't 
be detected).


The obvious answer is to not make @trusted the function returning a 
reference or a slice to malloced memory. But I remember Andrei wanting 
to make standard containers of this sort at one point, so I think it's 
important to note this limitation.


--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/

Re: The liabilities of binding rvalues to ref

[Timon Gehr]

On 05/05/2013 07:49 AM, Andrei Alexandrescu wrote:

...

There may be other important patterns to address at the core, please
chime in. I consider (1) above easy to tackle, which leaves us with at
least (2). My opinion is that any proposal for binding rvalues to ref
must offer a compelling story about these patterns.
...


Any solution that allows both lvalues and rvalues to bind to the same 
reference will have problem (2), and fixing up problem (1) introduces 
somewhat arbitrary rules. Probably we do not want to have to deal with 
them by default.


A possibility would be to fix (2) in a similar way to the proposed 
solution for (1): Only allow rvalues to bind to 'ref' if they cannot be 
turned into lvalues by changing the signature of a different function. I 
don't like this solution very much.


I still think auto ref should be extended to work for non-templated 
functions. The semantics should be the same (i.e. behave as if there 
were two copies that are eagerly semantically analyzed, but only 
generate code for one) where possible. It would be an error to have 
different behaviour of the two "copies". This would mean that in 
non-templated functions, it should be an error to rely on whether or not 
the passed argument was an lvalue. i.e. (auto) ref return of an auto ref 
argument (at least in @safe code) and __traits(isRef,autoRefArgument) 
should be disallowed. This would have the effect of making it illegal to 
return references to temporaries from functions (at least in @safe 
code), and hence the life time of rvalues would not have to be changed.


Both (1) and (2) would be close to non-issues with this solution.

Re: The liabilities of binding rvalues to ref

[Timon Gehr]

On 05/05/2013 01:55 PM, Timon Gehr wrote:

On 05/05/2013 07:49 AM, Andrei Alexandrescu wrote:

...

There may be other important patterns to address at the core, please
chime in. I consider (1) above easy to tackle, which leaves us with at
least (2). My opinion is that any proposal for binding rvalues to ref
must offer a compelling story about these patterns.
...


Any solution that allows both lvalues and rvalues to bind to the same
reference will have problem (2), and fixing up problem (1) introduces
somewhat arbitrary rules. Probably we do not want to have to deal with
them by default.

A possibility would be to fix (2) in a similar way to the proposed
solution for (1): Only allow rvalues to bind to 'ref' if they cannot be
turned into lvalues by changing the signature of a different function. I
don't like this solution very much.

I still think auto ref should be extended to work for non-templated
functions. The semantics should be the same (i.e. behave as if there
were two copies that are eagerly semantically analyzed, but only
generate code for one) where possible. It would be an error to have
different behaviour of the two "copies". This would mean that in
non-templated functions, it should be an error to rely on whether or not
the passed argument was an lvalue. i.e. (auto) ref return of an auto ref
argument (at least in @safe code) and __traits(isRef,autoRefArgument)
should be disallowed. This would have the effect of making it illegal to
return references to temporaries from functions (at least in @safe
code), and hence the life time of rvalues would not have to be changed.

Both (1) and (2) would be close to non-issues with this solution.


It seems to make sense that template function instantiations should be 
split into two copies per auto ref argument only if it is necessary to 
support differing semantics for lvalues and rvalues.


Peter Alexander brings up a good point regarding the implicit this 
reference for structs. Probably it should be passed by auto ref.

Re: The liabilities of binding rvalues to ref

[Peter Alexander]

On Sunday, 5 May 2013 at 11:55:28 UTC, Timon Gehr wrote:
I still think auto ref should be extended to work for 
non-templated functions. The semantics should be the same (i.e. 
behave as if there were two copies that are eagerly 
semantically analyzed, but only generate code for one) where 
possible.


This is not the case currently for template auto ref functions. 
For example, the two "versions" of the auto ref function do not 
share local static variables, nor do they have the same function 
address. They are literally two (or four, or eight, ...) separate 
functions. I really dislike how they have been implemented.

Re: The liabilities of binding rvalues to ref

[Timon Gehr]

On 05/05/2013 01:55 PM, Timon Gehr wrote:

...It would be an error to have
different behaviour of the two "copies". This would mean that in
non-templated functions, it should be an error to rely on whether or not
the passed argument was an lvalue. i.e. (auto) ref return of an auto ref
argument (at least in @safe code) and __traits(isRef,autoRefArgument)
should be disallowed. ...


It also would need to be an error to have local static variables.

Re: The liabilities of binding rvalues to ref

[Timon Gehr]

On 05/05/2013 02:11 PM, Peter Alexander wrote:

On Sunday, 5 May 2013 at 11:55:28 UTC, Timon Gehr wrote:

I still think auto ref should be extended to work for non-templated
functions. The semantics should be the same (i.e. behave as if there
were two copies that are eagerly semantically analyzed, but only
generate code for one) where possible.


This is not the case currently for template auto ref functions. For
example, the two "versions" of the auto ref function do not share local
static variables, nor do they have the same function address.


Very good point about the local static variables. This would be a wart 
of my proposed solution, as they'd need to be banned for auto ref functions.



They are literally two (or four, or eight, ...) separate functions. I really
dislike how they have been implemented.



Me too, but it makes sense to have two functions in some cases.

Migrating D front end to D - post Dconf

[Iain Buclaw]

Daniel and/or David,

We should list down in writing the issues preventing DMD, GDC, 
and LDC having a shared code base.  From what David has shown me, 
LDC will need the most work for this, but I'll list down what I 
can remember.


1. Support extern(C++) classes so can have a split C++/D 
implementation of eg: Expression and others.


2. Support representing integers and floats to a greater 
precision than what the host can natively support. In D there's 
BigInt for integral types, and there's a possibility of using 
std.numeric for floats.  For me, painless conversion between eg: 
BigInt <-> GCC's double_int is a requirement, but that is more of 
an after thought at this point in time.


3. Array ops should be moved out of the front end. The back end 
can deal with emitting the correct Libcall if required.


4. Continue building upon Target to hide target-specific things 
from the front end.  Off the top of my head I've got two to raise 
pulls for: __VENDOR__ and retrieving memalignsize for fields.


5. DMD sends messages to stdout, GDC sends to stderr.  Just a 
small implementation detail, but worth noting where 
'printf'appears, it's almost always rewritten as fprintf(stderr) 
for GDC.


6. LDC does not implement toObjFile, toCtype, toDt, toIR, 
possibly others...


7. BUILTINxxx could be moved into Target, as there is no reason 
why each back end can't support their own builtins for the 
purpose of CTFE.


8. D front end's port.h can't be used by GDC because of 
dependency  on mars.h, this could perhaps be replaced by 
std.numeric post conversion.


9. Opaque declarations of back end types defined in front end 
differ for each compiler implementation.  Eg: elem is a typedef 
to union tree_node.


10. The main function in mars.c is not used by GDC, possibly LDC 
also.  Another implementation detail but also a note to maybe 
split out errorSuplimental and others from that file.


11. The function genCfunc does not generate the arguments of the 
extern(C) symbol.


12. LDC adds extra reserved version identifiers that are not 
allowed to be declared in D code.  This could and probably should 
be merged into D front end. Don't think it would be wise to let 
back end's have the ability to add their own.  Also this list 
needs updating regardless to reflect the documented spec.


13. LDC makes some more arbitrary changes to which the reason for 
the change has been forgotten. Get on it David!  :o)


14. Reading sources asynchronously, GDC ifdefs this out.  Do we 
really need this?  I seem to recall that the speed increase is 
either negliegable or offers no benefit to compilation speed.


15. Deal with all C++ -> D conversion

Re: Migrating D front end to D - post Dconf

[Iain Buclaw]

On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:

15. Deal with all C++ -> D conversion


15. Deal with all C++ -> D conversion issues (see all DDMD marked 
pull requests).


16. Testing the C++ -> D front end conversion on Linux.   Daniel 
you can send me the sources to test that if getting a Linux box 
is a problem for you.



Anything else I missed?

Oh, perhaps licensing issues.  I know the C++ sources for the D 
front end have been assigned to the FSF by Walter,  I think the 
conversion to D is enough change to warrant reassignment.



1, 2, 3,  get destroying...

Regards
Iain.

Re: Migrating D front end to D - post Dconf

[David Nadlinger]

On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
13. LDC makes some more arbitrary changes to which the reason 
for the change has been forgotten. Get on it David!  :o)


This applies only to a small part of the changes. The larger 
share of them will actually need adaption of the upstream 
frontend sources for a very good reason if we want to have a 
truly shared codebase.


As for the size of the diff, don't forget that LDC doesn't enjoy 
the luxury of having IN_LLVM sections in the upstream source – 
the difference in amount of changes actually isn't that large:


---
$ fgrep -rI IN_GCC dmd/src | wc -l
49

$ fgrep -rI IN_LLVM ldc/dmd2 | wc -l
57
---

David

Re: Migrating D front end to D - post Dconf

[David Nadlinger]

On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
12. LDC adds extra reserved version identifiers that are not 
allowed to be declared in D code.  This could and probably 
should be merged into D front end. Don't think it would be wise 
to let back end's have the ability to add their own.  Also this 
list needs updating regardless to reflect the documented spec.


I think we should just add the full list from 
http://dlang.org/version.html. This would also resolve the issue 
for LDC.


David

Re: Migrating D front end to D - post Dconf

[Iain Buclaw]

On May 5, 2013 3:30 PM, "David Nadlinger"  wrote:
>
> On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
>>
>> 13. LDC makes some more arbitrary changes to which the reason for the
change has been forgotten. Get on it David!  :o)
>
>
> This applies only to a small part of the changes. The larger share of
them will actually need adaption of the upstream frontend sources for a
very good reason if we want to have a truly shared codebase.
>
> As for the size of the diff, don't forget that LDC doesn't enjoy the
luxury of having IN_LLVM sections in the upstream source – the difference
in amount of changes actually isn't that large:
>
> ---
> $ fgrep -rI IN_GCC dmd/src | wc -l
> 49
>
> $ fgrep -rI IN_LLVM ldc/dmd2 | wc -l
> 57
> ---
>
> David

Indeed, but I was thinking of changes that aren't ifdef 'd.  I'm sure I saw
a few...

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Rvalue references - The resolution

[deadalnix]

On Sunday, 5 May 2013 at 00:47:00 UTC, Walter Bright wrote:
If the compiler accepts that code, it will crash at runtime. If 
it doesn't accept that code, then it will also disallow 
legitimate code like:


 ref T foob(ref U u) { static T t; return t; }

 ref T bar() { U u; return foob(u); }



It doesn't accept it, with or without any combination of 
annotation. Now, the example with a static effectively require an 
annotation.



And it illustrate
wonderfully what I'm saying : most people in the discussion 
(and it has been
shown now that this includes you) were unaware of how does 
Rust solve the problem.


I don't think excluding a solution that isn't understood is 
the smartest thing

to do.


I suggest you enumerate the cases with a Rust-like system and 
show us how it solves the problem without annotations. Note 
that Rust has pretty much zero real world usage - it's one 
thing to say needing to use annotations is 'rare' and another 
to know it based on typical usage patterns of the language.




Rust assume, when no annotation is present, that the return ref's 
lifetime is the union of ref parameters lifetime. I'm sure we can 
find an example of D code somewhere that don't fit into this, but 
real world usage in D would almost never require any annotation 
(this is the case of all D codebase I've played with as of now, 
and I don't actually see any use case for example like the static 
one mentioned above).


For example, if the default is "assume the ref return refers to 
the ref parameter", then some containers would require the 
annotation and some would not. This is not very viable when 
doing generic coding, unless you are willing to provide two 
copies of each such function - one with the annotations and the 
other without.




The default can't be that as several parameters can be passed by 
ref. The default is return ref lifetime is the union of ref 
parameters lifetime. I don't see any container that require the 
annotation.


Note also that if you have A calls B calls C, the annotation on 
C doesn't propagate up to B, again leading to a situation where 
you're forced to make two versions of the functions.


(I say doesn't propagate because in a language that supports 
separate compilation, all the compiler knows about a function 
is its signature.)


It doesn't require code duplication. Named lifetime make sense 
for the caller, not the callee (in which they only are identifier 
that can be used to describe lifetime's relation explicitly for 
the caller).

Re: The liabilities of binding rvalues to ref

[deadalnix]

On Sunday, 5 May 2013 at 05:49:42 UTC, Andrei Alexandrescu wrote:
There may be other important patterns to address at the core, 
please chime in. I consider (1) above easy to tackle, which 
leaves us with at least (2). My opinion is that any proposal 
for binding rvalues to ref must offer a compelling story about 
these patterns.




Yes ! With optional parenthesis, it is super unclear if we access 
an lvalue or an rvalue and update its content or not.


A good example of that is the captures property from std.regex. 
The property is an revalue, and would look like a filed that 
reset itself all the time if bound to an lvalue.

Re: DConf 2013 last talk

[deadalnix]

On Sunday, 5 May 2013 at 01:55:36 UTC, bearophile wrote:

Jonathan M Davis:


So, it's
probably only a matter of time before we have a more precise 
garbage collector
in druntime (which will seriously reduce the false pointers 
problem, though I

can't remember if it completely eliminates it).


Probably it doesn't use things like a shadow stack, so it 
doesn't trace stack pointers well. So probably it's not fully 
precise.




It is conservative with stack and unions. So it isn't fully 
precise. I do think the tradeoff that is made here is the right 
one.

Re: The liabilities of binding rvalues to ref

[deadalnix]

I wish to add to the discussion that you want to pass by ref for 
2 reasons (and the intent is very different) :
 - You intend to modify the value in some meaningful way for the 
caller. In which case, binding to rvalue don't make any sense.
 - You want to avoid creating copies, when this isn't necessary. 
In this case, this is a performance reason, and binding to rvalue 
make sense.


Note that knowing when to pass by value or by reference for 
performance is more tricky than many people tend to think. The 
reason is simple : you win an indirection, so if the data are 
small enough, and especially is the ABI say they are passed via 
registers, this is a win to pass by value. Many C++ dev will tell 
you that this is faster, but the fact is that C++ compiler can 
transform pass by ref into pass by value when it speedup things. 
It is especially hard problem to solve in generic code.


Here is to state the problem. Now let's discuss solutions.

As shown before the problem is about performance? And when it 
come to performance, the first thing we should look for is to 
allow the optimizer to kick in. The first change I'd propose is 
to allow the compiler to optimize away all pure copy operation 
(which include memory allocation). I don't know how far we can go 
with that, but that is IMO the first direction we should explore.


It is simpler for the dev, less error prone, will improve all 
programs, and do not require any new feature.


I'm well aware that the famous sufficiently smart compiler may 
lurk here, and so we may need to come back on the issue later if 
that approach fail. It is still worth trying.

Re: The liabilities of binding rvalues to ref

[Dicebot]

Few additional points:

On Sunday, 5 May 2013 at 16:07:12 UTC, deadalnix wrote:
I wish to add to the discussion that you want to pass by ref 
for 2 reasons (and the intent is very different) :
 - You intend to modify the value in some meaningful way for 
the caller. In which case, binding to rvalue don't make any 
sense.


You may want to modify rvalue temporary for implementing some 
sort of move semantics like in C++11.


 - You want to avoid creating copies, when this isn't 
necessary. In this case, this is a performance reason, and 
binding to rvalue make sense.


Not necessarily performance reason on its own, copy construction 
of given object may have an undesired side effects. Or it may be 
even some singleton'ish object.

Re: Migrating D front end to D - post Dconf

[Luís.Marques]

On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
1. Support extern(C++) classes so can have a split C++/D 
implementation of eg: Expression and others.


I don't know if this will be in the videos, so I'll ask here. I 
thought extern(C++) only supported interfaces because everything 
else fell into the "we'd need to pretty much include a C++ 
compiler into D to support that" camp. Is that not quite true for 
classes? Did you find some compromise between usefulness and 
complexity that wasn't obvious before, or did the D compiler 
transition just motivate adding some additional complexity that 
previously wasn't deemed acceptable?

Re: The liabilities of binding rvalues to ref

[deadalnix]

On Sunday, 5 May 2013 at 16:14:01 UTC, Dicebot wrote:

Few additional points:

On Sunday, 5 May 2013 at 16:07:12 UTC, deadalnix wrote:
I wish to add to the discussion that you want to pass by ref 
for 2 reasons (and the intent is very different) :
- You intend to modify the value in some meaningful way for 
the caller. In which case, binding to rvalue don't make any 
sense.


You may want to modify rvalue temporary for implementing some 
sort of move semantics like in C++11.




No, you won't be able to reach any of this anyway. Move semantic 
is already cleanly implemented in D, so the C++ mess is 
irrelevant here.


- You want to avoid creating copies, when this isn't 
necessary. In this case, this is a performance reason, and 
binding to rvalue make sense.


Not necessarily performance reason on its own, copy 
construction of given object may have an undesired side 
effects. Or it may be even some singleton'ish object.


Having a singleton as a value type, and not marking the postblit 
as @disable is asking for trouble in general, nothing specific to 
the discussion here.

Re: About typequalifier and generic containers.

[Luís.Marques]

On Sunday, 5 May 2013 at 16:32:37 UTC, deadalnix wrote:

Foo!T do not with Foo!const(T), and for good reasons.


Can you give me an overview of those reasons, please?

Re: Migrating D front end to D - post Dconf

[Iain Buclaw]

On May 5, 2013 5:20 PM, ""@puremagic.com"
<"\"Luís".Marques"> wrote:
>
> On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
>>
>> 1. Support extern(C++) classes so can have a split C++/D implementation
of eg: Expression and others.
>
>
> I don't know if this will be in the videos, so I'll ask here. I thought
extern(C++) only supported interfaces because everything else fell into the
"we'd need to pretty much include a C++ compiler into D to support that"
camp. Is that not quite true for classes? Did you find some compromise
between usefulness and complexity that wasn't obvious before, or did the D
compiler transition just motivate adding some additional complexity that
previously wasn't deemed acceptable?

It was mentioned, however I do believe there are a few more complicated
things than that.  Many would be in a position to educate you on that.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Rvalue references - The resolution

[Walter Bright]

On 5/5/2013 4:43 AM, Michel Fortin wrote:

On 2013-05-04 18:33:10 +, Walter Bright  said:


Runtime Detection

There are still a few cases that the compiler cannot statically detect. For
these a runtime check is inserted, which compares the returned ref pointer to
see if it lies within the stack frame of the exiting function, and if it does,
halts the program. The cost will be a couple of CMP instructions and an LEA.
These checks would be omitted if the -noboundscheck compiler switch was 
provided.


I just want to note that this has the effect of making any kind of heap
allocation not done by the GC unsafe. For instance, if you have a container
struct that allocates using malloc/realloc and that container gives access to
its elements by reference then you're screwed (it can't be detected).

The obvious answer is to not make @trusted the function returning a reference or
a slice to malloced memory. But I remember Andrei wanting to make standard
containers of this sort at one point, so I think it's important to note this
limitation.


I know Andrei has thought about this, but I don't know what the solution is.

Re: static parameters

[Idan Arye]

On Sunday, 5 May 2013 at 17:12:51 UTC, Luís Marques wrote:
Are static parameters still planned for inclusion in the 
language?


Weren't those replaced by template arguments?

Re: static parameters

[Luís.Marques]

On Sunday, 5 May 2013 at 18:19:30 UTC, Idan Arye wrote:

Weren't those replaced by template arguments?


You tell me. I saw them discussed here 
http://www.youtube.com/watch?v=FRfTk44nuWE
Being a syntactic sugar convenience, I thought that if they were 
missing then the most likely reason would be that there were 
other priorities, but as other reasons were possible (e.g. the 
community rejected them) I decided to ask :-)

Re: The liabilities of binding rvalues to ref

[Andrei Alexandrescu]

On 5/5/13 3:00 AM, Jonathan M Davis wrote:

On Sunday, May 05, 2013 01:49:42 Andrei Alexandrescu wrote:

There may be other important patterns to address at the core, please
chime in. I consider (1) above easy to tackle, which leaves us with at
least (2). My opinion is that any proposal for binding rvalues to ref
must offer a compelling story about these patterns.


Another case is when you want to distinguish between lvalues and rvalues.


Good one. This is in fact what happened in C++: const T& binds so 
tightly to T rvalues, that it was impossible to work a wedge in between 
to allow overloading on T and on const T&. Therefore, a much heavier 
solution was needed.


Andrei

Re: The liabilities of binding rvalues to ref

[Andrei Alexandrescu]

On 5/5/13 7:55 AM, Timon Gehr wrote:

I still think auto ref should be extended to work for non-templated
functions. The semantics should be the same (i.e. behave as if there
were two copies that are eagerly semantically analyzed, but only
generate code for one) where possible. It would be an error to have
different behaviour of the two "copies". This would mean that in
non-templated functions, it should be an error to rely on whether or not
the passed argument was an lvalue. i.e. (auto) ref return of an auto ref
argument (at least in @safe code) and __traits(isRef,autoRefArgument)
should be disallowed. This would have the effect of making it illegal to
return references to temporaries from functions (at least in @safe
code), and hence the life time of rvalues would not have to be changed.

Both (1) and (2) would be close to non-issues with this solution.


I think the same. For non-templates "auto ref" should simply accept 
rvalues and lvalues alike. Inside the function an "auto ref" parameter 
is handled as a local (i.e. disappears at the end of the function) so 
the compiler disallows returning it by reference directly with the 
current algorithms. For more complicated patterns, dynamic checking will 
pick the slack.


I'll think I'll rework my DIP for that.


Andrei

immuable method address and export method address.

[Igor Stepanov]

Hello, I've two simple questions:

1. I have a structure:

struct Foo
{
  public int bar() const {return 0;}
  public int bar() immutable {return 1;}
}

How can I get immutable bar address?

When I've wrote next code I've got a const bar address. Is it a 
bug?


void main()
{
immutable Foo boo;
int delegate() immutable dg = &boo.bar;
}

Next question:
If I write туче code, it'll be builded successfully

void main()
{
foreach(cur; __traits(getOverloads, Foo, "bar"))
{
void* p = &cur;
writeln(cur); //prints a function pointer.
}
}

If I change protection of bar to export I've got a error:

struct Foo
{
  export int bar() const {return 0;}
  export int bar() immutable {return 1;}
}

void main()
{
foreach(cur; __traits(getOverloads, Foo, "bar"))
{
void* p = &cur; //Error: need 'this' to access member bar
writeln(cur);
}
}

How should it be?

dtutor.org: a call to action

[Tyro[17]]

The main contributors of D are doing a wonderful job of enhancing the 
language. I can confidently say that we are leagues ahead of where we 
stood a just two years ago. But there has been a long cry for 
documentation that has gone unanswered: not because they refuse to 
cooperate but rather, because they are a small volunteer force, occupied 
by real demands to address the quirks of the language, and lack the time 
to all issues by themselves.


It stands then that the community can make a conscious effort to address 
some of the outstanding issues. As such, I have chosen to champion the 
tutorial/documentation effort. Though, I possess very little programming 
experience but am willing to try and am hereby soliciting your 
assistance in making this a reality.


dtutor.org is an active domain dedicated to providing tutorials for the 
language. I will require content contributors but before we can begin to 
provide content there are a couple of issues to address:


I. Features to be supported

   Interactive Tutorials - Users must be able to modify and execute 
examples in place to observe side effects.


   Interactive Books - A number of free books exist around the internet 
that can be ported to D. The first two that come to mind are How to 
"Think Like a Computer Scientist", "Problem Solving with Algorithms and 
Data Structures Using Python" and Ali Çehreli's very own "Programming in D".


   Problems - Staged ICPC problems for users to attempt. Solutions may 
be submitted online for comparison against previously submitted 
solutions to determine efficiency ranking and users may choose to create 
and account to keep track of progress.


   Online Judge - to be used to determine accuracy and efficiency of 
submitted solutions to problems and planned programming contests.


   Forum - Unlocked to individual users per problem after solution 
accepted by Online Judge.


II. Look and Feel

Look and feel of the site will be largely influenced by two things: The 
DConf website and this little gem which provides encouragement for the 
ideas behind interactive tutorials/books:


Runestone (https://github.com/bnmnetp/runestone);

I came across it while searching for ideas on how to get started with 
dtutor.org and must admit: it is a fascinating little project.


I am wondering if there are any Python experts (or experts in general) 
out there willing to assist in porting it to D? It comes with built in 
support for Python and C/C++ among other languages. However, because 
dtutor.org aims to promote all things D, it would aid greatly to have a 
D implementation which removes all external dependencies and support 
vice implementing D support for the original project. By doing this we 
can showcase the strengths of DMDScript, vibe and other technology 
already available in D.


Logo: My idea for the logo is simply this (see attachment):

D!(tutor).org

As Andrei would say: destroy!

III. Constraints

DMDScript for web scripting
Vibe for hosting (diet templates)
MangoDB for database

IV. Timeline

The hope is for complete functionality by DConf 2014.
Shooting for Initial Launch by September.

Calling all website designers, database developers, authors and D 
enthusiast. Lend a hand in eliminating this problem.


Andrew
<>

Re: The liabilities of binding rvalues to ref

[Dicebot]

On Sunday, 5 May 2013 at 16:21:37 UTC, deadalnix wrote:
No, you won't be able to reach any of this anyway. Move 
semantic is already cleanly implemented in D, so the C++ mess 
is irrelevant here.


Agreed.

- You want to avoid creating copies, when this isn't 
necessary. In this case, this is a performance reason, and 
binding to rvalue make sense.


Not necessarily performance reason on its own, copy 
construction of given object may have an undesired side 
effects. Or it may be even some singleton'ish object.


Having a singleton as a value type, and not marking the 
postblit as @disable is asking for trouble in general, nothing 
specific to the discussion here.


Yes, sure, but you will still use ref if you want ( don't ask why 
:) ) to use it as an argument to a function and not because of 
performance but because it is only option. I was objecting to 
stating that "avoiding copies" -> "performance reasons".

Re: dtutor.org: a call to action

[Andrei Alexandrescu]

Looks great. A few thoughts interspersed:


I. Features to be supported


Love the list, particularly the interactive aspect.


Runestone (https://github.com/bnmnetp/runestone);


Would be great to showcase a site using runestone (I browsed the README
real quick without finding one).


DMDScript for web scripting


I think this is somewhat of a distraction; dmdscript is just an
implementation of Javascript so it only relates very little to D other
than being implemented by Walter.


Vibe for hosting (diet templates)


Yes, awesome.


MangoDB for database


Or other databases featuring D bindings (yet to be finished).


The hope is for complete functionality by DConf 2014. Shooting for
Initial Launch by September.


This seems to be a reasonable timeline.


Andrei

Re: Migrating D front end to D - post Dconf

[Walter Bright]

On 5/5/2013 9:17 AM, "Luís Marques" " wrote:

On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:

1. Support extern(C++) classes so can have a split C++/D implementation of eg:
Expression and others.


I don't know if this will be in the videos, so I'll ask here. I thought
extern(C++) only supported interfaces because everything else fell into the
"we'd need to pretty much include a C++ compiler into D to support that" camp.
Is that not quite true for classes? Did you find some compromise between
usefulness and complexity that wasn't obvious before, or did the D compiler
transition just motivate adding some additional complexity that previously
wasn't deemed acceptable?


extern(C++) interfaces are ABI compatible with C++ "com" classes - i.e. single 
inheritance, no constructors or destructors.

Re: About typequalifier and generic containers.

[Jonathan M Davis]

On Sunday, May 05, 2013 18:34:44 =?UTF-8?B?Ikx1w61z?=.Marques 
@puremagic.com wrote:
> On Sunday, 5 May 2013 at 16:32:37 UTC, deadalnix wrote:
> > Foo!T do not with Foo!const(T), and for good reasons.
> 
> Can you give me an overview of those reasons, please?

Foo!T and Foo!(const T) are completely different and essentially unrelated 
types. They're only connection is that they're instantiated from the same 
template. You can't assume that anything about them is the same. It's 
perfectly possible to do something like

struct Foo(T)
{
static if(is(const(T) == T))
{
string s;
byte b;
auto bar() { return s ~ b; }
}
else
{
T t;
float baz() { return 2.2; }
string toString() { "hello"; }
}
}

So, the compiler can't assume that Foo!T has any relation to Foo!(const T). In 
reality, 99.99% of the time, the only difference would be constness, but 
doing nonsense like what that Foo definition does is perfectly possible. With 
const T[] and const(T)[], the compiler knows all about how arrays work, so it 
knows that converting const T[] to const(T)[] (i.e. make it tail-const) is 
perfectly valid, and it just can't do that with user-defined types.

At one point, I tried to make a range's opSlice return a tail-const version of 
the range (and alias that to this for implicit conversions), but I ended up 
with a recursive template instantiation in the process, which blew the stack 
when compiling or somesuch. I _think_ that it could be done by using static if 
to break the recursion (though I didn't try that at the time), but I'm not 
entirely sure that that can be done, and even if it can, then it's getting 
fairly complicated to define a range which can be sliced as tail-const like 
arrays can, which likely means that almost no one will do it.

I don't know what the solution is (Steven has some ideas, but I don't know 
what they are), but if const and ranges are ever going to mix, we need to be 
able to reasonably get tail-const ranges from const ranges. Otherwise, as soon 
as you get a const range, it's pretty much useless.

- Jonathan M Davis

Re: Migrating D front end to D - post Dconf

[Luís.Marques]

On Sunday, 5 May 2013 at 20:33:15 UTC, Walter Bright wrote:
extern(C++) interfaces are ABI compatible with C++ "com" 
classes - i.e. single inheritance, no constructors or 
destructors.


That I know, thanks, I just understood that point one meant some 
additional extern(C++) support:


1. Support extern(C++) classes so can have a split C++/D 
implementation of eg: Expression and others.

Re: dtutor.org: a call to action

[Kirill]

Numerical simulations content suggestion.

Depending on time, I would like to do it at some point but just 
in case, i'll leave it here. I think people from scientific 
community would agree. I'm also for problem specific approach 
that can be deconstructed into tools rather than giving people 
tools. basically, a high school student should be able to figure 
out everything from starting an editor to getting an eps of 
gnuplot.


1. sample uses on clusters mpi or new hpx. monte-carlo 
calculation of an area of a circle.


2. numerical recipies covers a lot of common problems in science. 
it would be a nice guide on what to include. (giving reference to 
the book of course). it should also be used to show a correct 
style of programming.


3. wolfram mathematica, matlab and sage already did a good job of 
finding and documenting showcases of popular numerical 
computations.


==

web interface:

it would be nice to see the same tutorial for different paradigms 
of programming -- click a button for functional or for object 
oriented and so on. figuring out paradigms was the hardest part 
for me in learning c++.

Re: dtutor.org: a call to action

[Nathan M. Swan]

On Sunday, 5 May 2013 at 19:37:02 UTC, Tyro[17] wrote:
The main contributors of D are doing a wonderful job of 
enhancing the
language. I can confidently say that we are leagues ahead of 
where we

stood a just two years ago. But there has been a long cry for
documentation that has gone unanswered: not because they refuse 
to
cooperate but rather, because they are a small volunteer force, 
occupied
by real demands to address the quirks of the language, and lack 
the time

to all issues by themselves.


Don't we all :(



It stands then that the community can make a conscious effort 
to address
some of the outstanding issues. As such, I have chosen to 
champion the
tutorial/documentation effort. Though, I possess very little 
programming

experience but am willing to try and am hereby soliciting your
assistance in making this a reality.


Good luck!



dtutor.org is an active domain dedicated to providing tutorials 
for the
language. I will require content contributors but before we can 
begin to

provide content there are a couple of issues to address:

I. Features to be supported

Interactive Tutorials - Users must be able to modify and 
execute

examples in place to observe side effects.


You have DPaste to work with here (http://dpaste.dzfl.pl/), IIRC 
it is connected to sample code at dlang.org.




Interactive Books - A number of free books exist around the 
internet
that can be ported to D. The first two that come to mind are 
How to
"Think Like a Computer Scientist", "Problem Solving with 
Algorithms and
Data Structures Using Python" and Ali Çehreli's very own 
"Programming in D".


Videos are useful as well.



Problems - Staged ICPC problems for users to attempt. 
Solutions may

be submitted online for comparison against previously submitted
solutions to determine efficiency ranking and users may choose 
to create

and account to keep track of progress.

Online Judge - to be used to determine accuracy and 
efficiency of
submitted solutions to problems and planned programming 
contests.


I've had good experiences learning via stuff like that.



Forum - Unlocked to individual users per problem after 
solution

accepted by Online Judge.


Rejected Software (creators of vibe) has vibenews, which I 
believe is quite customizable.




II. Look and Feel

Look and feel of the site will be largely influenced by two 
things: The
DConf website and this little gem which provides encouragement 
for the

ideas behind interactive tutorials/books:

Runestone (https://github.com/bnmnetp/runestone);

I came across it while searching for ideas on how to get 
started with

dtutor.org and must admit: it is a fascinating little project.



It is!

I have to vouch for cplusplus.com, which isn't interactive, but I 
was able to teach myself C++ with only that and "C++ for 
Dummies," so it worked for one guy.


I am wondering if there are any Python experts (or experts in 
general)
out there willing to assist in porting it to D? It comes with 
built in
support for Python and C/C++ among other languages. However, 
because
dtutor.org aims to promote all things D, it would aid greatly 
to have a
D implementation which removes all external dependencies and 
support
vice implementing D support for the original project. By doing 
this we
can showcase the strengths of DMDScript, vibe and other 
technology

already available in D.

Logo: My idea for the logo is simply this (see attachment):

D!(tutor).org


If your target audience is people who know little about D, this 
would just look odd.




As Andrei would say: destroy!

III. Constraints

DMDScript for web scripting
Vibe for hosting (diet templates)
MangoDB for database

IV. Timeline

The hope is for complete functionality by DConf 2014.
Shooting for Initial Launch by September.

Calling all website designers, database developers, authors and 
D

enthusiast. Lend a hand in eliminating this problem.


Like everyone, my time is limited, but I can help a bit. Sign me 
up!




Andrew


NMS

Re: dtutor.org: a call to action

[Kirill]

bah, sorry for poor grammar. I forgot there is no edit or delete 
buttons


On Sunday, 5 May 2013 at 22:03:17 UTC, Kirill wrote:

Numerical simulations content suggestion.

Depending on time, I would like to do it at some point but just 
in case, i'll leave it here. I think people from scientific 
community would agree. I'm also for problem specific approach 
that can be deconstructed into tools rather than giving people 
tools. basically, a high school student should be able to 
figure out everything from starting an editor to getting an eps 
of gnuplot.


1. sample uses on clusters mpi or new hpx. monte-carlo 
calculation of an area of a circle.


2. numerical recipies covers a lot of common problems in 
science. it would be a nice guide on what to include. (giving 
reference to the book of course). it should also be used to 
show a correct style of programming.


3. wolfram mathematica, matlab and sage already did a good job 
of finding and documenting showcases of popular numerical 
computations.


==

web interface:

it would be nice to see the same tutorial for different 
paradigms of programming -- click a button for functional or 
for object oriented and so on. figuring out paradigms was the 
hardest part for me in learning c++.

Re: dtutor.org: a call to action

[Nathan M. Swan]

On Sunday, 5 May 2013 at 22:06:17 UTC, Nathan M. Swan wrote:

On Sunday, 5 May 2013 at 19:37:02 UTC, Tyro[17] wrote:
The main contributors of D are doing a wonderful job of 
enhancing the
language. I can confidently say that we are leagues ahead of 
where we

stood a just two years ago. But there has been a long cry for
documentation that has gone unanswered: not because they 
refuse to
cooperate but rather, because they are a small volunteer 
force, occupied
by real demands to address the quirks of the language, and 
lack the time

to all issues by themselves.


Don't we all :(



It stands then that the community can make a conscious effort 
to address
some of the outstanding issues. As such, I have chosen to 
champion the
tutorial/documentation effort. Though, I possess very little 
programming

experience but am willing to try and am hereby soliciting your
assistance in making this a reality.


Good luck!



dtutor.org is an active domain dedicated to providing 
tutorials for the
language. I will require content contributors but before we 
can begin to

provide content there are a couple of issues to address:

I. Features to be supported

   Interactive Tutorials - Users must be able to modify and 
execute

examples in place to observe side effects.


You have DPaste to work with here (http://dpaste.dzfl.pl/), 
IIRC it is connected to sample code at dlang.org.




   Interactive Books - A number of free books exist around the 
internet
that can be ported to D. The first two that come to mind are 
How to
"Think Like a Computer Scientist", "Problem Solving with 
Algorithms and
Data Structures Using Python" and Ali Çehreli's very own 
"Programming in D".


Videos are useful as well.



   Problems - Staged ICPC problems for users to attempt. 
Solutions may

be submitted online for comparison against previously submitted
solutions to determine efficiency ranking and users may choose 
to create

and account to keep track of progress.

   Online Judge - to be used to determine accuracy and 
efficiency of
submitted solutions to problems and planned programming 
contests.


I've had good experiences learning via stuff like that.



   Forum - Unlocked to individual users per problem after 
solution

accepted by Online Judge.


Rejected Software (creators of vibe) has vibenews, which I 
believe is quite customizable.




II. Look and Feel

Look and feel of the site will be largely influenced by two 
things: The
DConf website and this little gem which provides encouragement 
for the

ideas behind interactive tutorials/books:

Runestone (https://github.com/bnmnetp/runestone);

I came across it while searching for ideas on how to get 
started with

dtutor.org and must admit: it is a fascinating little project.



It is!

I have to vouch for cplusplus.com, which isn't interactive, but 
I was able to teach myself C++ with only that and "C++ for 
Dummies," so it worked for one guy.


I am wondering if there are any Python experts (or experts in 
general)
out there willing to assist in porting it to D? It comes with 
built in
support for Python and C/C++ among other languages. However, 
because
dtutor.org aims to promote all things D, it would aid greatly 
to have a
D implementation which removes all external dependencies and 
support
vice implementing D support for the original project. By doing 
this we
can showcase the strengths of DMDScript, vibe and other 
technology

already available in D.

Logo: My idea for the logo is simply this (see attachment):

D!(tutor).org


If your target audience is people who know little about D, this 
would just look odd.




As Andrei would say: destroy!

III. Constraints

DMDScript for web scripting
Vibe for hosting (diet templates)
MangoDB for database

IV. Timeline

The hope is for complete functionality by DConf 2014.
Shooting for Initial Launch by September.

Calling all website designers, database developers, authors 
and D

enthusiast. Lend a hand in eliminating this problem.


Like everyone, my time is limited, but I can help a bit. Sign 
me up!




Andrew


NMS


I forgot, do you have a github repo up?

NMS

Re: dtutor.org: a call to action

[Ivan Kazmenko]

I. Features to be supported

Problems - Staged ICPC problems for users to attempt. 
Solutions may

be submitted online for comparison against previously submitted
solutions to determine efficiency ranking and users may choose 
to create

and account to keep track of progress.

Online Judge - to be used to determine accuracy and 
efficiency of
submitted solutions to problems and planned programming 
contests.


You mean algorithmic contests like ACM ICPC, right?  There are a 
few online judges supporting the D programming language which 
already have all other necessary infrastructure (problem archive, 
online judge and server itself, etc).


First, there's Codeforces (http://codeforces.com).  There are 
already hundreds of algorithmic problems in the problem archive 
which can be solved individually or by participating in "virtual" 
past contests.  New contests (5 problems, 2 hour duration) are 
held, like, weekly.  The online judge supports a number of 
programming languages.  They recently upgraded the D compiler to 
the current DMD 2.062 (Windows version).


Then there's Sphere Online Judge (http://spoj.pl).  They support 
48 programming languages, their D version is listed as GDC 4.1.3 
which as I understand is pretty old (D1?).


And then there is a number of mathematical and/or algorithmic 
online contest sites where one runs the code locally on given 
inputs and submits only the result.  Examples of these are 
Project Euler (http://projecteuler.net) and Rosalind 
(http://rosalind.info).  After you successfully solve a problem, 
you usually get access to a forum where people post and discuss 
their approaches in different programming languages, trying to 
show the strengths of their tools.


An online judge dedicated to D seems like a fun idea at first.  
Still, things usually go the other way around.  Much effort is 
put into getting an online judge up and running.  It is far from 
trivial to constantly add good algorithmic problems.  But once 
you have these two, adding support for a programming language is 
a matter of hours.


Regarding programming contests, there's another flavor of them: 
instead of solving small math/algo problems in a limited time 
frame, the competitors can design or develop a small-ish software 
component and submit them for a formal review.  The judging 
criteria should however be precise enough (i.e. carefully 
prepared by someone having a clear general picture).  This could 
even turn into a successful business model, the presentation at 
http://bsr.london.edu/files/1357/who-needs-employees.pdf‎ seems 
to describe it in more detail.  It may happen that a similar 
model could be adopted to some parts of D development, provided 
that some of the current developers will like the idea and be 
really willing to try it.


-

Ivan Kazmenko.

Re: About typequalifier and generic containers.

[Simen Kjaeraas]

On Sun, 05 May 2013 23:32:47 +0200, Jonathan M Davis   
wrote:


I don't know what the solution is (Steven has some ideas, but I don't  
know
what they are), but if const and ranges are ever going to mix, we need  
to be
able to reasonably get tail-const ranges from const ranges. Otherwise,  
as soon

as you get a const range, it's pretty much useless.


I wrote a proof-of-concept tail-const range framework at some point, and
posted it to BugZilla[1]. It shows that such a thing is possible in the
language as-is, however I don't think it would win a beauty contest.

This is a hard problem to get right, and I'd love to see Steven's ideas.

[1]: http://d.puremagic.com/issues/show_bug.cgi?id=5377

--
Simen

Re: dtutor.org: a call to action

[Tyro[17]]

On 5/5/13 6:06 PM, Nathan M. Swan wrote:

On Sunday, 5 May 2013 at 19:37:02 UTC, Tyro[17] wrote:

The main contributors of D are doing a wonderful job of enhancing the
language. I can confidently say that we are leagues ahead of where we
stood a just two years ago. But there has been a long cry for
documentation that has gone unanswered: not because they refuse to
cooperate but rather, because they are a small volunteer force, occupied
by real demands to address the quirks of the language, and lack the time
to all issues by themselves.


Don't we all :(



It stands then that the community can make a conscious effort to address
some of the outstanding issues. As such, I have chosen to champion the
tutorial/documentation effort. Though, I possess very little programming
experience but am willing to try and am hereby soliciting your
assistance in making this a reality.


Good luck!


Thanks.



dtutor.org is an active domain dedicated to providing tutorials for the
language. I will require content contributors but before we can begin to
provide content there are a couple of issues to address:

I. Features to be supported

Interactive Tutorials - Users must be able to modify and execute
examples in place to observe side effects.


You have DPaste to work with here (http://dpaste.dzfl.pl/), IIRC it is
connected to sample code at dlang.org.


Indeed we do. My initial sentiments was that this should be done with 
DPaste but I'm now inclined to believe that Runestone is more suited for 
the job. Of course it will require some effort to port it to D.




Interactive Books - A number of free books exist around the internet
that can be ported to D. The first two that come to mind are How to
"Think Like a Computer Scientist", "Problem Solving with Algorithms and
Data Structures Using Python" and Ali Çehreli's very own "Programming
in D".


Videos are useful as well.


Should be part of the tutorial/book where applicable.


Online Judge - to be used to determine accuracy and efficiency of
submitted solutions to problems and planned programming contests.


I've had good experiences learning via stuff like that.


Though not much, the little experience I with them was comparatively 
positive.




Forum - Unlocked to individual users per problem after solution
accepted by Online Judge.


Rejected Software (creators of vibe) has vibenews, which I believe is
quite customizable.


Thanks, wasn't aware of that.



II. Look and Feel

Look and feel of the site will be largely influenced by two things: The
DConf website and this little gem which provides encouragement for the
ideas behind interactive tutorials/books:

Runestone (https://github.com/bnmnetp/runestone);

I came across it while searching for ideas on how to get started with
dtutor.org and must admit: it is a fascinating little project.



It is!

I have to vouch for cplusplus.com, which isn't interactive, but I was
able to teach myself C++ with only that and "C++ for Dummies," so it
worked for one guy.


Hope to provide a much better experience for the D community. Not to 
dismiss cplusplus.com (the have done a good job) but the hope is to help 
elevate D to its rightful place in the programming community at large. 
Thus, the aim to raise the bar that much higher.



Logo: My idea for the logo is simply this (see attachment):

D!(tutor).org


If your target audience is people who know little about D, this would
just look odd.


Until they reach enlightenment... Then it all make sense!!! But you 
point is noted.



Calling all website designers, database developers, authors and D
enthusiast. Lend a hand in eliminating this problem.


Like everyone, my time is limited, but I can help a bit. Sign me up!


Every little bit counts. Thanks.



Andrew


NMS

Re: Rvalue references - The resolution

[Michel Fortin]

On 2013-05-05 18:19:26 +, Walter Bright  said:


On 5/5/2013 4:43 AM, Michel Fortin wrote:

On 2013-05-04 18:33:10 +, Walter Bright  said:


Runtime Detection

There are still a few cases that the compiler cannot statically detect. For
these a runtime check is inserted, which compares the returned ref pointer to
see if it lies within the stack frame of the exiting function, and if it does,
halts the program. The cost will be a couple of CMP instructions and an LEA.
These checks would be omitted if the -noboundscheck compiler switch was 
provided.


I just want to note that this has the effect of making any kind of heap
allocation not done by the GC unsafe. For instance, if you have a container
struct that allocates using malloc/realloc and that container gives access to
its elements by reference then you're screwed (it can't be detected).

The obvious answer is to not make @trusted the function returning a 
reference or

a slice to malloced memory. But I remember Andrei wanting to make standard
containers of this sort at one point, so I think it's important to note this
limitation.


I know Andrei has thought about this, but I don't know what the solution is.


Just rethrowing an idea that was already thrown here: support annotated 
lifetimes *in addition* to this runtime detection system. Those who use 
manual memory management will need it to make their code @safe. Those 
who stick to the GC won't have to. Anyway, you don't have to implement 
both right away, it can always be decided later.


--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/

Re: dtutor.org: a call to action

[Jonathan M Davis]

On Sunday, May 05, 2013 19:42:30 Tyro[17] wrote:
> >> Logo: My idea for the logo is simply this (see attachment):
> >> D!(tutor).org
> > 
> > If your target audience is people who know little about D, this would
> > just look odd.
> 
> Until they reach enlightenment... Then it all make sense!!! But you
> point is noted.

And once enlightened, they'll ask why the parens were used when they're 
unnecessary... ;) Cute idea though.

- Jonathan M Davis

Re: dtutor.org: a call to action

[Tyro[17]]

On 5/5/13 4:27 PM, Andrei Alexandrescu wrote:

Looks great. A few thoughts interspersed:


I. Features to be supported


Love the list, particularly the interactive aspect.


Runestone (https://github.com/bnmnetp/runestone);


Would be great to showcase a site using runestone (I browsed the README
real quick without finding one).


This would definitely be a plus.

Documentation should be here 
http://docs.runestoneinteractive.org/build/html/index.html



DMDScript for web scripting


I think this is somewhat of a distraction; dmdscript is just an
implementation of Javascript so it only relates very little to D other
than being implemented by Walter.


Point taken.


Vibe for hosting (diet templates)


Yes, awesome.


MangoDB for database


Or other databases featuring D bindings (yet to be finished).


No objections there but MongoDB and Redis are the two currently 
supported by Vibe.



The hope is for complete functionality by DConf 2014. Shooting for
Initial Launch by September.


This seems to be a reasonable timeline.


Andrei

Re: dtutor.org: a call to action

[Tyro[17]]

On 5/5/13 6:38 PM, Ivan Kazmenko wrote:

I. Features to be supported

Problems - Staged ICPC problems for users to attempt. Solutions may
be submitted online for comparison against previously submitted
solutions to determine efficiency ranking and users may choose to create
and account to keep track of progress.

Online Judge - to be used to determine accuracy and efficiency of
submitted solutions to problems and planned programming contests.


You mean algorithmic contests like ACM ICPC, right?  There are a few
online judges supporting the D programming language which already have
all other necessary infrastructure (problem archive, online judge and
server itself, etc).


Yes. So is your suggestion that I leave this sort of thing to already 
established sites that caters specifically to these sort of contests? I 
would actually love to do that but my experience is sites (shootouts 
etc...) tend to drop coverage of D on a whim.



First, there's Codeforces (http://codeforces.com).  There are already
hundreds of algorithmic problems in the problem archive which can be
solved individually or by participating in "virtual" past contests.  New
contests (5 problems, 2 hour duration) are held, like, weekly.  The
online judge supports a number of programming languages.  They recently
upgraded the D compiler to the current DMD 2.062 (Windows version).

Then there's Sphere Online Judge (http://spoj.pl).  They support 48
programming languages, their D version is listed as GDC 4.1.3 which as I
understand is pretty old (D1?).


Or is outdated and becomes useless to our community.


And then there is a number of mathematical and/or algorithmic online
contest sites where one runs the code locally on given inputs and
submits only the result.  Examples of these are Project Euler
(http://projecteuler.net) and Rosalind (http://rosalind.info).  After
you successfully solve a problem, you usually get access to a forum
where people post and discuss their approaches in different programming
languages, trying to show the strengths of their tools.


ProjectEuler is very interesting but I haven't tried Rosalind so cannot 
comment there. The object of these sites however is not to teach 
programming (though programming is one method that can be used) but 
rather to uncover the solution to a given problem by whatever means 
necessary. I've seen solutions reached by simply loading data into Excel 
and performing some sorts and or inserting a couple of formulas. Not 
what I'm after.



An online judge dedicated to D seems like a fun idea at first. Still,
things usually go the other way around.  Much effort is put into getting
an online judge up and running.  It is far from trivial to constantly
add good algorithmic problems.  But once you have these two, adding
support for a programming language is a matter of hours.

Regarding programming contests, there's another flavor of them: instead
of solving small math/algo problems in a limited time frame, the
competitors can design or develop a small-ish software component and
submit them for a formal review.  The judging criteria should however be
precise enough (i.e. carefully prepared by someone having a clear
general picture).  This could even turn into a successful business
model, the presentation at
http://bsr.london.edu/files/1357/who-needs-employees.pdf‎ seems to
describe it in more detail.  It may happen that a similar model could be
adopted to some parts of D development, provided that some of the
current developers will like the idea and be really willing to try it.


Now there is an idea I'm willing to support. This is the sort of 
contests I would actually like to promote on the site for professional 
programmers. But timed math/algo type contests are also necessary for 
those in academia to hone their skills. The hope is that college 
students will be able to demonstrate there D programming acumen in 
national/international contest sponsored by yours truly



-

Ivan Kazmenko.


Andrew

Re: dtutor.org: a call to action

[Nathan M. Swan]

On Sunday, 5 May 2013 at 20:27:57 UTC, Andrei Alexandrescu wrote:
Would be great to showcase a site using runestone (I browsed 
the README

real quick without finding one).


interactivepython.org

Re: dtutor.org: a call to action

[Tyro[17]]

On 5/5/13 8:00 PM, Jonathan M Davis wrote:

On Sunday, May 05, 2013 19:42:30 Tyro[17] wrote:

Logo: My idea for the logo is simply this (see attachment):
 D!(tutor).org


If your target audience is people who know little about D, this would
just look odd.


Until they reach enlightenment... Then it all make sense!!! But you
point is noted.


And once enlightened, they'll ask why the parens were used when they're
unnecessary... ;) Cute idea though.

- Jonathan M Davis



Then would have been successful in creating yet another template deity. 
My original thought was D!"tutor"(org) but getting it to pass through 
Vibe correctly so I changed it. Which reminds me... how does one create 
a utf-8 encoded file at the shell prompt?


Andrew

Re: dtutor.org: a call to action

[Tyro[17]]

On 5/5/13 8:00 PM, Jonathan M Davis wrote:

On Sunday, May 05, 2013 19:42:30 Tyro[17] wrote:

Logo: My idea for the logo is simply this (see attachment):
 D!(tutor).org


If your target audience is people who know little about D, this would
just look odd.


Until they reach enlightenment... Then it all make sense!!! But you
point is noted.


And once enlightened, they'll ask why the parens were used when they're
unnecessary... ;) Cute idea though.

- Jonathan M Davis



Then would have been successful in creating yet another template deity. 
My original thought was D!"tutor"(org) but had problems getting it to 
pass through Vibe correctly so I changed it. Which reminds me... how 
does one create a utf-8 encoded file at the shell prompt?


Andrew

Re: dtutor.org: a call to action

[Jonathan M Davis]

On Sunday, May 05, 2013 20:55:29 Tyro[17] wrote:
> Which reminds me... how does one create
> a utf-8 encoded file at the shell prompt?

You'll need to be more specific about what you're trying to do. Are you talking 
about from D or about running commands in the shell? And if you're talking 
about the shell, the answer could depend on the type of shell.

In general, Phobos assumes that you're operating on UTF-8 files (or at least 
UTF-8 compatible files). All of the file operations using string do UTF-8. You 
have to use ubyte[] to be able to use other encodings. And we don't properly 
deal with BOM stuff right now, which we need to fix at some point.

- Jonathan M Davis

Re: dtutor.org: a call to action

[Ivan Kazmenko]

On Monday, 6 May 2013 at 00:47:22 UTC, Tyro[17] wrote:
You mean algorithmic contests like ACM ICPC, right?  There are 
a few
online judges supporting the D programming language which 
already have
all other necessary infrastructure (problem archive, online 
judge and

server itself, etc).


Yes. So is your suggestion that I leave this sort of thing to 
already established sites that caters specifically to these 
sort of contests? I would actually love to do that but my 
experience is sites (shootouts etc...) tend to drop coverage of 
D on a whim.


From this perspective, yes: if you do build an online judge, 
supporting D as a contest language will likely be your least 
concern.


First, there's Codeforces (http://codeforces.com).  There are 
already
hundreds of algorithmic problems in the problem archive which 
can be
solved individually or by participating in "virtual" past 
contests.  New
contests (5 problems, 2 hour duration) are held, like, weekly. 
 The
online judge supports a number of programming languages.  They 
recently
upgraded the D compiler to the current DMD 2.062 (Windows 
version).


Then there's Sphere Online Judge (http://spoj.pl).  They 
support 48
programming languages, their D version is listed as GDC 4.1.3 
which as I

understand is pretty old (D1?).


Or is outdated and becomes useless to our community.


Well, contacting the staff sometimes helps (at least with the 
former example of Codeforces).


And then there is a number of mathematical and/or algorithmic 
online
contest sites where one runs the code locally on given inputs 
and

submits only the result.  Examples of these are Project Euler
(http://projecteuler.net) and Rosalind (http://rosalind.info). 
 After
you successfully solve a problem, you usually get access to a 
forum
where people post and discuss their approaches in different 
programming

languages, trying to show the strengths of their tools.


ProjectEuler is very interesting but I haven't tried Rosalind 
so cannot comment there. The object of these sites however is 
not to teach programming (though programming is one method that 
can be used) but rather to uncover the solution to a given 
problem by whatever means necessary. I've seen solutions 
reached by simply loading data into Excel and performing some 
sorts and or inserting a couple of formulas. Not what I'm after.


Right, but that is the point which may be changed.  For example, 
Rosalind is a platform for studying bioinformatics through 
problem solving.  Each problem contains a motivational or 
educational part describing how the problem relates to this field 
of study.  You are free to use any language, but some of the 
current problems favor Python 2.  The reason is that there are 
mature libraries in that language, useful in bioinformatics.  The 
consequence is that there are tutorial versions of some problems 
describing how to do the stuff with a particular library instead 
of re-inventing the wheel.


Likewise, one can establish an online judge with problems 
covering the most basic algorithms or programming techniques.  If 
the goal is to teach and promote D in the process, each problem 
statement could contain a hint for a D construct one could use to 
solve it efficiently.  Allowing other languages to be used (e.g. 
requiring only the answer but not the program as ProjectEuler 
does) could serve for the promotion part.  This way, one could 
solve all the problems in some other language and still not learn 
D.  However, the problem statements will introduce its basic 
concepts, and the problem solutions discussion (accessible right 
after you solve the problem) will allow to compare that other 
language to D, promoting the latter when it's worth it.


So, on second thought, an online judge dedicated to D could be a 
feasible goal.


Regarding programming contests, there's another flavor of 
them: instead
of solving small math/algo problems in a limited time frame, 
the
competitors can design or develop a small-ish software 
component and
submit them for a formal review.  The judging criteria should 
however be
precise enough (i.e. carefully prepared by someone having a 
clear
general picture).  This could even turn into a successful 
business

model, the presentation at
http://bsr.london.edu/files/1357/who-needs-employees.pdf‎ 
seems to
describe it in more detail.  It may happen that a similar 
model could be
adopted to some parts of D development, provided that some of 
the
current developers will like the idea and be really willing to 
try it.


Now there is an idea I'm willing to support. This is the sort 
of contests I would actually like to promote on the site for 
professional programmers. But timed math/algo type contests are 
also necessary for those in academia to hone their skills. The 
hope is that college students will be able to demonstrate there 
D programming acumen in national/international contest 
sponsored by yours truly


Sure, TopCoder (the company which utilizes that busin

Re: DConf 2013 - what a show!

[Jonathan M Davis]

On Saturday, May 04, 2013 01:11:26 Walter Bright wrote:
> I just arrived home after 4 days of little sleep and dawn to late night
> talking with fellow D-heads. And the conference was ...
> 
> 
> !!AWESOME!!
> 
> 
> .. It exceeded my highest hopes. Basically, I had a grand time, and I hope
> you guys did, too. The excitement at the conference was palpable.

It was indeed awesome and far better than I had anticipated. The talks were 
incredibly informative (sometimes even in areas that I thought that I knew 
quite well), and a lot of good discussions took place. It's amazing how 
different it can be to discuss things in person, and I think that we all 
benefited from it.

> Anyone
> needing help was deluged with offers, many hatchets got buried

One cool thing along these lines that Iain told me about was that after his 
gdc talk, someone came up to him and just offered him a mac mini that they'd 
had lying around! He didn't ask any money for it. He just asked for Iain to 
make gdc awesome. Iain was blown away by that.

We've got a great community with a lot of enthusiasm, and with plenty of 
people willing to donate time and money (as was shown with kickstarter). We 
could always use more help, but who and what we have is great.

> (amazing how
> meeting the real person behind an online persona does that!)

Yeah. It was very weird to meet a lot of the people around here in person. Now 
I have faces (and voices!) to go with many of the posts around here. It makes 
a surprisingly large difference. In some cases, now I can even hear how some of 
the posters would say what they wrote in their own voice and accent. That 
alone is going to have a large impact on me.

As an interesting side note, I thought that it was interesting that people who 
used the web forum did a better job of recognizing people thanks to the 
gravatars. I use the mailing list, so I don't generally see that, and a lot of 
people recognized me whereas I recognized very few people.

> We'll definitely be doing one next year, so start roughing out your
> presentations now!

I'm definitely looking forward to it. It was a blast this time around, and I 
can't wait for the next one.

- Jonathan M Davis

Low-Lock Singletons In D

[dsimcha]

On the advice of Walter and Andrei, I've written a blog article 
about the low-lock Singleton pattern in D.  This is a previously 
obscure pattern that uses thread-local storage to make Singletons 
both thread-safe and efficient and was independently invented by 
at least me and Alexander Terekhov, an IBM researcher.  However, 
D's first-class treatment of thread-local storage means the time 
has come to move it out of obscurity and possibly make it the 
standard way to do Singletons.


Article:
http://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/

Reddit:
http://www.reddit.com/r/programming/comments/1droaa/lowlock_singletons_in_d_the_singleton_pattern/

Re: Low-Lock Singletons In D

[Joshua Niehus]

On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:

Article:
http://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/

Reddit:
http://www.reddit.com/r/programming/comments/1droaa/lowlock_singletons_in_d_the_singleton_pattern/


Excellent talk at the conf, solid blog: +1 and 1

DIP 37: Importing Packages as if They Were Modules

[Jonathan M Davis]

This DIP (which is similar to DIP 15) was discussed with Walter and Andrei at 
dconf 2013:

http://wiki.dlang.org/DIP37

They verbally approved it in that discussion and it has already been 
implemented by Daniel Murpy (though it hasn't been merged in yet): 

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

There is also an enhancement request for it:

http://d.puremagic.com/issues/show_bug.cgi?id=10022

The idea is very simple and does not require large changes to the compiler to 
work as it mostly takes advantage of what the module system and imports 
already do. However, it probably does merit having an actual DIP for it as 
well as a public discussion, so I've created a DIP for it and am opening this 
thread so that we can discuss it.

- Jonathan M Davis

Re: DConf 2013 - what a show!

[Mike Parker]

On Monday, 6 May 2013 at 02:07:39 UTC, Jonathan M Davis wrote:




Yeah. It was very weird to meet a lot of the people around here 
in person. Now
I have faces (and voices!) to go with many of the posts around 
here. It makes
a surprisingly large difference. In some cases, now I can even 
hear how some of
the posters would say what they wrote in their own voice and 
accent. That

alone is going to have a large impact on me.


+100. I loved the presentations, but being able to talk to people 
face-to-face had a much different effect on me than I 
anticipated, and not just in matching voices & faces with forum 
posts. I mentioned to a few people that given where I live and 
that I don't work in the tech industry, I never have a chance to 
discuss anything related to my programming hobby, let alone D. 
Talking face-to-face with so many different people about this 
stuff really motivated me to put more effort into my D projects.


One of my big time sinks is my interest in the free online 
courses offered by coursera.org and edx.org. I've signed up for 
several over the past few months. I've enjoyed studying them and 
have learned a good deal from some of them, but it's all purely 
recreational and has really consumed my free time to a degree I 
underestimated. My time would be better used writing D articles, 
working on Derelict, and getting one of my abandonware games 
completed.


This conference has really restored my enthusiasm for all things 
D. And looking forward to DConf 2014 is going to sustain it.

Re: immuable method address and export method address.

[deadalnix]

On Sunday, 5 May 2013 at 19:34:34 UTC, Igor Stepanov wrote:

Hello, I've two simple questions:

1. I have a structure:

struct Foo
{
  public int bar() const {return 0;}
  public int bar() immutable {return 1;}
}

How can I get immutable bar address?

When I've wrote next code I've got a const bar address. Is it a 
bug?


void main()
{
immutable Foo boo;
int delegate() immutable dg = &boo.bar;
}



Yes. First, the immutable keyword before dg don't do what you 
think in D. Right now this is an hole in the type 
system/spec/implementation (pick one). But boo being immutable it 
should return the immutable delegate anyway. So you have two bugs 
in one. Congrat !


Hopefully, I've been able to discuss this with Andrei at DConf, 
who agreed on the problem and we were able to discuss solutions.



Next question:
If I write туче code, it'll be builded successfully

void main()
{
foreach(cur; __traits(getOverloads, Foo, "bar"))
{
void* p = &cur;
writeln(cur); //prints a function pointer.
}
}

If I change protection of bar to export I've got a error:

struct Foo
{
  export int bar() const {return 0;}
  export int bar() immutable {return 1;}
}

void main()
{
foreach(cur; __traits(getOverloads, Foo, "bar"))
{
void* p = &cur; //Error: need 'this' to access member 
bar

writeln(cur);
}
}

How should it be?


The method aren't static, so you should need this all the time. I 
can understand both behavior, but it is clearly inconsistent. We 
should pick one and stick to it.

Re: DIP 37: Importing Packages as if They Were Modules

[deadalnix]

On Monday, 6 May 2013 at 03:16:31 UTC, Jonathan M Davis wrote:
This DIP (which is similar to DIP 15) was discussed with Walter 
and Andrei at

dconf 2013:

http://wiki.dlang.org/DIP37

They verbally approved it in that discussion and it has already 
been
implemented by Daniel Murpy (though it hasn't been merged in 
yet):


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

There is also an enhancement request for it:

http://d.puremagic.com/issues/show_bug.cgi?id=10022

The idea is very simple and does not require large changes to 
the compiler to
work as it mostly takes advantage of what the module system and 
imports
already do. However, it probably does merit having an actual 
DIP for it as
well as a public discussion, so I've created a DIP for it and 
am opening this

thread so that we can discuss it.



I would prefer to find the package file in std/datetime.d so no 
change is required in lookup rules. Whatever the naming 
convention is, I'm all for it.

Re: Rvalue references - The resolution

[deadalnix]

On Sunday, 5 May 2013 at 23:45:21 UTC, Michel Fortin wrote:
Just rethrowing an idea that was already thrown here: support 
annotated lifetimes *in addition* to this runtime detection 
system. Those who use manual memory management will need it to 
make their code @safe. Those who stick to the GC won't have to. 
Anyway, you don't have to implement both right away, it can 
always be decided later.


Yes, that is also my point of view. We don't even need to support 
annotation now, simply ensure that we don't close the door to 
annotation.

Re: Migrating D front end to D - post Dconf

[Daniel Murphy]

"Iain Buclaw"  wrote in message 
news:qtcogcbrhfzjvuoay...@forum.dlang.org...
> Daniel and/or David,
>
> We should list down in writing the issues preventing DMD, GDC, and LDC 
> having a shared code base.  From what David has shown me, LDC will need 
> the most work for this, but I'll list down what I can remember.
>

ok here we go:

We have three goals:
A: D frontend ported to D
B: Identical frontend code shared between all three backends
C: Fixing the layering violations in the glue layer (in some cases this 
probably blocks B)

> 1. Support extern(C++) classes so can have a split C++/D implementation of 
> eg: Expression and others.
>

s/others/all ast classes/
Requred for A only

> 2. Support representing integers and floats to a greater precision than 
> what the host can natively support.

This should be 'Support representing integers and floats to the EXACT 
precisison that the TARGET supports at runtime'.

The old arguments about how you can't rely on floating point exactness do 
not hold up when cross compiling - all compilers that differ only in host 
compiler/machine must produce identical binaries.

This is really a seperate issue.

> In D there's BigInt for integral types, and there's a possibility of using 
> std.numeric for floats.  For me, painless conversion between eg: BigInt 
> <-> GCC's double_int is a requirement, but that is more of an after 
> thought at this point in time.
>

Because this does not block anything it _can_ wait until the port is 
complete, we can live with some weirdness in floating point at compile time. 
I completely agree it should be fixed eventually.

> 3. Array ops should be moved out of the front end. The back end can deal 
> with emitting the correct Libcall if required.
>

Only blocks C...

> 4. Continue building upon Target to hide target-specific things from the 
> front end.  Off the top of my head I've got two to raise pulls for: 
> __VENDOR__ and retrieving memalignsize for fields.
>

Only blocks B (and fixing it helps C)

> 5. DMD sends messages to stdout, GDC sends to stderr.  Just a small 
> implementation detail, but worth noting where 'printf'appears, it's almost 
> always rewritten as fprintf(stderr) for GDC.
>

Similar.

> 6. LDC does not implement toObjFile, toCtype, toDt, toIR, possibly 
> others...
>

This is another layering violation, and eventually I believe we should 
migrate to an _actual_ visitor pattern, so ast classes do not need to know 
anything about the glue layer.  I think we should work around this for now. 
(With #ifdef, or adding _all_ virtuals to the frontend and stubbing the 
unused ones)

> 7. BUILTINxxx could be moved into Target, as there is no reason why each 
> back end can't support their own builtins for the purpose of CTFE.
>

Makes sense.  I guess if Target detects a builtin it gets Port to evaluate 
it.  Maybe we should rename Port to Host?

> 8. D front end's port.h can't be used by GDC because of dependency  on 
> mars.h, this could perhaps be replaced by std.numeric post conversion.
>

Didn't we find it doesn't rely on anything substantial?  This can certainly 
be cleaned up.

> 9. Opaque declarations of back end types defined in front end differ for 
> each compiler implementation.  Eg: elem is a typedef to union tree_node.
>

Same problem as 6, except opaque types can be safely ignored/used as they 
are opaque.

> 10. The main function in mars.c is not used by GDC, possibly LDC also. 
> Another implementation detail but also a note to maybe split out 
> errorSuplimental and others from that file.
>

I'm happy with each compiler having their own 'main' file.  Yes we need to 
move the common stuff into another file.

> 11. The function genCfunc does not generate the arguments of the extern(C) 
> symbol.
>

I think this only blocks C.

> 12. LDC adds extra reserved version identifiers that are not allowed to be 
> declared in D code.  This could and probably should be merged into D front 
> end. Don't think it would be wise to let back end's have the ability to 
> add their own.  Also this list needs updating regardless to reflect the 
> documented spec.
>

Makes sense.

> 13. LDC makes some more arbitrary changes to which the reason for the 
> change has been forgotten. Get on it David!  :o)
>

I know very little about this but hopefully most of it can go into 
Target/get merged upstream.

> 14. Reading sources asynchronously, GDC ifdefs this out.  Do we really 
> need this?  I seem to recall that the speed increase is either negliegable 
> or offers no benefit to compilation speed.
>

I think #ifdefed or dropped are both fine.

> 15. Deal with all C++ -> D conversion

Yeah.

> 16. Testing the C++ -> D front end conversion on Linux.   Daniel you can 
> send me the sources to test that if getting a Linux box is a problem for 
> you.

It's not a problem, just not my primary platform and therefore not my first 
focus.  At the moment you would need a modified porting tool to compile for 
anything except win32.  T

Re: Migrating D front end to D - post Dconf

[Daniel Murphy]

I'm expecting lots of positive comments when I get off my flight in 14 
hours.

"Daniel Murphy"  wrote in message 
news:km7aqo$2kv4$1...@digitalmars.com...
> "Iain Buclaw"  wrote in message 
> news:qtcogcbrhfzjvuoay...@forum.dlang.org...
>> Daniel and/or David,
>>
>> We should list down in writing the issues preventing DMD, GDC, and LDC 
>> having a shared code base.  From what David has shown me, LDC will need 
>> the most work for this, but I'll list down what I can remember.
>>
>
> ok here we go:
>
> We have three goals:
> A: D frontend ported to D
> B: Identical frontend code shared between all three backends
> C: Fixing the layering violations in the glue layer (in some cases this 
> probably blocks B)
>
>> 1. Support extern(C++) classes so can have a split C++/D implementation 
>> of eg: Expression and others.
>>
>
> s/others/all ast classes/
> Requred for A only
>
>> 2. Support representing integers and floats to a greater precision than 
>> what the host can natively support.
>
> This should be 'Support representing integers and floats to the EXACT 
> precisison that the TARGET supports at runtime'.
>
> The old arguments about how you can't rely on floating point exactness do 
> not hold up when cross compiling - all compilers that differ only in host 
> compiler/machine must produce identical binaries.
>
> This is really a seperate issue.
>
>> In D there's BigInt for integral types, and there's a possibility of 
>> using std.numeric for floats.  For me, painless conversion between eg: 
>> BigInt <-> GCC's double_int is a requirement, but that is more of an 
>> after thought at this point in time.
>>
>
> Because this does not block anything it _can_ wait until the port is 
> complete, we can live with some weirdness in floating point at compile 
> time. I completely agree it should be fixed eventually.
>
>> 3. Array ops should be moved out of the front end. The back end can deal 
>> with emitting the correct Libcall if required.
>>
>
> Only blocks C...
>
>> 4. Continue building upon Target to hide target-specific things from the 
>> front end.  Off the top of my head I've got two to raise pulls for: 
>> __VENDOR__ and retrieving memalignsize for fields.
>>
>
> Only blocks B (and fixing it helps C)
>
>> 5. DMD sends messages to stdout, GDC sends to stderr.  Just a small 
>> implementation detail, but worth noting where 'printf'appears, it's 
>> almost always rewritten as fprintf(stderr) for GDC.
>>
>
> Similar.
>
>> 6. LDC does not implement toObjFile, toCtype, toDt, toIR, possibly 
>> others...
>>
>
> This is another layering violation, and eventually I believe we should 
> migrate to an _actual_ visitor pattern, so ast classes do not need to know 
> anything about the glue layer.  I think we should work around this for 
> now. (With #ifdef, or adding _all_ virtuals to the frontend and stubbing 
> the unused ones)
>
>> 7. BUILTINxxx could be moved into Target, as there is no reason why each 
>> back end can't support their own builtins for the purpose of CTFE.
>>
>
> Makes sense.  I guess if Target detects a builtin it gets Port to evaluate 
> it.  Maybe we should rename Port to Host?
>
>> 8. D front end's port.h can't be used by GDC because of dependency  on 
>> mars.h, this could perhaps be replaced by std.numeric post conversion.
>>
>
> Didn't we find it doesn't rely on anything substantial?  This can 
> certainly be cleaned up.
>
>> 9. Opaque declarations of back end types defined in front end differ for 
>> each compiler implementation.  Eg: elem is a typedef to union tree_node.
>>
>
> Same problem as 6, except opaque types can be safely ignored/used as they 
> are opaque.
>
>> 10. The main function in mars.c is not used by GDC, possibly LDC also. 
>> Another implementation detail but also a note to maybe split out 
>> errorSuplimental and others from that file.
>>
>
> I'm happy with each compiler having their own 'main' file.  Yes we need to 
> move the common stuff into another file.
>
>> 11. The function genCfunc does not generate the arguments of the 
>> extern(C) symbol.
>>
>
> I think this only blocks C.
>
>> 12. LDC adds extra reserved version identifiers that are not allowed to 
>> be declared in D code.  This could and probably should be merged into D 
>> front end. Don't think it would be wise to let back end's have the 
>> ability to add their own.  Also this list needs updating regardless to 
>> reflect the documented spec.
>>
>
> Makes sense.
>
>> 13. LDC makes some more arbitrary changes to which the reason for the 
>> change has been forgotten. Get on it David!  :o)
>>
>
> I know very little about this but hopefully most of it can go into 
> Target/get merged upstream.
>
>> 14. Reading sources asynchronously, GDC ifdefs this out.  Do we really 
>> need this?  I seem to recall that the speed increase is either 
>> negliegable or offers no benefit to compilation speed.
>>
>
> I think #ifdefed or dropped are both fine.
>
>> 15. Deal with all C++ -> D conversion
>
> Yeah.
>
>> 1

Re: dtutor.org: a call to action

[H. S. Teoh]

On Sun, May 05, 2013 at 08:55:29PM -0400, Tyro[17] wrote:
[...]
> Which reminds me... how does one create a utf-8 encoded file at the
> shell prompt?
[...]

Depends.

On Linux, most modern versions of VI and EMACS support utf-8 natively,
it's just a matter of setting up the default settings. For bash, cat,
grep, and friends, it's just a matter of setting up a UTF-8 locale on
the system (or for a single user, but if you can, might as well make it
default on the whole system). Then use a terminal like rxvt-unicode to
actually see the characters, and setup XKB to international key
composition to actually type Unicode characters, and you're good to go.

(Note: most modern distros should have all of the above setup by default
already. You really only need to do it manually when upgrading from an
older system.)

On Windows... I have no idea. Haven't used it for anything significant
for over a decade now. :-P


T

-- 
"No, John.  I want formats that are actually useful, rather than
over-featured megaliths that address all questions by piling on
ridiculous internal links in forms which are hideously over-complex." --
Simon St. Laurent on xml-dev

Re: Low-Lock Singletons In D

[Andrei Alexandrescu]

On 5/5/13 10:35 PM, dsimcha wrote:

On the advice of Walter and Andrei, I've written a blog article about
the low-lock Singleton pattern in D. This is a previously obscure
pattern that uses thread-local storage to make Singletons both
thread-safe and efficient and was independently invented by at least me
and Alexander Terekhov, an IBM researcher. However, D's first-class
treatment of thread-local storage means the time has come to move it out
of obscurity and possibly make it the standard way to do Singletons.

Article:
http://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/

Reddit:
http://www.reddit.com/r/programming/comments/1droaa/lowlock_singletons_in_d_the_singleton_pattern/


The reddit post is in need for upvotes to make it on the /r/programming 
front page. I think posting time wasn't the best: Saturday is the worst 
day to post anything 
(http://www.slideshare.net/babasave/the-hidden-secrets-of-successful-reddit-posts).


Anyhow, I've also posted to https://news.ycombinator.com/item?id=5660897

Vote up!


Andrei

Re: DIP 37: Importing Packages as if They Were Modules

[Daniel Murphy]

"deadalnix"  wrote in message 
news:vyytwcgofkilgcyoq...@forum.dlang.org...
> On Monday, 6 May 2013 at 03:16:31 UTC, Jonathan M Davis wrote:
>> This DIP (which is similar to DIP 15) was discussed with Walter and 
>> Andrei at
>> dconf 2013:
>>
>> http://wiki.dlang.org/DIP37
>>
>> They verbally approved it in that discussion and it has already been
>> implemented by Daniel Murpy (though it hasn't been merged in yet):
>>
>> https://github.com/D-Programming-Language/dmd/pull/1961
>>
>> There is also an enhancement request for it:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=10022
>>
>> The idea is very simple and does not require large changes to the 
>> compiler to
>> work as it mostly takes advantage of what the module system and imports
>> already do. However, it probably does merit having an actual DIP for it 
>> as
>> well as a public discussion, so I've created a DIP for it and am opening 
>> this
>> thread so that we can discuss it.
>>
>
> I would prefer to find the package file in std/datetime.d so no change is 
> required in lookup rules. Whatever the naming convention is, I'm all for 
> it.

Using 'package' means you can't actually explicitly name the module.  Not 
sure why you'd want/need to... With the lookup rules this shouldn't actually 
be a problem.

The of your suggestion downside is that you then don't have the entire 
package contents inside the package directory.  I think that would be a 
pain. 

Re: Migrating D front end to D - post Dconf

[Walter Bright]

When devising solutions, I want to prefer solutions that do not rely on 
#ifdef/#endif. I've tried to scrub those out of the dmd front end source code.

Re: DIP 37: Importing Packages as if They Were Modules

[Timothee Cour]

under DIP37, assuming Clock is under std.datetime.common, will we have:

fullyQualifiedName!Clock == std.datetime.common.Clock,
whereas currently we have: fullyQualifiedName!Clock == std.datetime.Clock.

Likewise with moduleName!Clock, packageName, __MODULE__ etc, which
will have a different value compared to currently.
So this will result in potential code breakage for code that relies on
that. Just something to think about.

Re: Rvalue references - The resolution

[Zach the Mystic]

On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:

Static Compiler Detection (in @safe mode):

1. Do not allow taking the address of a local variable, unless 
doing a safe type 'paint' operation.


2. In some cases, such as nested, private, and template 
functions, the source is always available so the compiler can 
error on those. Because of the .di file problem, doing this 
with auto return functions is problematic.


3. Issue error on return statements where the expression may 
contain a ref to a local that is going out of scope, taking 
into account the observations.


Runtime Detection

There are still a few cases that the compiler cannot statically 
detect. For these a runtime check is inserted, which compares 
the returned ref pointer to see if it lies within the stack 
frame of the exiting function, and if it does, halts the 
program. The cost will be a couple of CMP instructions and an 
LEA. These checks would be omitted if the -noboundscheck 
compiler switch was provided.


This is a brilliant solution. I'm glad my DIP seems to have 
helped pivot the design process into this superior conclusion, 
which uses something, i.e. runtime checking, I simply didn't 
think of. I guess I didn't realize that the stack has "bounds", 
so to say.


I suppose that underneath the hood the compiler will still track 
the state of the return value using something like a 'scope' bit. 
It's just that the user code doesn't need to see this bit, which 
is probably how it should be. And it's great to realize that a 
suitable safety framework - -noboundscheck - has been found which 
already exists to encompass the checking.


I think the main data still to be researched is the slowdown with 
both compile and run times with this checking implemented - not 
that I see how to avoid it, but it's better to know than not to 
know, right?

Re: static parameters

[Jacob Carlborg]

On 2013-05-05 20:49, "Luís Marques" " wrote:


You tell me. I saw them discussed here
http://www.youtube.com/watch?v=FRfTk44nuWE
Being a syntactic sugar convenience, I thought that if they were missing
then the most likely reason would be that there were other priorities,
but as other reasons were possible (e.g. the community rejected them) I
decided to ask :-)


That's from the first D conference, in 2007 or something like that.

--
/Jacob Carlborg

Re: Rvalue references - The resolution

[Zach the Mystic]

On Sunday, 5 May 2013 at 02:36:45 UTC, Jonathan M Davis wrote:
As it is, we arguably didn't choose the best defaults with the 
attributes that
we have (e.g. @system is the default instead of @safe, and 
impure is the
default instead of pure). The result is that we have to use a 
lot of
annotations if we want to properly take advantage of the 
various language
features, whereas ideally, having to use annotations for stuff 
like @safety or
purity would be the exception. Don was complaining that one 
reason that moving
to D2 at Sociomantic looks unappealing in spite of the benefits 
is the fact
that they're going to have to add so many extra annotations to 
their code.


In the thread which appeared on github someone suggested 
'@infer', which I altered to '@auto', which gets all the 
attributes automatically, and creates the '.di' with the full 
attributes (which might actually be problematic if they change 
too often and force compilation too many times). I'm starting to 
think it might actually be quite valuable to have this annotation 
available to the programmer. What do you think?