Re: More D & Rust

[Paulo Pinto]

On Wednesday, 17 October 2012 at 17:14:59 UTC, Michael wrote:

I can't compile even hello world on both Win 7 and Win XP.

rust 0.4, latest mingw.


Try it out in Linux. Windows support is still shaky due to LLVM, 
which also has Windows issues.


If you check Rust mailing list there are a few posts about not so 
good Windows support.


I had to endure the same thing with Go, as Go team only cared 
about Linux & Mac OS X, leaving any other operating system 
support to the community.


--
Paulo

Re: make install; where do .di files go?

[David Nadlinger]

On Wednesday, 17 October 2012 at 23:33:44 UTC, Manu wrote:

That I support his comments and suggestion.


Oh, really just that then. I wasn't quite sure if you were still
worried about


Although that seems sad; D shouldn't identify its self as
the second coming of D, since that basically implies that the 
first

coming was a failure.


David

Re: Const ref and rvalues again...

[monarch_dodra]

On Thursday, 18 October 2012 at 04:30:17 UTC, Jonathan M Davis 
wrote:

On Thursday, October 18, 2012 06:24:08 jerro wrote:

What would be the problem with const ref taking rvalues?


Read the thread that I already linked to:

http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com

- Jonathan M Davis


I read the thread, and not a single one of the "problematic 
cases" are actually valid C++.


Yes: the faulty MSVC has taught people to do retarded things, or 
be afraid of things that were illegal to begin with (in 
particular, pass an rvalue to a ref, WHICH IS ILLEGAL IN C++), 
such as "increment(5)".


There is actually nothing wrong with creating a temporary when 
something is bound to a const ref, provided the compiler follows 
the rules:


*Only LValues with an EXACT type match may be passed to a 
reference.
*In regards to *const* references, RValues may be copied in a 
temporary, and that temporary bound the the ref.


I'm not saying we particularly *need* this in D (C++ has a "by 
ref" paradigm that makes it more important, but D *rarelly* ever 
passes by const ref).


But if the compiler respects the above two rules (which it 
should), then RValue to const ref is both perfectly doable and 
safe (as safe as refs get anyways).

Re: make install; where do .di files go?

[Nick Sabalausky]

On Thu, 18 Oct 2012 01:12:45 +0200
"David Nadlinger"  wrote:

> On Wednesday, 17 October 2012 at 23:08:32 UTC, Manu wrote:
> > Hear hear.
> 
> At least to me, it is not at all clear what you are trying to 
> imply with this comment.
> 

http://en.wikipedia.org/wiki/Hear_hear

Re: Const ref and rvalues again...

[Jonathan M Davis]

On Thursday, October 18, 2012 06:24:08 jerro wrote:
> What would be the problem with const ref taking rvalues?

Read the thread that I already linked to:

http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com

- Jonathan M Davis

Re: Const ref and rvalues again...

[jerro]

On Thursday, 18 October 2012 at 03:31:41 UTC, Jonathan M Davis 
wrote:

On Thursday, October 18, 2012 05:07:52 Malte Skarupke wrote:

My propsed solution is this:
- Make functions that take "ref in" arguments also accept 
rvalues.


There was some discussion of this, though that seems to me to 
be basically the

same as making const ref take rvalues only worse.


What would be the problem with const ref taking rvalues?

Re: Const ref and rvalues again...

[Jonathan M Davis]

On Thursday, October 18, 2012 05:07:52 Malte Skarupke wrote:
> My propsed solution is this:
> - Make functions that take "ref in" arguments also accept rvalues.

There was some discussion of this, though that seems to me to be basically the 
same as making const ref take rvalues only worse. Certainly, it seems 
inherently broken to me to have a function try and take its arguement by ref 
and then be given an rvalue.

> - The user can still provide an overload that accepts an rvalue,
> using the "in" keyword, and that one will be preferred over the
> "ref in" version.
> 
> 
> What do you think?

in as alias for const scope. scope is generally not applicable to structs (and 
when it is, it's not applied properly - scope currently only works properly 
for delegates), and const just puts us back at const ref again. You appear to 
be suggesting that in do something different here, and I don't think that that 
works.

The most recent, in-depth discussion on this issue can be found here: 
http://forum.dlang.org/thread/4f84d6dd.5090...@digitalmars.com

It wasn't entirely conclusive, but there _was_ some discussion on making ref 
take rvalues. I believe that more research was necessary, and I'm not sure 
where any of it stands now. One of the more promising ideas (IMHO) was to 
simply change it so that auto ref means what it was supposed to mean 
originally - that the programmer wants the argument to be passed efficiently 
but 
doesn't care whether it's an lvalue or rvalue - but some people screamed about 
that, because they've found the current version of auto ref to be useful (in 
spite of the fact that it doesn't do what it was supposed to do).

Really, I think that this comes down to us needing to figure out how to make it 
so that ref can take lvalues under at least some set of circumstances (which 
seems like a bad idea to me), or we need to come up with a parameter attribute 
which indicates that we don't want the argument copied and don't care if it's 
an lvalue or rvalue (like const& is usually used for in C++ but making it so 
that it's _exactly_ that rather than just being primarily used for that). And 
if we can't use auto ref for that, then we need to come up with a new 
attribute of some kind to do that. However, IIRC Kenji tried to change auto 
ref to do that but ran into issues of some kind. I don't know where it stands 
now.

- Jonathan M Davis

Re: Const ref and rvalues again...

[Mehrdad]

On Thursday, 18 October 2012 at 03:07:56 UTC, Malte Skarupke 
wrote:

What do you think?

Malte



I've asked for this before.
http://d.puremagic.com/issues/show_bug.cgi?id=8121


Doesn't seem to be a priority. :(

Const ref and rvalues again...

[Malte Skarupke]

Hello,

I realize that this has been discussed before, but so far there 
is no solution and this really needs to be a high priority:


We need a way for a function to declare that it doesn't want it's 
argument to be copied, but it also doesn't care whether the 
argument is an rvalue or an lvalue.


The C++ way of doing this would be to declare the argument as a 
const &. Apparently it is not desired that we do the same thing 
for const ref.


Currently, if you want that behavior, you have to write 2^n 
permutations of your function, with n being the number of 
arguments that the function takes.


Here's my attempt at passing a struct to a function that takes 
three arguments without the struct being copied:


int copyCounter = 0;
struct CopyCounter
{
this(this) { ++copyCounter; }
}
void takeThree(ref in CopyCounter a, ref in CopyCounter b, ref in 
CopyCounter c)

{
writeln("took three");
}
void takeThree(in CopyCounter a, ref in CopyCounter b, ref in 
CopyCounter c)

{
takeThree(a, b, c);
}
void takeThree(ref in CopyCounter a, in CopyCounter b, ref in 
CopyCounter c)

{
takeThree(a, b, c);
}
void takeThree(ref in CopyCounter a, ref in CopyCounter b, in 
CopyCounter c)

{
takeThree(a, b, c);
}
void takeThree(in CopyCounter a, in CopyCounter b, ref in 
CopyCounter c)

{
takeThree(a, b, c);
}
void takeThree(in CopyCounter a, ref in CopyCounter b, in 
CopyCounter c)

{
takeThree(a, b, c);
}
void takeThree(ref in CopyCounter a, in CopyCounter b, in 
CopyCounter c)

{
takeThree(a, b, c);
}
void takeThree(in CopyCounter a, in CopyCounter b, in CopyCounter 
c)

{
takeThree(a, b, c);
}
static CopyCounter createCopyCounter()
{
return CopyCounter();
}
void main()
{
CopyCounter first;
CopyCounter second;
CopyCounter third;
takeThree(first, second, third);
takeThree(createCopyCounter(), second, createCopCounter());
assert(copyCounter == 0); // yay, works
}


My propsed solution is this:
- Make functions that take "ref in" arguments also accept rvalues.
- The user can still provide an overload that accepts an rvalue, 
using the "in" keyword, and that one will be preferred over the 
"ref in" version.



What do you think?

Malte

Re: Bits rotations

[H. S. Teoh]

On Thu, Oct 18, 2012 at 04:55:38AM +0200, Adam D. Ruppe wrote:
> On Thursday, 18 October 2012 at 02:36:59 UTC, bearophile wrote:
> >uint foo(in uint x) pure nothrow {
> >return (x << 11) | (x >> (32 - 11));
> >}
> 
> Why would you write that instead of using rol(x, 11) today?
> 
> uint rol(in uint x, in uint y) pure nothrow {
> return (x << y) | (x >> (32 - y));
> }
[...]
> Perhaps we should add that rol function to the stdlib to save people
> from quickly doing it themselves, but there's no need to do anything
> beyond this simple function.

+1, add this to core.bitop.


T

-- 
If you compete with slaves, you become a slave. -- Norbert Wiener

Re: Bits rotations

[Adam D. Ruppe]

On Thursday, 18 October 2012 at 02:36:59 UTC, bearophile wrote:

uint foo(in uint x) pure nothrow {
return (x << 11) | (x >> (32 - 11));
}


Why would you write that instead of using rol(x, 11) today?

uint rol(in uint x, in uint y) pure nothrow {
return (x << y) | (x >> (32 - y));
}

uint foo(in uint x) pure nothrow {
return rol(x, 11);
}

the rest is the same. Compile it and see a rol instruction, 
inlined, in the main function.


Though there is a bit of extra spam around it, some movs that 
don't seem necessary to me.


Here's the top function so you can see the movs:

 <_D5test43rolFNaNbxkxkZk>:
   0:   55  push   ebp
   1:   8b ec   movebp,esp
   3:   50  push   eax
   4:   8b 45 08moveax,DWORD PTR [ebp+0x8]
   7:   8b 4d fcmovecx,DWORD PTR [ebp-0x4]
   a:   8b e5   movesp,ebp
   c:   d3 c0   roleax,cl
   e:   5d  popebp
   f:   c2 04 00ret0x4
  12:   90  nop
  13:   90  nop



Perhaps we should add that rol function to the stdlib to save 
people from quickly doing it themselves, but there's no need to 
do anything beyond this simple function.

Re: Regarding hex strings

[H. S. Teoh]

On Thu, Oct 18, 2012 at 02:45:10AM +0200, bearophile wrote:
[...]
> hex strings are useful, but I think they were invented in D1 when
> strings were convertible to char[]. But today they are an array of
> immutable UFT-8, so I think this default type is not so useful:
> 
> void main() {
> string data1 = x"A1 B2 C3 D4"; // OK
> immutable(ubyte)[] data2 = x"A1 B2 C3 D4"; // error
> }
> 
> 
> test.d(3): Error: cannot implicitly convert expression
> ("\xa1\xb2\xc3\xd4") of type string to ubyte[]
[...]

Yeah I think hex strings would be better as ubyte[] by default.

More generally, though, I think *both* of the above lines should be
equally accepted.  If you write x"A1 B2 C3" in the context of
initializing a string, then the compiler should infer the type of the
literal as string, and if the same literal occurs in the context of,
say, passing a ubyte[], then its type should be inferred as ubyte[], NOT
string.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

Regarding hex strings

[bearophile]

(Repost)

hex strings are useful, but I think they were invented in D1 when 
strings were convertible to char[]. But today they are an array 
of immutable UFT-8, so I think this default type is not so useful:


void main() {
string data1 = x"A1 B2 C3 D4"; // OK
immutable(ubyte)[] data2 = x"A1 B2 C3 D4"; // error
}


test.d(3): Error: cannot implicitly convert expression 
("\xa1\xb2\xc3\xd4") of type string to ubyte[]



Generally I want to use hex strings to put binary data in a 
program, so usually it's a ubyte[] or uint[].


So I have to use something like:

auto data3 = cast(ubyte[])(x"A1 B2 C3 D4".dup);


So maybe the following literals are more useful in D2:

ubyte[] data4 = x[A1 B2 C3 D4];
uint[]  data5 = x[A1 B2 C3 D4];
ulong[] data6 = x[A1 B2 C3 D4 A1 B2 C3 D4];

Bye,
bearophile

Re: How mutable is immutable?

[Malte Skarupke]

The issue is that you're thinking as you would in Java.

I guess the rule in D for immutable is this: Immutable data won't 
change as long as it exists.


The last part of that sentence would be a stupid thing to say in 
Java because things don't just cease to exist while you're still 
doing something with them. That is not the case in D.


That being said it's very unlikely that you will ever run into 
this situation. You have to end the lifetime of the object 
manually to run into these issues. And in that case it'll be very 
easy to figure out what's wrong.

Re: Optimizing out unnecessary allocations

[Walter Bright]

On 10/17/2012 11:10 AM, David Nadlinger wrote:
> Thus, my question: Is it legal for a D compiler to eliminate dead GC 
allocations
> (given that there are no side effects due to constructors, …)?

Yes.

The test case can be fixed by attempting to use the result of new.

Re: make install; where do .di files go?

[Manu]

On 18 October 2012 02:12, David Nadlinger  wrote:

> On Wednesday, 17 October 2012 at 23:08:32 UTC, Manu wrote:
>
>> Hear hear.
>>
>
> At least to me, it is not at all clear what you are trying to imply with
> this comment.


That I support his comments and suggestion.

Re: make install; where do .di files go?

[David Nadlinger]

On Wednesday, 17 October 2012 at 23:08:32 UTC, Manu wrote:

Hear hear.


At least to me, it is not at all clear what you are trying to 
imply with this comment.


David

Re: make install; where do .di files go?

[Manu]

On 18 October 2012 00:39, Nick Sabalausky <
seewebsitetocontac...@semitwist.com> wrote:

> On Wed, 17 Oct 2012 15:03:41 +0300
> Manu  wrote:
> >
> > Well let's attempt to begin that process in that case :)
> >
>
> I agree.
>
> > why include/d2? include/d/ seems much better... what are the chances a
> > library have both a d1 and d2 version which may conflict in include/d?
> >
>
> While this doesn't solve the issue of multiple versions of the same lib,
> I think "multiple versions of the same lib" is an issue that can't be
> properly solved until we have a standard package manager, anyway.
>
> So my vote goes for sticking everything (*except* phobos and druntime
> since those are tied to a specific version of the compiler)
> into /usr/include/d2
>
> I don't think we should be remotely worried about calling it "d2",
> because really the whole "D2 is now called D" thing is little more than
> a marketing/branding/defaults matter, and we're not talking about
> evangelizing D here, we're just talking about a technical
> implementation matter. And even if "D" now means "D2" by default, the
> D1/D2 monikers are still very useful when disambiguation is needed,
> which is exactly the case here. (I don't see Pythoners worrying about
> "Let's avoid calling v3.x 'Python 3'.")
>
> And even if one *could* argue that there's little chance of technical
> conflicts, using '/usr/include/d2' *guarantees* there won't be any
> conflicts, and doesn't cause any real problem, so the whole question
> becomes completely irrelevant anyway. '/usr/include/d' might have
> issues, '/usr/include/d2' *will work*, period. So I say let's just go
> with '/usr/include/d2' and be done with it. Then we can get around to
> adding a proper package manager later to solve the "multiple versions
> of the same lib", but in the meantime at least we've made progress.
>

Hear hear.

Re: make install; where do .di files go?

[Jordi Sayol]

Al 18/10/12 00:03, En/na Mike Wey ha escrit:
>> The problem here is that the "libtango-headers" maintainer decided to place 
>> "object.di" directly into "/usr/include/d", overriding to use this directory 
>> for any other D compiler/version.
>>
> 
> Is there any chance of getting the package changed?
> 

Don't know, this is the link to the debian source page: 
http://packages.debian.org/source/sid/libtango

-- 
Jordi Sayol

Re: make install; where do .di files go?

[Mike Wey]

On 10/17/2012 05:39 PM, Jordi Sayol wrote:

Al 17/10/12 14:03, En/na Manu ha escrit:


why include/d2? include/d/ seems much better... what are the chances a library 
have both a d1 and d2 version which may conflict in include/d?



A practical example:
Imagine that you installs the libray "foo" for D, and places the sources at 
"/usr/include/d/foo" directory, so you need to add "-I/usr/include/d" as compiler 
argument.

In Debian/Ubuntu there is the "libtango-headers" package, which install, among others, 
"/usr/include/d/object.di". This Tango "object.di" breaks d2, so you will not be able to compile anything 
with the "-I/usr/include/d" argument, and so, you cannot compile against your "foo" library.

The problem here is that the "libtango-headers" maintainer decided to place "object.di" 
directly into "/usr/include/d", overriding to use this directory for any other D compiler/version.



Is there any chance of getting the package changed?

--
Mike Wey

Re: Optimizing out unnecessary allocations

[David Nadlinger]

On Wednesday, 17 October 2012 at 18:10:26 UTC, David Nadlinger 
wrote:
Thus, my question: Is it legal for a D compiler to eliminate 
dead GC allocations (given that there are no side effects due 
to constructors, …)?


Walter confirmed that this should be allowed. Pull request fixing 
the test: https://github.com/D-Programming-Language/dmd/pull/1191


David

Re: make install; where do .di files go?

[David Nadlinger]

On Wednesday, 17 October 2012 at 21:39:15 UTC, Nick Sabalausky 
wrote:
So my vote goes for sticking everything (*except* phobos and 
druntime

since those are tied to a specific version of the compiler)
into /usr/include/d2


That's also what I do for Thrift.

David

Re: make install; where do .di files go?

[Nick Sabalausky]

On Wed, 17 Oct 2012 15:03:41 +0300
Manu  wrote:
> 
> Well let's attempt to begin that process in that case :)
> 

I agree.

> why include/d2? include/d/ seems much better... what are the chances a
> library have both a d1 and d2 version which may conflict in include/d?
> 

While this doesn't solve the issue of multiple versions of the same lib,
I think "multiple versions of the same lib" is an issue that can't be
properly solved until we have a standard package manager, anyway.

So my vote goes for sticking everything (*except* phobos and druntime
since those are tied to a specific version of the compiler)
into /usr/include/d2

I don't think we should be remotely worried about calling it "d2",
because really the whole "D2 is now called D" thing is little more than
a marketing/branding/defaults matter, and we're not talking about
evangelizing D here, we're just talking about a technical
implementation matter. And even if "D" now means "D2" by default, the
D1/D2 monikers are still very useful when disambiguation is needed,
which is exactly the case here. (I don't see Pythoners worrying about
"Let's avoid calling v3.x 'Python 3'.")

And even if one *could* argue that there's little chance of technical
conflicts, using '/usr/include/d2' *guarantees* there won't be any
conflicts, and doesn't cause any real problem, so the whole question
becomes completely irrelevant anyway. '/usr/include/d' might have
issues, '/usr/include/d2' *will work*, period. So I say let's just go
with '/usr/include/d2' and be done with it. Then we can get around to
adding a proper package manager later to solve the "multiple versions
of the same lib", but in the meantime at least we've made progress.

Re: Optimizing out unnecessary allocations

[Artur Skawina]

On 10/17/12 23:00, David Nadlinger wrote:
> On Wednesday, 17 October 2012 at 20:37:53 UTC, Artur Skawina wrote:
>> Well, I think such optimizations are fine (as long as documented and there
>> exists alternatives), but note that this testcase checks for the case where
>> the object size calculation overflows. Ie it must not succeed.
> 
> Could you elaborate on that? It strikes me that this is either a GC 
> implementation detail or invalid D code in the first place (i.e. should not 
> be expected to compile resp. is undefined behavior).

Well, eg on a 32-bit platform the newly allocated memory object would need to
have a size of 8*2G == 16G. I guess you could see it as a GC implementation
detail, but that allocation can never succeed, simply because such an object
would be larger than the available address space, hence can't be mapped 
directly.
The 'new long[ptrdiff_t.max]' case can be caught at compile time, but a 
different
'new long[runtime_variable_which_happens_to_be_2G]' can not, and then the GC 
MUST
catch the overflow, instead of allocating a ((size_t)long.sizeof*2G) sized 
object
Which is what I assume that test was meant to check.

But even in the constant, statically-checkable case, would it make sense to 
ignore
the error if the allocation was "dead"? If nothing ever accesses the new object,
ignoring the error seems harmless. But is it OK to allow faulty code to 
silently run
long as the compiler can prove that the bug won't be triggered? Will every 
compiler
make the same decision? Would a different optimization level cause the error to 
be
thrown? For these reasons, silently optimizing away "harmless", but buggy code 
is
not a good idea.

artur

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Wed, Oct 17, 2012 at 12:55:56PM -0700, Jonathan M Davis wrote:
[...]
> I'm increasingly convinced that input ranges which are not forward
> ranges are useless for pretty much anything other than foreach. Far
> too much requires that you be able to save the current state - and
> most stuff _inherently_ requires it such that it's not simply a
> question of implementing the function differently.

It's perfectly possible to implement joiner, chain, find, count, cmp,
equal, until, filter, map, reduce, without assuming that the value
returned by .front is persistent. Just to name a few. In fact, it's even
possible to implement cartesianProduct in which one of the ranges is an
input range.  I'd hardly call that useless.


> And adding even further restrictions on input ranges just makes it
> worse. It actually wouldn't hurt my feelings one whit if we got rid of
> the idea of input ranges entirely.

The motivating example for input ranges, at least according to TDPL, is
find(). There's nothing about find() that precludes non-forward input
ranges. A lot would be missing from the usefulness of ranges if we were
forced to only use forward ranges.


[...]
> Regardless, there's nothing in how input ranges are currently defined
> which indicates that front would ever be invalidated for _any_ type of
> range, and ByLine and ByChunk are pretty much the only ranges I've
> ever seen which invalidate previous calls to front. So, I don't see
> how you could think that they're anything but abnormal.

I can think of quite a few situations in which it's useful to not assume
that the return value of .front is persistent, which I've already
mentioned before: in-place array permutation, reused buffers for complex
computations, etc..


> And if you really want to argue that whether front can be invalidated
> or not is somehow part of the difference between an input range and a
> forward range, then the documentation on that needs to make that
> _very_ clear, and it's going to be that much worse to deal with input
> ranges which aren't forward ranges.
[...]

I think I'm not so sure about Andrei's lumping input ranges with
persistent return values from .front together with forward ranges. Some
algorithms, like findAdjacent, do not need a forward range, but they do
need a persistent .front. I do not like the idea of artificially
limiting the scope of findAdjacent just because you can't assume input
ranges' .front returns a persistent value. Like somebody else mentioned,
whether .front is transient or not is orthogonal to whether the range is
an input range or a forward range. There can be ranges whose .front is
persistent, but they can't be forward ranges for practical reasons.


T

-- 
Having a smoking section in a restaurant is like having a peeing section
in a swimming pool. -- Edward Burr 

Re: make install; where do .di files go?

[Nick Sabalausky]

On Wed, 17 Oct 2012 19:42:25 +0300
Manu  wrote:
> 
> Okay, so the problem is that an existing package has already declared
> that directory to be a standard location. so then include/d2/ then...
> I guess. Although that seems sad; D shouldn't identify its self as
> the second coming of D, since that basically implies that the first
> coming was a failure.
> 

Not really, it just means it's part of the v2.x line. Debian 6
doesn't mean that Debians 1-5 were failures. Lots of software has
breaking revisions with a new major version number, and so then
sometimes you need to disambiguate.

Re: make install; where do .di files go?

[Nick Sabalausky]

On Wed, 17 Oct 2012 15:08:13 +0300
Manu  wrote:

> On 17 October 2012 12:28, Nick Sabalausky <
> seewebsitetocontac...@semitwist.com> wrote:
> 
> > On Tue, 16 Oct 2012 14:56:02 -0700
> > "H. S. Teoh"  wrote:
> > >
> > > How else would you have multiple versions of the same lib, though?
> > > They can't all live in the same place since files will conflict.
> > >
> >
> > Unfortunately, I see only two realistic possibilities:
> >
> > A. Forget about system-wide lib installation and pass -I... to the
> > compiler for each lib you're using. Kind of a pain but...
> >
> > B. Wait for a proper D package manager.
> >
> > Personally, I choose "A", at least for the time being ;)
> >
> 
> What about C: Nominate a place, just like C does??
> I don't see the problem. Where is the essential difference from
> system-wide installed C libraries?
> 

I was referring to the "How else would you have multiple versions of
the same lib". If all libs are put into the same directory, then you
can't have multiple versions of the same one without giving each
version a different name. I wouldn't want to have to search/replace all
"import foobar-1-0;" with "import foobar-1-11;" everytime I upgrade a
lib.

I guess what you could do is have a directory structure like this:

/usr/include/d2/foobar/1.0/foobar.d
/usr/include/d2/foobar/1.7/foobar.d
/usr/include/d2/foobar/2.1/foobar.d

But then you'd still have to use -I... when you import anything, which
removes some of the benefit of having one standard installation
directory for libs. But I guess that is still an improvement over just
not having any standard install directory.

Re: Optimizing out unnecessary allocations

[David Nadlinger]

On Wednesday, 17 October 2012 at 20:37:53 UTC, Artur Skawina 
wrote:
Well, I think such optimizations are fine (as long as 
documented and there
exists alternatives), but note that this testcase checks for 
the case where

the object size calculation overflows. Ie it must not succeed.


Could you elaborate on that? It strikes me that this is either a 
GC implementation detail or invalid D code in the first place 
(i.e. should not be expected to compile resp. is undefined 
behavior).


David

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Timon Gehr]

On 10/17/2012 07:20 PM, Andrei Alexandrescu wrote:

On 10/16/12 3:41 PM, H. S. Teoh wrote:

I think with D's compile-time introspection capabilities, it _should_ be
possible to implement a generic deepCopy template that works for any
type.

Of course, then one has to address tricky issues such as complex data
structures that have interlinking parts; a blind recursive deep-copy may
not have the desired effect (e.g., if we're deep-copying a graph and
there are multiple paths (via references) to the same node, then we
shouldn't end up with multiple copies of that node). Some care will also
need to be taken to deal with cyclic structures, etc.. And some
optimizations can probably be done to avoid copying immutable objects,
since that would be a waste of time&  memory.

Probably some kind of graph traversal algorithm can be used to address
these issues, I think, perhaps with the help of an AA or two to recreate
the original linking structure in the copy.


Yes, deepDup should be implementable as a library and use a temporary
dictionary of already-duplicated items to avoid infinite recursion.

We should add that to Phobos - could you please add a task to trello.


Andrei



A deepDup is missing information about what is representation and what
is just a reference kept in order to access external data, so it is
quite useless.

Re: Optimizing out unnecessary allocations

[Artur Skawina]

On 10/17/12 20:10, David Nadlinger wrote:
> I recently revived an LDC optimization pass (originally written by Frits van 
> Bommel) that can remove dead allocations and promote small GC allocations to 
> stack memory by recognizing the related druntime calls.
> 
> However, I didn't commit it to the main branch yet because it causes a test 
> case in the DMD test suite to fail: 
> https://github.com/D-Programming-Language/dmd/blob/eaa03fefeb1a698f586d5f5a09068f3433bf4b29/test/runnable/testgc2.d
> 
> The test is intended to make sure that the garbage collector properly handles 
> out-of-memory situations, but in doing so assumes that the compiler can't 
> touch the array allocations. However, when building with optimizations on, 
> LDC recognizes the fact that the allocations are unused and subsequently 
> removes them, causing the "assert(0)"s to be hit:
> 
> ———
> try {
>   long[] l = new long[ptrdiff_t.max];
>   assert(0);
> }
> catch (OutOfMemoryError o){}
> ———
> 
> Thus, my question: Is it legal for a D compiler to eliminate dead GC 
> allocations (given that there are no side effects due to constructors, …)?
> 
> I'd strongly argue in favor of such optimizations to be legal, because not 
> allowing them would eliminate quite a few optimization possibilities. There 
> is also precedent for such behavior; many C compilers treat malloc() in a 
> similar fashion.


Well, I think such optimizations are fine (as long as documented and there
exists alternatives), but note that this testcase checks for the case where
the object size calculation overflows. Ie it must not succeed.
Would ignoring the error when nothing accesses the object make sense?

artur

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[monarch_dodra]

On Wednesday, 17 October 2012 at 19:42:39 UTC, bearophile wrote:

Andrei Alexandrescu:


You closed it.

Also that bug has nothing to do with this topic because you 
can't compile the buggy code and have it silently do the wrong 
thing.



Andrei


Sorry.

A solution is to introduce a "byLineFast" that is similar to 
the current "byLine", and make "byLine" copy.


Another solution is to keep only "byLine" and give it a 
compile-time boolean argument to disable the copy, that is 
active on default.


Bye,
bearophile


Given that "byLine" already exists, I'm not sure we can change it 
now. But I wouldn't be against adding a "byLineSlow" or something.


However, if we could start again, I'd *definitely* favor a deep 
copying "byLine" by default, and have a faster, but harder to use 
"byLineFast".

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[monarch_dodra]

On Wednesday, 17 October 2012 at 19:14:12 UTC, Jonathan M Davis 
wrote:
On Wednesday, October 17, 2012 12:39:13 Andrei Alexandrescu 
wrote:

On 10/16/12 1:28 PM, Jonathan M Davis wrote:
> So, it's fine that ByLine is a range as long as we're 
> willing to put up
> with it not working with a lot of range-based functions 
> because of its
> abnormal behavior. But I don't think that it's at all 
> reasonable for
> range-based functions in general to not be able to rely on 
> front
> returning the same type every time or on its value 
> disappearing or
> becoming invalid in some way after a call to popFront. 
> That's completely

> untenable IMHO.

Then what is to you the difference between an input range and 
a forward

range?


Whether you can get a copy of the range. If you call save, you 
can save its
current state and have two copies of the range to operate on 
separately,
That's completely different from whether front can be kept 
around or not. It's
perfectly possible to have an input range whose previous front 
does not get
invalidated by a call to popFront. ByLine would be that way if 
it allocated a
new buffer instead of reusing the old one. It just doesn't do 
that because it's

less efficient to do so.

- Jonathan M Davis


This.

When you think about it, byLine *could* be a ForwardRange (it 
could save its pget position in the file), allowing it to 
backtrack, but that *still* wouldn't prevent it from overwriting 
its own internal buffer on calls to front: That is just a detail 
of its implementation.


A range's "Input-ness" or "Forward-ness" is completely orthogonal 
from the returned front's transitiveness.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Wednesday, October 17, 2012 13:15:12 Andrei Alexandrescu wrote:
> On 10/16/12 3:07 PM, H. S. Teoh wrote:
> > Perhaps mark ranges with an .isTransient property
> 
> isTransient!R is exactly the same thing as isInputRange!R &&
> !isForwardRange!R.

In what way? There is nothing anywhere that states that an input range's front 
could be invalidated upon a call to popFront. There's nothing inherent in the 
fact that range can't be saved that makes it so that front must be invalidated 
upon a call to popFront. You could easily define an input range of bytes over a 
file where front is perfectly valid after a call to popFront, because it's a 
value type. You could also define ByLine so that its front is perfectly valid 
after a call to popFront. It's just that it requires that a new buffer be 
allocated instead of reusing the buffer. That has nothing to do with the fact 
that its incapable of copying its state such that you could have multiple 
copies of it being iterated over separately. I don't see anything in the 
concept or definition of input ranges which implies that front would be 
invalidated by a call to popFront.

I'm increasingly convinced that input ranges which are not forward ranges are 
useless for pretty much anything other than foreach. Far too much requires 
that you be able to save the current state - and most stuff _inherently_ 
requires it such that it's not simply a question of implementing the function 
differently. And adding even further restrictions on input ranges just makes it 
worse. It actually wouldn't hurt my feelings one whit if we got rid of the 
idea of input ranges entirely. It's perfectly possible to implement ranges 
like ByLine as forward ranges. It just requires a bit more work. But they'd be 
_way_ more useful if they were. In my experience the only time that you don't 
need to dup what ByLine or ByChunk gives you is when all you need is foreach, 
and if that's really the case, then opApply can be used for foreach, and 
ByLine and ByChunk can be defined in ways that actually allow them to not only 
not invalidate the result of previous front calls but to actually be full-on 
forward ranges, making them actually useful for things beyond foreach.

Regardless, there's nothing in how input ranges are currently defined which 
indicates that front would ever be invalidated for _any_ type of range, and 
ByLine and ByChunk are pretty much the only ranges I've ever seen which 
invalidate previous calls to front. So, I don't see how you could think that 
they're anything but abnormal. And if you really want to argue that whether 
front can be invalidated or not is somehow part of the difference between an 
input range and a forward range, then the documentation on that needs to make 
that _very_ clear, and it's going to be that much worse to deal with input 
ranges which aren't forward ranges.

- Jonathan M Davis

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[bearophile]

Andrei Alexandrescu:


You closed it.

Also that bug has nothing to do with this topic because you 
can't compile the buggy code and have it silently do the wrong 
thing.



Andrei


Sorry.

A solution is to introduce a "byLineFast" that is similar to the 
current "byLine", and make "byLine" copy.


Another solution is to keep only "byLine" and give it a 
compile-time boolean argument to disable the copy, that is active 
on default.


Bye,
bearophile

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Wednesday, October 17, 2012 12:39:13 Andrei Alexandrescu wrote:
> On 10/16/12 1:28 PM, Jonathan M Davis wrote:
> > So, it's fine that ByLine is a range as long as we're willing to put up
> > with it not working with a lot of range-based functions because of its
> > abnormal behavior. But I don't think that it's at all reasonable for
> > range-based functions in general to not be able to rely on front
> > returning the same type every time or on its value disappearing or
> > becoming invalid in some way after a call to popFront. That's completely
> > untenable IMHO.
> 
> Then what is to you the difference between an input range and a forward
> range?

Whether you can get a copy of the range. If you call save, you can save its 
current state and have two copies of the range to operate on separately, 
That's completely different from whether front can be kept around or not. It's 
perfectly possible to have an input range whose previous front does not get 
invalidated by a call to popFront. ByLine would be that way if it allocated a 
new buffer instead of reusing the old one. It just doesn't do that because it's 
less efficient to do so.

- Jonathan M Davis

Re: More D & Rust

[thedeemon]

On Wednesday, 17 October 2012 at 18:38:25 UTC, 
DypthroposTheImposter wrote:
 I guess D doesn't support unique_ptr like behavior, humm.. I 
like this in C++, is it possible in D?


http://dlang.org/phobos/std_typecons.html#Unique
?

Re: More D & Rust

[DypthroposTheImposter]

 I guess D doesn't support unique_ptr like behavior, humm.. I 
like this in C++, is it possible in D?

Re: Import improvement

[foobar]

On Wednesday, 17 October 2012 at 15:16:12 UTC, Andrei 
Alexandrescu wrote:

On 10/16/12 2:49 AM, Jacob Carlborg wrote:

On 2012-10-16 02:10, Peter Alexander wrote:

It's cute, but I think it is terribly misleading. I wouldn't 
recommend

that to anyone.


I agree. I'm using foo.bar._, that's the same used by Scala.


Sounds good. Arbitrary + precedent > arbitrary.

Andrei


Let's be accurate here:
Meaningful >>> Arbitrary + precedent > arbitrary.

If I want to truly import an _entire_ package than both:
import package.all;
import package.*;
make sense/ meaningful.

If I want to have a special file that includes specific public 
imports for the package's public API than it should be called 
appropriately. e.g:

import package.api;

I've seen such usage of an "api" package in Google's Android 
platform for instance.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[monarch_dodra]

On Wednesday, 17 October 2012 at 18:13:42 UTC, Andrei 
Alexandrescu wrote:

On 10/17/12 1:29 PM, monarch_dodra wrote:

On Wednesday, 17 October 2012 at 17:15:14 UTC, Andrei
Alexandrescu wrote:

On 10/16/12 3:07 PM, H. S. Teoh wrote:

Perhaps mark ranges with an .isTransient property


isTransient!R is exactly the same thing as isInputRange!R &&
!isForwardRange!R.

Andrei


Technically, (isTransient!R) is just a subset of 
(isInputRange!R

&& !isForwardRange!R)

"byDChar" (if it existed), would be a perfectly valid
non-transient input only range.


Depends on implementation - popFront may actually wipe the 
character.


Andrei


"byDChar" (if it existed), *could* be a perfectly valid 
non-transient input only range, if the implementation returns the 
character by value. :)

Optimizing out unnecessary allocations

[David Nadlinger]

I recently revived an LDC optimization pass (originally written 
by Frits van Bommel) that can remove dead allocations and promote 
small GC allocations to stack memory by recognizing the related 
druntime calls.


However, I didn't commit it to the main branch yet because it 
causes a test case in the DMD test suite to fail: 
https://github.com/D-Programming-Language/dmd/blob/eaa03fefeb1a698f586d5f5a09068f3433bf4b29/test/runnable/testgc2.d


The test is intended to make sure that the garbage collector 
properly handles out-of-memory situations, but in doing so 
assumes that the compiler can't touch the array allocations. 
However, when building with optimizations on, LDC recognizes the 
fact that the allocations are unused and subsequently removes 
them, causing the "assert(0)"s to be hit:


———
try {
  long[] l = new long[ptrdiff_t.max];
  assert(0);
}
catch (OutOfMemoryError o){}
———

Thus, my question: Is it legal for a D compiler to eliminate dead 
GC allocations (given that there are no side effects due to 
constructors, …)?


I'd strongly argue in favor of such optimizations to be legal, 
because not allowing them would eliminate quite a few 
optimization possibilities. There is also precedent for such 
behavior; many C compilers treat malloc() in a similar fashion.


David

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/17/12 1:29 PM, monarch_dodra wrote:

On Wednesday, 17 October 2012 at 17:15:14 UTC, Andrei
Alexandrescu wrote:

On 10/16/12 3:07 PM, H. S. Teoh wrote:

Perhaps mark ranges with an .isTransient property


isTransient!R is exactly the same thing as isInputRange!R &&
!isForwardRange!R.

Andrei


Technically, (isTransient!R) is just a subset of (isInputRange!R
&& !isForwardRange!R)

"byDChar" (if it existed), would be a perfectly valid
non-transient input only range.


Depends on implementation - popFront may actually wipe the character.

Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/17/12 12:57 PM, David Nadlinger wrote:

On Wednesday, 17 October 2012 at 15:14:44 UTC, Andrei Alexandrescu wrote:

Such issues do happen, are relatively rare, and are virtually untested
because there's been no unittests with a deliberately "bad" input
range. Although of course we do need to add the appropriate fixes and
unittests, I'm not worried about it at all systemically.


If an abstraction encourages use in a way which leads to hard-to-detect
logic bugs that do not occur with the most common test cases, this is
_exactly_ the thing we should be worried about!


When I designed input ranges vs. forward ranges there were long 
discussion on how to distinguish them. If you have a better design it 
would probably not influence the state of the affair, but it would be a 
good discussion to have. FWIW I can already think of a couple but all 
rely on UFCS.


Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/17/12 12:53 PM, H. S. Teoh wrote:

On Wed, Oct 17, 2012 at 12:39:13PM -0400, Andrei Alexandrescu wrote:

On 10/16/12 1:28 PM, Jonathan M Davis wrote:

So, it's fine that ByLine is a range as long as we're willing to put
up with it not working with a lot of range-based functions because of
its abnormal behavior. But I don't think that it's at all reasonable
for range-based functions in general to not be able to rely on front
returning the same type every time or on its value disappearing or
becoming invalid in some way after a call to popFront. That's
completely untenable IMHO.


Then what is to you the difference between an input range and a
forward range?

[...]

So what you're saying, is that we cannot rely on the value of .front
after popFront() is called, and that the only way to ensure the validity
of .front is to use a forward range's .save, and access the saved copy's
.front?


Affirmative.


It makes sense to me, but then we'd need to revise quite a lot of code
in Phobos, as I've seen quite a number of places where .front is cached
in some local variable or struct field, which would be invalid by your
definition.


Yes. Only code that ostensibly works with input ranges needs to be reviewed.


Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/17/12 12:39 PM, H. S. Teoh wrote:

On Wed, Oct 17, 2012 at 12:22:55PM -0400, Andrei Alexandrescu wrote:

On 10/16/12 11:17 AM, H. S. Teoh wrote:

OTOH, if we clearly state that .front may not persist past the next
popFront(), then it would be up to the caller to .dup the return
value, or otherwise make a safe copy of it (or use the value before
calling popFront()).

The current ambiguous situation leads to one range doing one thing,
and another range doing something else, and either way, either this
code will break or that code will break.


Input ranges don't guarantee preservation of .front upon calling
.popFront. They do allow several to .front (without an intervening
call to .popFront) that should return the same result (i.e. a
one-element buffer).

[...]

This is contrary to what Jonathan has been saying. So which is it:
should .front return a persistent value, or a transient value that may
get invalidated by popFront? I have been assuming it's the latter, but
others have been saying it's the former.


The latter for input ranges, the former for anything stronger.


As Jonathan pointed out, some algorithms won't work with transient
.front values. I can think of one: findAdjacent, which requires that the
previous value of .front be preserved (otherwise you couldn't compare it
with the following element -- the template has no reliable way of saving
the previous value since we don't have a reliable way to deep-copy a
possibly complex data structure that might be getting overwritten by
popFront).


findAdjacent correctly restricts itself to work only with forward ranges.


Other algorithms, like joiner, currently don't work with transient
.front values, but can be made to work by tweaking the implementation.
People will hate me for saying this, but I think Phobos algorithms
*should* be written to work with minimal expectations, so I don't
consider it unreasonable to expect std.algorithm to work with transient
.front values where possible. (User code is a different matter, of
course). There *are* cases for which it can't work, which is why I
proposed the isTransient property, but people didn't seem to like that
idea.


No isTransient is needed.


Andrei

Re: isInfinite isInadequate

[Andrei Alexandrescu]

On 10/17/12 8:18 AM, Peter Alexander wrote:

2. Make cycle assert when the source range is empty.


I think this is sensible.

Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/17/12 5:59 AM, bearophile wrote:

monarch_dodra:


Can't we just have a "byLineDeep" or "byLineSafe", but that returns
actual deep copied immutable strings?


See this old enhancement of mine they have closed:
http://d.puremagic.com/issues/show_bug.cgi?id=4474


You closed it.

Also that bug has nothing to do with this topic because you can't 
compile the buggy code and have it silently do the wrong thing.



Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 5:38 PM, H. S. Teoh wrote:

I was thinking probably a bool[void*] should work as a way of keeping
track of what has already been copied, so a simple depth-first traversal
should work.


Should be void*[void*] to also get the actual new location.

Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 5:51 PM, deadalnix wrote:

Le 16/10/2012 21:21, Jonathan M Davis a écrit :

On Tuesday, October 16, 2012 12:07:01 H. S. Teoh wrote:

Perhaps mark ranges with an .isTransient property (which can be an enum
so it doesn't waste any space), and range-based functions that require
non-transient ranges will refuse to work with a transient range. Or
alternatively, switch to a different implementation that takes
transience into account (which may be slower, etc., but the important
thing is to do it right -- after all, D's motto is safe by default,
unsafe if you ask for it).


Not a bad idea, though it's still arguably a bit disgusting to
potentially
have to check for that all over the place. Inevitably, most functions
won't
check, and ByLine _still_ won't work. Yes, Phobos would presumably end up
checking in most cases, but I suspect that little else will. We
arguably have
way to many things to check about ranges as it is. So, I'd be far more
tempted
to just change ByLine to use opApply rather than adding the extra
complication
of isTransient to the standard library just for this one use case.



I have to agree here. Even if I see several uses outside byLine, this is
known that most code will not take that into account. Adding a property
isn't going to help.


The property is already there - .save. The question boils down to 
whether input ranges should be acceptable as ranges or not.


Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[monarch_dodra]

On Wednesday, 17 October 2012 at 17:15:14 UTC, Andrei
Alexandrescu wrote:

On 10/16/12 3:07 PM, H. S. Teoh wrote:

Perhaps mark ranges with an .isTransient property


isTransient!R is exactly the same thing as isInputRange!R && 
!isForwardRange!R.


Andrei


Technically, (isTransient!R) is just a subset of (isInputRange!R
&& !isForwardRange!R)

"byDChar" (if it existed), would be a perfectly valid
non-transient input only range.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 3:41 PM, H. S. Teoh wrote:

I think with D's compile-time introspection capabilities, it _should_ be
possible to implement a generic deepCopy template that works for any
type.

Of course, then one has to address tricky issues such as complex data
structures that have interlinking parts; a blind recursive deep-copy may
not have the desired effect (e.g., if we're deep-copying a graph and
there are multiple paths (via references) to the same node, then we
shouldn't end up with multiple copies of that node). Some care will also
need to be taken to deal with cyclic structures, etc.. And some
optimizations can probably be done to avoid copying immutable objects,
since that would be a waste of time&  memory.

Probably some kind of graph traversal algorithm can be used to address
these issues, I think, perhaps with the help of an AA or two to recreate
the original linking structure in the copy.


Yes, deepDup should be implementable as a library and use a temporary 
dictionary of already-duplicated items to avoid infinite recursion.


We should add that to Phobos - could you please add a task to trello.


Andrei

Re: More range woes: composed ranges are unsafe to return from functions

[Andrei Alexandrescu]

On 10/16/12 4:28 PM, jerro wrote:

On Tuesday, 16 October 2012 at 19:31:18 UTC, H. S. Teoh wrote:

On Tue, Oct 16, 2012 at 08:44:56PM +0200, monarch_dodra wrote:
[...]

No idea either, but I'll volunteer to investigate ;)

I agree with Jonathan though, sounds like a bug somewhere. There
is no reason for your code to fail.

I'll post back if I find anything.


Another data point: if I move the .joiner call out of cprod() into
main(), then there is no problem. Could it be that something in joiner
is breaking somehow, when returned from a function?


T


I don't know, but if I change the code to this:

auto cprod(R1,R2)(R1 A, R2 B) {
// This part is exactly the same as in main(), below. So
// in theory, it should work exactly the same way.
auto mapper = (typeof(tuple(cast(size_t) 0, A.front, B.front)) a) => chain(
zip(repeat(a[1]), B.save.take(a[0])),
zip(A.save.take(a[0]+1), repeat(a[2])));

auto r = zip(sequence!"n"(cast(size_t)0), A.save, B.save)
.map!mapper()
.joiner;

// But something goes wrong here: is it because the
// above composed ranges are stack-allocated temporaries
// that go out of scope upon return?
return r;
}

It works too.


My guess: there's a bug in handling the stack frame with the lambdas 
involved.


Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 3:21 PM, Jonathan M Davis wrote:

Not a bad idea, though it's still arguably a bit disgusting to potentially
have to check for that all over the place. Inevitably, most functions won't
check, and ByLine _still_ won't work. Yes, Phobos would presumably end up
checking in most cases, but I suspect that little else will.


Then "little else" should claim working with input ranges and rely on 
forward ranges semantics.



The problem is that what ByLine is doing is incredibly abnormal.


Works exactly as intended, and is eerily normal.

Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 3:07 PM, H. S. Teoh wrote:

Perhaps mark ranges with an .isTransient property


isTransient!R is exactly the same thing as isInputRange!R && 
!isForwardRange!R.


Andrei

Re: More D & Rust

[Michael]

I can't compile even hello world on both Win 7 and Win XP.

rust 0.4, latest mingw.

Re: make install; where do .di files go?

[Jacob Carlborg]

On 2012-10-17 18:42, Manu wrote:


since that basically implies that the first coming
was a failure.


That is just as sad.

--
/Jacob Carlborg

Re: make install; where do .di files go?

[Jacob Carlborg]

On 2012-10-17 16:13, Manu wrote:


Well I really, really do.
Infact, that is the single most significant thing that attracts me to
linux rather than windows. The standardised include/lib paths are an
absolute win for linux.


I completely sold how the package manager works in Ruby and together 
with Bundler. With Bundler you need to explicitly say that you want 
access to a particular package, otherwise you cannot import/include it.


This work out beautifully and you can have how many packages and 
different versions of the same package as you want, with very slim 
chance of a conflict.


--
/Jacob Carlborg

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[David Nadlinger]

On Wednesday, 17 October 2012 at 15:14:44 UTC, Andrei 
Alexandrescu wrote:
Such issues do happen, are relatively rare, and are virtually 
untested because there's been no unittests with a deliberately 
"bad" input range. Although of course we do need to add the 
appropriate fixes and unittests, I'm not worried about it at 
all systemically.


If an abstraction encourages use in a way which leads to 
hard-to-detect logic bugs that do not occur with the most common 
test cases, this is _exactly_ the thing we should be worried 
about!


David

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Wed, Oct 17, 2012 at 12:39:13PM -0400, Andrei Alexandrescu wrote:
> On 10/16/12 1:28 PM, Jonathan M Davis wrote:
> >So, it's fine that ByLine is a range as long as we're willing to put
> >up with it not working with a lot of range-based functions because of
> >its abnormal behavior. But I don't think that it's at all reasonable
> >for range-based functions in general to not be able to rely on front
> >returning the same type every time or on its value disappearing or
> >becoming invalid in some way after a call to popFront. That's
> >completely untenable IMHO.
> 
> Then what is to you the difference between an input range and a
> forward range?
[...]

So what you're saying, is that we cannot rely on the value of .front
after popFront() is called, and that the only way to ensure the validity
of .front is to use a forward range's .save, and access the saved copy's
.front?

It makes sense to me, but then we'd need to revise quite a lot of code
in Phobos, as I've seen quite a number of places where .front is cached
in some local variable or struct field, which would be invalid by your
definition.


T

-- 
This is not a sentence.

Re: Account on ARM/Debian

[David Nadlinger]

On Wednesday, 17 October 2012 at 16:24:44 UTC, Joseph Rushton 
Wakeling wrote:
Just to note, even if you're building from source it's handy to 
have a "stable release" branch alongside the latest dev.


Well, that depends on your definition of stable. LDC Git master 
is supposed always pass the CI tests, i.e. the DMD, druntime and 
Phobos test suites.


A possible extension of that would be to have a separate 
»stable« Git branch which is automatically advanced along with 
master by the CI system whenever a given revision passes all the 
tests. If somebody wants to set up a system like this, I'd be 
happy to officially adopt it.


But in my experience, anything more than that, i.e. declaring 
revisions stable based on criteria which can't be evaluated by an 
automatic test suite, is not worth it, at least for smallish 
projects like LDC. Judging whether a given state is stable by 
hand is notoriously hard to get right, and the reason we have 
beta phases before releases, etc.


David

Re: 48 hour game jam

[thedeemon]

On Wednesday, 17 October 2012 at 15:47:14 UTC, Manu wrote:


Wait up, I misread (my error message is deceiving!)
I have no idea why it would complain about the missing d3dx 
dll, unless

you're running the exe from the wrong location.
The dll is sitting right there next to the exe right, in the 
bin folder?


They sit in the same bin folder however note: it asks for d3dx9, 
not d3dx11 !

This is happening in Vista 32-bit, if that matters.

Re: make install; where do .di files go?

[Manu]

On 17 October 2012 18:39, Jordi Sayol  wrote:

> Al 17/10/12 14:03, En/na Manu ha escrit:
> >
> > why include/d2? include/d/ seems much better... what are the chances a
> library have both a d1 and d2 version which may conflict in include/d?
> >
>
> A practical example:
> Imagine that you installs the libray "foo" for D, and places the sources
> at "/usr/include/d/foo" directory, *so you need to add "-I/usr/include/d"
> as compiler argument*.
>

No, I don't need to add it as an argument, that's the point.


In Debian/Ubuntu there is the "libtango-headers" package, which install,
> among others, "/usr/include/d/object.di". This Tango "object.di" breaks d2,
> so you will not be able to compile anything with the "-I/usr/include/d"
> argument, and so, you cannot compile against your "foo" library.
>
> The problem here is that the "libtango-headers" maintainer decided to
> place "object.di" directly into "/usr/include/d", overriding to use this
> directory for any other D compiler/version.
>

Okay, so the problem is that an existing package has already declared that
directory to be a standard location. so then include/d2/ then... I guess.
Although that seems sad; D shouldn't identify its self as the second coming
of D, since that basically implies that the first coming was a failure.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 1:28 PM, Jonathan M Davis wrote:

So, it's fine that ByLine is a range as long as we're willing to put up with it
not working with a lot of range-based functions because of its abnormal
behavior. But I don't think that it's at all reasonable for range-based
functions in general to not be able to rely on front returning the same type
every time or on its value disappearing or becoming invalid in some way after
a call to popFront. That's completely untenable IMHO.


Then what is to you the difference between an input range and a forward 
range?


Andrei

Re: Account on ARM/Debian

[David Nadlinger]

On Wednesday, 17 October 2012 at 16:24:44 UTC, Joseph Rushton 
Wakeling wrote:
Just to note, even if you're building from source it's handy to 
have a "stable release" branch alongside the latest dev.


Well, that depends on your definition of stable. LDC Git master 
is supposed always pass the CI tests, i.e. the DMD, druntime and 
Phobos test suites.


A possible extension of that would be to have a separate 
»stable« Git branch which is automatically advanced along with 
master by the CI system whenever a given revision passes all the 
tests. If somebody wants to set up a system like this, I'd be 
happy to officially adopt it.


But in my experience, anything more than that, i.e. declaring 
revisions stable based on criteria which can't be evaluated by an 
automatic test suite, is not worth it, at least for smallish 
projects like LDC. Judging whether a given state is stable by 
hand is notoriously hard to get right, and the reason we have 
beta phases before releases, etc.


David

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Wed, Oct 17, 2012 at 12:22:55PM -0400, Andrei Alexandrescu wrote:
> On 10/16/12 11:17 AM, H. S. Teoh wrote:
> >OTOH, if we clearly state that .front may not persist past the next
> >popFront(), then it would be up to the caller to .dup the return
> >value, or otherwise make a safe copy of it (or use the value before
> >calling popFront()).
> >
> >The current ambiguous situation leads to one range doing one thing,
> >and another range doing something else, and either way, either this
> >code will break or that code will break.
> 
> Input ranges don't guarantee preservation of .front upon calling
> .popFront. They do allow several to .front (without an intervening
> call to .popFront) that should return the same result (i.e. a
> one-element buffer).
[...]

This is contrary to what Jonathan has been saying. So which is it:
should .front return a persistent value, or a transient value that may
get invalidated by popFront? I have been assuming it's the latter, but
others have been saying it's the former.

As Jonathan pointed out, some algorithms won't work with transient
.front values. I can think of one: findAdjacent, which requires that the
previous value of .front be preserved (otherwise you couldn't compare it
with the following element -- the template has no reliable way of saving
the previous value since we don't have a reliable way to deep-copy a
possibly complex data structure that might be getting overwritten by
popFront).

Other algorithms, like joiner, currently don't work with transient
.front values, but can be made to work by tweaking the implementation.
People will hate me for saying this, but I think Phobos algorithms
*should* be written to work with minimal expectations, so I don't
consider it unreasonable to expect std.algorithm to work with transient
.front values where possible. (User code is a different matter, of
course). There *are* cases for which it can't work, which is why I
proposed the isTransient property, but people didn't seem to like that
idea.


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 11:17 AM, H. S. Teoh wrote:

OTOH, if we clearly state that .front may not persist past the next
popFront(), then it would be up to the caller to .dup the return value,
or otherwise make a safe copy of it (or use the value before calling
popFront()).

The current ambiguous situation leads to one range doing one thing, and
another range doing something else, and either way, either this code
will break or that code will break.


Input ranges don't guarantee preservation of .front upon calling 
.popFront. They do allow several to .front (without an intervening call 
to .popFront) that should return the same result (i.e. a one-element 
buffer).


Andrei

Re: Account on ARM/Debian

[Joseph Rushton Wakeling]

On 10/17/2012 05:45 PM, David Nadlinger wrote:

I recently got an ODROID-X (4x1.4 GHz Cortex A9, 1GB RAM) for a very similar
purpose, i.e. running the LDC test suite on ARM. It's fast enough that working
on compiler development without resorting to cross-compiling is actually
somewhat fun, but I didn't get around to set it up it yet – we are cleaning
things up for an actual x86/x86_64 release right now, as some distros seem to
decisively prefer packaging releases instead of Git revisions.


Just to note, even if you're building from source it's handy to have a "stable 
release" branch alongside the latest dev.

Re: alias A = B; syntax

[Chris Nicholson-Sauls]

I would generally be pretty 'meh' on an enhancement like this, if 
not for the umpteen times I've aliased rather complex (read: 
long) types/template-instances and found myself thinking it would 
be nice for the new name to be at the (visually grep'able) 
beginning of the declaration.


Consider simple example:

alias pipe!( readText, splitLines, map!( e => e.splitter( ',' ) 
), array ) readRows;


alias readRows = pipe!( readText, splitLines, map!( e => 
e.splitter( ',' ) ), array );


So ultimately I'm happy to see the change, even if it isn't high 
on the priority list imho.


-- Chris Nicholson-Sauls

Re: How mutable is immutable?

[Timon Gehr]

On 10/17/2012 01:49 PM, Don Clugston wrote:

On 01/01/12 13:50, Timon Gehr wrote:

On 01/01/2012 10:40 AM, Denis Shelomovskij wrote:

So, I'm a function `f`, I have an `immutable(type)[]` argument and I
want to store it for my friend `g` in an TLS variable `v`:
---
string v;
debug string sure;

void f(string s) { v = s; debug sure = s.idup; }
void g() { assert(v == sure); }
---
I also store a copy of `s` into `sure` for my friend to ensure immutable
date hasn't been mutated.
Can my friend's assertion ever fail without breaking a type-system?
Sure. Just consider this:
---
void main() {
auto s = "abba".idup;
f(s);
delete s;
g();
}
---
Is it by-design? Looks like deleting immutable (and const because of
implicit conversion) data should be prohibited.
OK. Let `delete` be fixed. Can we still fail?
---
void h() {
immutable(char)[4] s = "abba";
f(s);
}
void main() {
h();
g();
}
---
Damn! So, what can we do with it? Not sure, but I have a proposal.

Fix it in language:
* disallow `delete` of const/immutable data
* disallow immutable data on the stack

This makes data really immutable if I don't miss something. Anyway, I
want `immutable` qualified data to be immutable without breaking a
type-system (if one do it, its his own responsibility), so some changes
should be made (IMHO).


You are using unsafe language features to break the type system. That is
not the fault of the type system.

'@safe:' at the top of the program should stop both examples from
working, it is a bug that it does not.


That's the point -- *which* checks are missing from @safe?


Escaping stack data and arbitrarily freeing memory are not operations
found in memory safe languages.


But I'm not sure that you're right, this looks broken to me, even
without @safe.

What does it mean to create immutable data on the stack? The stack is
intrinsically mutable!


So is the heap.

What does it mean to garbage collect immutable data?

What does it mean to allocate an 'int' on the stack?


What does it mean to delete immutable data?


Deallocate the storage for it and make it available for reuse.
Accessing it afterwards leads to arbitrary behaviour. This is the same
with mutable data. As the program may behave arbitrarily in this case,
it is valid behaviour to act as if immutable data changed.


I think it's reasonable for both of them to require a cast, even in
@system code.



The implementation of the 'scope' storage class should be fixed. We 
could then require an unsafe cast(scope) to disable prevention of stack 
address escaping. Rust's borrowed pointers may give some hints on how

to extend 'scope' to fields of structs.

As to delete, delete is as unsafe when the involved data is immutable
as when it is mutable. Why require an additional cast in one case?

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Wednesday, October 17, 2012 11:17:08 Andrei Alexandrescu wrote:
> I think integration of pure streams within ranges is important and
> beneficial.

The problem isn't that it's a stream. The problem is that it reuses the buffer 
that it returns, which is great for efficiency but horrible for algorithms 
which 
actually try and use it as a range. Having to worry about front being 
invalidated after a call to popFront would be a big problem - especially when 
that's not at all normal behavior. And in many cases, you _can't_ code 
algorithms in a way that supports that (e.g. if it needs to compare the result 
of two subsequent calls to front). Having to worry about such ranges is just 
going to complicate things even more. We already have enough issues with 
special cases as it is - like save not being called because reference type 
ranges are so rare, and least that's actually part of the range API, whereas 
the idea that front could be invalidated really isn't.

- Jonathan M Davis

Re: make install; where do .di files go?

[Jordi Sayol]

Al 17/10/12 14:03, En/na Manu ha escrit:
> 
> why include/d2? include/d/ seems much better... what are the chances a 
> library have both a d1 and d2 version which may conflict in include/d?
> 

A practical example:
Imagine that you installs the libray "foo" for D, and places the sources at 
"/usr/include/d/foo" directory, so you need to add "-I/usr/include/d" as 
compiler argument.

In Debian/Ubuntu there is the "libtango-headers" package, which install, among 
others, "/usr/include/d/object.di". This Tango "object.di" breaks d2, so you 
will not be able to compile anything with the "-I/usr/include/d" argument, and 
so, you cannot compile against your "foo" library.

The problem here is that the "libtango-headers" maintainer decided to place 
"object.di" directly into "/usr/include/d", overriding to use this directory 
for any other D compiler/version.

-- 
Jordi Sayol

Re: Account on ARM/Debian

[David Nadlinger]

On Monday, 15 October 2012 at 17:05:00 UTC, Andrei Alexandrescu 
wrote:
I've been talking to Iain Buclaw, gdc's leader, and was 
surprised to learn he has a quite workable ARM port available. 
To make it production-ready, we should have some continuous 
test integration, which entails ssh access to an ARM/Debian 
account.


Is there anyone on this list who'd want to donate such an 
account?


I recently got an ODROID-X (4x1.4 GHz Cortex A9, 1GB RAM) for a 
very similar purpose, i.e. running the LDC test suite on ARM. 
It's fast enough that working on compiler development without 
resorting to cross-compiling is actually somewhat fun, but I 
didn't get around to set it up it yet – we are cleaning things 
up for an actual x86/x86_64 release right now, as some distros 
seem to decisively prefer packaging releases instead of Git 
revisions.


It would likely be always on, albeit behind a somewhat broken 
router, so you'd have to use a VPN for outside access. Also, I'm 
not quite sure how the tiny box would handle the pressure from 
both GDC and LDC.


Anyway, Iain, if the Raspberry PI offers don't work out, feel 
free to give me a shout.


David

Re: 48 hour game jam

[thedeemon]

On Monday, 15 October 2012 at 14:47:06 UTC, Manu wrote:

Ah, nicely spotted, I should stick that DLL in the zip now that 
you mention it.


I've just tried running this version:
https://github.com/downloads/RemedyGameJam/stache/Stache-Windows-0.1d.zip

It cannot run asking for d3dx9_43.dll and then says "failed to 
load Fuji_Debug.dll".

Re: Account on ARM/Debian

[Johannes Pfau]

Am Tue, 16 Oct 2012 08:17:36 -0700
schrieb Walter Bright :

> 
> Once you guys get this up on the Rasp, it would be great to write up
> a brief "cookbook" page on how to get a D program running on it.

http://gdcproject.org/wiki/Raspberry%20Pi
http://gdcproject.org/wiki/Raspberry%20Pi/build/Raspbian%28Hardfloat%29

I think we could provide compiler binaries instead which should make
the whole process a lot easier. And a simple "Hello World" tutorial
could be added as well.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Wed, Oct 17, 2012 at 11:17:08AM -0400, Andrei Alexandrescu wrote:
> On 10/16/12 1:59 AM, Jonathan M Davis wrote:
> >On Monday, October 15, 2012 22:48:15 Jonathan M Davis wrote:
> >>So, I don't really know what the right answer is, but I _really_
> >>don't like the idea of having to worry about the result of front
> >>changing after a call to popFront in every single function that ever
> >>uses front. In the general case, I just don't see how that's
> >>tenable. I'd _much_ rather that it be up to the programmer using
> >>abnormal ranges such as ByLine to use them correctly.
> >
> >And actually, it seems to me that issues like this make it look like
> >it was a mistake to make ranges like ByLine ranges in the first
> >place. They should have just defined opApply so that they'd work
> >nicely in foreach but not with range- based functions. They're
> >clearly not going to work with a _lot_ of range-based functions.
> 
> I think integration of pure streams within ranges is important and
> beneficial.
[...]

I agree, and I think that's what makes ranges such a powerful concept.
I'd hate to lose it just over implementation details like popFront()
pulling the carpet from under a few functions that assume the
persistence of what .front returns. I'd much rather live with an
isTransient property (which is only needed in a very few cases, and only
needs to be checked in a handful of places where the dependence matters,
and so is not a big inconvenience at all), than to devolve into Java's
wrapper upon adapter upon wrapper design.


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit 
forever.

Re: Account on ARM/Debian

[Johannes Pfau]

Am Wed, 17 Oct 2012 13:56:58 +0200
schrieb "mist" :

> "not at that stage" means there are some probability-based issues 
> with codegen or some major blocker that prevents from even 
> trying? I'd really like to try some kind of proof-of-concept 
> GDC/ARM kernel-level stuff.
> 

Issue 120 was the biggest blocker for now. The fix still isn't merged
yet (my fault, I'll try to finish it this week). All other bugs which
happen on ARM, but not on x86(32 bit) are filed in the gdc bug
tracker( 
http://gdcproject.org/bugzilla/buglist.cgi?list_id=78&resolution=---&query_format=advanced&rep_platform=ARM&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&component=gdc&product=GDC
).
Some are just bugs in the compiler test suite.
#10 is a real issue but it should be an issue on x86 as well.
#8 is the evaluation order problem that has been discussed on the NG. I
guess it'll take some time till this is finished, but usually it
shouldn't cause problems.
#7 is an optimizer/codegen bug and needs further investigation.

But all in all, the compiler is in a good shape. Phobos / Druntime are
completely untested though (we can't run the unittests with GDC right
now, IIRC)

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 1:59 AM, Jonathan M Davis wrote:

On Monday, October 15, 2012 22:48:15 Jonathan M Davis wrote:

So, I don't really know what the right answer is, but I _really_ don't like
the idea of having to worry about the result of front changing after a call
to popFront in every single function that ever uses front. In the general
case, I just don't see how that's tenable. I'd _much_ rather that it be up
to the programmer using abnormal ranges such as ByLine to use them
correctly.


And actually, it seems to me that issues like this make it look like it was a
mistake to make ranges like ByLine ranges in the first place. They should have
just defined opApply so that they'd work nicely in foreach but not with range-
based functions. They're clearly not going to work with a _lot_ of range-based
functions.


I think integration of pure streams within ranges is important and 
beneficial.


Andrei

Re: Import improvement

[Andrei Alexandrescu]

On 10/16/12 2:49 AM, Jacob Carlborg wrote:

On 2012-10-16 02:10, Peter Alexander wrote:


It's cute, but I think it is terribly misleading. I wouldn't recommend
that to anyone.


I agree. I'm using foo.bar._, that's the same used by Scala.


Sounds good. Arbitrary + precedent > arbitrary.

Andrei

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 1:09 AM, H. S. Teoh wrote:

The scary thing is, I see similar code like this all over Phobos. Does
this mean that most of std.algorithm may need to be revised to address
this issue? At the very least, it would seem that a code audit is in
order to weed out this particular issue.


Such issues do happen, are relatively rare, and are virtually untested 
because there's been no unittests with a deliberately "bad" input range. 
Although of course we do need to add the appropriate fixes and 
unittests, I'm not worried about it at all systemically.


Andrei

Re: alias A = B; syntax

[Andrei Alexandrescu]

On 10/16/12 1:08 AM, Andrej Mitrovic wrote:

On 10/16/12, Jonathan M Davis  wrote:

We'd have to dig through the newsgroup archives


Nah just ask Andrei he already confirmed this once.


And I confirm again.

https://github.com/D-Programming-Language/dmd/pull/1187#issuecomment-9526522

Andrei

Re: Add these to Phobos?

[Andrei Alexandrescu]

On 10/15/12 10:35 PM, Mehrdad wrote:

On Tuesday, 16 October 2012 at 01:47:58 UTC, Jonathan M Davis wrote:

It should probably explain the rationale behind returning SortedRange
so that it's much clearer as to why you'd want to use the return value
rather than the original (now sorted) range.



+1

As it stands it's not at all clear from the documentation what the
intention is, or how someone can go about sorting something without
mutating it.

Thanks for the responses.


Agreed. Part of the problem was that at the time I changed sort to 
return a value (it used to return void), severe compiler bugs forced me 
to take it out again for a while. So it's been "experimental" until it 
just silently started working and I forgot about it; and you know how 
documentation of experimental work goes...


Regarding sorted(), one possibility would be to define a lazy sorting 
routine under that name or lazySort(). It would make for a better name 
than heap(), which implements the desired functionality.



Andrei

Re: Add these to Phobos?

[Andrei Alexandrescu]

On 10/15/12 9:47 PM, Jonathan M Davis wrote:

And if SortedRange is changed to provide access to its underlying range via a
member named source (it was recently suggested by Andrei that we should
standardize on doing that where appropriate), then it could become a one-
liner:

auto result = sort(array(range)).source;


Yes, I think we should move toward the ".source" convention for all 
applicable ranges, e.g. retro.source yields the original range etc.


Andrei

Re: Import improvement

[Andrei Alexandrescu]

On 10/15/12 9:30 PM, 1100110 wrote:

I like what vibe.d did by having an import all file named d.d

Therefore you can:
import vibe.d;

It's nice, it's clean, and I've blatantly stolen it for a few of my own
projects.



O_O .. That might be one of the worst things I've ever seen!
It doesn't even make sense. Is there actually a vibe.d file? And why
try to
make the import statement look like a source filename?


There is a source/vibe/d.d file.
The reason it is there is because vibe.d includes it's own main(),
There is a source/vibe/vibe.d file, but that is there for you to roll
your own main().

Shrug. "import file.d;" <- actual name is file.d
doesn't work, and it isn't designed to work like that. So unless you
know nothing about how the import
system works, it's not really a problem.

And I would assume that it was done since the name of the project is
"vibe.d".

If this is the worst thing that you've seen, then I don't think you've
seen golang.. Or javascript's underscore library...
"_.each([1, 2, 3], function(num){ alert(num); });
=> alerts each number in turn...
_.each({one : 1, two : 2, three : 3}, function(num, key){ alert(num); });
=> alerts each number in turn..."

That might be one of the worst, most confusing things that I've seen.


Wondering what happens if one has a file called something.d.d and 
imports it as something.d.


Andrei

Re: Add these to Phobos?

[Andrei Alexandrescu]

On 10/15/12 9:29 PM, Mehrdad wrote:

Hmm, I didn't know 'sort' returns a value. That's very confusing
since now I have no idea if it's mutating or not. Python has both
sort and sorted, with clear meanings. (The goal was to make a
non-mutating version that I could call functional.) Maybe we
should clarify what sort exactly does and doesn't do...


std.algorithm operates in place wherever possible, and sort's result is 
a view on the same range as the original, but with new capabilities 
created by the sorting process. I think it's a very elegant design.


Andrei

Re: Cartesian product of infinite ranges, round 2

[Andrei Alexandrescu]

On 10/15/12 8:46 PM, H. S. Teoh wrote:

Thanks to an idea by Andrei, I now have an implementation of the
Cartesian product of two infinite ranges that requires only forward
ranges.

However, I'm running into an array-out-of-bounds problem with
std.algorithm.joiner, and I don't know how to reduce the code to track
down the problem. Here's the code:

[snip]

I'm traveling with little time to spare, but one visible thing is that 
the limit of the iteration (25) spills into the result. May be easiest 
to track things starting from that observation.


Andrei

Re: Add these to Phobos?

[Andrei Alexandrescu]

On 10/15/12 7:39 PM, Mehrdad wrote:

On Monday, 15 October 2012 at 22:35:41 UTC, Andrei Alexandrescu wrote:

On 10/15/12 5:35 PM, Mehrdad wrote:

I think we need something like these in Phobos -- I was quite surprised
that I didn't find these in Phobos. They're really handy in Python.

[snip]

Ideas?


Yes, I wanted to add some relational operators forever! There's a
group() function in std.algorithm but doesn't offer a range of ranges.

Andrei


+1 yeah, group() was useless for me. I wanted to group consecutive items
together by some criterion, which it (ironically) explicitly doesn't do.


It's not ironic, it's intentional. In libraries such as Scala's you 
specify GroupBy with whatever predicate against an arbitrary stream, and 
it takes care of all the intermediate data structures (e.g. hashes, 
arrays) and/or additional operations (sorting).


In D, there's a strong emphasis of explicit costs and benefits, so to 
group by an arbitrary key you'd first sort by that key and then use the 
"dumb group" that only knows how to group on adjacent entries.


I'm not sure which approach is best, but I tend to think the current 
approach is a better fit for D's general ethos.



Andrei

Re: Shared keyword and the GC?

[deadalnix]

Why not definitively adopt the following (and already proposed) memory 
scheme (some practice are now considered valid when this scheme is not 
respected) :


Thread local head (one by thread) -> shared heap -> immutable heap

This model have multiple benefices :
 - TL heap only can be processed by only interacting with one thread.
 - immutable head can be collected 100% concurently if we allow some 
floating garbage.
 - shared heap is the only problem, but as its size stay small, the 
problem stay small.

Re: 48 hour game jam

[Manu]

On 17 October 2012 17:08, Jacob Carlborg  wrote:

> On 2012-10-17 13:57, Manu wrote:
>
>  It occurred to me last night, I think almost all the work to get OSX
>> running is actually already done in the iPhone drivers. You might be
>> better off to copy the iPhone files, and adapt that to OSX. Ethan seems
>> to think iPhone and OSX are almost identical.
>>
>
> They are fairly similar. I'll have a look at the iPhone driver when I get
> home tonight. If you want the game to look as a proper Mac OS X application
> there are some additional code that is required. That is for creating the
> main menu and the dock icon.
>
> Anyway, I know how to handle this now.


Okay, awesome. Cheers.
I got it running on Linux-x64 last night, so I think that's the only thing
holding OSX back.

Re: make install; where do .di files go?

[Manu]

On 17 October 2012 17:09, Jacob Carlborg  wrote:

> On 2012-10-17 14:08, Manu wrote:
>
>  What about C: Nominate a place, just like C does??
>> I don't see the problem. Where is the essential difference from
>> system-wide installed C libraries?
>>
>
> I don't like that approach used by C.


Well I really, really do.
Infact, that is the single most significant thing that attracts me to linux
rather than windows. The standardised include/lib paths are an absolute win
for linux.

Re: 48 hour game jam

[Jacob Carlborg]

On 2012-10-17 13:57, Manu wrote:


It occurred to me last night, I think almost all the work to get OSX
running is actually already done in the iPhone drivers. You might be
better off to copy the iPhone files, and adapt that to OSX. Ethan seems
to think iPhone and OSX are almost identical.


They are fairly similar. I'll have a look at the iPhone driver when I 
get home tonight. If you want the game to look as a proper Mac OS X 
application there are some additional code that is required. That is for 
creating the main menu and the dock icon.


Anyway, I know how to handle this now.

--
/Jacob Carlborg

Re: make install; where do .di files go?

[Jacob Carlborg]

On 2012-10-17 14:08, Manu wrote:


What about C: Nominate a place, just like C does??
I don't see the problem. Where is the essential difference from
system-wide installed C libraries?


I don't like that approach used by C.

--
/Jacob Carlborg

Re: Feature request: enum init shouldn't create a new enumeration

[Daniel Murphy]

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

"Tommi"  wrote in message 
news:ozvdphftlwxkeumrn...@forum.dlang.org...
> On Monday, 15 October 2012 at 08:25:18 UTC, Tommi wrote:
>> in reality, it's very easy to write a bug that makes an enum variable 
>> have an invalid value. E.g:
>
> Writing that bug wasn't as easy as I thought though. Here's the code with 
> a bug:
>
> enum MyEnum { first, second, third }
>
> auto me = MyEnum.min;
>
> while (me <= MyEnum.max)
> {
> // do something
> ++me;
> }
>
> final switch (me) // this should throw
> {
> case MyEnum.first:  break;
> case MyEnum.second: break;
> case MyEnum.third:  break;
> }
>
> Instead, currently this code runs just fine, none of the switch cases are 
> taken. So, this bug might manifest itself very far from where it actually 
> should have been throwing: on that final switch expression. Thus hunting 
> this bug down could be tedious. 

Re: isInfinite isInadequate

[monarch_dodra]

On Wednesday, 17 October 2012 at 12:45:07 UTC, Peter Alexander 
wrote:
On Wednesday, 17 October 2012 at 12:33:54 UTC, monarch_dodra 
wrote:
Technically, cycle([]) *is* isInfinite, but the program will 
assert because of a run-time error due to the user's logic. 
Nobody said that just because a range is infinite, that it 
can't ever fail...


cycle([]) is not infinite. A infinitely repeated empty range is 
the empty range.


I'd argue that cycle should be redefined as "Repeats the 
*content* of the given forward range ad infinitum." From there, 
passing it an empty range would be a logic error, since said 
range didn't have any content.

Re: isInfinite isInadequate

[Peter Alexander]

On Wednesday, 17 October 2012 at 12:33:54 UTC, monarch_dodra 
wrote:
Technically, cycle([]) *is* isInfinite, but the program will 
assert because of a run-time error due to the user's logic. 
Nobody said that just because a range is infinite, that it 
can't ever fail...


cycle([]) is not infinite. A infinitely repeated empty range is 
the empty range.

Re: Strange Loop 2012

[Philippe Sigaud]

On Wed, Oct 17, 2012 at 4:54 AM, bearophile  wrote:
>>
>> https://raw.github.com/psnively/types_vs_tests/master/src/main/scala/Shapeless.scala
>
>
> If this is equivalent, then in D it was too much easy:

Why not use integral template parameters directly? And checking if all
params are between 0 and 9, of course. The user syntax would then be
cleaner:

void main() {
static assert(!isValid!(0, 1)());
static assert( isValid!(3, 4, 5, 8, 8, 2, 8, 6, 5)());
static assert( isValid!(1, 2, 3, 4, 5, 6, 7, 8, 9)());
}

And, of course, there is no need for templates at all. A standard,
compile-time interpreted function could do it for you:

void main() {
static assert(!isValid(0, 1));
static assert( isValid(3, 4, 5, 8, 8, 2, 8, 6, 5));
static assert( isValid(1, 2, 3, 4, 5, 6, 7, 8, 9));
}

Re: isInfinite isInadequate

[monarch_dodra]

On Wednesday, 17 October 2012 at 12:18:32 UTC, Peter Alexander 
wrote:
So, std.range.isInfinite checks if r.empty is a compile time 
boolean equal to false. This works most of the time, but not 
always. Some ranges are infinite, but cannot be determined to 
be so at compile time (or even run time!)


cycle([1, 2, 3]).until(4);// infinite, but not isInfinite
cycle(new int[0]);// not infinite, but isInfinite
collatzSequence(n).until(1);  // infiniteness an open problem!

In short, isInfinite does not -- and cannot -- work as a way of 
telling if a range is finite or infinite in general.


On resolution is to take isInfinite at face value: it only 
tells you if a range is statically determined to be infinite. 
If isInfinite is false, it could still be infinite.


This leaves us with the tricky cases like cycle(new int[0]). 
There's three resolutions to this (as far as I can tell):


1. Change cycle to not be an infinite range.
2. Make cycle assert when the source range is empty.
3. Ignore this issue.

Option 1 is sound, but kind of sucks, because generally cycle 
is infinite.


Option 2 is sound, but I don't like the idea of asserting on 
logically valid input just because the problem is too hard.


Option 3 is not sound, but may be practical. Perhaps these 
edge-case, fake, infinite sequences are not worth worrying 
about -- just let it slide and make other people worry about 
the consequences.


This Phobos pull request is relevant: 
https://github.com/D-Programming-Language/phobos/pull/871


Thoughts?



cycle(new int[0]);// not infinite, but isInfinite
2. Make cycle assert when the source range is empty.


Technically, while cycle does not assert, it will fail on the 
first call to front, either because of a divide by 0 (RA: 
index%length), or because of a call to an empty front.


We should add an assert. IMO.


TBH, I do not see either as being a problem:

Technically, cycle([]) *is* isInfinite, but the program will 
assert because of a run-time error due to the user's logic. 
Nobody said that just because a range is infinite, that it can't 
ever fail...


Ranges that go on forever, but are not *isInfinite*. My stance on 
this point is that it is not a *big* problem either. I see it 
more as a runtime "infinite loop", rather than an compile time 
"infinite range". It's like a for loop where the run-time end 
condition will always be true.


That said, if the user *does* know the range will be infinite, I 
wouldn't be against having an "assumeInfinite" template function, 
that can take any range, and transform into an (assumed) compile 
time infinite range.

isInfinite isInadequate

[Peter Alexander]

So, std.range.isInfinite checks if r.empty is a compile time 
boolean equal to false. This works most of the time, but not 
always. Some ranges are infinite, but cannot be determined to be 
so at compile time (or even run time!)


cycle([1, 2, 3]).until(4);// infinite, but not isInfinite
cycle(new int[0]);// not infinite, but isInfinite
collatzSequence(n).until(1);  // infiniteness an open problem!

In short, isInfinite does not -- and cannot -- work as a way of 
telling if a range is finite or infinite in general.


On resolution is to take isInfinite at face value: it only tells 
you if a range is statically determined to be infinite. If 
isInfinite is false, it could still be infinite.


This leaves us with the tricky cases like cycle(new int[0]). 
There's three resolutions to this (as far as I can tell):


1. Change cycle to not be an infinite range.
2. Make cycle assert when the source range is empty.
3. Ignore this issue.

Option 1 is sound, but kind of sucks, because generally cycle is 
infinite.


Option 2 is sound, but I don't like the idea of asserting on 
logically valid input just because the problem is too hard.


Option 3 is not sound, but may be practical. Perhaps these 
edge-case, fake, infinite sequences are not worth worrying about 
-- just let it slide and make other people worry about the 
consequences.


This Phobos pull request is relevant: 
https://github.com/D-Programming-Language/phobos/pull/871


Thoughts?

Re: make install; where do .di files go?

[Manu]

On 17 October 2012 12:28, Nick Sabalausky <
seewebsitetocontac...@semitwist.com> wrote:

> On Tue, 16 Oct 2012 14:56:02 -0700
> "H. S. Teoh"  wrote:
>
> > On Tue, Oct 16, 2012 at 05:45:07PM -0400, Nick Sabalausky wrote:
> > > On Tue, 16 Oct 2012 14:00:32 -0700
> > > "H. S. Teoh"  wrote:
> > >
> > > > On Tue, Oct 16, 2012 at 04:37:32PM -0400, Nick Sabalausky wrote:
> > > > > On Tue, 16 Oct 2012 17:48:54 +0200 Jordi Sayol
> > > > >  wrote:
> > > > > >
> > > > > > Linux dmd will not include /usr/include/d path by default to
> > > > > > avoid conflicts with ldc1 (tango) "object.di" incompatibility,
> > > > > > and I recommend you to not use this path for that reason.
> > > > > >
> > > > >
> > > > > Then we can use '/usr/include/d2'. Problem solved ;)
> > > >
> > > > I propose /usr/include/d/${version}/. It will make it possible for
> > > > multiple versions of dmd to coexist, as well as eliminate version
> > > > incompatibility problems (or at least make them very unlikely).
> > > >
> > > > Mixing everything in /usr/include/d (or /usr/include/d2) with the
> > > > fact that dmd releases have been incompatible with older
> > > > druntime/phobos is just asking for trouble.
> > > >
> > >
> > > If by ${version} you mean 2.059, 2.060, etc., then I don't like
> > > that. I don't want to have to have the same library installed
> > > separately for every version of DMD on my system. That's just a
> > > mess.
> >
> > If you have multiple versions of DMD sharing the same /usr/include/d,
> > that's even more of a mess.
> >
> > Of course, ideally, when you upgrade DMD it will also uninstall the
> > older stuff so that you don't have like 50 stale copies of
> > druntime/phobos after upgrading 50 times. That's something for the
> > package manager to take care of. :-P
> >
>
> Well, if you're talking about phobos/druntime, then I agree since those
> are tied to the compiler they come with. But I was talking about third
> party libs. I think it may be good to keep a separation for D1 libs vs
> D2 libs, but not (for example) 2.059 vs 2.060 (except, of course, for
> phobos and druntime).
>
> Of course, I'm not sure separate 2.059 vs 2.060 (etc...) dirs for
> third-party libs would even work at all, because how are you going to
> tell (for example) a .deb file which compiler's dir to install
> into? Give your lib a separate .deb for each version of DMD?
> "dlibfoobar-dmd-2.059.deb", "dlibfoobar-dmd-2.060.deb"...etc?
>
> >
> > > A way to have multiple versions of the same lib would be good
> > > though. Although that's one of the reasons I prefer to just use -I
> > > instead of messing with system-wide installation anyway.
> >
> > How else would you have multiple versions of the same lib, though?
> > They can't all live in the same place since files will conflict.
> >
>
> Unfortunately, I see only two realistic possibilities:
>
> A. Forget about system-wide lib installation and pass -I... to the
> compiler for each lib you're using. Kind of a pain but...
>
> B. Wait for a proper D package manager.
>
> Personally, I choose "A", at least for the time being ;)
>

What about C: Nominate a place, just like C does??
I don't see the problem. Where is the essential difference from system-wide
installed C libraries?

Re: make install; where do .di files go?

[Manu]

On 17 October 2012 11:48, Jordi Sayol  wrote:

> Al 16/10/12 22:37, En/na Nick Sabalausky ha escrit:
> >> Linux dmd deb/rpm packages installs "/etc/dmd.conf" file which
> >> contains the modules/interfaces paths. The easiest way to add another
> >> path for your library in Linux is to create a "pkg-config" file.
> >
> > Would that be Debian-specific though?
>
> This is Linux and C specific.
> In debian/Ubuntu/LinuxMint, with "libgtk-3-dev" and "pkg-config" packages
> installed, just type:
> $ pkg-config --cflags --libs gtk+-3.0
> You'll get all the sources, libraries and some flags that gcc needs to
> properly compile gtk projects.
>
> >> Linux dmd will not include /usr/include/d path by default to avoid
> >> conflicts with ldc1 (tango) "object.di" incompatibility, and I
> >> recommend you to not use this path for that reason.
> >>
> >
> > Then we can use '/usr/include/d2'. Problem solved ;)
> >
>
> Is a possibility, but it must be agreed.
>

Well let's attempt to begin that process in that case :)

why include/d2? include/d/ seems much better... what are the chances a
library have both a d1 and d2 version which may conflict in include/d?

Re: Account on ARM/Debian

[mist]

"not at that stage" means there are some probability-based issues 
with codegen or some major blocker that prevents from even 
trying? I'd really like to try some kind of proof-of-concept 
GDC/ARM kernel-level stuff.


I don't think we're at that stage yet.  What would be 
appreciated
would be for testers to report back on any codegen issues.   I 
should

be able to make GDC ARM binaries available for download.

Re: 48 hour game jam

[Manu]

On 17 October 2012 09:35, Jacob Carlborg  wrote:

> On 2012-10-16 19:57, Ethan wrote:
>
>> I'm just going to throw it out there that you don't actually need to
>> touch Objective-C at all. Cocoa/Foundation/all those Objective-C
>> interfaces sit on top of something known as Core Foundation, which are C
>> APIs. The pointers used by Core Foundation can generally be used as
>> Objective-C objects of the same type as well.
>>
>
> That's not entirely correct. Most of the types in Core Foundation are a
> toll free bridge to the corresponding Objective-C types in the Foundation
> framework. But all the GUI related classes, i.e. AppKit, are not available
> in the same way.
>
>
>  It would be handy to have a D binding to all the Core- libraries on OSX.
>> I might do that myself when I get my Mac if such a binding doesn't
>> already exist. The book should be equally applicable for iOS as well,
>> but last time I was in iOS land I was still a newbie to the whole OSX
>> programming thing.
>>
>
> If you're going to write GUI applications on Mac OS X you need to interact
> with the Objective-C frameworks. The reason for this is that, as stated
> above, AppKit is only available from Objective-C and you really need to be
> able to create your own Objective-C classes and subclasses.
>
> There are two ways to interact with Objective-C
>
> * Create an Objective-C/D bridge
> * Make D binary compilable with Objective-C
>
> The Objective-C/D bridge would use the Objective-C runtime functions
> defined in C to interact with Objective-C. Every time an object is passed
> over the bridge it needs to be encapsulated or de-encapsulated. Another
> problem is the code/template bloat. A Hello World application will be
> around 60MB in size. This has already been done:
>
> http://www.dsource.org/**projects/dstep
>
> The other approach would be to make D binary compaitable with Objective-C,
> that is, provide extern (Objective-C) declarations. This would generate
> basically the same code as the Objective-C compiler would, but with the
> nice syntax of D instead of the horrible syntax that Objective-C is. This
> would also allow you do create bindings to Objective-C classes, methods and
> functions just as with C.
>
> The problem with this approach, it's a lot of work to modify the compiler.
> But that has already been done as well:
>
> http://michelf.ca/projects/d-**objc/ 
>
> This fork of DMD isn't ready yet (there's an alpha available) and there
> hasn't been any changes made in over a year. If I recall correctly, Michel
> Fortin said he hasn't got the time now to work on this. It also the problem
> with always playing catchup with the upstream version of DMD.


It occurred to me last night, I think almost all the work to get OSX
running is actually already done in the iPhone drivers. You might be better
off to copy the iPhone files, and adapt that to OSX. Ethan seems to think
iPhone and OSX are almost identical.